Re: [Puppet Users] Re: Using foo::params, inheritance, and parameterized classes simultaneously?
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
Re: [Puppet Users] Re: Using foo::params, inheritance, and parameterized classes simultaneously?
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
Re: [Puppet Users] Re: Using foo::params, inheritance, and parameterized classes simultaneously?
On Sun, Jan 15, 2012 at 16:48, R.I.Pienaar r...@devco.net wrote: sounds like you want to use hiera http://www.devco.net/archives/2011/06/06/puppet_backend_for_hiera.php Ah, I didn't see before that it actually gets it's data from mutliple backends. That's pretty sweet! -- 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.
[Puppet Users] Re: Exec depends on ressources that are several different types
On Jan 11, 9:07 am, Aaron Grewell aaron.grew...@gmail.com wrote: require accepts an array, so you should be able to do this: require = [File['foo'],Exec['bar']] It worked. Thanks so much. I should submit this as an addition in one of the wiki examples on the puppet website. Patrick -- 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.
Re: [Puppet Users] Re: Exec depends on ressources that are several different types
On Sun, Jan 15, 2012 at 4:17 PM, Patrick Viet patrick.v...@learnosity.comwrote: On Jan 11, 9:07 am, Aaron Grewell aaron.grew...@gmail.com wrote: require accepts an array, so you should be able to do this: require = [File['foo'],Exec['bar']] It worked. Thanks so much. I should submit this as an addition in one of the wiki examples on the puppet website. Ideally submit it as a bug against this page: http://docs.puppetlabs.com/guides/language_guide.html here: http://projects.puppetlabs.com/projects/puppet-docs/issues/new -- Nigel Kersten Product Manager, Puppet Labs -- 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.
[Puppet Users] Staging environment for infra with 20+ unique servers
Hello, one of my clients has a server infrastructure with 20+ servers that are all unique. Currently it runs without a puppet staging environment which makes me sleep badly at night :) The problem is: the client doesn't have the resources to run 20 staging servers as well, and the overhead of setting up 20 virtualboxes is quite sizable (worth it to me, but I'm not teh decision maker). I was wondering if anyone is doing anything smart for instance with vagrant and passing a different --fqdn param to puppet? I could for instance have 20 different snapshots in a single virtualbox image, one for each server they have? outside the box thinking welcome :) -- 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.
Re: [Puppet Users] NRPE configuration with Augeas
You probably want your onlyif to look like
match command[./${name}='${value}'] size == 0
I would probably do something like this (https://gist.github.com/1619400). The
reason for the two augeas resources is one will create the command if it
doesn't exist at all, the other will update the named command if it exists but
has the wrong command string.
On Sunday, 15 January 2012 at 8:27 AM, Jared Curtis wrote:
I'm trying to build a NRPE management module that has the ability to
add or modify existing commands. I think Augeas would be the best
method to handle this but I'm running into a few issues. Here's what I
have so far
define nrpe::command($value) {
include augeas
augeas{ ${fqdn}_NRPE_${name}:
context = /files/${nrpe::params::conf},
changes = set command[last()+1]/${name} ${value},
onlyif = get command[*]/${name} != ${value},
require = Class['augeas'],
}
}
The problem is this will add duplicate commands.
What I want is something like this
nrpe::command { 'check_users': value= 'check users command';
'check_something': value = 'check something command'; }
Which will produce this
command[check_users]=check users command
command[check_something]=check something command
Any suggestions on how to correct this?
--
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
(mailto:puppet-users@googlegroups.com).
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
(mailto:puppet-users+unsubscr...@googlegroups.com).
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
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.
