Puppet-3.6.0 introduces directory environments, which act a bit different from the current config environments. We'll need to switch before upgrading to Puppet-4.0.0, where config environments will no longer be supported.

While we're at it, we also need to get rid of the 'import' statement in site.pp.

(the latter due to http://docs.puppetlabs.com/puppet/latest/reference/lang_import.html#deprecation-notice)

This knocks out one of the deprecation warnings.

This can land any time, but should already be in place by the time the third patch lands.

This actually lands support for directory environments. This will break user environments, but I'll run a short for shell loop to rename existing environments on releng-puppet2.srv.releng.scl3. I still need to figure out how to not use 'import', but I'd like to get these three landed first.

Comment on attachment 8442281 [details] [diff] [review] bug1014047-direnv.patch Review of attachment 8442281 [details] [diff] [review]: ----------------------------------------------------------------- please e-mail release@ about this when it lands, and update wiki docs :-)

Comment on attachment 8442281 [details] [diff] [review] bug1014047-direnv.patch Well, that caused severe performance regressions. That there was a typo (confidir vs. confdir) didn't help, but even after fixing that the load didn't come down. eric0 suggests that this is because environment_timeout is too low (10s, vs the default 120s), but that doesn't feel right to me. We'll see.

OK, landed, with a 600s environment_timeout. This seems to be behaving fine. However, ten minutes (or even the old, global default of 3 minutes) is a long time to wait for non-production changes to take effect. The 'environment.conf' where this setting is configured is a file in the repository, so it's a bit difficult to have that file differ between environments. The best option I can see is to remove it from the repository and install it in each environment and in /etc/puppet/production. This should probably be done with ensure=>present, so users can edit it in their environment. This will also need some careful attention around bootstrapping new masters. Other ideas?

Whoops, that was missing a file due to an error in the .gitignore.

Comment on attachment 8448747 [details] [diff] [review] bug1014047-r2.patch Review of attachment 8448747 [details] [diff] [review]: ----------------------------------------------------------------- ::: modules/puppetmaster/files/user_environment.conf @@ +1,1 @@ > +config_version = /etc/puppet/get_rev.sh $environment Nit: Comment at top of file saying something about how "once in place, it will not change by puppet", e.g. users can edit, and that if we need to change in puppet it also won't change the in-place file.

Comment on attachment 8448747 [details] [diff] [review] bug1014047-r2.patch I sent an email to the list about this change: ---- Bug 1014047 deletes 'environment.conf' from the hg repo, and re-creates it as a puppet-managed file. Unfortunately, between updating the hg repo on a master and running puppet on that master, 'environment.conf' is missing, and once the cache expires, you'll see errors about an import loop. If puppet runs on the master before that cache expires, all is well, but that's up to chance (10 minute cache, 30 minutes between puppet runs). The fix is to add /etc/puppet/production/environment.conf with the following contents, after the hg repo is updated: --- config_version = /etc/puppet/get_rev.sh $environment manifest = manifests/site.pp environment_timeout = 600s --- Alternately, I used cp /etc/puppet/production/environment.conf /tmp && /etc/puppet/update.sh && cp /tmp/environment.conf /etc/puppet/production/environment.conf immediately after landing the change. I've fixed this in the servo, moco, and relabs orgs.