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
pgpekND3Sg67h.pgp
Description: PGP signature
_______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
