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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
