On Mon, Jan 05, 2009 at 04:31:22PM -0500, Michael DeHaan wrote:
> Dan Guernsey wrote:
>
>> I think he's just asking for the value passed to --inherit in:
>> cobbler profile add ... --inherit=...
>> during profile creation.
>> He also wants a way to access (include, SNIPPET, whatever) the kickstart
>> for the parent profile.
>>
>> I guess this is to avoid having to 'synchronize inheritance' between
>> profiles and corresponding kickstart templates. For instance, using the
>> tree given by Alex earlier:
>>
>> # cobbler list
>> distro f10-x86_64
>> profile f10-x86_64
>> profile desktop-f10-x86_64
>> system prospero
>> profile server-f10-x86_64
>> profile webserver-f10-x86_64
>> system shylock
>>
>> The kickstart for profile webserver-f10-x86_64 could look like this:
>>
>> ## Child specific variables, defs, and other kickstart stuff
>> ...
>> $SNIPPET($inheritsks)
>> ...
>> ## More child specifics
>>
>> Instead of:
>>
>> ## Child specific stuff
>> ...
>> $SNIPPET('server-f10-x86_64.ks') ## Making assumptions about the ks
filename
>> ...
>> ## More
>>
>> With this setup, if the profile tree is modified (ie. the --inherit
>> property is changed), the $SNIPPET(...) line won't need to be changed.
>> I think this feature would be simple to add to cobbler, either:
>> Add a variable allowing templates to access properties of the
>> profile via an object (this may already exist. I haven't kept up with
>> development):
>> $SNIPPET(profile.inherits.ksfile)
>> --or--
>> Add a variable containing the name of the parent ksfile:
>> $SNIPPET(inheritsks)
>> --or--
>> Add a command that snippets the parent profile:
>> $parentSNIPPET()
>>
>> I think the top option is the most flexible, but may require excessive
>> modification.
>> The only purpose of the third option would be to hide the filename of
>> the parent's ksfile.
>> The second option is probably the simplest and should satisfy Axel's
>> request.
>>
>>
> Ok, that makes some more sense -- however it does introduce the
> complexity in many ways of ensuring that the parents are not
> installable, or that you're using pykickstart
> to do blending.
>
Why not installable? See my other post.
> I really don't want to go there for various reasons --the main reason is
> that pykickstart's forwards compatibility does not exist -- a RHEL 4
> cobbler server would choke on trying
> to render something for RHEL 5.
>
> Also, certain pre/post magic seems to make it want to flip out.
>
> Ultimately it introduces a design complexity that I don't wish to have.
>
All that is needed is to have a variable like ksparents that points to
the parent's unrendered kickstart file on disk.
------------------------------------------------------------------------
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
Perhaps you could Cheetah include the parent kickstart on disk also?
That's "#include"
--Michael.