Scott,
Thank you for your reply.
It would be very similar to the way classes are implemented in cobbler, using the
--mgmt-classes flag. The only difference is that the environment data is not a list, it
is just one field. Also in contrast, the parameters passed to puppet (via --ksmeta)
returns a key value array in YAML format. So, environment is another format, and the
simplest.
Check out this for sample YAML that puppet expects for classes, environment, and
parameters:
http://docs.puppetlabs.com/guides/external_nodes.html
Look in the box under "External node scripts for version 0.23 and later"
A --mgmt-environment flag would be my preferred method, for consistency, ie:
#cobbler system add
mysystem.mog.com --mgmt-environment="dev"
--mgmt-classes="base webserver devusers"
The functionality that this provides, is puppet can be configured to serve up puppet
manifests from different directory trees depending on "environment." This is
a big deal to us because we are using puppet to manage production systems, yet also doing
lots of class development for more variable boxes. One wrong move on the production
scripts could kill everything (wrong nslookup, user, etc.) but I need to be able to hack
on those with plenty of leeway for trial and error in our development deployment
environment. The work around is run multiple puppet instances on different ports, but
that is messy and now we have this nice feature in puppet built in to support this - may
as well use it.
Let me know if you have any other questions, or how else I may support this.
In our setup we implemented environments as part of the hostname
(e.g.
). Then we put an override in the
parameters section. Basically have a key called environment in the
ksmeta that would be able to override the default set by dns. I don't
have a problem with what you are asking for, I'm just not sure if it is
needed given that you can put it in ksmeta. Do you see some reason?
--
Scott Henson
Red Hat CIS Operator
WVU Alum BSAE/BSME