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

[Michael DeHaan]

Sandor W. Sklar wrote:
>
> On Apr 7, 2008, at 9:13 AM, Michael DeHaan wrote:
>>
>> 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.
>
> Agreed. Also keep in mind that I used "packages" as an example; I'm 
> hoping to use the same method with the disk partitioning section of 
> the ks, as well as the post section (and, I guess, for the pre section 
> as well; always forget about that one. :-)

Yes, so really about groups of snippets then. I follow. Sounds cleaner too!

This may get close to what Aaron was referring to earlier today also -- 
not sure.

>>
>>
>> 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?
>
> Good question. I agree that it would be rare to have something 
> assigned on a "system" basis, as opposed to a profile. That said, I've 
> taken responsibility for setting up the Cobbler environment for my 
> team of sysadmins, and I guess I'm just anticipating the probability 
> that one of them would say, "what if I want X, Y, and Z only for one 
> system, and I don't want to make a separate profile." Fairly contrived 
> example, I think, but I won't be surprised to have it posed to me. :-)
>
Yes, that definitely happens... I can see that being more useful in a 
general context if we don't just apply it to packages. (For instance,
this system has storage that is just /slightly/ off) ... at least 
conceptually.

>>
>> Thoughts on how that should work?
>
> Well, in my "perfect" world, I kind of like the pseudo-code from my 
> original email, but I understand the desire to keep more complex code 
> out of what should be a template. I guess, if you start with the idea 
> that a proper kickstart file has four "official" sections[1] (command, 
> %packages, %pre, %post), it would make sense to maybe have each of 
> those items defined as standard cobbler profile metadata; doing so 
> would completely modularize kickstart generation.
>

What if we changed the semantics of...

SNIPPET::foosball

which would now be smart and would pull one of the following, whichever 
exists first:

/var/lib/cobbler/snippets/system/foosball/$system_name
/var/lib/cobbler/snippets/profile/foosball/$profile_name
/var/lib/cobbler/snippets/distro/foosball/$distro_name
/var/lib/cobbler/snippets/foosball

whichever was found first.

I think this is what you're getting at and could be done fairly cleanly 
without being package specific.

Of course the stock install would lay down none of these paths except 
the directories and this would largely be just documented
if you decide to use it (on the Wiki).

--Michael