Puppet users - Nov 2012 - puppet 3 + hiera + "cross modules references"

Hello,
I''m trying to figure out how I can use puppet 3 & hiera in an
efficient way.

Let''s say that I''ve two classes:
class foo ( $param ) {
   notify {"foo": message => "value is ${foo::param}"}
}
class bar ( $param ) {
   notify {"bar": message => "value is ${bar::param}"}
}

My hiera file looks like:
---
foo::param: value
bar::param: value

Everything works fine with node:
node mynode {
     include foo
     include bar
}

Now, let''s imagine that I need bar::param to have same value than 
foo::param. One way could be to update both of them. But then I need to 
make sure that they''re always synced. Not so good.

The other way should be to put foo::param as bar::param value, like:
---
foo::param: value
bar::param: %{foo::param}

This works, if and only if I include class foo in my node recipe.
Of course I still could set bar class as follow:
class bar ($param = hiera(''foo::param'')) { ... }

But, in that case, it introduced a dependency between both classes.
And when classes comes from different modules, this is not always the 
desired behavior.

What I would like to do is making hiera resolves "reference" and 
automatically retrieve foo::param value, even if foo class is not included.
Use case could be to define some global value like web application 
parameters like hostname which should be defined globally and used when 
needed.

Any comment welcomed.
Regards,
Jean Baptiste

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Friday, November 2, 2012 5:42:24 AM UTC-5, JB wrote:
>
> Hello, 
> I''m trying to figure out how I can use puppet 3 & hiera in an
efficient
> way. 
>
> Let''s say that I''ve two classes: 
> class foo ( $param ) { 
>    notify {"foo": message => "value is
${foo::param}"}
> } 
> class bar ( $param ) { 
>    notify {"bar": message => "value is
${bar::param}"}
> } 
>
> My hiera file looks like: 
> --- 
> foo::param: value 
> bar::param: value 
>
> Everything works fine with node: 
> node mynode { 
>      include foo 
>      include bar 
> } 
>
> Now, let''s imagine that I need bar::param to have same value than 
> foo::param. One way could be to update both of them. But then I need to 
> make sure that they''re always synced. Not so good. 
>
> The other way should be to put foo::param as bar::param value, like: 
> --- 
> foo::param: value 
> bar::param: %{foo::param} 
>
> This works, if and only if I include class foo in my node recipe. 
> Of course I still could set bar class as follow: 
> class bar ($param = hiera(''foo::param'')) { ... } 
>
> But, in that case, it introduced a dependency between both classes. 
> And when classes comes from different modules, this is not always the 
> desired behavior. 
>

There are some important question to answer here to determine the best 
course of action:

   1. why are the values for foo::param and bar::param the same?  If it is 
   circumstantial or coincidental, then squeezing out the duplication is 
   probably harmful rather than helpful.  In that case I would recommend just 
   having duplicate data
   2. Supposing that there is a functional reason why the two parameters 
   are the same, the next question is who owns the data?  If one of the 
   classes is the logical owner, then it is *right* for the other to depend 
   on it.

If the data are fundamentally the same, but neither class can reasonably be 
construed as its owner, then it ought to be given to some third entity on 
which both the others can rely.  That "entity" might be an actual
class, or
it might just be a separate logical namespace for the Hiera key.
 
>
> What I would like to do is making hiera resolves "reference" and 
> automatically retrieve foo::param value, even if foo class is not 
> included. 
>

I think that''s a bad idea because it hides the logical relationship
among
your classes in your data instead of making it evident in your classes.

If you insist on pursuing such a course, however, then you should 
investigate whether the underlying YAML parser supports YAML 1.2.  That 
version of YAML has a built-in mechanism for aliasing data elsewhere in a 
document, which should accomplish what you seek.  Think again, though.

 
> Use case could be to define some global value like web application 
> parameters like hostname which should be defined globally and used when 
> needed. 
>

That sort of thing really ought to be pulled out to its own class.  Example:

class webapp::server {
  # Note: hides the $::hostname fact
  $hostname = hiera(''webapp::server::hostname'')
}

class webapp::app1 {
  include ''webapp::server''
  # use $webapp::server::hostname ...
}

class webapp::app2 {
  include ''webapp::server''
  # use $webapp::server::hostname ...
}



John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/ZHH45apeUL0J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.