[et-mgmt-tools] Looping through possibilities in a "snippet"

[Michael DeHaan]

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