David Campos
2013-May-02 15:32 UTC
[Puppet Users] Puppet 3.1.1, hiera and parameter autoload
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?
--
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 puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Nan Liu
2013-May-02 16:02 UTC
Re: [Puppet Users] Puppet 3.1.1, hiera and parameter autoload
On Thu, May 2, 2013 at 10:32 AM, David Campos <noymn.the.archangel@gmail.com> 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 puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
David Campos
2013-May-03 07:15 UTC
Re: [Puppet Users] Puppet 3.1.1, hiera and parameter autoload
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 <noymn.the...@gmail.com<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 puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.