[Puppet Users] Possible to overriding Hiera on the run-time?

2015-09-16 Thread Sans
Hi there,

I got to solve a "rare" issue here which I'm running out of ideas for. In 
our manifest, we do some conditional  git pull (using vcsrepo forgemodule) 
based on a Hiera variable that set either true or false. We keep the value 
as false i.e. no git-pull by default but want to set it true, on the fly 
temporarily for onetime run. Is there anyway to override hiera value when 
running puppet agent from the command-line on the run-time? 

Generally, we run on-demand puppet agent using mcollective, like this: mco 
puppet runonce -I 
Is there anywhay to achieve the same using mCollective at all? Or what 
other options do I have?

Any suggestions/pointer will be greatly appreciated. 

-San

-- 
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/a3f0be40-c999-4d39-8a6d-63f664fb6767%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Puppetmaster performance degradation after update to 3.8.2

2015-09-16 Thread Adam Winberg
Upgraded from 3.7.3 to 3.8.2 and have after that had very slow compilation
and file serving from the puppet master. We're running our puppetmaster
with apache/passenger, ca. 900 hosts. Complete puppet runs earlier took
10-15s and after update take 30-300s. Very unstable performance.

Even running with just a few clients the runtimes are really slow.
Decreasing the 'PassengerMaxPoolSize' makes the runs faster, but then it
cant cope with an increased load.

I have also tried with the jvm puppetserver with roughly the same
performance (or lack thereof). I noticed the same pattern, if i set
'max-active-instances' in puppetserver.conf to 2, I get acceptable
performance with a handful of clients, but with increased load it doesnt
cope. If I raise the 'max-active-instances' the performance is even worse.

This is running on an vmware server, 8 cpu and 12GB RAM.

Cant find anything in the release notes that explain this performance
drops, does anyone recognize the problem?

I have now downgraded to 3.7.3 and my puppet runs are as fast as ever
again.

Any help appreciated.

Regards
Adam

-- 
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/CAFCL3HvvEC4HA4xD655sAPMBMznVdsqcQCYp5FHn%3D_SQ8TG2qg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Re: invoke modules from puppetforge from hiera yamls?

2015-09-16 Thread jcbollinger


On Tuesday, September 15, 2015 at 8:14:05 PM UTC-5, Chris Jefferies wrote:
>
>
>
> At my office we use puppet hiera. The general approach has been to use key 
> value pairs in the yaml files as the source for variables in the modules 
> which are defined with snippets that look like this:
>
> hiera('some_hiera_variable', 'www.google.com')
>
> The main puppet init.pp is a small piece of config pointing to hiera 
> backend. All the hosts/nodes are defined in role based YAMLs and invoke 
> various modules with their associated configs and service modules. After 
> that there is a list of key value pairs that are used in the modules with 
> the hiera() function.
>


It sounds to me like you are using un-parameterized classes, and relying on 
Hiera lookups to feed data to them.  If so, then Bravo!  At one time I 
advocated just such an approach, and I still think it's perfectly viable.  
I never could stem the tide of enthusiasm for class parameterization, 
however, and although there are still some gotchas surrounding 
parameterized classes, the automated data binding feature introduced in 
Puppet 3 mitigates the more glaring of those issues.

 

>
> So when I download modules from sourceforge I note that none I've looked 
> at so far refer to hiera or have variables like the above example.
>
>

Yet all parameterized classes *do* use Hiera to lookup values for any 
parameters that are not set via their declarations (this is automated data 
binding), and for the most part, class declarations should not set *any* 
parameters, nor even use the resource-like class declaration syntax at 
all.  And of course classes may still perform explicit Hiera lookups, but 
these days, it is typical for them to rely on data binding instead.  This 
tends to work well for most purposes.

 

> Is there a way to reference a module's parameters from the hiera and if 
> so, what's the basic approach? For instance, if the module documentation 
> from puppetforge shows blocks like these (which would be defined in a 
> site.pp):
>
> class {'::icinga':
>   dbtype => 'mysql',
>   dbhost => 'localhost',
>   dbuser => 'icinga',
>   dbpasswd   => 'icinga',
>   dbname => 'icinga',
>   }
>
>
>

The preceding is a class declaration in the resource-like style.  Generally 
speaking, don't do that.  Instead, yes, classes can obtain parameter values 
from Hiera (see Chad's link), and that's how they should obtain them in 
most cases.

 

> icinga::classicui::user {'username':
>   passwd => 'HashPa22worD',
> }
>
>

*That*, on the other hand, is the declaration of a bona fide resource.  
Resource declarations do not participate in automated data binding, and 
they are not subject to any of the gotchas associated with resource-like 
class declarations.

 

> ...how does one translate these into hiera definitions? Perhaps there is a 
> tutorial on this subject?
>
>

Chad gave you a link.  Basically, though, it's simple: if class 
"my_module::a_class" has a parameter "param1", and that class is declared 
in a manner that does not specify a value for that parameter (for example, 
via an include-like declaration) then Puppet attempts to look up the value 
in hiera via key "my_module::a_class::param1".  If that key is not present 
then Puppet falls back to the declared default value, or fails if no 
default is declared.

 

> I am reticent to start seeding the module code with hiera() variables 
> because it seems I'll end up with custom code and unable to retrieve module 
> updates that would overwrite my changes.
>
>

You are right to be concerned.  If you are relying on third-party modules 
(and most people do), then it is wise to avoid forking them, if possible.  
Indeed, this is one very good reason for Hiera and externalizing data in 
the first place.


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/96935c61-a42f-47ee-b0ff-9c810ebf9668%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] invoke modules from puppetforge from hiera yamls?

2015-09-16 Thread Chad Huneycutt
Take a look at this page:
http://docs.puppetlabs.com/hiera/3.0/puppet.html .  The section
entitled "Automatic Parameter Lookup" explains how to specify puppet
class parameters in hiera.

- Chad

On Tue, Sep 15, 2015 at 7:23 PM, Chris Jefferies  wrote:
>
>
> At my office we use puppet hiera. The general approach has been to use key
> value pairs in the yaml files as the source for variables in the modules
> which are defined with snippets that look like this:
>
> hiera('some_hiera_variable', 'www.google.com')
>
> The main puppet init.pp is a small piece of config pointing to hiera
> backend. All the hosts/nodes are defined in role based YAMLs and invoke
> various modules with their associated configs and service modules. After
> that there is a list of key value pairs that are used in the modules with
> the hiera() function.
>
> So when I download modules from sourceforge I note that none I've looked at
> so far refer to hiera or have variables like the above example.
>
> Is there a way to reference a module's parameters from the hiera and if so,
> what's the basic approach? For instance, if the module documentation from
> puppetforge shows blocks like these (which would be defined in a site.pp):
>
> class {'::icinga':
>   dbtype => 'mysql',
>   dbhost => 'localhost',
>   dbuser => 'icinga',
>   dbpasswd   => 'icinga',
>   dbname => 'icinga',
>   }
>
>
> icinga::classicui::user {'username':
>   passwd => 'HashPa22worD',
> }
>
> class{'::icinga':
>   initdb   => true,
>   with_classicui   => true,
>   enabled_features => ['statusdata', 'compatlog', 'command'],
> }
>
>
> class { 'apache':
> default_vhost => false,
> }
>
> ...how does one translate these into hiera definitions? Perhaps there is a
> tutorial on this subject?
>
> I am reticent to start seeding the module code with hiera() variables
> because it seems I'll end up with custom code and unable to retrieve module
> updates that would overwrite my changes.
>
> Sorry to be such a noob on the subject but any tips would be appreciated.
>
> Thanks, Chris.
>
> --
> 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/002b3a69-9f89-4bd6-96de-e9b4b373038c%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Chad M. Huneycutt

-- 
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/CAOJfo14w3c2%2Bm14Y84RoqzUgbfEAG4vPKZQzsiEt7KfNcgMiAw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Duplicate declaration - class is already declared

2015-09-16 Thread jcbollinger


On Tuesday, September 15, 2015 at 2:33:16 PM UTC-5, Julian Meier wrote:
>
> Thanks you! The explanation about private and public classes is just great!
>
> So, there seems to be no way to define IN the module how public classes 
> get evaluated (order), right?
>


Evaluation order is deterministic, as governed by the order of DSL 
statements in your manifests.  Manifests are evaluated in document order, 
left-to-right, top-to-bottom.  In that sense, yes, you can define in a 
module in what order classes are evaluated.  You cannot, however, use 
declarations in one manifest to influence the order of evaluation of 
declarations in a different manifest.  This is why the differentiation 
between public and private classes is so important.  For private classes, 
you can control evaluation order because you can control all the places 
where a declaration may be evaluated, but for public classes, all bets are 
off.


I really want to use some params from `::ospuppet` in `::ospuppet::master` 
> and `::ospuppet::server` (
> https://github.com/juame/juame-ospuppet/tree/0.3.0).
>
>

That's fine.  Then rely on automated data binding to set those parameter 
values.  If class ::ospuppet serves *only* to house such shared data, then 
as a bonus, you will no longer need to declare it from outside the module 
at all.  In that case you could make it private, but if you do so then I 
would rename it to avoid confusion, maybe to ::ospuppet::data.

Or if you're going that far, then you could also consider getting rid of 
the shared data class altogether.  Your two other classes could instead 
obtain the data directly from Hiera, by calling one of its data-access 
functions.  You then obtain data sharing / deduplication by having each 
class that wants the data look it up in Hiera via the same key.


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/4aa89f72-b662-41ec-a81f-ab371824374f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] "puppet-agent": upgrade from 1.2.2 to 1.2.4 breaks my ssl connections with the Rabbitmq middleware

2015-09-16 Thread Francois Lafont
Hi,

Today, there was an upgrade of the AIO "puppet-agent" package from
1.2.2 to 1.2.4. Before the upgrade, the ssl connections of nodes
with the Rabbitmq middleware worked fine. But after, the ssl connections
worked no longer and the link between the nodes (mcollective servers)
and the middleware was broken.

Before the upgrade:


root@client-trusty:~# dpkg -l puppet-agent | grep puppet-agent | awk '{print 
$1" "$2" "$3" "$4}'
ii puppet-agent 1.2.2-1trusty amd64

# The middleware is a rabbitmq server in another host.
root@client-trusty:~# MIDDLEWARE_SRV=172.31.14.7:61614

root@client-trusty:~# 
cert=/etc/puppetlabs/puppet/ssl/certs/client-trusty.athome.priv.pem 
root@client-trusty:~# 
key=/etc/puppetlabs/puppet/ssl/private_keys/client-trusty.athome.priv.pem 
root@client-trusty:~# cacert=/etc/puppetlabs/puppet/ssl/certs/ca.pem

# Try a ssl handshake. All is OK.
root@client-trusty:~# /opt/puppetlabs/puppet/bin/openssl s_client -connect 
$MIDDLEWARE_SRV -cert $cert -key $key -CAfile $cacert && echo ALL IS OK
CONNECTED(0003)
depth=1 CN = Puppet CA: puppet4.athome.priv
verify return:1
depth=0 CN = middleware.athome.priv
verify return:1
---
Certificate chain
 0 s:/CN=middleware.athome.priv
   i:/CN=Puppet CA: puppet4.athome.priv
 1 s:/CN=Puppet CA: puppet4.athome.priv
   i:/CN=Puppet CA: puppet4.athome.priv
---
Server certificate
-BEGIN CERTIFICATE-
MIIFgjCCA2qgAwIBAgIBBzANBgkqhkiG9w0BAQsFADApMScwJQYDVQQDDB5QdXBw
ZXQgQ0E6IHB1cHBldDQuYXRob21lLnByaXYwHhcNMTUwOTEyMTYxNzE5WhcNMjAw
OTExMTYxNzE5WjAhMR8wHQYDVQQDDBZtaWRkbGV3YXJlLmF0aG9tZS5wcml2MIIC
IjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAu2En9wplbcqTW6qzZXFEmGIf
/NgvjWHxuNAOA5szcYZ4f3wwAfq25kp6hjDaIRYsgzny6FY7AZ4SDiSTtS8kNMFn
jBJy/81RQKtqP97X+6y84q8EtA/4i4p1g9U7GOZ6LWTFa2h4sd7zl2ahM02szgBX
CIqZjrpm9M1ucTd2ZlqZ80CEKNKxbe+UaTufrGI9+ZxHo+wyxD9TW1Cuvw+Ke9OJ
rir5bCD2RvNbNE/89pRWr1J3jbxnSZNVqwiaRZWg7c7R4qjrauLgftM8d1PzUM32
Mx+17tbF4m6xOldg26c8FGQ5kTW8BXC2mGtffI/0zEYmMhKYnoUIQ7HFyuGc4Krp
V1ikql7R995b2elWHIZYaXvoaWg9048y+ueGSNKPbGBReY8FLO8SZgxbvkGXsear
cKW+eCMnUhGY/J34ComNs6jownXvpq4AKED8KP+dRzs6Z9QDFeXO6qEcyS4AD4zm
2zFsztRtwI9cjbViiSEuTo0vFo1n31RYU4augiyfSQ7gfZaRR0EodkdUxTbDSwPK
ym4+t9G2cloG8WI/+njxom86KfJEp2nHG6F0zbZuFMYyfqUzL2PNKp2ZO7MYrCVM
d1ljyLp/jIP/8Ymu16EFnX7LA8F+a7Vvb3e3dmWjBS+vixKXnRl/cUhZ+T84+o1k
3LuFr7PHOE62Otxgbc8CAwEAAaOBvDCBuTA3BglghkgBhvhCAQ0EKgwoUHVwcGV0
IFJ1YnkvT3BlblNTTCBJbnRlcm5hbCBDZXJ0aWZpY2F0ZTAOBgNVHQ8BAf8EBAMC
BaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQC
MAAwHQYDVR0OBBYEFBxwJMjotqyQKrEXYSMi4wrjI2irMB8GA1UdIwQYMBaAFN2R
YjtfzoMYH0wUkn7uel8YjeHrMA0GCSqGSIb3DQEBCwUAA4ICAQCi6ysJ4Virm3x8
Emq19JnvF/9oOcoT1DmR+qhIF0hNmTPeje5C2o72d4UrxL7nJ1rDyF5dvzQ50Ku5
eza40x/zK2lAv4AB+amCPiXsiPdKLQDGYKyz0SexhQ5Kwl+IpPAqQbBSZHuMUQTA
VIdQglLUgTTaSmo39VvHC9DMiI55TcpBvsqDJ2DhCTJKuCkWwsBBlbl1DyWvCczt
vE8NAlFpXXDHZpvEzP3kDDB66wXwi9MihGu4a+LFiSleCktNkFMwGb3T3pVIKNQg
FzjH1Q15LSPgIvALnfSfphC6A6NwdAiAKJGSxrA9n1Kd9Iz3HZ9huxAnQjrAh68/
vxwokyaSWq0vFmKGAPATKNHm2aEExpSB6Dh6l1E3+YANJRa/lxzl6PB2k4G1OfmY
SybvvL1D1vy1fohem4gB5eErBnV9pjzkiXeBpoCH0YLtRti4Ru/YJATDDbsoXEd3
xN/o0ZCRe6djxy9Kr3y3X+fUbAgOcBrF9UHWuz4JMUAizJWEPQv3y8MTR4KifSXK
wvVQsZvqeHwpp4GDyNB/tUFJYeF4G2xRSu72ES26g08s0YR3DMLMzzf3MHngJTQn
XV9BNYAitOheIq80yHbq0ErLK1aHzW5ovg/gp3qdG/I48DTSN3UYf+zCbNsneoxo
2QR6gvFfAtJqxySNtcvtfEFhLhN4TQ==
-END CERTIFICATE-
subject=/CN=middleware.athome.priv
issuer=/CN=Puppet CA: puppet4.athome.priv
---
Acceptable client certificate CA names
/CN=Puppet CA: puppet4.athome.priv
---
SSL handshake has read 3656 bytes and written 3699 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol  : TLSv1
Cipher: ECDHE-RSA-AES256-SHA
Session-ID: 85F7EADC8638B92FB19C5E2FB6005EA50B95FB63AC4D0B514A15FA70D9F70D63
Session-ID-ctx: 
Master-Key: 
561B8C015947AEEB117EAD92E57C2A99429F5A7D434C6094CC89987C774C3F2F565C467CC322547DBEBC0359B411A8C3
Key-Arg   : None
PSK identity: None
PSK identity hint: None
Start Time: 1442425360
Timeout   : 300 (sec)
Verify return code: 0 (ok)
---
Q
DONE
ALL IS OK


Now, I upgrade the "puppet-agent" package :


root@client-trusty:~# apt-get install puppet-agent
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be upgraded:
  puppet-agent
1 upgraded, 0 newly installed, 0 to remove and 7 not upgraded.
Need to get 9,901 kB of archives.
After this operation, 1,188 kB of additional disk space will be used.
Get:1 http://apt.puppetlabs.com/ trusty/PC1 puppet-agent amd64 1.2.4-1trusty 
[9,901 kB]
Fetched 9,901 kB in 0s (19.4 MB/s) 
(Reading database ... 89683 files and directories currently installed.)
Preparing to unpack .../puppet-agent_1.2.4-1trusty_amd64.deb ...

Re: [Puppet Users] Puppetmaster performance degradation after update to 3.8.2

2015-09-16 Thread Josh Cooper
Hi Adam,

On Wed, Sep 16, 2015 at 3:47 AM, Adam Winberg 
wrote:

> Upgraded from 3.7.3 to 3.8.2 and have after that had very slow compilation
> and file serving from the puppet master. We're running our puppetmaster
> with apache/passenger, ca. 900 hosts. Complete puppet runs earlier took
> 10-15s and after update take 30-300s. Very unstable performance.
>
> Even running with just a few clients the runtimes are really slow.
> Decreasing the 'PassengerMaxPoolSize' makes the runs faster, but then it
> cant cope with an increased load.
>
> I have also tried with the jvm puppetserver with roughly the same
> performance (or lack thereof). I noticed the same pattern, if i set
> 'max-active-instances' in puppetserver.conf to 2, I get acceptable
> performance with a handful of clients, but with increased load it doesnt
> cope. If I raise the 'max-active-instances' the performance is even worse.
>
> This is running on an vmware server, 8 cpu and 12GB RAM.
>
> Cant find anything in the release notes that explain this performance
> drops, does anyone recognize the problem?
>
> I have now downgraded to 3.7.3 and my puppet runs are as fast as ever
> again.
>
> Any help appreciated.
>
> Regards
> Adam
>
>
> --
> 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/CAFCL3HvvEC4HA4xD655sAPMBMznVdsqcQCYp5FHn%3D_SQ8TG2qg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

I would take a look at the `--profile` option as described in
https://puppetlabs.com/blog/tune-puppet-performance-profiler, making sure
to update config.ru as needed.

Josh

-- 
Josh Cooper
Developer, Puppet Labs

*PuppetConf 2015 ** is right around the
corner! Join us October 5-9 in Portland, OR. **Register now
**.*

-- 
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/CA%2Bu97umgvfrNbJFeSRk8Rvnxkys-MAaSHEQKCeKqETy1OrXG1w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] Puppetmaster performance degradation after update to 3.8.2

2015-09-16 Thread Adam Winberg
I actually tried the --profile option but never got it to actually record
any 'PROFILE' log data. The logdest and debug flags works as expected, but
no 'PROFILE' entries in the logfile.

On Thu, Sep 17, 2015 at 1:02 AM, Josh Cooper  wrote:

> Hi Adam,
>
> On Wed, Sep 16, 2015 at 3:47 AM, Adam Winberg 
> wrote:
>
>> Upgraded from 3.7.3 to 3.8.2 and have after that had very slow
>> compilation and file serving from the puppet master. We're running our
>> puppetmaster with apache/passenger, ca. 900 hosts. Complete puppet runs
>> earlier took 10-15s and after update take 30-300s. Very unstable
>> performance.
>>
>> Even running with just a few clients the runtimes are really slow.
>> Decreasing the 'PassengerMaxPoolSize' makes the runs faster, but then it
>> cant cope with an increased load.
>>
>> I have also tried with the jvm puppetserver with roughly the same
>> performance (or lack thereof). I noticed the same pattern, if i set
>> 'max-active-instances' in puppetserver.conf to 2, I get acceptable
>> performance with a handful of clients, but with increased load it doesnt
>> cope. If I raise the 'max-active-instances' the performance is even worse.
>>
>> This is running on an vmware server, 8 cpu and 12GB RAM.
>>
>> Cant find anything in the release notes that explain this performance
>> drops, does anyone recognize the problem?
>>
>> I have now downgraded to 3.7.3 and my puppet runs are as fast as ever
>> again.
>>
>> Any help appreciated.
>>
>> Regards
>> Adam
>>
>>
>> --
>> 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/CAFCL3HvvEC4HA4xD655sAPMBMznVdsqcQCYp5FHn%3D_SQ8TG2qg%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> I would take a look at the `--profile` option as described in
> https://puppetlabs.com/blog/tune-puppet-performance-profiler, making sure
> to update config.ru as needed.
>
> Josh
>
> --
> Josh Cooper
> Developer, Puppet Labs
>
> *PuppetConf 2015 ** is right around the
> corner! Join us October 5-9 in Portland, OR. **Register now
> **.*
>
> --
> 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/CA%2Bu97umgvfrNbJFeSRk8Rvnxkys-MAaSHEQKCeKqETy1OrXG1w%40mail.gmail.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/CAFCL3HvcwfOAiY99Qpf3CC%2BnVs6heVtTwzrgyOXzX5X4D-fAsA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.