Merits of directory environments and opt-in fallback mode?

[Vincent Janelle]

I understand the evils of the environment fallback that was previously in puppet (where all environments were promoted to 'production' if they weren't configured in puppet's configuration), however the current design I'm thinking could benefit from it.

Would it be sensible to be able to restore the previous behaviour (or better yet a 'default' named environment) via an opt-in configuration flag?  With a giant caveat in the documentation of course that explains how exactly this will bite you in the ass.

[Daniele Sluijters]

> (where all environments were promoted to 'production' if they weren't configured in puppet's configuration)

What do you mean here, exactly?

> 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.

[Vincent Janelle]

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.