On Mon, Oct 26, 2009 at 12:16 PM, R.I.Pienaar <[email protected]> wrote: > > hello, > > ----- "Luke Kanies" <[email protected]> wrote: > >> On Oct 26, 2009, at 11:40 AM, R.I.Pienaar wrote: >> >> > >> > hello, >> > >> > ----- "Markus Roberts" <[email protected]> wrote: >> > >> >> * Sites that need this functionality can set up a starting >> >> environment >> >> for nodes that only pushes the configuration file, and the >> >> configuration file can be a template filled in with the >> appropriate >> >> external_node parameters. This will require an extra cycle for new >> >> nodes and for existing nodes when their environment changes at >> such >> >> sites, but would not require any code changes or have any impact >> on >> >> sites that don't need it. >> > >> > I'd say this should be the last resort, I've seen several places >> > that changes a machines environment fairly often, during maintenance >> >> > periods for example. >> > >> > Forcing the environment change to only happen after another run >> > would be very bad for them. >> > >> >> * Change puppet to request the node information from the server >> >> before >> >> anything else (e.g. before plugins). This would have a small >> overhead >> >> for all puppet runs and necessitate a moderately small code >> change. >> > >> > nice. >> > >> >> * Change the default environment on the client to a special "ask >> the >> >> server" environment. Clients that specified an environment in >> their >> >> configuration or on the command line would use that environment. >> >> Clients that did not specify an environment would request it from >> the >> >> server, imposing a small overhead only for machines that needed >> it. >> >> This would require a somewhat larger code change. >> > >> > Even nicer. I assume we can then specify on the server the default >> > environment that all unconfigured nodes would end up in? This would >> > be very nice indeed. >> >> Yes. The "somewhat larger" code change part, though, is both more >> code and decent bit more complexity - having values vary based on >> client vs. server is annoyingly complicated. > > > But it isn't really different behavior from what we had in 0.24.x so I think > there's an expectation. I can see how it's a pain code wise though. > >> >> > Keeping in mind that it is also very desirable to be able to set the >> > environment via a fact. >> >> Hmm. Using facts complicates things even further, because it's >> another way for the client to specify the environment. Why do you >> want to be able to do that? > > machines know where they are and in what environment they are, it seems a > logical extension. I've never seen this documented as something that should > work, but always been glad it does :)
That's exactly it for us. Setting it via a fact allows users to switch their machine from the "stable" environment to the "testing" or "unstable" environments. We allow users to set this value on the machine as either a debconf value or a plist key. We asked for this feature quite a way back, around 0.22.x I think? I'd hate to see this go away.... > > I think Nigel use this method extensively as well, and it does work with > 0.25.1rc2 > >> The next question becomes, do we need to do this for 0.25.1? I would >> tend to say no, we ship 0.25.1 nowish (because it's ready), and only >> do this for either a 0.25.2 if we produce one, or rowlf. > > I think 0.25.1 should get out there quick as we can really, and if we go for > the above there'll be a lot of code changes, not the kind of thing to do at > rc2 stage imho. > > > -- > R.I.Pienaar > > > > -- nigel --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
