Hi Grégory, Thanks for looking into this. If I'm understanding correctly, you are seeing this issue with data bindings, but I'm not certain if you are also seeing it with the hiera functions. Could you produce a simple reproduction case (or cases depending on how many things are affected by this problem) so that we are all on the same page here?
On Sun, Mar 10, 2013 at 4:26 AM, Grégory Oestreicher <[email protected]> wrote: > Hi all, > > I'm writing to the list after asking on IRC and getting no answers about an > issue I found. > > It seems that there's a bug when trying to use Hiera with environments. When a > Hiera key is queried the environment is always set to 'production', no matter > which one the node is set in. I'm not using an ENC but declaring the > environment in puppet.conf on the agent side. > I can believe that we have some problems with environment. There are a lot of different places that it gets set in the code and some of the values have turned out to be red-herrings. > Looking into the issue here's what I found. In puppet/resource.rb:321 (in > Puppet::Resource#lookup_external_default_for) the scope object is used to > initialize a Puppet::DataBinding::Variables, and from then on > scope['environment'] will be used to access the environment. However this > never returns the value of the current node env, which is rightly returned > when using scope.environment.to_s. > That is troubling. If the scope does not return the correct environment, then the $environment variable in manifests will also not be correct. > I've started to look into Puppet::Parser::Scope and others to find where and > how the environment is initialized, but my Ruby skill are measly and I > couldn't get very far. As I needed this working quickly the workaround I did > was to patch Puppet::Parser::Scope#lookupvar to return 'environment.name.to_s' > when the requested key is 'environment' or '::environment'. Ugly, but it > works. > Thank you for working on this and sharing what you found. Would you be able to work with us to come up with a complete fix for this? > If this bug is not known or fixed I'll happily create a new report for it. > A quick search on Redmine brought up: * http://projects.puppetlabs.com/issues/19396 * http://projects.puppetlabs.com/issues/16275 I wonder how far this rabbit hole goes.... Andy > Cheers, > Grégory > > PS: here's the ugly patch > > --- parser/scope.rb.orig 2013-03-10 11:23:45.000000000 +0000 > +++ parser/scope.rb 2013-03-08 14:25:38.000000000 +0000 > @@ -261,7 +261,9 @@ > options[:origin] = self unless options[:origin] > table = ephemeral?(name) ? @ephemeral.last : @symtable > > - if name =~ /^(.*)::(.+)$/ > + if name == 'environment' or name == '::environment' > + environment.name.to_s > + elsif name =~ /^(.*)::(.+)$/ > begin > qualified_scope($1).lookupvar($2, options.merge({:origin => nil})) > rescue RuntimeError => e > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/puppet-dev?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
