I did implement the first approach: change the variable name to something different. The problem is that I have to check all the calls to hiera_hash that are located at parameter scope to prevent that behavior...
I would keep the parametrized class in order to be able to modify its data with tools as foreman (until I find a better way through ENC). On Thursday, May 2, 2013 6:02:43 PM UTC+2, Nan Liu wrote: > > On Thu, May 2, 2013 at 10:32 AM, David Campos > <[email protected]<javascript:> > > wrote: > >> Hello all, >> >> I don't know if I have hit a strange bug or it's just an incorrect >> interpretation about how parameter autoloading works... Today I have been >> searching, analysing and about to hit my head against a wall trying to >> figure out why a call to hiera_hash was not merging data from top level >> among different hierarchies. The problem was that I was trying to do >> something like this: >> >> class jenkins::slave ( >> $client = hiera_hash("jenkins::slave::client"), >> $connection = hiera_hash("jenkins::slave::connection"), >> $config = hiera_hash("jenkins::slave::config"), >> $security = hiera_hash("jenkins::slave::security")) { >> >> >> My idea was as simple as to retrieve data from 4 hashes and later on work >> with that data but with the advantage to have that data defined into a >> lower level (a sort of common class or project hierarchies) and refine at >> leafs. All did compile and run smoothly but the results were not what I >> expected. Leafs did have preference but they did set the whole value, no >> merge was being done on top level variables that were not being defined at >> leaf hierarchy (or the one that first made a match). Hashes were acting as >> priority scope: first hit -> return. >> >> After playing with lower classes, reinstalling, trying older versions and >> including a lot of extra loggers I did try a desperate attempt without >> hope: change one of the variables name into something different from other >> classes (it did happen that jenkins::slave::config did conflict with >> another class but that class was being processed and the variable and class >> should be different kinds)... >> >> class jenkins::slave ( >> $client = hiera_hash("jenkins::slave::client"), >> $connection = hiera_hash("jenkins::slave::connection"), >> $slave_config = hiera_hash("jenkins::slave::config"), >> >> $security = hiera_hash("jenkins::slave::security")) { >> >> >> And magic happened! $slave_config variable was doing merge but not the >> others! I did not understand why the others were not working (they were not >> colliding with anything in my code) but then a voice came to my mind... >> Puppet 3.x did include a new feature, parameter autoload through hiera... >> And it works... But removes the explicit functionality that was my call to >> hiera_hash! >> >> Is that behavior correct? Is it a bug? >> > > It's behaving as specified, but unfortunately a bit retarded for your use > case. If you translate your manifests per specification of what Puppet 3 is > implicitly doing, it's a bit clearer why it behaves that way: > > #whoops, use hiera results > class jenkins::slave ( > $config = hiera('jenkins::slave::config', > hiera_hash("jenkins::slave::config")), > ) { > > #uses hiera_hash since slave_config does not exist. > class jenkins::slave ( > $slave_config = hiera('jenkins::slave::slave_config', > hiera_hash("jenkins::slave::config")), > ) { > > I guess either change heira variable and use something like > jenkins::slave::config_hash or avoid the implicit lookup by declaring the > variable inside the class. > > class jenkins::slave ( > $config = hiera_hash("jenkins::slave::config_hash"), > ) { > > class jenkins::slave { > $config = hiera_hash("jenkins::slave::config") > > Nan > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" 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-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
