I would be very happy to see a seamless/lazy/magic approach to using
variables. Something similar to what Al quoted seems nice: I'd like to
be able to have the option to feed values to variables in different
places (of which one will take precedence over the other, and you
preferrably add a value only in one place) and then use that variable
in the module itself. That would make reuse of modules by others so
much nicer as they wouldn't be tied to using whatever your environment
looks like that you developed the modules for.
I guess it would look much like facter: it just provides values, but
hides where it got the values for those variables from. As Nigel
pointed out, data needs to be moved to outside manifests, and hiera
seems like a good tool for it.
Walter
On Sun, Jan 15, 2012 at 10:42, Alessandro Franceschi <a...@lab42.it> wrote:
>
>
> On Sunday, January 15, 2012 12:41:50 AM UTC+1, Nigel Kersten wrote:
>>
>>
>>
>> What would it take for you to just have one source of truth for data
>> Alessandro?
>>
>> e.g. what would we have to change about Puppet for us to simply use Hiera
>> ?
>>
>> We're looking to integrate Hiera into Puppet for Telly, and in general
>> moving data outside of manifests has a lot of benefits, but I'm interested
>> to know whether you're of a similar mind with regard to the data you're
>> considering.
>
>
> Nigel,
> first of all do consider that I don't exclude Hiera's use in this approach.
> It's a choice, you can use Hiera to assign values to top scope variables or
> directly when you call parametrized classes, actually where and how you give
> values to variables is not forced by the module.
> The reason why I didn't place hiera lookups directly in the module is that
> these "nextgen" modules are supposed to work for Puppet > 2.6 and not
> everybody might want to use it or have integrated Hiera in their setup, but
> if the same modules can provide out of the box whatever is needed to work
> seamlessly, I've no problems with that. (see third point).
>
> Second point is that some variables, which are typically module's internal
> variables (names, paths and so on), should be IMHO provided by the module
> itself (the typical stuff for params class), to give some extra value (cross
> operating system support) to the module and preserve the user from providing
> this kind of common and preset data.
> I do present also these variables as class parameters because I need a quick
> way to pour all the modules variables (both "internal like these and the
> ones the module's users is likely to provide) to some place on the target
> system (for the puppi stuff, but actually once you have them in a yaml file
> you can use them in other ways). To do this I use Ken's neat get_class_vars
> () function.
> At the same time there are some rare cases when a user may need to supply
> these variables (for example paths and names for a custom package), so it's
> not bad to have them as parameters available in the class.
>
> Third point is that actually I would love to use Hiera directly in the
> module (or better something that fallbacks to Hiera... see below) if there
> would be a backend that permits something like what Dan has suggested me
> (sorry for public quoting Dan, but I think your suggestions deserves wider
> attention):
>
> ---QUOTE----
>
> Instead of having to code all of the logic for how to perform the lookups
> for all of the data in the params namespace(this is a lot of code!), I
> would recommend using hiera (or another function) and coding the class
> inclusion, and data lookup precedence in a custom backend.
>
> I have a feeling that if you do a good enough job on the backend, it could
> just become the default puppet hiera backend.
>
> I imagine it working something like this:
>
> when looking up a variable $var
>
> class foo::bar (
> $var = als_hiera($var)
> ) {
>
> }
>
> It does the followins:
> - if the parameter was set in the class declaration, that always wins
> (this is just how Puppet works)
> - if an explicit class parameter was not set, the hiera function is
> called, and does the following:
> 1. Look for a variable called $::foo_var ($::${module_name}_var)
> 2. Look for a variable called $::var
>
> I like this capability of being able to set common behaviors across modules
> with a single topscope variable, I do think this needs to be configurable
> somehow:
>
> $var = als_hiera($var, {'topscope_lookup' => false})
>
> since this pattern may not be desirable for certain parameters
>
> 3. If the class params::foo (::params::${module_name} exists, include it and
> look for the variable:
>
> ::params::foo::var
>
> 4. if the class ::foo::params (:$module_name::params) exists, include it and
> lookup the value of the variable:
>
> ::foo::params::var
>
> --- QUOTE ----
>
> To this I might add that it would be nice to have the option to set a
> default value if none is provided in the above sources:
> var = als_hiera($var, {'default' => "mydefault"})
>
>
> So, to reply to your question, Nigel, something like a hiera backend or a
> Puppet function that does what is written before in any Puppet setup would
> be what I need.
>
> The ideal, maybe, would be a simple function that does the above and then if
> Hiera is in place, uses Hiera without requiring it: I really would like to
> reach a scenario where a person picks a single module and eventually the
> dependent modules (stdlib and so on), and can use it on his Puppetmaster
> without the need to introduce Hiera on it, if it's not already there.
> This, at least, until most of the people will have a PuppetMaster with
> integrated Hiera ... till that moment I would like to have modules usable in
> the widest range of Puppet setups possible.
>
> A similar function would be more than enough for me to throw happily away
> 80% of the code that is
> in https://github.com/example42/puppet-openssh/blob/master/manifests/params.pp
>
> All the best
> al
>
> --
> 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/-/l1YoNqgCGqsJ.
>
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
--
Walter Heck
--
follow @walterheck on twitter to see what I'm up to!
--
Check out my new startup: Server Monitoring as a Service @ http://tribily.com
Follow @tribily on Twitter and/or 'Like' our Facebook page at
http://www.facebook.com/tribily
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
