Sandor W. Sklar wrote:
On Apr 7, 2008, at 8:42 AM, Michael DeHaan wrote:
Sandor W. Sklar wrote:
I would probably solve the problem of sourcing the packages list from
an external file in a different way...
Hi, Michael,
Thanks; I hadn't thought of doing it that way. I'd prefer that the
cobbler-rendered kickstarts were "complete", but it seems that this is
a good workaround that accomplishes what I'm trying to do.
I'll file an RFE on exploring it this way.
Knowing very little of python (guess I'm going to have to crack a book
some day), can I assume that doing what I originally hoped for would
be too awkward? ( I use that word instead of "not possible", because
the Perl that I know has let me to understand that nothing is
impossible! :-)
Kinda, in general a template that tries to test for existance of a file
on the filesystem starts being more "code" than template. That can get
scary, as you've seen. Cheetah does allow blurring that line, but I like
keeping the template files as "data" for basic string substitution and
not pushing it that far.
This isn't to say we can't achieve a similar solution in Cobbler itself,
that may be more elegant than either option. I'll open up a RFE on this
to see what the options are -- things that allow someone to edit
kickstarts /less/ would be good, and I can see something like this even
being presented in the UI.
We could have cobbler automatically include content from
/var/lib/cobbler/packages_list/profiles/$name and
/var/lib/cobbler/packages_list/systems/$name every time we sync if we
wanted to. We do have the question then of what gets appended to a list
or what gets used /instead/, and which use case is more important. I can
kind of see cases for both.
Ideally one wouldn't be assigning specific packages to specific systems,
as the point of a profile is to make a configuration available to all
things that look "like" something. Can you explain your use case for
assigning specific packages to specific systems?
Thoughts on how that should work?
I do like this idea a lot...
--Michael
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools