[Puppet Users] Puppet Experimental Features like parser=future

[shashank]

Hi All,

I was using puppet since the release of puppet 2.6 version in various 
projects.Now came across the "Puppet Experimental Features" in the Puppet 
3.x series  and some of which are really very useful for projects I was 
taking care of. 

My concern is that how much it is safe to use the Puppet Experimental 
Features like parser=future in the production environment as I am using 
puppet 3.7.1.I had already tested this feature on the testing environment 
for a long time and used some of the features frequently like (each($x) |$a 
| {} ).

Now my codes are ready for the production environment, please suggest me 
whether I should go with the puppet parser future feature or should I 
remove the codes supported by these feature from my manifests (Basically 
the feature of iteration over hashes using 'each') ?

Thanks

-- 
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/995dac1c-defb-4523-9be4-2da8cd839eae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Did PE 3.7 kills r10k?

[Johan De Wit]

Hi,

I wrote a post addressing this issue : 
http://johan.koewacht.net/puppet/2015/01/12/R10k-and-PE-Console.html


Any comments are more then welcome.

Grts

Johan


On 27/12/14 20:32, chris mague wrote:

Vadym,

I ran into the same problem and was able to work around as follows 
with the caveat that it's unsupported:


sudo su - pe-postgres
psql
\connect pe-classifier
select * from groups;
# write everything down
update groups set environment_name='agent-specified' where 
environment_name='production';

# then set the last column to 't' if you have any other groups.

You may need to specify the override




On Saturday, December 27, 2014 7:59:55 AM UTC-8, Vadym Chepkov wrote:



On Saturday, December 27, 2014 9:44:44 AM UTC-5, Martin Alfke wrote:

Hi Vadym,

the PE node classifier is an ENC.
This ENC sets environments per nodes as an authority. Nodes
can no longer switch their environments if you use an ENC with
environment parameters set.

You still have the technical possibility to continue using
manifests based node classification and therefor you can
continue using r10k.
You will only loose the environment enforcement via ENC.

hth,

Martin



Hi Martin,

That's the problem,  PE 3.7 creates 'default' group, which can't
be edited and this group enforces 'production' environment for
each node.
You can create a new group and override environment there, but you
would have to do it for each single topic branch you create in git
and development team can't work on more than one topic branches
from the same node. This makes development process extremely
difficult.

Regards,
Vadym




--
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/30babbee-4d8e-467e-90ea-c3d0af8f446c%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.



--
Johan De Wit

Open Source Consultant

Red Hat Certified Engineer  (805008667232363)
Puppet Certified Professional 2013/2014 (PCP006)
blog : http://johan.koewacht.net/
_
 
Open-Future Phone +32 (0)2/255 70 70

Zavelstraat 72  Fax   +32 (0)2/255 70 71
3071 KORTENBERG Mobile+32 (0)474/42 40 73
BELGIUM http://www.open-future.be
_
 



Next Events:
Bacula Administrator 1 | 
http://www.open-future.be/bacula-administrator-i-training-13th-till-15th-january
Puppet Fundamentals | 
http://www.open-future.be/puppet-fundamentals-training-26th-till-28th-january
Puppet Architect | 
http://www.open-future.be/puppet-architect-training-29th-till-30th-january
Linux Training | http://www.open-future.be/linux-training-9th-till-13th-february
Puppet Practitioner | 
http://www.open-future.be/puppet-practitioner-training-17th-till-19th-february
Bacula Administrator 1 | 
http://www.open-future.be/bacula-administrator-i-training-24th-till-26th-february
Subscribe to our newsletter | http://eepurl.com/BUG8H

--
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/54BF7FF3.6090603%40open-future.be.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet Experimental Features like parser=future

[Henrik Lindberg]

On 2015-21-01 11:25, shashank wrote:

Hi All,

I was using puppet since the release of puppet 2.6 version in various
projects.Now came across the "Puppet Experimental Features" in the
Puppet 3.x series  and some of which are really very useful for projects
I was taking care of.

My concern is that how much it is safe to use the Puppet Experimental
Features like parser=future in the production environment as I am using
puppet 3.7.1.I had already tested this feature on the testing
environment for a long time and used some of the features frequently
like (each($x) |$a | {} ).

Now my codes are ready for the production environment, please suggest me
whether I should go with the puppet parser future feature or should I
remove the codes supported by these feature from my manifests (Basically
the feature of iteration over hashes using 'each') ?



Today, a release of Puppet 4.0.0 is around the corner together with a 
release of 3.7.4. In Puppet 4.0.0 the future parser and evaluator in 3.x 
is the default, and the 3.7.4 release with --parser future turned on is 
as close as we can get to 4.0.0 behavior. This for the purpose of being 
a migration path from 3x to 4x (i.e. run 3x with future parser turned on 
to fix issues before doing the migration to 4.0).


Since 'future parser' is available as an experimental feature its 
features are not subject to semver and there may be breaking changes 
between minor versions.


Over the 3x series there were naturally more issues and risk at the 
beginning. The 3.7.3 release is quite decent, but it has a couple of 
bugs related to collection of resources that have been fixed in 3.7.4.


Also, since it is marked 'experimental', it is really up to careful 
testing on the user's part before making a decision to run with future 
parser turned on in production - e.g. spotify has been testing future 
parser versions all along, and are now running it in production with 3.7.3.


The best is naturally to use 3.7.4 with future parser. It is due any day 
now.


On the question if it "is safe to use in production" the answer is "yes, 
if you have tested" as there are no known issues that would make us say 
it is unsafe. There are however language changes that if you are 
extremely unlucky and have "old messy puppet code" you may silently get 
a different result without errors being raised. This is the reason that 
careful testing has to be done. Other changes may cause parse/validation 
or runtime errors - those are considered safe as it alerts you to what 
you need to fix.


If you decide to try a version of 3.7.x < 3.7.4 it is prudent to check 
issue tickets marked DSL fixed in later releases so you know what could 
potentially bite you. (It is probably easier to upgrade to latest 3.7 
though :-)


Hope that helps you making a decision
Regards
- henrik

--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

--
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/m9o0m0%24qb3%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet Experimental Features like parser=future

[shashank]

Thanks Henrik,

It's really helpful.


On Wednesday, January 21, 2015 at 4:27:27 PM UTC+5:30, Henrik Lindberg 
wrote:
>
> On 2015-21-01 11:25, shashank wrote: 
> > Hi All, 
> > 
> > I was using puppet since the release of puppet 2.6 version in various 
> > projects.Now came across the "Puppet Experimental Features" in the 
> > Puppet 3.x series  and some of which are really very useful for projects 
> > I was taking care of. 
> > 
> > My concern is that how much it is safe to use the Puppet Experimental 
> > Features like parser=future in the production environment as I am using 
> > puppet 3.7.1.I had already tested this feature on the testing 
> > environment for a long time and used some of the features frequently 
> > like (each($x) |$a | {} ). 
> > 
> > Now my codes are ready for the production environment, please suggest me 
> > whether I should go with the puppet parser future feature or should I 
> > remove the codes supported by these feature from my manifests (Basically 
> > the feature of iteration over hashes using 'each') ? 
> > 
>
> Today, a release of Puppet 4.0.0 is around the corner together with a 
> release of 3.7.4. In Puppet 4.0.0 the future parser and evaluator in 3.x 
> is the default, and the 3.7.4 release with --parser future turned on is 
> as close as we can get to 4.0.0 behavior. This for the purpose of being 
> a migration path from 3x to 4x (i.e. run 3x with future parser turned on 
> to fix issues before doing the migration to 4.0). 
>
> Since 'future parser' is available as an experimental feature its 
> features are not subject to semver and there may be breaking changes 
> between minor versions. 
>
> Over the 3x series there were naturally more issues and risk at the 
> beginning. The 3.7.3 release is quite decent, but it has a couple of 
> bugs related to collection of resources that have been fixed in 3.7.4. 
>
> Also, since it is marked 'experimental', it is really up to careful 
> testing on the user's part before making a decision to run with future 
> parser turned on in production - e.g. spotify has been testing future 
> parser versions all along, and are now running it in production with 
> 3.7.3. 
>
> The best is naturally to use 3.7.4 with future parser. It is due any day 
> now. 
>
> On the question if it "is safe to use in production" the answer is "yes, 
> if you have tested" as there are no known issues that would make us say 
> it is unsafe. There are however language changes that if you are 
> extremely unlucky and have "old messy puppet code" you may silently get 
> a different result without errors being raised. This is the reason that 
> careful testing has to be done. Other changes may cause parse/validation 
> or runtime errors - those are considered safe as it alerts you to what 
> you need to fix. 
>
> If you decide to try a version of 3.7.x < 3.7.4 it is prudent to check 
> issue tickets marked DSL fixed in later releases so you know what could 
> potentially bite you. (It is probably easier to upgrade to latest 3.7 
> though :-) 
>
> Hope that helps you making a decision 
> Regards 
> - henrik 
>
> -- 
>
> Visit my Blog "Puppet on the Edge" 
> http://puppet-on-the-edge.blogspot.se/ 
>
>

-- 
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/e4fb2c64-59f8-43b4-964e-5593c067fab6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Monitoring apache::vhost

[Jonathan Gazeley]

Hi folks,

My legacy puppet code includes a manifest called httpd::vhost which 
installs an Apache vhost and does some extra things, like add Nagios checks.


I'm now removing my old httpd::vhost module and switching to 
puppetlabs/apache, and using apache::vhost. This means I now have to 
manually remember to add a Nagios check for each instance of apache::vhost.


Is there a neat way to automatically have something insert Nagios checks 
for each instance of apache::vhost without manual intervention?


Thanks,
Jonathan

--
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/54BF90B7.6050504%40bristol.ac.uk.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] inherits deprecated in puppet 4.x

[Erik Dalén]

Note that you can also just put the standard classes (and variables)
directly in the top scope. No real need to encapsulate them inside a node
scope (unless you are overriding the value of facts in the manifest, but
that seems like a pretty bad idea anyway).

A minor difference is also that resources that are inside a node scope will
automatically get tagged with the certname of the node, but resources and
classes in top scope won't. But that automatic tagging is mostly useless
and a waste of space in PuppetDB IMO.




On Mon Jan 12 2015 at 2:56:06 PM jcbollinger 
wrote:

>
>
> On Friday, January 9, 2015 at 3:34:41 PM UTC-6, RIlindo Foster wrote:
>>
>> It seems you are using this as a way to classify nodes. Your best option
>> is to use  an ENC (Foreman or Hiera) to classify your nodes, ideally using
>> the roles and profiles pattern to abstract your modules.
>>
>>
>
> I strongly disagree. If you don't otherwise need (or want) an ENC, then
> this is not a good reason to start using one.  Changing the default node to
> a class and 'include'ing it, as Peter suggested, is much easier, and mostly
> equivalent to node inheritance.  If you use node-scoped variables in the
> (original) default node, however, then you have more work to do any way
> around.
>
>
> 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/d657abc7-35ba-4c88-84fb-0f714853aa69%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/CAAAzDLf8h85qCG0_UG5x-6mzULQp4MLPNNJvmEFux_eVgXsPdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Announce: Puppet Server 1.0.2 available!

[Trevor Vaughan]

Hi Oli,

I've been using Puppet Server for a while now and it works a champ.

The only real issue is getting used to the amount of time that it takes to
start.

Trevor

On Mon, Jan 19, 2015 at 9:43 AM, Oliver Schad <
puppet.oliver.sc...@automatic-server.com> wrote:

> Hi everybody,
>
> does somebody already use the puppet server at all? Can you share your
> experiences?
>
> Best Regards
> Oli
>
> --
> 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/20150119154355.181e2b73%40dickeberta.automatic-server.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

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

Re: [Puppet Users] Re: File 'replace => false' doesn't match my expectations...

[jcbollinger]

On Tuesday, January 20, 2015 at 1:28:33 PM UTC-6, Marc necro'd an ancient 
thread:
>
> Using 'replace => false' should not trigger a checksum operation but given 
> the time it takes with big files I think it does.
> Does it make sense to perform checksum when 'replace' is set to false?
>
> *  exec { 'wget -O - http://repo01.demo.lan/coreos/coreos_qemu.img.bz2 
>  | bzcat > 
> /root/coreos/core01/core01.img':*
> *path=> '/usr/bin',*
> *creates => '/root/coreos/core01/core01.img',*
> *  }*
>
> *  file { [ '/root/coreos/core02/core02.img',*
> *   '/root/coreos/core03/core03.img',*
> *   '/root/coreos/core04/core04.img' ]:*
> *ensure  => file,*
> *replace => false,*
> *source  => '/root/coreos/core01/core01.img',*
> *owner   => 'root',*
> *group   => 'root',*
> *mode=> '0644',*
> *  }*
>
>

I appreciate that you've been searching the archives for information about 
your issue.  Nevertheless, when you have a new question (which yours is), 
please start a new thread.

I agree that it doesn't seem useful to checksum a File configured with 
"replace => false".  If you can confirm that checksums are in fact being 
computed, then you should consider filing a bug report 
.  In any case, a 
work-around and possible diagnostic test would be to set "checksum => 
'mtime'" on your affected File resources.  A straight workaround with no 
diagnostic value would be to simply set "checksum => 'none'".


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/3af3ea0c-0d5a-4bc6-9d5e-1f0e107bed71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: invoke-rc.d errors - what happened to this system?

[jcbollinger]

On Tuesday, January 20, 2015 at 3:42:10 PM UTC-6, JonY wrote:
>
> Looking at the debug log it appears that puppet is calling 
> '/etc/init.d/dnsmasq status' before this message appears.. but when I enter 
> the same command subsequently I'm told ''running'. and nothing else.
>
> Similar messages appear for puppet, ifplugd, apache2.. every service that 
> I monitor with puppet. 
>
> On Tuesday, January 20, 2015 at 12:19:12 PM UTC-8, JonY wrote:
>>
>> Debian 6 machine running 3.7.1. Attempts to run 'puppet agent --test' 
>> give a stream of errors like this:
>>
>> invoke-rc.d: WARNING: 'invoke-rc.d dnsmasq start' called
>> invoke-rc.d: during shutdown sequence.
>> invoke-rc.d: enabling safe mode: initscript policy layer disabled.
>>
>>
>> If I do a 'service dnsmasq start' after this it works ok with no error 
>> messages. 
>>
>> 'runlevel' reports '3 6'.
>>
>> The system is apparently bolluxed somehow but I'm not sure what's wrong. 
>> Where should I look?
>>
>

I have little experience with Debian, but your system apparently thinks it 
is in the middle of restarting (the current runlevel is 6).  That dovetails 
with the messages you receive about services being started while a shutdown 
is in progress.

I cannot explain why you get diagnostics during the Puppet run, but not 
from the command line.  My best guess would be that Puppet is using a 
different method to attempt to start services than the 'service' command.  
This would be a function of the 'provider' selected to manage Service 
resources on the affected machine; which you can find at the beginning of 
the agent's log when you run with --debug messages enabled.

I think the first direction to investigate, however, is why the machine 
thinks it's shutting down.  I predict that the agent will stop emitting 
such the diagnostics you observed when you get the runlevel fixed, which 
you probably can achieve most easily by restarting the machine.  Do verify 
that the runlevel is correct immediately after system start, and do monitor 
whether an agent run actually causes that runlevel issue.  It may be, 
however, that the issue arose from a one-off event.


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/4920f38d-c02a-4f8a-8ab4-62f8dbfe8c95%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Announce: Puppet Server 1.0.2 available!

[Mike Hendon]

Triggering a refresh when you've changed manifests is also a pain.

On Wednesday, 21 January 2015 13:02:38 UTC, Trevor Vaughan wrote:
>
> Hi Oli,
>
> I've been using Puppet Server for a while now and it works a champ.
>
> The only real issue is getting used to the amount of time that it takes to 
> start.
>
> Trevor
>
> On Mon, Jan 19, 2015 at 9:43 AM, Oliver Schad <
> puppet.ol...@automatic-server.com > wrote:
>
>> Hi everybody,
>>
>> does somebody already use the puppet server at all? Can you share your
>> experiences?
>>
>> Best Regards
>> Oli
>>
>> --
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/20150119154355
>> .181e2b73%40dickeberta.automatic-server.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699
> tvau...@onyxpoint.com 
>
> -- This account not approved for unencrypted proprietary information --
>  

-- 
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/8b5ca648-a220-4cf4-a278-992a8817b0fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Puppet with Satellite 6. Customize puppet modules

[Biju Joseph]

Puppet with Satellite 6. How to configure puppet modules for different 
hosts group. For example with I want to manage resolv.conf and ntp.conf 
with puppet, but wanted to give different values based on server group. For 
example I have a server group for Dallas servers in which I have a specific 
set of DNS and NTP servers. For another server group for Austin servers I 
have different set of DNS and NTP. How I can accomplish this with puppet 
modules.

-- 
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/d1de57df-ba6d-4106-add4-4a212b64ab81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] inherits deprecated in puppet 4.x

[Alessandro Franceschi]

Given that:
- I've used nodes inheritance with profit for years, in the past
- Now I mostly prefer a nodeless setup (with or without ENC)
let me spam the list with a fragment of my book Extending Puppet on the 
topic, as it contains some (controversial?) points of view I'm curious to 
hear opinions about (note: it was written before knowing about Puppet4 
removal of nodes' inheritance, so now, I would not use it in any case) :

  Node inheritance done right 

Node inheritance has a bad reputation. All the Puppet books around, even 
the ones of a giant like James Turnbull, and the official Puppet Labs 
documentation describe it as a bad practice, and this puzzles me, as I had 
successfully used this approach for years. 

The main problem, I think, has been a documentation issue, as it's not well 
explained to users that node inheritance makes sense when used to assign 
variables, but it is dangerous when used to manage class grouping. 

Let's see an example of a wrong approach to node inheritance: 

   node default {
 include general

   }
   node 'it' inherits default {

$zone = 'it'
   } 

   node 'web01.it.example.com' inherits 'it' {
 $role = 'web'
 include role::web

} 

The issue in this extremely simplified example is that when Puppet parses 
general, it hasn't set the $role and $zone values, and the result for the 
resources declared in general, depending on them, would probably not be 
what was expected. 

When node inheritance is used only to set and eventually override variables 
and not to include classes, none of these problems are present: 

   node basenode {
 dns_server = '8.8.8.8'

   }
   node 'it' inherits basenode {

  $zone = 'it'
$dns_server = '1.2.3.4'
   }

   node 'web01.it.example.com' inherits 'it' {
 $role = 'web'
 include site

} 
  
Now, I would not use this approach anymore, as it requires an include line 
for each node, and it sets variables at node scope. This implies that while 
they can be used in the node's classes, we cannot refer to them with a 
fully qualified name, and so, for example, we cannot use them on a Hiera 
hierarchy.

Still, in situations where an ENC and Hiera are not used and the node names 
are not descriptive, this is a working and effective way to identify nodes 
using the benefits of a hierarchical structure, based on inheritance. 
 

On Wednesday, January 21, 2015 at 1:38:23 PM UTC+1, Erik Dalén wrote:
>
> Note that you can also just put the standard classes (and variables) 
> directly in the top scope. No real need to encapsulate them inside a node 
> scope (unless you are overriding the value of facts in the manifest, but 
> that seems like a pretty bad idea anyway).
>
> A minor difference is also that resources that are inside a node scope 
> will automatically get tagged with the certname of the node, but resources 
> and classes in top scope won't. But that automatic tagging is mostly 
> useless and a waste of space in PuppetDB IMO.
>
>
>
>
> On Mon Jan 12 2015 at 2:56:06 PM jcbollinger  > wrote:
>
>>
>>
>> On Friday, January 9, 2015 at 3:34:41 PM UTC-6, RIlindo Foster wrote:
>>>
>>> It seems you are using this as a way to classify nodes. Your best option 
>>> is to use  an ENC (Foreman or Hiera) to classify your nodes, ideally using 
>>> the roles and profiles pattern to abstract your modules.
>>>
>>>
>>
>> I strongly disagree. If you don't otherwise need (or want) an ENC, then 
>> this is not a good reason to start using one.  Changing the default node to 
>> a class and 'include'ing it, as Peter suggested, is much easier, and mostly 
>> equivalent to node inheritance.  If you use node-scoped variables in the 
>> (original) default node, however, then you have more work to do any way 
>> around.
>>
>>
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/d657abc7-35ba-4c88-84fb-0f714853aa69%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/5fe91224-7062-4529-b95a-3e62e59128b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Announce: Puppet Server 1.0.2 available!

[Tony Thayer]

I've been using it in testing and so far so good. It is pretty heavy on 
resources and it takes somewhere around five minutes to start on the VM I'm 
using, but it has been picking up changes to my manifests almost instantly. 
Previously I would have to manually restart the puppetmaster service almost 
half the time when I wanted a change to take effect.

On Monday, January 19, 2015 at 7:48:09 AM UTC-8, oschad wrote:
>
> Hi everybody, 
>
> does somebody already use the puppet server at all? Can you share your 
> experiences? 
>
> Best Regards 
> Oli 
>

-- 
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/2c192d8f-0270-48d5-b8eb-4da004485926%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Partial management of /etc/hosts.allow / Augeas and Arrays

[Barry Gestwicki]

I finally got to give this a whirl and it worked beautifully!  Thanks again 
for your advice (as well as for exposing me to a feature I wasn't aware 
of), Ian, and have a great day!

On Sunday, January 18, 2015 at 8:01:30 PM UTC-6, ianm wrote:
>
> On Fri, 2015-01-16 at 08:27 -0800, Barry Gestwicki wrote: 
>
> > 
> > 3.) Augeas / Type - This seems to be my best option thus far. 
> > However, I've ran in to a bit of a snag in how to get an array to work 
> > with Augeas resource declarations within a defined type.  When I 
> > execute the sample code below, what I get is an entire "blob" where my 
> > resulting line in /etc/hosts.allow is something like "sshd: 
> > 1.1.1.2.2.2.3.3.3.", instead of the desired and expected end-result of 
> > "sshd: 1.1.1., 2.2.2., 3.3.3.".   
> > 
> You could assemble your augeas changes in a template and pass the result 
> to augeas with: 
>
>changes => template('tcpwrappers/hosts.allow.erb') 
>
> (I don't use that for tcpwrappers but I do for other modules. 
> The call to a template will be slower but you can assemble 
> a complex set of augeas changes more easily and combine all 
> the changes for a file into one augeas resource.) 
>
>
> -- 
> Ian 
>

-- 
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/f75fe045-03dc-42d5-a095-d17b3a260912%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: File 'replace => false' doesn't match my expectations...

[Marc]

I have filed a ticked: https://tickets.puppetlabs.com/browse/PUP-3866

Thank you,
Marc

On Wednesday, January 21, 2015 at 2:56:20 PM UTC+1, jcbollinger wrote:
>
>
>
> On Tuesday, January 20, 2015 at 1:28:33 PM UTC-6, Marc necro'd an ancient 
> thread:
>>
>> Using 'replace => false' should not trigger a checksum operation but 
>> given the time it takes with big files I think it does.
>> Does it make sense to perform checksum when 'replace' is set to false?
>>
>> *  exec { 'wget -O - http://repo01.demo.lan/coreos/coreos_qemu.img.bz2 
>>  | bzcat > 
>> /root/coreos/core01/core01.img':*
>> *path=> '/usr/bin',*
>> *creates => '/root/coreos/core01/core01.img',*
>> *  }*
>>
>> *  file { [ '/root/coreos/core02/core02.img',*
>> *   '/root/coreos/core03/core03.img',*
>> *   '/root/coreos/core04/core04.img' ]:*
>> *ensure  => file,*
>> *replace => false,*
>> *source  => '/root/coreos/core01/core01.img',*
>> *owner   => 'root',*
>> *group   => 'root',*
>> *mode=> '0644',*
>> *  }*
>>
>>
>
> I appreciate that you've been searching the archives for information about 
> your issue.  Nevertheless, when you have a new question (which yours is), 
> please start a new thread.
>
> I agree that it doesn't seem useful to checksum a File configured with 
> "replace => false".  If you can confirm that checksums are in fact being 
> computed, then you should consider filing a bug report 
> .  In any case, a 
> work-around and possible diagnostic test would be to set "checksum => 
> 'mtime'" on your affected File resources.  A straight workaround with no 
> diagnostic value would be to simply set "checksum => 'none'".
>
>
> 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/90ca988b-f3b5-491a-a2ad-765f5d8524d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Announce: Puppet Server 1.0.2 available!

[Cristian Falcas]

Is there any speed difference in compiling a catalog?

Best regards,
Cristian


On Wed, Jan 21, 2015 at 8:27 PM, Tony Thayer  wrote:
> I've been using it in testing and so far so good. It is pretty heavy on
> resources and it takes somewhere around five minutes to start on the VM I'm
> using, but it has been picking up changes to my manifests almost instantly.
> Previously I would have to manually restart the puppetmaster service almost
> half the time when I wanted a change to take effect.
>
> On Monday, January 19, 2015 at 7:48:09 AM UTC-8, oschad wrote:
>>
>> Hi everybody,
>>
>> does somebody already use the puppet server at all? Can you share your
>> experiences?
>>
>> Best Regards
>> Oli
>
> --
> 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/2c192d8f-0270-48d5-b8eb-4da004485926%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/CAMo7R_cmj_%2B_sWsKJnq3bzvwpLg4_6__2PdL_K5DwD-34iE2Ow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Dynamic / nested / setting a varible with / from a variable in puppet.

[omfg9899]

  Hello all and thanx in advance to anyone that replies to my endless 
headache here.

  I am trying to do a couple of things, and failing miserably. I will touch 
on the most important one for the moment.

 I am trying to set a variable based on a variable.  Effectively a dynamic 
variable.  I can do this in bash all day long. :/ 

class webapps_dt($envir = "${which_envir}", $envir = upcase($envir), 
$agent_name = "WEBAPP_EC2EAST_$envir_SERVICE, $server = 
"collector-somehost.atsome-domain.com", $version="5.5.0") {


  The problem is, I can't figure out for the life of me how to nest or 
embed that variable inside that variable.  I can nest or embed a fact, but 
not another variable.  In case anyone is wondering, the second thing I am 
trying to solve is upper casing the original fact.  What I am searching for 
is the environment in which the machines are built. ( dev / cert / prod ), 
but I want them to be uppercase like the rest of the string.  That has of 
course failed too.  So assuming that envir = DEV, I can't get this to work..

 Any ideas?  Thought?  Miracles?


Thanks,

J

-- 
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/8810c5ab-9342-4ccf-b467-f729e488f516%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.