[Puppet Users] Custom provider woes and questions

[Peter Berghold]

This email has two parts:

First part

Looking at "Sh*t Gary Says" seems to imply I may be going about creating
custom types/providers.  I am currently creating a type under
lib/puppet/type/{typename}.rb without that logic doing anything with the
actual logic being in lib/puppet/provider/{typename}/ruby.rb which has
worked fine for me in the past.

Someone confirm/deny.

Second part

I've created a pair of custom types/providers, one to set parameters and
the other to set state.   The issue I'm running into is the state provider
is trying to work and the parameter provider doesn't even seem to be
loading in Puppet at all without any sort of error showing up.

Here is how they are being invoked in a manifest:

myparmtype { 'instance':
parm1=>'value1',
parm2=>'value2'
}
->
mystatetype{'instance':
   state =>'mystate'
}

Sorry for the obfuscation, but what I'm working on is largely company
proprietary.

Thoughts anybody?

Is there a limit to the number of types/providers a module can have?

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAArvnv022R2jX5TOdLX1MnqEyfdK8Ep51hWP%3D%2Bhqd1cLN-XaMA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet Exec resource with complex Environment Variables...

[jcbollinger]

On Friday, December 4, 2015 at 10:27:52 AM UTC-6, Sean wrote:
>
> Greetings,
>
> I am working on streamlining some older puppet code, that uses a lot of 
> Exec resources to accomplish it's purposes.  It's not terribly elegant and 
> we're working on design to replace it with code that leverages puppet 
> features.  One of the pieces I'm struggling with is how to set complex 
> environment variables that are available to use in onlyif/unless statements 
> as well as the command itself.  I'm wondering if this just isn't possible?
>
> Here's an example with the aide.  NOTE that we're not in a spot where I 
> can make puppet manage the aide config file, and thus use an aide module 
> and parameters instead of shell variables.  All of these commands run 
> successfully in a bash shell for the various conditions that would apply. 
>  I have other similar scenarios, but aide is one of the more complex ones.
>
>   exec { 'init-aide-database':
> path=> 
> '/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin',
> environment => [ 'DBDIR=$(egrep \'^@@define DBDIR \' 
> /etc/aide.conf|awk \'{print $NF}\')',
>   'DBFILE=$(egrep \'^database=file\' /etc/aide.conf|awk -F/ \'{print 
> $NF}\')',
>   'DBNEW=$(egrep \'^database_out=file\' /etc/aide.conf|awk -F/ 
> \'{print $NF}\')',
>   ],
> command => '/usr/sbin/aide --init >/dev/null 2>&1 && cp -p 
> ${DBDIR}/${DBNEW} ${DBDIR}/${DBFILE}',
> unless  => 'test -f ${DBDIR}/${DBNEW} && test -f 
> ${DBDIR}/${DBFILE}',
> require => Package['aide'],
> logoutput   => true,
> timeout => 0,
>   }
>
> When executing, puppet always runs the exec because the env var's are 
> empty, so the unless case always fails.  Then we get a scenario where we're 
> running aide --init when it's not needed and the cp command throws an error 
> due to empty variables.
>
>

Are you sure?  I'd be inclined to suppose that the problem was that the 
environment variables don't have the values you expect them to have.  As 
far as I am aware, Puppet inserts environment variables into child 
processes' environments via a mechanism that does not involve evaluating 
the value expressions via the shell (even when you use the 'shell' 
provider).

I had thought that the same environment is presented to the 'unless' and 
'onlyif' commands as is presented to the main command, but I can't 
immediately back that up, as the documentation is at best unclear on that 
point.  If you could establish that it is not, then that might justify 
filing a ticket.

 

> My thought at the moment is that I need to build two shell scripts as file 
> resources.  One to call in the unless test, and another to call in the 
> command if the unless script fails.  Perhaps that's more elegant, but we're 
> hoping to avoid delivering script files to the nodes wherever possible. 
>  I'm hoping the gurus out here might point me in the best direction!
>


If you must determine the needed values for your environment variables at 
run time, by executing shell code, then I'm pretty confident that one way 
or another you will need to build that in to each of the commands you use.  
The approach you describe is a reasonable way to do that.

You could also consider whether it would be worth the effort to build a 
full-fledged custom type.  You would still need to perform some environment 
mangling, but you could at least avoid managing separate command scripts.


John

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/4cb89384-3113-4b11-ae48-a09281abc0b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppetmaster compiles old catalogs

[jcbollinger]

On Sunday, December 6, 2015 at 8:27:21 AM UTC-6, César wrote:
>
> Hi all,
>
> we're seeing every now and then an odd behaviour with Puppet catalog 
> compilation. Basically, we modify and save the node manifests and a few 
> seconds later we trigger a catalog run to apply the changes.
> However, what we see is that sometimes the Puppet master compiles the old 
> version of the node manifest, leaving changes behind and requiring two 
> catalog runs to apply all of them.
>
> A sample site.pp would look like this:
>
>
> import "/path/to/manifests/plugins/ms1.pp"
>
> import "/path/to/manifests/plugins/n1.pp"
>
> import "/path/to/manifests/plugins/n2.pp"
>
> node default {}
>
>
> I would like to know if using import might be causing this? (We use Puppet 
> 3.3.2)
> If that's not the case, do you have any hints or tips to troubleshoot the 
> issue? How does the Puppetmaster handle the compilation of the node 
> manifest? We tried to use the configuration option to avoid caching, but so 
> far that didn't fix it.
>
>

Are you sure the master is running Puppet 3.3?  What you're describing 
sounds like an effect of new-style environment caching, but I don't think 
that was implemented yet in Puppet 3.3.  (The Puppet version on the agents 
doesn't matter for this purpose.)


John

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/b30626d2-8c22-4505-92e9-995ade55779a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Puppet 4: default value of a parameter in a module and dependency

[jcbollinger]

On Friday, December 4, 2015 at 7:23:44 PM UTC-6, François Lafont wrote: 

> Yes, you are absolutely right and your explanations show me that I was not 
> precise enough when I have described my question. Sorry for that. I will 
> try to fix it. 
>
> 1. My question was in fact only about _public_ classes of my modules. 
>
> 2. These classes are _always_ called via "require" or "include", never 
> with parameters. (The only case where I can call sometimes classes with 
> parameters is when a class in a module calls another private class of 
> the same module.) 
>
> So I fact my question is, for a node, the ENC will trigger this puppet 
> code: 
>
> # Only "include" or "require". 
> include moda 
> include modb 
> include modc::fooc 
> include modc::barc 
> include modd::food 
> include modd::bard 
> include mode 
> etc... 
>
> and I would like to have the default value of ::modb::param equal to 
> the value of the parameter ::moda::param. And I think it's possible (if 
> 1. and 2. are satisfied) with this code in 
> ./modules/modc/functions/data.pp: 
>
> function modb::data { 
>
>   # We assume that the type expected here is a non-empty string. 
>   $param = lookup('moda::param', String[1], 'first') 
>
>   # code... 
>
>   { 
> ... 
> modb::param => $param, 
> ... 
>   } 
>
> } 
>
> And mabe (but I'm not completely sure on this point), it could be a good 
> idea to put in ./modules/modb/metadata.json a dependency ("modb depends on 
> moda"). But I have lot of doubts on this point...? 
>
> John, are we agreed in these conditions? 
>


I'm not sure where my agreement factors in.  Your conditions are whatever 
they are, or at most what I can persuade you they should be.

I still maintain that you are contemplating an inappropriately tight 
coupling between your modules.  You likely can come up with a list of 
restrictions sufficient to ensure that there is a method to determine what 
value a parameter of class ::moda *would* take in the event that that class 
were declared, other than actually declaring the class and checking what 
value it actually *did* take.  You have not yet stipulated enough 
conditions for that, however: you would at least need to account also for 
the possibility of the value depending on Hiera interpolation tokens that 
in turn depend on the 'calling' class or module.

 

> > If you conceive a module to be in a position to control or even to know 
> > whether and how a class from a different module is declared, then that's 
> a 
> > strong signal that you should combine or refactor your modules.  If you 
> > think one module has need for direct access to in-module data of a 
> > different module, then that is also a signal that you should combine or 
> > refactor. 
>
> And in the conditions which I have described above, do you still think 
> that 
> a refactor is needed? 
>
>

I think the specific conditions are irrelevant to the main thrust of my 
position.  The fact that your code and data would need to comply with a 
relatively complex set of conditions for what you propose to be workable at 
all is one of my primary arguments.  I predict that taking on such a set of 
extra requirements will cause you grief, more likely sooner than later, and 
I urge you to devise another way to accomplish your objective.

If you insist on proceeding in this general direction, however, then I'd 
suggest employing a variation on the Params Class pattern.  Create a class 
::moda::params and give it a parameter or ordinary class variable 
$::moda::params::param that will serve both as the (definite) 
initialization value for $::moda::param and as the default value for 
$::modb::param.  This will require that $::moda::param be made an ordinary 
class variable instead of a class parameter, so that it can never take a 
value different from $::moda::params::param.  It will also require that 
class ::modb inherit directly or indirectly from class ::moda::params.  In 
Puppet 4, $::moda::params::param can receive its value in any way you see 
fit, including automated data binding (if you opt to make 
$::moda::params::param a class parameter), but you would create an 
evaluation-order dependency if every you used a resource-like declaration 
of it, either directly or via an ENC.  Class ::moda::params would avoid 
declaring any resources so that declaring it (as classes ::moda and ::modb 
would both need to ensure happens) will not directly affect the target 
node's state.

If you're following closely you will observe that that solves the problem 
by adding a layer of indirection.  You may also recognize that class 
inheritance across module boundaries is considered poor practice by many; 
this should be taken as further support for my argument that your proposed 
modules are too tightly coupled.

 

> According to me, 2 modules moda modb can be independent but sometimes it 
> can 
> be relevant (and handy) that the default value of modb::param is equal to 
> the value of moda::param, no? For 

Re: [Puppet Users] Puppet Enterprise Installation Error on CentOS7

[Martin Alfke]

Hi Nikhil,

please paste the log file (/var/opt/puppetlabs/puppetserver/puppetserver.log) 
into gist (not a screenshot).
http://gist.github.com/

I assume that the error is at the end of the file.

Did you run the journalctl -xn command (like mentioned in the output)?
The error log snippet you have pasted indicates, that you can not reach 
official cents mirrors.
Has your VM access to the internet? Can you run ‘yum update’ successfully on 
the machine?

Best,
Martin


On 06 Dec 2015, at 00:27, Nikhil Rao  wrote:

> 
> 
> On Saturday, 5 December 2015 11:58:58 UTC-5, Nikhil Rao wrote:
> I tried to install puppet enterprise from puppet master and while selecting 
> monolithic installation and setting upto 500 nodes and setting up the DNS 
> name and the alias name and encountered an error WARNING 1: set 2 CPU cores 
> instead of 4 CPU cores WARNING 2: set at-least 100GB space in /Opt folder. 
> And i ended up in the following error "Error: Could not start 
> Service[pe-puppetserver]: Execution of '/bin/systemctl start pe-puppetserver' 
> returned 1: Job for pe-puppetserver.service failed. See 'systemctl status 
> pe-puppetserver.service' and 'journalctl -xn' for details. Error: 
> /Stage[main]/Puppetenterprise::Master::Puppetserver/Service[pe-puppetserver]/ensure:
>  change from stopped to running failed: Could not start 
> Service[pe-puppetserver]: Execution of '/bin/systemctl start pe-puppetserver' 
> returned 1: Job for pe-puppetserver.service failed. See 'systemctl status 
> pe-puppetserver.service' and 'journalctl -xn' for details."
> What should i change in my vmware settings Please advice
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I have posted the log file and the error is as follows . But couldnt decode 
> what the exact error is ... Please can you advice on what the issue is  
> exactly and i have changed the Cores and it didnt throw a warning. But still 
> stuck at pe-puppetserver
> 
>  
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/649da43e-a615-41b6-bd35-bdf4e18d18f1%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/E08A92A8-4FF8-4760-94D7-BCC4553CE810%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Custom provider woes and questions

[Peter Berghold]

Nevermind... figured out what was going on..   and fixed that problem and
now a more bugs to squash...

How do I raise a failed exception in a provider (this before I start
googleing) :-)

On Mon, Dec 7, 2015 at 9:53 AM Peter Berghold 
wrote:

> This email has two parts:
>
> First part
>
> Looking at "Sh*t Gary Says" seems to imply I may be going about creating
> custom types/providers.  I am currently creating a type under
> lib/puppet/type/{typename}.rb without that logic doing anything with the
> actual logic being in lib/puppet/provider/{typename}/ruby.rb which has
> worked fine for me in the past.
>
> Someone confirm/deny.
>
> Second part
>
> I've created a pair of custom types/providers, one to set parameters and
> the other to set state.   The issue I'm running into is the state provider
> is trying to work and the parameter provider doesn't even seem to be
> loading in Puppet at all without any sort of error showing up.
>
> Here is how they are being invoked in a manifest:
>
> myparmtype { 'instance':
> parm1=>'value1',
> parm2=>'value2'
> }
> ->
> mystatetype{'instance':
>state =>'mystate'
> }
>
> Sorry for the obfuscation, but what I'm working on is largely company
> proprietary.
>
> Thoughts anybody?
>
> Is there a limit to the number of types/providers a module can have?
>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAArvnv20aBVzYQyU5ifFJQcuVQPEaCp63VntLMMXBBmP9%3D5SRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Puppet Exec resource with complex Environment Variables...

[Sean]

John,

Thanks for the reply.  To answer your first question, no I'm not completely 
sure.  What I can say is that I can run the commands in a shell by hand and 
the result is what I hope for.  When I run puppet, with this particular 
class included, puppet hangs for a while with no screen output.  This leads 
me to believe that the "unless" fails and the "command" executes.  I can 
verify that by running (in another shell):

[root@desktop ~]# ps -ef|grep aide
root 28085 1  0 14:42 ?00:00:00 sh -c /usr/sbin/aide --init 
>/dev/null 2>&1 && cp -p ${DBDIR}/${DBNEW} ${DBDIR}/${DBFILE}
root 28088 28085 20 14:42 ?00:01:24 /usr/sbin/aide --init


I can say when I run the various piece by hand inside an interactive shell 
everything comes out as expected:

[root@desktop ~]# DBDIR=$(egrep '^@@define DBDIR ' /etc/aide.conf |awk 
'{print $NF}')
[root@desktop ~]# echo $DBDIR
/var/lib/aide
[root@desktop ~]# DBFILE=$(egrep '^database=file' /etc/aide.conf |awk -F/ 
'{print $NF}')
[root@desktop ~]# echo $DBFILE
aide.db.gz
[root@desktop ~]# DBNEW=$(egrep '^database_out=file' /etc/aide.conf |awk 
-F/ '{print $NF}')
[root@desktop ~]# echo $DBNEW
aide.db.new.gz
[root@desktop ~]# test -f ${DBDIR}/${DBNEW} && test -f ${DBDIR}/${DBFILE}
[root@desktop ~]# echo $?
0
[root@desktop ~]# /usr/sbin/aide --init >/dev/null 2>&1 && cp -p 
${DBDIR}/${DBNEW} ${DBDIR}/${DBFILE}
cp: overwrite ‘/var/lib/aide/aide.db.gz’? y

The cp overwrite prompt above comes from the alias cp='cp -i ' in my shell. 
 I'm not sure if that would be there inside puppet, but if so I'll modify 
to negate that option.

For testing, I created a separate class for just this one exec.  I modified 
the unless and command statements as follows:

command => 'echo "/usr/sbin/aide --init >/dev/null 2>&1 && cp -p 
${DBDIR}/${DBNEW} ${DBDIR}/${DBFILE}"',
unless  => 'echo "test -f ${DBDIR}/${DBNEW} && test -f 
${DBDIR}/${DBFILE}" && test -f ${DBDIR}/${DBNEW} && test -f 
${DBDIR}/${DBFILE}',

So basically the "unless" echo's what it's doing, then tries to do it.  The 
"command" just echoes what it would do.  Here's the puppet agent --test 
--debug output for the class:

Debug: Exec[init-aide-database](provider=posix): Executing check 'echo 
"test -f ${DBDIR}/${DBNEW} && test -f ${DBDIR}/${DBFILE}" && test -f 
${DBDIR}/${DBNEW} && test -f ${DBDIR}/${DBFILE}'
Debug: Executing 'echo "test -f ${DBDIR}/${DBNEW} && test -f 
${DBDIR}/${DBFILE}" && test -f ${DBDIR}/${DBNEW} && test -f 
${DBDIR}/${DBFILE}'
Debug: /Stage[main]/Testenv/Exec[init-aide-database]/unless: test -f $(egrep 
'^@@define DBDIR ' /etc/aide.conf|awk '{print $NF}')/$(egrep 
'^database_out=file' /etc/aide.conf|awk -F/ '{print $NF}') && test -f $(egrep 
'^@@define DBDIR ' /etc/aide.conf|awk '{print $NF}')/$(egrep 
'^database=file' /etc/aide.conf|awk -F/ '{print $NF}')
Debug: /Stage[main]/Testenv/Exec[init-aide-database]/unless: sh: line 0: 
test: too many arguments
Debug: Exec[init-aide-database](provider=posix): Executing 'echo 
"/usr/sbin/aide --init >/dev/null 2>&1 && cp -p ${DBDIR}/${DBNEW} 
${DBDIR}/${DBFILE}"'
Debug: Executing 'echo "/usr/sbin/aide --init >/dev/null 2>&1 && cp -p 
${DBDIR}/${DBNEW} ${DBDIR}/${DBFILE}"'
Notice: /Stage[main]/Testenv/Exec[init-aide-database]/returns: /usr/sbin/aide 
--init >/dev/null 2>&1 && cp -p $(egrep '^@@define DBDIR ' /etc/aide.conf|awk 
'{print $NF}')/$(egrep '^database_out=file' /etc/aide.conf|awk -F/ '{print 
$NF}') $(egrep '^@@define DBDIR ' /etc/aide.conf|awk '{print $NF}')/$(egrep 
'^database=file' /etc/aide.conf|awk -F/ '{print $NF}')
Notice: /Stage[main]/Testenv/Exec[init-aide-database]/returns: executed 
successfully
Debug: /Stage[main]/Testenv/Exec[init-aide-database]: The container Class[
Testenv] will propagate my refresh event
Debug: Class[Testenv]: The container Stage[main] will propagate my refresh 
event

So it looks like the strings inside the environment variables aren't 
interpreted by the shell, they're just passed as literal strings.  But 
notably, the the unless test fails with an error from /usr/bin/test that 
doesn't surface when running interactively.  I will attempt to run in the 
shell provider instead of posix, but if that fails, I just re-code 
everything into shell scripts and have puppet push and execute them.  If we 
need to make this a bug, I'll be happy to help, but I'm running on EL7 with 
puppet out of EPEL7, with no intent of going to Puppet 4 anytime soon.

Thanks again for taking a look!

On Monday, December 7, 2015 at 11:37:19 AM UTC-5, jcbollinger wrote:
>
>
>
> On Friday, December 4, 2015 at 10:27:52 AM UTC-6, Sean wrote:
>>
>> Greetings,
>>
>> I am working on streamlining some older puppet code, that uses a lot of 
>> Exec resources to accomplish it's purposes.  It's not terribly elegant and 
>> we're working on design to replace it with code that leverages puppet 
>> features.  One of the pieces I'm struggling with is how to set complex 
>> environment variables that are available to use in 

[Puppet Users] Best way to do cross-module dependencies

[Dan Mahoney]

Hey all,

Everything I've done thusfar in creating my own custom modules has drilled 
some basics into my head -- these are right from the puppet web docs:

"A module’s classes, defined types, and plugins *should all be related,* and 
the module should aim to be *as self-contained as possible.*

Manifests in one module should never reference files or templates stored in 
another module."

I've also seen it preached hard that modules should attempt in all cases to 
be "portable".

So, with that said -- how is the best way to declare dependencies across 
modules?

For example, I have a one-file-per-rule firewall stack, where rules are 
placed in /etc/firewall.d, and loaded using a standardized ordering script 
-- this way my "httpd" module can add (and own) an "httpd" firewall rule. 
 How would I tell my web module that if that firewall type is in play, that 
it should add a file there, and reload the firewall?  How do I get the web 
module to only do this *if* that firewall type is in play, without directly 
*requiring* it?

I have a similar thing for syslog, where I can populate a directory and 
have individual packages own files in there.  Same question.

I also have a similar thing for logfile rotation.  Same question.

I don't want to build huge metaclasses all in site.pp -- nor does it seem 
sane to me to build meta-modules that do all the combining, although those 
*are* both ways forward.

Thanks,

-Dan

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/6e51be82-b270-4cb8-bf31-90e39eedd9cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Hiera 3.X subkeys lookup

[Adrian Muraru]

With the addition of subkeys lookup, e.g. hiera('a.b.c'), those yaml 
configuration files already including top level keys with a "." in the key 
name are rendered invalid.
Is there a way to disable subkey lookup support on demand for a given 
backend?

thanks,
adrian

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/6d1807d9-ab03-4ae0-ab77-ca7dd864f4cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] In puppet 3.8.3, classes are defined twice in catalog

[韩雨哲]

In the module, the classes are designed like this:
A::install{}

class A{
  A::install{}
}

class A::B{
  A::B::install{
require -> Class[A]
  }
}

class A::C{
  A::C::install{
require -> Class[A]
  }
}


The result of puppet master compile is:
"classes": [
  "A",
  "A::B",
  "A::C",
  "A::install",
  "A",
  "A::B",
  "A::C"
]

Then the "require" function doesn't take effect. And I must change it to 
"require -> Class[A::install].

But in puppet 2.7.2, it looks ok.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/af2d6154-bb11-4800-88c2-ff502382a675%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.