Axel Thimm wrote:
> 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
> [email protected]
> https://fedorahosted.org/mailman/listinfo/cobbler
>
Perhaps you could Cheetah include the parent kickstart on disk also?
That's "#include"
--Michael.
_______________________________________________
cobbler mailing list
[email protected]
https://fedorahosted.org/mailman/listinfo/cobbler
