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. 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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.> > 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.> > 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.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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Sat, Apr 5, 2008 at 12:23 PM, Luke Kanies <luke@madstop.com> wrote:> > 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.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.>> > > > 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Hi>> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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. 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 --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
For those of us lazy enough to not use environments, it doesn''t really matter what the environment is. 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.christensen@maxnet.co.nz| www.maxnet.co.nz -----Original Message----- From: puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] On Behalf Of Luke Kanies Sent: Monday, 7 April 2008 4:30 a.m. To: puppet-users@googlegroups.com Subject: [Puppet Users] Re: enviroment default setting 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. 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 --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Sun, Apr 6, 2008 at 5:11 AM, Peter Meier <peter.meier@immerda.ch> wrote:> 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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 7, 2008, at 9:30 AM, Evan Hisey wrote:> 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 --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Sun, Apr 6, 2008 at 11:30 AM, Luke Kanies <luke@madstop.com> wrote:> > 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?I vote for production as default.> > > > > > 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. >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? 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 7, 2008, at 10:46 AM, Evan Hisey wrote:>> >> 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 --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Sun, Apr 6, 2008 at 10:30 AM, Luke Kanies <luke@madstop.com> wrote:> > 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 think "development" is a perfectly acceptable default for those who 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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. - Jeff jtimberman wrote:> > I think "development" is a perfectly acceptable default for those who > 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.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, Apr 7, 2008 at 1:21 PM, jtimberman <grumpysmurf@gmail.com> wrote:> > On Sun, Apr 6, 2008 at 10:30 AM, Luke Kanies <luke@madstop.com> wrote: > > > > 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 think "development" is a perfectly acceptable default for those who > 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.I can understands most of the argument here, except is not the 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) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 7, 2008, at 1:51 PM, Jeff Adams wrote:> 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. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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. Dean -- Dean Wilson http://www.unixdaemon.net Profanity is the one language all programmers understand --- Anon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 8, 2008, at 3:01 AM, Dean Wilson wrote:> > 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 --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Hi>> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, Apr 8, 2008 at 10:34 AM, Peter Meier <peter.meier@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) > 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, Apr 8, 2008 at 8:59 AM, Evan Hisey <ehisey@gmail.com> wrote:> > On Tue, Apr 8, 2008 at 10:34 AM, Peter Meier <peter.meier@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) > > 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.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.> > > > > 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 Systems Administrator MacOps --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 8, 2008, at 10:34 AM, Peter Meier wrote:> 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 --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---