On Monday, 13 October 2014 04:14:27 UTC-7, Daniele Sluijters wrote: > > > (where all environments were promoted to 'production' if they weren't > configured in puppet's configuration) > > What do you mean here, exactly? >
The previous 'config file environments' ( https://docs.puppetlabs.com/puppet/latest/reference/environments_classic.html ) had a behaviour where if the environment wasn't found, it'd use the defaults in the main block. > > > however the current design I'm thinking could benefit from it. > > Can you give a rationale / use case that would benefit from this? As you > present it now it's just bringing it back for the sake of bringing it back. > The particular deployment strategies (region specific baked AMIs), combined with a self-service environment that we're utilizing means that there's a level of infrastructure that we're responsible for (puppet, mcollective, etc) that we wish to always be managed(per-AZ deployments). We're planning on (ab)using the directory environments facility so that every logical grouping of infrastructure (ie, cassandra, elasticsearch, $random_thing_here) has its own defined environment - however if the people actually running it don't wish to utilize puppet, we don't want to put the additional requirements that they create an empty environment, just to do no work. In this case, the default managed common set would be suitable. The actual trifecta of environments (dev,stage,prod) will have their own masters and never shall the twain meet. Essentially with the roles/profiles pattern, we'd have a common set of criteria everywhere, and if the work wasn't defined, they'd just get the minimum we've determined is necessary. It just wouldn't be advantageous in our case to have to coordinate/train all the various product teams on puppet(yet). The caveats being of course (as with the previous config file environments) is that resources become unmanaged if the 'environment' no longer exists. I'm currently working around this via testing if a particular directory exists in the ENC, and doing the promotions there. However, it was suggested I submit information about this being in the master as an opt-in feature. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/2a8f275d-82cf-497b-acf5-1b4cb637e34e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
