Hi So I am a bit of a newbie. My assumption was to setup using a master puppet server. But I wanted to make sure that environment was handled by the master puppet - I have control over that and I might not be able to exclude control over the managed box from other users (dam developers !).
I wanted some way to test what I was doing was correct. " If your nodes care deeply about which Puppet environment they are assigned to, then you are doing something wrong. " so I am planning on having atleast a production, sim , inf, non prod and a dev environment. I would presume a box would want to know which environment they are in, because in prod they might be on a certain rpm / module or certain config - lets say for example MOTD. But i might be wrong ? My thought had been to align production environment with production server, infra with infra servers and non prod non infra in the non prod environment. Thanks Alex On 23 June 2016 at 03:26, jcbollinger <john.bollin...@stjude.org> wrote: > > > On Wednesday, June 22, 2016 at 2:21:27 AM UTC-5, Alex Samad wrote: >> >> :))) >> >> seems like after writing this I found my answer >> >> I used >> >> puppet agent --test --verbose >> >> shows me that it is classified as environment alex. thats good. >> >> but >> puppet config print environment >> still show production? so I am guessing the above just looks at the puppet >> config files and as I haven't set environment it defaults to production ! >> >> So the question is, is this the best way to do it ? >> > > > The command ... > > puppet config print environment > > ... indeed does print a value derived from the local Puppet configuration > file. The default for this value is 'production'. Whatever value the > command prints is the value that will be used for the node's environment, > provided that the node-specified environment is not overridden by an > external node classifier running on the master. This allows nodes to > request specific environments, while still affording the master the final > say. No matter whether the setting takes a default or explicit value in the > node's local configuration (which 'puppet config print environment' will > print), that value must be taken as provisional at best. > > If your nodes care deeply about which Puppet environment they are assigned > to, then you are doing something wrong. If you just want to check, however, > then the method you discovered, relying on verbose output from the agent, > seems entirely reasonable. You could perhaps tweak that by adding a --tags > option that filters out all resources, so that you get node information > without applying anything. You cannot get a reliably correct answer without > consulting the master, because the master has the final word on the matter. > > > John > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Puppet Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/puppet-users/mZBLZQKZ0xM/unsubscribe. > To unsubscribe from this group and all its topics, 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/c9d7b296-ff84-4887-9707-5fe4d647fde7%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/CAJ%2BQ1PUaSdp9-y5na9RXZTzXDGk8jrhamp6Mh9VwVYgD_LdUPw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
