The Problem

When running puppet server you have two levers to adjust how short-lived Puppet environments are cleared from memory.

1. max-requests-per-instance in puppetserver.conf
2. environment_timeout in puppet.conf/environment.conf

Each option has it's own cons, because neither addresses the core problem we want to tackle. We want to clear Puppet environments from memory when they haven't been used for a while and there's no direct way to do that.

With max-requests-per-instance we're destroying a whole JRuby which takes out all of the Puppet environments that were ever loaded into it.

With environment_timeout we have to clear environments after a certain amount of time even if that environment is getting lots of catalogs compiled against it right now.

The solution

Create a setting that allows for expiring a Puppet environment after it has not been compiled against for a set period of time. If we were to call this setting environment_ttl and we set it to 30m then that would mean that if you ran an agent against your test environment and then then no other agents checked into that environment for 30m then the test environment would be marked expired.

This gets to the bottom of the problem customers see when deploying short-lived Puppet environments.

This setting would be a global setting not a per-environment setting.

We decided to implement a new environment_timeout_mode setting that controls how environment_timeout behaves when its value is greater than 0 and less than unlimited. In 6.x, environments will be expired relative to when they are created. If environment_timeout_mode equals from_last_used, environments will be expired relative to when they were last used. The environment_timeout_mode setting affects values of environment_timeout set globally in puppet.conf and per-environment $codedir/environments/$environment/environment.conf.

Caveats

The setting would presumably interact with the environment_timeout setting. This setting could only be applied when the environment_timeout is not 0. If environment_timeout is 0 then this setting would emit a warning and do nothing.

When the environment_timeout < environment_ttl then environment_timeout would take precedence because it would mark the environment expired before the environment_ttl code had a chance to run.

When environment_timeout > environment_ttl then this is the primary use case for the setting and environment_ttl finally has a chance to help expire environments more quickly/efficiently than our current settings allow.