On Tue, 5 Apr 2011 13:39:38 -0700, Walker Traylor walker@mog.com wrote:
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. foo.app.dev.example.com). 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?
On Tue, Apr 5, 2011 at 2:18 PM, Scott Henson shenson@redhat.com wrote:
On Tue, 5 Apr 2011 13:39:38 -0700, Walker Traylor walker@mog.com wrote:
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. foo.app.dev.example.com). 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?
My problem with ksmeta is that it ends up being a dumping ground for a myriad of meta-information. It would be preferable to have information specific to a config management system clearly identified and separated out, similar to the way network interfaces are expanded.
It also doesn't help that the WebUI and CLI parse changes to ksmeta completely differently, and updating a system through the WebUI is liable to break even a moderately complex use of ksmeta.
---Brett.
On Tue, 5 Apr 2011 14:24:32 -0700, brett lentz brett.lentz@gmail.com wrote:
My problem with ksmeta is that it ends up being a dumping ground for a myriad of meta-information. It would be preferable to have information specific to a config management system clearly identified and separated out, similar to the way network interfaces are expanded.
True, but breaking out this one field doesn't really help the situation much.
It also doesn't help that the WebUI and CLI parse changes to ksmeta completely differently, and updating a system through the WebUI is liable to break even a moderately complex use of ksmeta.
This, we should probably fix. Can you give me an example of what happens?
On Tue, Apr 5, 2011 at 3:15 PM, Scott Henson shenson@redhat.com wrote:
On Tue, 5 Apr 2011 14:24:32 -0700, brett lentz brett.lentz@gmail.com wrote:
My problem with ksmeta is that it ends up being a dumping ground for a myriad of meta-information. It would be preferable to have information specific to a config management system clearly identified and separated out, similar to the way network interfaces are expanded.
True, but breaking out this one field doesn't really help the situation much.
Rome wasn't built in a day. ;-)
I see this as an incremental process of obtaining feedback of what ksmeta is used for, and making a decision of whether ksmeta is the right place, or if a better home for it can be found/built.
It also doesn't help that the WebUI and CLI parse changes to ksmeta completely differently, and updating a system through the WebUI is liable to break even a moderately complex use of ksmeta.
This, we should probably fix. Can you give me an example of what happens?
My ksmeta for one profile looks like this:
ks_meta : somevar=foo othervar=0 autofs_master=foo.auto.master zabbix_server=10.0.0.1,::ffff:10.0.0.1,10.0.0.2,::ffff:10.0.0.2 ntp_servers=10.0.0.3 xen=false tree=http://@@http_server@@/cblr/links/CentOS-5.3-x86_64 zabbix_proxy_server=10.1.0.1 puppet_server=puppetmaster.prod.loc.domain.com anothervar=0 ldap_servers=ldap://ldap01.prod.loc.domain.com:1234,ldap://ldap02.prod.loc.domain.com:1234 morevars=['foo', 'bar', 'baz']
So... the problem is, where ever there are quotes, or multiple variables in an array, or a comma-separated list... the WebUI displays this in a form that, if it's submitted without editing, is parsed *completely* differently. The commas end up causing half of the value from one variable to be stored as a totally new and distinct variable.
In short, it makes the WebUI only useful in a read-only context.
On Tue, 5 Apr 2011 15:39:34 -0700, brett lentz brett.lentz@gmail.com wrote:
On Tue, Apr 5, 2011 at 3:15 PM, Scott Henson shenson@redhat.com wrote:
On Tue, 5 Apr 2011 14:24:32 -0700, brett lentz brett.lentz@gmail.com wrote:
My problem with ksmeta is that it ends up being a dumping ground for a myriad of meta-information. It would be preferable to have information specific to a config management system clearly identified and separated out, similar to the way network interfaces are expanded.
True, but breaking out this one field doesn't really help the situation much.
Rome wasn't built in a day. ;-)
I see this as an incremental process of obtaining feedback of what ksmeta is used for, and making a decision of whether ksmeta is the right place, or if a better home for it can be found/built.
True. It sounds like something reasonable to bring into cobbler. I think it also sounds reasonable to have a mgmt_parameters along with it? That way you could (theoretically) store all information from puppet's external nodes in puppet pretty easily. Correct me if I'm wrong.
It also doesn't help that the WebUI and CLI parse changes to ksmeta completely differently, and updating a system through the WebUI is liable to break even a moderately complex use of ksmeta.
This, we should probably fix. Can you give me an example of what happens?
My ksmeta for one profile looks like this:
ks_meta : somevar=foo othervar=0 autofs_master=foo.auto.master zabbix_server=10.0.0.1,::ffff:10.0.0.1,10.0.0.2,::ffff:10.0.0.2 ntp_servers=10.0.0.3 xen=false tree=http://@@http_server@@/cblr/links/CentOS-5.3-x86_64 zabbix_proxy_server=10.1.0.1 puppet_server=puppetmaster.prod.loc.domain.com anothervar=0 ldap_servers=ldap://ldap01.prod.loc.domain.com:1234,ldap://ldap02.prod.loc.domain.com:1234 morevars=['foo', 'bar', 'baz']
So... the problem is, where ever there are quotes, or multiple variables in an array, or a comma-separated list... the WebUI displays this in a form that, if it's submitted without editing, is parsed *completely* differently. The commas end up causing half of the value from one variable to be stored as a totally new and distinct variable.
In short, it makes the WebUI only useful in a read-only context.
Would it work if we output valid yaml into that field and then only accepted valid yaml back? It feels to me that the format we are using isn't particularly deterministic on parsing. Yaml would fix that. Thoughts?
On Wed, Apr 6, 2011 at 10:07 AM, Scott Henson shenson@redhat.com wrote:
On Tue, 5 Apr 2011 15:39:34 -0700, brett lentz brett.lentz@gmail.com wrote:
On Tue, Apr 5, 2011 at 3:15 PM, Scott Henson shenson@redhat.com wrote:
On Tue, 5 Apr 2011 14:24:32 -0700, brett lentz brett.lentz@gmail.com wrote:
My problem with ksmeta is that it ends up being a dumping ground for a myriad of meta-information. It would be preferable to have information specific to a config management system clearly identified and separated out, similar to the way network interfaces are expanded.
True, but breaking out this one field doesn't really help the situation much.
Rome wasn't built in a day. ;-)
I see this as an incremental process of obtaining feedback of what ksmeta is used for, and making a decision of whether ksmeta is the right place, or if a better home for it can be found/built.
True. It sounds like something reasonable to bring into cobbler. I think it also sounds reasonable to have a mgmt_parameters along with it? That way you could (theoretically) store all information from puppet's external nodes in puppet pretty easily. Correct me if I'm wrong.
It also doesn't help that the WebUI and CLI parse changes to ksmeta completely differently, and updating a system through the WebUI is liable to break even a moderately complex use of ksmeta.
This, we should probably fix. Can you give me an example of what happens?
My ksmeta for one profile looks like this:
ks_meta : somevar=foo othervar=0 autofs_master=foo.auto.master zabbix_server=10.0.0.1,::ffff:10.0.0.1,10.0.0.2,::ffff:10.0.0.2 ntp_servers=10.0.0.3 xen=false tree=http://@@http_server@@/cblr/links/CentOS-5.3-x86_64 zabbix_proxy_server=10.1.0.1 puppet_server=puppetmaster.prod.loc.domain.com anothervar=0 ldap_servers=ldap://ldap01.prod.loc.domain.com:1234,ldap://ldap02.prod.loc.domain.com:1234 morevars=['foo', 'bar', 'baz']
So... the problem is, where ever there are quotes, or multiple variables in an array, or a comma-separated list... the WebUI displays this in a form that, if it's submitted without editing, is parsed *completely* differently. The commas end up causing half of the value from one variable to be stored as a totally new and distinct variable.
In short, it makes the WebUI only useful in a read-only context.
Would it work if we output valid yaml into that field and then only accepted valid yaml back? It feels to me that the format we are using isn't particularly deterministic on parsing. Yaml would fix that. Thoughts?
Display and requiring valid yaml or json is probably adequate and a lot easier than most alternatives. This would work for me.
---Brett.
cobbler-devel@lists.fedorahosted.org
-
brett lentz -
Scott Henson