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.
--
Axel.Thimm at
ATrpms.net