On Thu, May 2, 2013 at 10:32 AM, David Campos <[email protected]
> 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.
