It would be handy to set the environment of a puppet client with the
$environment fact regardless of the version of said client.
Currently the puppetmaster prefers the ''environment''
configuration
option over the $environment fact, causing behavior to diverge between
<0.24 and <=0.24 clients. Since <0.24 clients don''t have a
default
value for that configuration option, the fact is authoritative.
However, the >=0.24 clients set a default for the configuration option
(''development''), making the fact moot.
The most straight forward solution would be to have the puppetmaster
always prefer the $environment fact.
Is there an argument for the configuration option taking precedence
over the fact? Is it worth the added complexity of only preferring the
fact if the configuration option hasn''t been set explicitly?
-P
On Feb 7, 2008, at 1:07 PM, Philip Walls wrote:> It would be handy to set the environment of a puppet client with the > $environment fact regardless of the version of said client. > > Currently the puppetmaster prefers the ''environment'' configuration > option over the $environment fact, causing behavior to diverge between > <0.24 and <=0.24 clients. Since <0.24 clients don''t have a default > value for that configuration option, the fact is authoritative. > However, the >=0.24 clients set a default for the configuration option > (''development''), making the fact moot. > > The most straight forward solution would be to have the puppetmaster > always prefer the $environment fact. > > Is there an argument for the configuration option taking precedence > over the fact? Is it worth the added complexity of only preferring the > fact if the configuration option hasn''t been set explicitly?Yeah -- pluginsync is affected by the environment, and client facts are not available to the server during this phase of the configuration. It would obviously be straightforward to add a setting that allowed us to configure this on the server, but I can''t really decide if that''s a good idea or not. Maybe it could be a temporary option, with a deprecation notice or something; I wouldn''t want it to stay around forever. Anyone else have an opinion? -- Puritanism: The haunting fear that someone, somewhere, may be happy. -- H. L. Mencken --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke,
I just looked into this a bit further, and it seems that the
modifications necessary would actually be entirely client side. The
client currently sets the "environment" fact (in
networking/client/master.rb) to whatever the configuration value is
and passes that to the server during the catalog generation phase.
Previously I was assuming that the configuration values were passed
independently of facts (eg. options{} in puppet/node.rb), but it
appears that this isn''t the case. For example, options[:environment]
(referenced several times in puppet/node.rb to determine the correct
environment) appears to always be empty on a 0.24.1 server, even when
connecting from a 0.24.1 client. When I modify a 0.24.1 client not to
override the environment fact with the configuration option, the
environment is selected based on that fact. This seemingly confirms my
suspicion.
-P
On Feb 7, 2008 12:32 PM, Luke Kanies <luke@madstop.com>
wrote:>
> On Feb 7, 2008, at 1:07 PM, Philip Walls wrote:
>
> > It would be handy to set the environment of a puppet client with the
> > $environment fact regardless of the version of said client.
> >
> > Currently the puppetmaster prefers the ''environment''
configuration
> > option over the $environment fact, causing behavior to diverge between
> > <0.24 and <=0.24 clients. Since <0.24 clients don''t
have a default
> > value for that configuration option, the fact is authoritative.
> > However, the >=0.24 clients set a default for the configuration
option
> > (''development''), making the fact moot.
> >
> > The most straight forward solution would be to have the puppetmaster
> > always prefer the $environment fact.
> >
> > Is there an argument for the configuration option taking precedence
> > over the fact? Is it worth the added complexity of only preferring the
> > fact if the configuration option hasn''t been set explicitly?
>
>
> Yeah -- pluginsync is affected by the environment, and client facts
> are not available to the server during this phase of the configuration.
>
> It would obviously be straightforward to add a setting that allowed us
> to configure this on the server, but I can''t really decide if
that''s a
> good idea or not. Maybe it could be a temporary option, with a
> deprecation notice or something; I wouldn''t want it to stay around
> forever.
>
> Anyone else have an opinion?
>
> --
> Puritanism: The haunting fear that someone, somewhere, may be happy.
> -- H. L. Mencken
> ---------------------------------------------------------------------
> Luke Kanies | http://reductivelabs.com | http://madstop.com
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>
For reference, here''s the simple patch I used against my 0.24.1 client that prevents it from overriding the environment fact with the configuration value if one has been set by the facter. On Feb 7, 2008 3:59 PM, Philip Walls <pawalls@google.com> wrote:> Luke, > > I just looked into this a bit further, and it seems that the > modifications necessary would actually be entirely client side. The > client currently sets the "environment" fact (in > networking/client/master.rb) to whatever the configuration value is > and passes that to the server during the catalog generation phase. > > Previously I was assuming that the configuration values were passed > independently of facts (eg. options{} in puppet/node.rb), but it > appears that this isn''t the case. For example, options[:environment] > (referenced several times in puppet/node.rb to determine the correct > environment) appears to always be empty on a 0.24.1 server, even when > connecting from a 0.24.1 client. When I modify a 0.24.1 client not to > override the environment fact with the configuration option, the > environment is selected based on that fact. This seemingly confirms my > suspicion. > > -P > > > On Feb 7, 2008 12:32 PM, Luke Kanies <luke@madstop.com> wrote: > > > > On Feb 7, 2008, at 1:07 PM, Philip Walls wrote: > > > > > It would be handy to set the environment of a puppet client with the > > > $environment fact regardless of the version of said client. > > > > > > Currently the puppetmaster prefers the ''environment'' configuration > > > option over the $environment fact, causing behavior to diverge between > > > <0.24 and <=0.24 clients. Since <0.24 clients don''t have a default > > > value for that configuration option, the fact is authoritative. > > > However, the >=0.24 clients set a default for the configuration option > > > (''development''), making the fact moot. > > > > > > The most straight forward solution would be to have the puppetmaster > > > always prefer the $environment fact. > > > > > > Is there an argument for the configuration option taking precedence > > > over the fact? Is it worth the added complexity of only preferring the > > > fact if the configuration option hasn''t been set explicitly? > > > > > > Yeah -- pluginsync is affected by the environment, and client facts > > are not available to the server during this phase of the configuration. > > > > It would obviously be straightforward to add a setting that allowed us > > to configure this on the server, but I can''t really decide if that''s a > > good idea or not. Maybe it could be a temporary option, with a > > deprecation notice or something; I wouldn''t want it to stay around > > forever. > > > > Anyone else have an opinion? > > > > -- > > Puritanism: The haunting fear that someone, somewhere, may be happy. > > -- H. L. Mencken > > --------------------------------------------------------------------- > > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > > _______________________________________________ > > Puppet-users mailing list > > Puppet-users@madstop.com > > https://mail.madstop.com/mailman/listinfo/puppet-users > > >_______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Feb 7, 2008, at 5:59 PM, Philip Walls wrote:> Luke, > > I just looked into this a bit further, and it seems that the > modifications necessary would actually be entirely client side. The > client currently sets the "environment" fact (in > networking/client/master.rb) to whatever the configuration value is > and passes that to the server during the catalog generation phase.Huh, you''re right. I''m not really sure if this was intentional, but I guess I''d accept a patch that preferred a fact to the setting.> > Previously I was assuming that the configuration values were passed > independently of facts (eg. options{} in puppet/node.rb), but it > appears that this isn''t the case. For example, options[:environment] > (referenced several times in puppet/node.rb to determine the correct > environment) appears to always be empty on a 0.24.1 server, even when > connecting from a 0.24.1 client. When I modify a 0.24.1 client not to > override the environment fact with the configuration option, the > environment is selected based on that fact. This seemingly confirms my > suspicion.Overall, I''m pretty flexible about how this works, I guess, but note that we''re in a kind of strange in-between state right now. The current network interface doesn''t actually support specifying the client environment, so the only way to get it is from the facts. This will be fixed in 0.25, when the interfaces will be improved considerably. -- Nature and nature''s laws lay hid in night, God said, "Let Newton be," and all was light. It did not last; the devil howling "Ho! Let Einstein be!" restored the status quo. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke, The patch should be attached to my most recent email (Feb 7, 2008 4:22 PM PST). Let me know if you need me to resend. On Feb 13, 2008 6:08 AM, Luke Kanies <luke@madstop.com> wrote:> On Feb 7, 2008, at 5:59 PM, Philip Walls wrote: > > > Luke, > > > > I just looked into this a bit further, and it seems that the > > modifications necessary would actually be entirely client side. The > > client currently sets the "environment" fact (in > > networking/client/master.rb) to whatever the configuration value is > > and passes that to the server during the catalog generation phase. > > Huh, you''re right. I''m not really sure if this was intentional, but I > guess I''d accept a patch that preferred a fact to the setting. > > > > > Previously I was assuming that the configuration values were passed > > independently of facts (eg. options{} in puppet/node.rb), but it > > appears that this isn''t the case. For example, options[:environment] > > (referenced several times in puppet/node.rb to determine the correct > > environment) appears to always be empty on a 0.24.1 server, even when > > connecting from a 0.24.1 client. When I modify a 0.24.1 client not to > > override the environment fact with the configuration option, the > > environment is selected based on that fact. This seemingly confirms my > > suspicion. > > > Overall, I''m pretty flexible about how this works, I guess, but note > that we''re in a kind of strange in-between state right now. The > current network interface doesn''t actually support specifying the > client environment, so the only way to get it is from the facts. > > This will be fixed in 0.25, when the interfaces will be improved > considerably. > > -- > Nature and nature''s laws lay hid in night, > God said, "Let Newton be," and all was light. > > It did not last; the devil howling "Ho! > Let Einstein be!" restored the status quo. > > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
On Feb 13, 2008, at 12:47 PM, Philip Walls wrote:> Luke, > > The patch should be attached to my most recent email (Feb 7, 2008 4:22 > PM PST). Let me know if you need me to resend.Can you file it as an enhancement request, with patch attached? I''d love to see tests validating the change in behaviour, of course. -- Anyone who considers arithmatical methods of producing random digits is, of course, in a state of sin. --John Von Neumann --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke, Per your request, I submitted a bug with attached patch and test case at http://reductivelabs.com/trac/puppet/ticket/1078 Thank you for the prompt, helpful responses. -P On Wed, Feb 13, 2008 at 11:23 AM, Luke Kanies <luke@madstop.com> wrote:> On Feb 13, 2008, at 12:47 PM, Philip Walls wrote: > > > Luke, > > > > > The patch should be attached to my most recent email (Feb 7, 2008 4:22 > > PM PST). Let me know if you need me to resend. > > > Can you file it as an enhancement request, with patch attached? > > I''d love to see tests validating the change in behaviour, of course. > > -- > Anyone who considers arithmatical methods of producing random digits > is, of course, in a state of sin. --John Von Neumann > > > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >