Hi All, I have an issue with puppet where we are getting errors on some of our new built servers where the catalogue is trying to render before distributing custom facts that are required to render the catalogue correctly. We are running puppet 2.6.6 server and client. Error: err: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to parse template sudo/sudoers: Could not find value for ''customfact1'' at /etc/puppet/default/modules/sudo/manifests/ init.pp:11 on node host.example.com Its my understanding the ''customfact1'' fact is meant to be transferred to the host as part of the pluginsync process before the catalogue is rendered, but this doesn''t seem to be happening on our new builds from the above error. Does anyone have any insight into the pluginsync/catalogue process and how this is fixable? Cheers, Josh -- 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.
> Its my understanding the ''customfact1'' fact is meant to be transferred > to the host as part of the pluginsync process before the catalogue is > rendered, but this doesn''t seem to be happening on our new builds from > the above error.Yes it works exactyl that way.> Does anyone have any insight into the pluginsync/catalogue process and > how this is fixable?Can you provide more information from a `puppet agent --test` run from your client? Otherwise it''s quite hard to guess what your problem is. ~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 3 August 2011 04:38, josbal <joshua.baldock@gmail.com> wrote:> Hi All, > > I have an issue with puppet where we are getting errors on some of our > new built servers where the catalogue is trying to render before > distributing custom facts that are required to render the catalogue > correctly. > > We are running puppet 2.6.6 server and client. > > Error: > err: Could not retrieve catalog from remote server: Error 400 on > SERVER: Failed to parse template sudo/sudoers: Could not find value > for ''customfact1'' at /etc/puppet/default/modules/sudo/manifests/ > init.pp:11 on node host.example.com > > Its my understanding the ''customfact1'' fact is meant to be transferred > to the host as part of the pluginsync process before the catalogue is > rendered, but this doesn''t seem to be happening on our new builds from > the above error. > > Does anyone have any insight into the pluginsync/catalogue process and > how this is fixable? >The "pluginsync" config var defaults to false. I believe there''s a ticket to default it to true in the future. But until that happens you have a few options: 1. Populate "pluginsync = true" in "puppet.conf" before the first run. 2. Use the "--pluginsync" argument on the first run 3. Possibly use stages to send out the correct "puppet.conf" before any modules use variables that are populated by custom facts. -- 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.
Stages would not really help in this situation since manifests would be evaluated before plugins are synced in this scenario, the pluginsync would need to be set to true for it to be done before the manifest is compiled. One way I combated the problem is to use "production" environment as a node on-boarding set of manifests to get it up to date and prepped for its current environment and I have other environments defined for specific purposes. The other way would be to use if statements to check for the fact being there. If the value is nil, then its not there. From: puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] On Behalf Of Dan Carley Sent: Wednesday, August 03, 2011 5:29 AM To: puppet-users@googlegroups.com Subject: Re: [Puppet Users] pluginsync before catalogue? On 3 August 2011 04:38, josbal <joshua.baldock@gmail.com> wrote: Hi All, I have an issue with puppet where we are getting errors on some of our new built servers where the catalogue is trying to render before distributing custom facts that are required to render the catalogue correctly. We are running puppet 2.6.6 server and client. Error: err: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to parse template sudo/sudoers: Could not find value for ''customfact1'' at /etc/puppet/default/modules/sudo/manifests/ init.pp:11 on node host.example.com Its my understanding the ''customfact1'' fact is meant to be transferred to the host as part of the pluginsync process before the catalogue is rendered, but this doesn''t seem to be happening on our new builds from the above error. Does anyone have any insight into the pluginsync/catalogue process and how this is fixable? The "pluginsync" config var defaults to false. I believe there''s a ticket to default it to true in the future. But until that happens you have a few options: 1. Populate "pluginsync = true" in "puppet.conf" before the first run. 2. Use the "--pluginsync" argument on the first run 3. Possibly use stages to send out the correct "puppet.conf" before any modules use variables that are populated by custom facts. -- 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. -- 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 Aug 3, 9:32 am, "Matthew J Black" <mjbl...@gmail.com> wrote:> The "pluginsync" config var defaults to false. I believe there''s a ticket to > default it to true in the future. But until that happens you have a few > options:[...]> 3. Possibly use stages to send out the correct "puppet.conf" before any > modules use variables that are populated by custom facts.Nope. Fact values are determined once per run, regardless of the number of stages. They are not re-determined between stages. In a similar vein, however, there is 4. Use Puppet environments to distribute the correct puppet.conf to clients that don''t have it, without using any of the modules that require your custom facts. That requires two Puppet runs (using different environments) to reach the target configuration, but that''s what you need for Puppet to solve the problem automatically, because that''s the only way to get node facts re-evaluated. Environments don''t get as much discussion around here nowadays as they used to get, and I suppose that''s because run stages have stolen some of their thunder. Nevertheless, there are scenarios for which environments are better suited than is any other Puppet feature, and some of those are in the area of initial provisioning. John -- 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 Aug 3, 2011, at 9:33 AM, jcbollinger wrote:> > > On Aug 3, 9:32 am, "Matthew J Black" <mjbl...@gmail.com> wrote: >> The "pluginsync" config var defaults to false. I believe there''s a ticket to >> default it to true in the future. But until that happens you have a few >> options: > > [...] > >> 3. Possibly use stages to send out the correct "puppet.conf" before any >> modules use variables that are populated by custom facts. > > Nope. Fact values are determined once per run, regardless of the > number of stages. They are not re-determined between stages. In a > similar vein, however, there is > > 4. Use Puppet environments to distribute the correct puppet.conf to > clients that don''t have it, without using any of the modules that > require your custom facts. That requires two Puppet runs (using > different environments) to reach the target configuration, but that''s > what you need for Puppet to solve the problem automatically, because > that''s the only way to get node facts re-evaluated. > > Environments don''t get as much discussion around here nowadays as they > used to get, and I suppose that''s because run stages have stolen some > of their thunder. Nevertheless, there are scenarios for which > environments are better suited than is any other Puppet feature, and > some of those are in the area of initial provisioning.---- I''ve sort of been scratching at that post but unable to find the proper technique to solve my itch. Obviously can set something like ''environment = staging'' in /etc/puppet/puppet.conf on the master and then it will pick it up but when changing it with an External Nodes Classifier (in my case, foreman), and using an erb template for the clients'' puppet.conf which has environment = <%= environment %> - one would think that this would change but it doesn''t http://projects.puppetlabs.com/issues/3910 so I believe there is some limbo here Craig -- 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 08/03/2011 12:50 PM, Craig White wrote:> an erb template for the clients'' puppet.conf which has environment =<%= environment %>the environment is set on the client, so you''ve implemented a no-op. -- vagn -- 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 Aug 3, 11:50 am, Craig White <craig.wh...@ttiltd.com> wrote:> On Aug 3, 2011, at 9:33 AM, jcbollinger wrote:[...]> > On Aug 3, 9:32 am, "Matthew J Black" <mjbl...@gmail.com> wrote: > >> The "pluginsync" config var defaults to false. I believe there''s a ticket to > >> default it to true in the future. But until that happens you have a few > >> options: > > > [...] > > >> 3. Possibly use stages to send out the correct "puppet.conf" before any > >> modules use variables that are populated by custom facts. > > > Nope. Fact values are determined once per run, regardless of the > > number of stages. They are not re-determined between stages. In a > > similar vein, however, there is > > > 4. Use Puppet environments to distribute the correct puppet.conf to > > clients that don''t have it, without using any of the modules that > > require your custom facts. That requires two Puppet runs (using > > different environments) to reach the target configuration, but that''s > > what you need for Puppet to solve the problem automatically, because > > that''s the only way to get node facts re-evaluated. > > > Environments don''t get as much discussion around here nowadays as they > > used to get, and I suppose that''s because run stages have stolen some > > of their thunder. Nevertheless, there are scenarios for which > > environments are better suited than is any other Puppet feature, and > > some of those are in the area of initial provisioning. > > ---- > I''ve sort of been scratching at that post but unable to find the proper technique to solve my itch. > > Obviously can set something like ''environment = staging'' in /etc/puppet/puppet.conf on the master > > and then it will pick it up but when changing it with an External Nodes Classifier (in my case, foreman), and using an erb template for the clients'' puppet.conf which has environment = <%= environment %> - one would think that this would change but it doesn''t > > http://projects.puppetlabs.com/issues/3910 > > so I believe there is some limbo hereI think you''re saying that the variable ''environment'' is not working for this purpose. I''m not very surprised. Not only is there some ambiguity surrounding whether it should or does represent the client''s requested environment or the server''s imposed environment, but more importantly, *neither* of those is what you actually want: the environment the client should use *next time*. Your ENC or an appropriate class should set that value in a different variable (e.g. targetEnvironment, nextEnvironment, ...), and your template should use that. John -- 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 Dan, Thanks for this information. The --pluginsync option worked as suggested. Will look at adding this to our build process for new servers. I agree it would be good to see pluginsync set to true as default in the future. Cheers, Josh On Aug 3, 7:28 pm, Dan Carley <dan.car...@gmail.com> wrote:> On 3 August 2011 04:38, josbal <joshua.bald...@gmail.com> wrote: > > > > > > > > > > > Hi All, > > > I have an issue with puppet where we are getting errors on some of our > > new built servers where the catalogue is trying to render before > > distributing custom facts that are required to render the catalogue > > correctly. > > > We are running puppet 2.6.6 server and client. > > > Error: > > err: Could not retrieve catalog from remote server: Error 400 on > > SERVER: Failed to parse template sudo/sudoers: Could not find value > > for ''customfact1'' at /etc/puppet/default/modules/sudo/manifests/ > > init.pp:11 on node host.example.com > > > Its my understanding the ''customfact1'' fact is meant to be transferred > > to the host as part of the pluginsync process before the catalogue is > > rendered, but this doesn''t seem to be happening on our new builds from > > the above error. > > > Does anyone have any insight into the pluginsync/catalogue process and > > how this is fixable? > > The "pluginsync" config var defaults to false. I believe there''s a ticket to > default it to true in the future. But until that happens you have a few > options: > > 1. Populate "pluginsync = true" in "puppet.conf" before the first run. > 2. Use the "--pluginsync" argument on the first run > 3. Possibly use stages to send out the correct "puppet.conf" before any > modules use variables that are populated by custom facts.-- 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 Aug 3, 2011, at 2:46 PM, jcbollinger wrote:> On Aug 3, 11:50 am, Craig White <craig.wh...@ttiltd.com> wrote: >> On Aug 3, 2011, at 9:33 AM, jcbollinger wrote: >> >>> Environments don''t get as much discussion around here nowadays as they >>> used to get, and I suppose that''s because run stages have stolen some >>> of their thunder. Nevertheless, there are scenarios for which >>> environments are better suited than is any other Puppet feature, and >>> some of those are in the area of initial provisioning. >> >> ---- >> I''ve sort of been scratching at that post but unable to find the proper technique to solve my itch. >> >> Obviously can set something like ''environment = staging'' in /etc/puppet/puppet.conf on the master >> >> and then it will pick it up but when changing it with an External Nodes Classifier (in my case, foreman), and using an erb template for the clients'' puppet.conf which has environment = <%= environment %> - one would think that this would change but it doesn''t >> >> http://projects.puppetlabs.com/issues/3910 >> >> so I believe there is some limbo here > > > I think you''re saying that the variable ''environment'' is not working > for this purpose. I''m not very surprised. Not only is there some > ambiguity surrounding whether it should or does represent the client''s > requested environment or the server''s imposed environment, but more > importantly, *neither* of those is what you actually want: the > environment the client should use *next time*. Your ENC or an > appropriate class should set that value in a different variable (e.g. > targetEnvironment, nextEnvironment, ...), and your template should use > that.---- sure - that''s what Ohad suggested and it''s somewhat workable. The issue really is that this is a hack workaround. For example, the interface for configuring the environment in foreman allows you to select it but it doesn''t change a thing on the client. So there''s a disconnect when you define the environment in an ENC - the client simply ignores it. I would find a ''next time'' implementation to be perfect and much better than the deafness that it currently has. Craig -- 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 Aug 3, 5:34 pm, Craig White <craig.wh...@ttiltd.com> wrote:> sure - that''s what Ohad suggested and it''s somewhat workable. The issue really is that this is a hack workaround. For example, the interface for configuring the environment in foreman allows you to select it but it doesn''t change a thing on the client. So there''s a disconnect when you define the environment in an ENC - the client simply ignores it.It seems agreed on all sides that Puppet has a longstanding weakness in how the master determines from which environment to serve catalogs and files to clients. It is true that to use environments successfully, you need to work around those issues.> I would find a ''next time'' implementation to be perfect and much better than the deafness that it currently has.I think you may be missing the point there, however. I am not proposing an alternative implementation of what Puppet already has, and to which Foreman (I suppose) provides access out-of-the-box. Rather, I am observing that by using the ''environment'' variable in your puppet.conf template, you are ascribing the wrong meaning to it. The existing definition of that variable (i.e. the node''s ''this time'' environment) is good and useful -- it''s just not what you want for the job at hand. You need something separate for this job, so I suggested you set up a *new* variable with which to define nodes'' ''next time'' environments. I don''t use Foreman, so I''m not sure what would be involved on that front, but I would imagine that it''s not very difficult. On the other hand, I personally wouldn''t use Foreman for this at all, inasmuch as doing so seems to imply that I would need to manually set the desired ''next time'' environment, on a per-node basis, via the Foreman GUI. Instead, I would create a class that gets included in every environment, in which a variable defining the ''next time'' environment is set based on the ''this time'' environment. Your template would be filled from that variable instead of from the global variable ''environment''. John -- 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 Aug 4, 2011, at 12:33 PM, jcbollinger wrote:> > On Aug 3, 5:34 pm, Craig White <craig.wh...@ttiltd.com> wrote: >> sure - that''s what Ohad suggested and it''s somewhat workable. The issue really is that this is a hack workaround. For example, the interface for configuring the environment in foreman allows you to select it but it doesn''t change a thing on the client. So there''s a disconnect when you define the environment in an ENC - the client simply ignores it. > > > It seems agreed on all sides that Puppet has a longstanding weakness > in how the master determines from which environment to serve catalogs > and files to clients. It is true that to use environments > successfully, you need to work around those issues. > > >> I would find a ''next time'' implementation to be perfect and much better than the deafness that it currently has. > > > I think you may be missing the point there, however. I am not > proposing an alternative implementation of what Puppet already has, > and to which Foreman (I suppose) provides access out-of-the-box. > Rather, I am observing that by using the ''environment'' variable in > your puppet.conf template, you are ascribing the wrong meaning to it. > > The existing definition of that variable (i.e. the node''s ''this time'' > environment) is good and useful -- it''s just not what you want for the > job at hand. You need something separate for this job, so I suggested > you set up a *new* variable with which to define nodes'' ''next time'' > environments. > > I don''t use Foreman, so I''m not sure what would be involved on that > front, but I would imagine that it''s not very difficult. On the other > hand, I personally wouldn''t use Foreman for this at all, inasmuch as > doing so seems to imply that I would need to manually set the desired > ''next time'' environment, on a per-node basis, via the Foreman GUI. > Instead, I would create a class that gets included in every > environment, in which a variable defining the ''next time'' environment > is set based on the ''this time'' environment. Your template would be > filled from that variable instead of from the global variable > ''environment''.---- OK - I gather what I would have to do is hack Foreman so that it says ''Environment'' but actually sets another variable that i can use to manipulate the client''s environment. What I was trying to do was to automatically set up a new server to an environment called ''staging'' and when the time was right, use Foreman to switch it to ''production'' Doable - thanks Craig -- 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.
Hey John, I''ve been using environments quite some time with lots of success. I love the idea of creating a bootstrap environment which I never thought of. This gave me an idea to address an issue I''m trying to tackle. A client s using Puppet for their app setup/deployment. We provide the sysops management. We need to isolate app from ops so what I''m thinking is having a cron job that invoke puppet updates twice passing different environment name (i.e. prod_app or prod_opp). Do you see any problem with that? Also you mentioned issues with environments and how to get around them. Could you elaborate on that? Thanks, John -- 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.
It would probably be easier to give the apps team their own module path, that''s what we''re doing anyway. On Aug 5, 2011 11:10 PM, "John Martin" <pbwebguy@gmail.com> wrote:> Hey John, > > I''ve been using environments quite some time with lots of success. I > love the idea of creating a bootstrap environment which I never > thought of. > > This gave me an idea to address an issue I''m trying to tackle. A > client s using Puppet for their app setup/deployment. We provide the > sysops management. We need to isolate app from ops so what I''m > thinking is having a cron job that invoke puppet updates twice passing > different environment name (i.e. prod_app or prod_opp). Do you see > any problem with that? > > Also you mentioned issues with environments and how to get around > them. Could you elaborate on that? > > Thanks, > > John > > -- > 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 topuppet-users+unsubscribe@googlegroups.com.> For more options, visit this group athttp://groups.google.com/group/puppet-users?hl=en.>-- 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 Aug 6, 1:10 am, John Martin <pbweb...@gmail.com> wrote:> Hey John, > > I''ve been using environments quite some time with lots of success. I > love the idea of creating a bootstrap environment which I never > thought of. > > This gave me an idea to address an issue I''m trying to tackle. A > client s using Puppet for their app setup/deployment. We provide the > sysops management. We need to isolate app from ops so what I''m > thinking is having a cron job that invoke puppet updates twice passing > different environment name (i.e. prod_app or prod_opp). Do you see > any problem with that?Yes, actually, I''m afraid I do. It''s one thing to orchestrate a bootstrapping process by using Puppet to progress the client through a sequence of states represented by different environments. In that case, each environment encompasses everything about the node that is managed at the corresponding point in the process. It''s a different thing altogether to apply configurations that alternate between entirely separate sets of managed resources. It would be even worse if the resources managed in the different configurations did not fall into disjoint sets. Conceptually, it''s the wrong model. Practically, it opens the door to a variety of problems, though I don''t currently see any that would be complete showstoppers. Every configuration delivered to your nodes should be complete. For your situation, I like Aaron''s idea of giving the client their own module path to work with. This does not completely isolate their classes from yours, inasmuch as resource declarations and global variable definitions are globally visible, but I think that''s what you actually want. If the app has a different idea about the needed properties of some resource than sysops has, then the two of you need to work out an agreement. Anything else will result in the resource always having the wrong properties from at least one party''s perspective.> Also you mentioned issues with environments and how to get around > them. Could you elaborate on that?I was mostly talking about the matters discussed in Puppet issue #3910, which Craig linked in a much earlier post in this thread. The issue description and the associated comments are a worthwhile read for anyone using environments or considering doing so. As for working around the problems, here are some things that you might consider; 1) IF it is consistent with your security model and other needs, consider always putting nodes in their self-specified environments. In that case, all should be good from a Puppet perspective. 2) If you choose to specify node environments server-side, then beware of setting different module paths for different environments. If you must do so, then structure your manifests so that you can keep all the common path elements at the beginning of the path, in the same order for all environments. Serve plugins and files only out of those paths, or otherwise keep plugins and served files synchronized across all module paths. 3) Do not rely on node environment for access control to files and plugins. 4) Beware of the $::environment variable. Its semantics are not well defined when the client requests one environment and the server chooses a different one for it. I am not personally confident that its current behavior will be retained when issue #3910 is finally resolved, which appears to be slated for Real Soon Now. John -- 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.
John- Thanks for that in-depth feedback. It was great and something to chew on. I''m going to need to evaluate the integrity risk to the isolation requirements of the client to see which practice makes most sense. I do agree that the addition module approach would add to the consistency. It occurred to me that I can have separate source code trees for our own modules there by supporting separate release cycles as well instead of checking the code into the same repo. The Dev team manages 5-6 environments but Ops only has test and production. -John -- 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 Thu, Aug 4, 2011 at 10:33 PM, jcbollinger <John.Bollinger@stjude.org> wrote:> > On Aug 3, 5:34 pm, Craig White <craig.wh...@ttiltd.com> wrote: >> sure - that''s what Ohad suggested and it''s somewhat workable. The issue really is that this is a hack workaround. For example, the interface for configuring the environment in foreman allows you to select it but it doesn''t change a thing on the client. So there''s a disconnect when you define the environment in an ENC - the client simply ignores it. > > > It seems agreed on all sides that Puppet has a longstanding weakness > in how the master determines from which environment to serve catalogs > and files to clients. It is true that to use environments > successfully, you need to work around those issues. > > >> I would find a ''next time'' implementation to be perfect and much better than the deafness that it currently has. > > > I think you may be missing the point there, however. I am not > proposing an alternative implementation of what Puppet already has, > and to which Foreman (I suppose) provides access out-of-the-box. > Rather, I am observing that by using the ''environment'' variable in > your puppet.conf template, you are ascribing the wrong meaning to it. > > The existing definition of that variable (i.e. the node''s ''this time'' > environment) is good and useful -- it''s just not what you want for the > job at hand. You need something separate for this job, so I suggested > you set up a *new* variable with which to define nodes'' ''next time'' > environments. > > I don''t use Foreman, so I''m not sure what would be involved on that > front, but I would imagine that it''s not very difficult. On the other > hand, I personally wouldn''t use Foreman for this at all, inasmuch as > doing so seems to imply that I would need to manually set the desired > ''next time'' environment, on a per-node basis, via the Foreman GUI. > Instead, I would create a class that gets included in every > environment, in which a variable defining the ''next time'' environment > is set based on the ''this time'' environment. Your template would be > filled from that variable instead of from the global variable > ''environment''.for the record, there is an change all of these environments in one go option in the UI/API too... Ohad> > > John > > -- > 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. > >-- 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.