We Once we do PUP-10312 or introduce a workflow where the agent can otherwise request specific versions of environments, we need to ensure that an environment cache entry persists throughout an agent run.
The environment cache gets invalidated (in all JRubies/all threads) by Puppet Server when a DELETE request is sent to the {{environment_cache}} endpoint. File-sync hits this endpoint when it finishes doing a deploy, to ensure that Puppet will pick up the newest version of the code.
If we are not locking the JRuby pool anymore when this happens, there is the potential for agent runs to still be in progress that are using an existing version of the env. So we don't want to flush out that version until we're sure that it is no longer in use.
Furthermore, we want to be able to use the same caching mechanism when running both with and without versioned environments/lockless deploys, to avoid unnecessary conditional logic that will have to be ripped out later when we eventually stop supporting unversioned environments.
This will probably involve a restructure of the environment cache defined [here|https://github.com/puppetlabs/puppet/blob/master/lib/puppet/environments.rb#L304]. It is currently a mapping of {{<env name>}} to {{Environment}} objects. If we are going to support saving multiple versions, keying solely off of name is probably insufficient.
Ideas:
* overloaded versions of {{get}} that either take just the name (and return the "latest" env) or the name and desired version, and have the cache be a nested hash. The most recent version of the env should be stored both in a "latest" key so it can be used as a default, and under a key with its version.
* change the key to no longer just be the name, but perhaps a different string like the name and version concatenated, and keep the same internal data structure we have now. This requires that if an environment is cached without a version, nothing later will try to access it with a version, and vice versa.
Only places associated with an agent run are likely to need to know what version of the env to use. So it seems like the first option might be better, though this will also impact the {{get_conf}} family of methods, since they call through to {{get}}. |
|
|
