enviroment default setting
Evan Hisey
wiki page I am reading. They read as follows:
From http://reductivelabs.com/trac/puppet/wiki/ConfigurationReference:
# environment
#
# The environment Puppet is running in. For clients (e.g., puppetd)
this determines the environment itself, which is used to find modules
and much more. For servers (i.e.,
# puppetmasterd)
# this provides the default environment for nodes we know nothing about.
#
# * Default: development
This either reads that the default value for enviroment is
development, which sounds like a scary default value. That means that
clients by default ask for development if not found then go to what
server says to use as default which is also development, and that
unknown enviroments also get development.
From http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments:
# Puppet defaults to not using an environment, and if you do not set
one on either the client or server, then it will behave as though
environments do not exist at all, so you can safely
# ignore this feature if you do not need it.
I take this to mean the default value is null for enviroment when not
set on either the server or the client.
# Valid environment names need to be defined, both server-side and
client-side. This is done via the environments variable defined in
ConfigurationReference
This line just confuses the issue. Do clients and servers both to have
them assigned for it to have an effect? And how do you define the
client side via puppet or can you?
From http://reductivelabs.com/trac/puppet/wiki/CommonModules:
# Configuration
#
# [This needs 0.24 or later]
#
# To setup the environments, add these values to your puppet.conf:
#
# [main]
# # This is the default environment for all clients
# environment=production
#
# [puppetmasterd]
# # specify allowed environments
# environments=production,testing,development
#
# # configure environments
# [development]
# modulepath=$confdir/modules-development:/usr/share/puppet/modules
#
# [testing]
# modulepath=$confdir/modules-testing:/usr/share/puppet/modules
#
# [production]
# modulepath=$confdir/modules-production:/usr/share/puppet/modules
#
Just helped to confuse the whole issue.
Evan
Luke Kanies
>
> Okay I see different possible way this value acts depending on which
> wiki page I am reading. They read as follows:
>
>
> From http://reductivelabs.com/trac/puppet/wiki/ConfigurationReference:
>
> # environment
> #
> # The environment Puppet is running in. For clients (e.g., puppetd)
> this determines the environment itself, which is used to find modules
> and much more. For servers (i.e.,
> # puppetmasterd)
> # this provides the default environment for nodes we know nothing
> about.
> #
> # * Default: development
>
> This either reads that the default value for enviroment is
> development, which sounds like a scary default value. That means that
> clients by default ask for development if not found then go to what
> server says to use as default which is also development, and that
> unknown enviroments also get development.
I don't understand why this is a scary default.
>
> From http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments
> :
>
> # Puppet defaults to not using an environment, and if you do not set
> one on either the client or server, then it will behave as though
> environments do not exist at all, so you can safely
> # ignore this feature if you do not need it.
>
> I take this to mean the default value is null for enviroment when not
> set on either the server or the client.
This page is now incorrect, but it was correct when I wrote it. Can
someone update it?
>
> # Valid environment names need to be defined, both server-side and
> client-side. This is done via the environments variable defined in
> ConfigurationReference
>
> This line just confuses the issue. Do clients and servers both to have
> them assigned for it to have an effect? And how do you define the
> client side via puppet or can you?
Essentially, anyone using the environment has to have the valid list
set. I don't know how well that will work in the end, but it seemed
reasonable to have a fixed list of valid environments.
How so? This is how you configure environments.
--
Never regret. If it's good, it's wonderful. If it's bad, it's
experience. -- Victoria Holt
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
Evan Hisey
>
> On Apr 4, 2008, at 5:54 PM, Evan Hisey wrote:
>
> >
> > Okay I see different possible way this value acts depending on which
> > wiki page I am reading. They read as follows:
> >
> >
> > From http://reductivelabs.com/trac/puppet/wiki/ConfigurationReference:
> >
> > # environment
> > #
> > # The environment Puppet is running in. For clients (e.g., puppetd)
> > this determines the environment itself, which is used to find modules
> > and much more. For servers (i.e.,
> > # puppetmasterd)
> > # this provides the default environment for nodes we know nothing
> > about.
> > #
> > # * Default: development
> >
> > This either reads that the default value for enviroment is
> > development, which sounds like a scary default value. That means that
> > clients by default ask for development if not found then go to what
> > server says to use as default which is also development, and that
> > unknown enviroments also get development.
>
> I don't understand why this is a scary default.
it. Bring up new machines to default to experimental code just strikes
me as a bad idea. You could easily end up with a hosed machine right
off the bat. I would have expected the default environment to be one
that defaults the machines to a known to be stable environment. A
production environment is generally considered to be stable.
Upon thinking about this more. Would not the best choice be to default
to a null value and let the puppetmaster assign the environment value
if it has one set? This way clients with no value get assigned what
ever the server thinks is the stable or default enviroment. Then
should the client have a value set, or assigned at runtime, that value
can then override the server setting as it currently does.
>
> >
> > From http://reductivelabs.com/trac/puppet/wiki/CommonModules:
> >
> > # Configuration
> > #
> > # [This needs 0.24 or later]
> > #
> > # To setup the environments, add these values to your puppet.conf:
> >........
> > #
> > # [production]
> > # modulepath=$confdir/modules-production:/usr/share/puppet/modules
> > #
> >
> > Just helped to confuse the whole issue.
>
> How so? This is how you configure environments.
This was a contrast to the section above that indicated both server
and the client have to be set for it to work. I took this to mean, in
the context of the page, that only the server side needs to be set.
Evan
Peter Meier
>> I don't understand why this is a scary default.
> The development environment is the most like to have broken things in
> it. Bring up new machines to default to experimental code just strikes
> me as a bad idea. You could easily end up with a hosed machine right
> off the bat. I would have expected the default environment to be one
> that defaults the machines to a known to be stable environment. A
> production environment is generally considered to be stable.
>
> Upon thinking about this more. Would not the best choice be to default
> to a null value and let the puppetmaster assign the environment value
> if it has one set? This way clients with no value get assigned what
> ever the server thinks is the stable or default enviroment. Then
> should the client have a value set, or assigned at runtime, that value
> can then override the server setting as it currently does.
I agree that development is a scary default and also share the opinion
that a default to something like production would be better.
However as far as I understand
http://reductivelabs.com/trac/puppet/wiki/CommonModules#configuration
you can override the global default (development) on the server (as if
the client is sending no environment, the server will choose this one).
And therefore you need to define the default only once. So not a big
deal the end. Or I am now confused as well?
> >
>> > From http://reductivelabs.com/trac/puppet/wiki/CommonModules:
>> >
>> > # Configuration
>> > #
>> > # [This needs 0.24 or later]
>> > #
>> > # To setup the environments, add these values to your puppet.conf:
>> >........
>> > #
>> > # [production]
>> > # modulepath=$confdir/modules-production:/usr/share/puppet/modules
>> > #
>> >
>> > Just helped to confuse the whole issue.
>>
>> How so? This is how you configure environments.
> This was a contrast to the section above that indicated both server
> and the client have to be set for it to work. I took this to mean, in
> the context of the page, that only the server side needs to be set.
I understand this as well that only the server side need to be set, as
it is withing the [puppetmaster]-section which only applies to servers.
Or the default environment is within the [main]-section.
So which contrast do you mean? Maybe we/you can clarify and update the
description above.
greets Pete
Luke Kanies
> The development environment is the most like to have broken things in
> it. Bring up new machines to default to experimental code just strikes
> me as a bad idea. You could easily end up with a hosed machine right
> off the bat. I would have expected the default environment to be one
> that defaults the machines to a known to be stable environment. A
> production environment is generally considered to be stable.
I'm amenable to this change, I guess, although I must say that the
thought of a brand new machine being broken because it's in dev
instead of prod doesn't scare me that much.
What do others think?
>
> Upon thinking about this more. Would not the best choice be to default
> to a null value and let the puppetmaster assign the environment value
> if it has one set? This way clients with no value get assigned what
> ever the server thinks is the stable or default enviroment. Then
> should the client have a value set, or assigned at runtime, that value
> can then override the server setting as it currently does.
>
If this is a problem for you, please use external nodes. They give
you complete control for how nodes are assigned to environments.
I don't think a null environment is feasible. I started out that way,
but too many aspects of Puppet do and will require environment
information. It's both easier and more sensible to always assume
there's an environment set than to always be testing for whether one
is set.
--
A government that robs Peter to pay Paul can always depend on the
support of Paul. -- George Bernard Shaw
Arjuna Christensen
I personally let Git take care of all of my development/testing/production stuff, and let Puppet be 'dumb' in this sense.
Defaulting to development is fine, providing you haven't setup a development environment with broken stuff in it :)
My 2c, :)
Arjuna Christensen | Systems Engineer
Maximum Internet Ltd
DDI: + 64 9 913 9683 | Ph: +64 9 915 1825 | Fax:: +64 9 300 7227
arjuna.ch...@maxnet.co.nz| www.maxnet.co.nz
Evan Hisey
> I agree that development is a scary default and also share the opinion
> that a default to something like production would be better.
> However as far as I understand
> http://reductivelabs.com/trac/puppet/wiki/CommonModules#configuration
> you can override the global default (development) on the server (as if
> the client is sending no environment, the server will choose this one).
> And therefore you need to define the default only once. So not a big
> deal the end. Or I am now confused as well?
>
I gave this one a test today. Becuase the client sends development by
default, it seems that development will over ride the server
selection of production anyway. This would mean that the client side
setting needs to get set before puppet runs.
>
> > >
> >> > From http://reductivelabs.com/trac/puppet/wiki/CommonModules:
> >> >
> >> > # Configuration
> >> > #
> >> > # [This needs 0.24 or later]
> >> > #
> >> > # To setup the environments, add these values to your puppet.conf:
> >> >........
> >> > #
> >> > # [production]
> >> > # modulepath=$confdir/modules-production:/usr/share/puppet/modules
> >> > #
> >> >
> >> > Just helped to confuse the whole issue.
> >>
> >> How so? This is how you configure environments.
> > This was a contrast to the section above that indicated both server
> > and the client have to be set for it to work. I took this to mean, in
> > the context of the page, that only the server side needs to be set.
>
> I understand this as well that only the server side need to be set, as
> it is withing the [puppetmaster]-section which only applies to servers.
> Or the default environment is within the [main]-section.
> So which contrast do you mean? Maybe we/you can clarify and update the
> description above.
From what Luke described and my test, it seems that the client side
choice is dominate. Which does makes senseor else the clients would
not have the abilty to set enviroments. This leads though to issue of
the clients default being development and my original consern of
bootstraping to a broken enviroment.
Luke Kanies
> I gave this one a test today. Becuase the client sends development by
> default, it seems that development will over ride the server
> selection of production anyway. This would mean that the client side
> setting needs to get set before puppet runs.
Correct. The client always has a value, and if you're using the
default nodes setup, the server always prefers the client's environment.
--
Fallacies do not cease to be fallacies because they become fashions.
--G. K. Chesterton
Evan Hisey
>
> On Apr 5, 2008, at 4:13 PM, Evan Hisey wrote:
>
> > The development environment is the most like to have broken things in
> > it. Bring up new machines to default to experimental code just strikes
> > me as a bad idea. You could easily end up with a hosed machine right
> > off the bat. I would have expected the default environment to be one
> > that defaults the machines to a known to be stable environment. A
> > production environment is generally considered to be stable.
>
> I'm amenable to this change, I guess, although I must say that the
> thought of a brand new machine being broken because it's in dev
> instead of prod doesn't scare me that much.
>
> What do others think?
>
>
> >
> > Upon thinking about this more. Would not the best choice be to default
> > to a null value and let the puppetmaster assign the environment value
> > if it has one set? This way clients with no value get assigned what
> > ever the server thinks is the stable or default enviroment. Then
> > should the client have a value set, or assigned at runtime, that value
> > can then override the server setting as it currently does.
> >
>
>
> If this is a problem for you, please use external nodes. They give
> you complete control for how nodes are assigned to environments.
>
both on line and in Jame's book, I am not sure I like this idea. It
looks like I would be going back to the same stuff I went to puppet to
get away. Also going to external node classifiers appears to change
where and when the node identifcation occurs. When using the internal
node defs. puppet parse them _after_ the site.pp manifest. When using
teh external_node call it parse the nodes _before_ it calls the
manifests. Am I correct?
This does bring up a question though, can enviroments be set in
the internal node defs per node to over ride the site wide settings?
or the site.pp for a site wide setting? If this is possible then that
leads to some more interesting options on how to set up environments.
It also looks like you could use node_terminus = plain and
external_nodes pointed to a fiel with normal node deifinitions in
them.
> I don't think a null environment is feasible. I started out that way,
> but too many aspects of Puppet do and will require environment
> information. It's both easier and more sensible to always assume
> there's an environment set than to always be testing for whether one
> is set.
>
I'll trust your judgement on this one. You wrote the code after all.
Evan
Luke Kanies
>>
>> I'm amenable to this change, I guess, although I must say that the
>> thought of a brand new machine being broken because it's in dev
>> instead of prod doesn't scare me that much.
>>
>> What do others think?
> I vote for production as default.
Heh, clearly; you don't qualify as 'others' in this case, since it was
your idea in the first place. :)
>> If this is a problem for you, please use external nodes. They give
>> you complete control for how nodes are assigned to environments.
>>
> After looking at the descriptions of setting up external nodes,
> both on line and in Jame's book, I am not sure I like this idea. It
> looks like I would be going back to the same stuff I went to puppet to
> get away. Also going to external node classifiers appears to change
> where and when the node identifcation occurs. When using the internal
> node defs. puppet parse them _after_ the site.pp manifest. When using
> teh external_node call it parse the nodes _before_ it calls the
> manifests. Am I correct?
In-manifest nodes are parsed and evaluated at the same time as the
rest of Puppet code. If you use external nodes, they're evaluated
before the rest of the configuration is compiled. This is a feature,
because it allows you to collect the complete class and parameter
lists before any code is compiled.
>
> This does bring up a question though, can enviroments be set in
> the internal node defs per node to over ride the site wide settings?
> or the site.pp for a site wide setting? If this is possible then that
> leads to some more interesting options on how to set up environments.
> It also looks like you could use node_terminus = plain and
> external_nodes pointed to a fiel with normal node deifinitions in
> them.
No, they cannot.
--
I cannot and will not cut my conscience to fit this year's fashions.
-- Lillian Hellman
jtimberman
>
> I'm amenable to this change, I guess, although I must say that the
> thought of a brand new machine being broken because it's in dev
> instead of prod doesn't scare me that much.
>
> What do others think?
wish to use environments.
Simply put, when a new server is built, I don't consider it production
ready, even if the build code (puppet manifest) is validated as
production capable. The system needs to be tested for access and
functionality before it can really be considered capable of running a
production site or service. If you assume that every single time your
box will be perfectly built, you're really just setting yourself up
for explanation to management about why some problem occured.
Especially since the problem can be hardware related, and puppet would
have no way to determine that, or even resolve that.
This may not be particularly common, but I don't think that Luke
should change the default because "your"[1] environment considers a
fresh build production capable, where another site might have a
completely different procedure to deploy production systems.
Lowest common denominator here, development as the default environment
wins. You can always change your environment to default to production
instead.
[1] your in the collective sense, any arbitrary reader.
--
Joshua Timberman
http://tinyurl.com/3er9jo
Jeff Adams
(still running .23), but if there's any chance what-so-ever that puppet
would/could decide to convert any/all of my already deployed servers to
the default, I'd sure rather have them move to the production config
rather than the dev config.
- Jeff
Evan Hisey
development enviroment where you would be developing the new puppet
manifests? Even if a server is not production ready, does it not make
more sense to bring a machine up in the environment that it is going
to be configured and used in to test that it is ready for production?
The site to site variability, production, deployment., staging, etc
was why I had thought that a null setting would be best. But Luke has
pointed out this is an issue, because puppet has things that need an
enviroment setting.
The next best solution would have been for an unset client to
default to whatever the server thinks is the default enviroment. This
is the behavior I though was indicated by
http://reductivelabs.com/trac/puppet/wiki/ConfigurationReference
desciption of the enviroments setting. In case of point this is not,
as client always has an enviroment set. That enviroment currently is
development.
When no enviroment is the default enviroment also appears to be
development. This produces a net result of "ignore" this value when
neither is set on the client or server. If I am correct on this, I can
fix the UsingMultipleEnvironments entry to reflect this.
You know looking at this I see 2 different uses of the enviroments
setting. One view is to seperate developement/predeployment machines
on to one network or enviroment from the production machines. The
second camp is people that want to try and use the environments to
create sort of a test sandbox for puppet manifests. I am squarely in
the second camp becuase I do not have the resources for a nice
dedicated development network (it is right there on my wishlist next
to a "real" back up solution").
Evan
( thinking out loud)
Luke Kanies
> I'll be the first to admit that I'm not up to speed on environments
> (still running .23), but if there's any chance what-so-ever that
> puppet
> would/could decide to convert any/all of my already deployed servers
> to
> the default, I'd sure rather have them move to the production config
> rather than the dev config.
There isn't any chance of that.
--
Brand's Asymmetry:
The past can only be known, not changed. The future can only be
changed, not known.
Dean Wilson
> I think "development" is a perfectly acceptable default for those who
> wish to use environments.
I'd side with that one.
How often do you migrate a live machine to development? How often do you
test in development and then move to live? If the first number's higher
than the second then you may have a process problem ;)
Making a server 'production' ready should be a conscious action, not
something you get if by default.
Dean
--
Dean Wilson http://www.unixdaemon.net
Profanity is the one language all programmers understand
--- Anon
Luke Kanies
>
> On Mon, Apr 07, 2008 at 11:21:27AM -0700, jtimberman wrote:
>> I think "development" is a perfectly acceptable default for those who
>> wish to use environments.
>
> I'd side with that one.
>
> How often do you migrate a live machine to development? How often do
> you
> test in development and then move to live? If the first number's
> higher
> than the second then you may have a process problem ;)
>
> Making a server 'production' ready should be a conscious action, not
> something you get if by default.
For the record, you probably don't want to try to switch a machine
from development to production, just like you wouldn't want to switch
a Debian machine from unstable to stable. Packages and such will be
too much updated, and you wouldn't revert them.
--
I don't always know what I'm talking about, but I'm always pretty much
convinced that I'm right. -- Mojo Nixon
Peter Meier
>> How often do you migrate a live machine to development? How often do
>> you
>> test in development and then move to live? If the first number's
>> higher
>> than the second then you may have a process problem ;)
>>
>> Making a server 'production' ready should be a conscious action, not
>> something you get if by default.
>
> For the record, you probably don't want to try to switch a machine
> from development to production, just like you wouldn't want to switch
> a Debian machine from unstable to stable. Packages and such will be
> too much updated, and you wouldn't revert them.
But maybe you want to switch a machine from stable to unstable, due to
testing issues, needed features or simply version problems. And in my
opinion this example is arguing more for Evan's and my position than the
other. Or we are all completly not understanding each another and it
might be better to start the discussion from scratch.
In my opinion the pro- or con- in this discussion is more a point of
view how you're setup is and you are looking at it.
In my current setup the development enviroment is the one which is used
for development, so these manifests, modules should be rather treated as
unstable (like debian unstable) and therfore I'd rather not like to have
them on a new server which might become a stable server. Therefor I'd
rather be conservative and say every server should be seen as a stable
target until I exactly choose it to be rather unstable.
Like you are setting up a server with debian stable and then apt-pinning
certain packages from unstable as you need newer versions. But you begin
always with the stable one. You are not installing unstable and then
later merging the server or only packages to stable.
However as mentioned this might be my personal (and afaiu Evan's)
specific point of view on the topic of the usage of environments.
Personally I can live with that, that the default environment is set to
development and that I have to set it explicity when running my first
puppet setup. (it doesn't matter to add a cli-parameter more to the
bootstrap script).
I tried to document this a bit and make it maybe a more clear
As well I tried to document a possible goal for environments which I
described in another thread and was asked by DavidS to document this
explanation somewhere:
http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments
Please correct me if I got anything wrong and for sure please correct
the language!
thanks and greets Pete
Evan Hisey
>
> Hi
>
>
> In my current setup the development enviroment is the one which is used
> for development, so these manifests, modules should be rather treated as
> unstable (like debian unstable) and therfore I'd rather not like to have
> them on a new server which might become a stable server. Therefor I'd
> rather be conservative and say every server should be seen as a stable
> target until I exactly choose it to be rather unstable.
> However as mentioned this might be my personal (and afaiu Evan's)
> specific point of view on the topic of the usage of environments.
Quite correct, this indeed my view and you spelled out the situation
very nicely.
> I tried to document this a bit and make it maybe a more clear
> As well I tried to document a possible goal for environments which I
> described in another thread and was asked by DavidS to document this
> explanation somewhere:
>
> http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments
>
> Please correct me if I got anything wrong and for sure please correct
> the language!
Just looked over the UsingMultipleEnvironments page again. I think it
now does a much better job of reflecting the reality of using puupet
and enviroments. Possibly adding a section with a bootstrp example in
multpile enviroments would be a good addition.
>
> thanks and greets Pete>
Evan
Nigel Kersten
On Tue, Apr 8, 2008 at 10:34 AM, Peter Meier <peter...@immerda.ch> wrote:
>
> Hi
>
>
> In my current setup the development enviroment is the one which is used
> for development, so these manifests, modules should be rather treated as
> unstable (like debian unstable) and therfore I'd rather not like to have
> them on a new server which might become a stable server. Therefor I'd
> rather be conservative and say every server should be seen as a stable
> target until I exactly choose it to be rather unstable.
> However as mentioned this might be my personal (and afaiu Evan's)Quite correct, this indeed my view and you spelled out the situation
> specific point of view on the topic of the usage of environments.
very nicely.
This is my view too, and one reason why we submitted this patch for the client to prefer the environment fact over the configuration option when the configuration option is undefined.
http://reductivelabs.com/trac/puppet/ticket/1078
We also treat our development environment as an unstable branch, where all our different platform teams commit to, and then we integrate changes from those environments into our platform specific stable,unstable,testing environments.
We're possibly a different case to a lot of you because the vast number of our puppet clients are actually workstations, not servers.
We regularly switch machines between environment foo_bar_stable to foo_bar_unstable or foo_bar_testing as part of our release process.
Just looked over the UsingMultipleEnvironments page again. I think it
> I tried to document this a bit and make it maybe a more clear
> As well I tried to document a possible goal for environments which I
> described in another thread and was asked by DavidS to document this
> explanation somewhere:
>
> http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments
>
> Please correct me if I got anything wrong and for sure please correct
> the language!
now does a much better job of reflecting the reality of using puupet
and enviroments. Possibly adding a section with a bootstrp example in
multpile enviroments would be a good addition.
>
> thanks and greets Pete>
Evan
--
Nigel Kersten
Systems Administrator
MacOps
Luke Kanies
> But maybe you want to switch a machine from stable to unstable, due to
> testing issues, needed features or simply version problems. And in my
> opinion this example is arguing more for Evan's and my position than
> the
> other. Or we are all completly not understanding each another and it
> might be better to start the discussion from scratch.
I've already said I'd accept this change.
I was waiting for a patch, but to end the conversation, I've pushed
this change.
--
You've achieved success in your field when you don't know whether what
you're doing is work or play. -- Warren Beatty