Jira (PUP-10142) Make Puppet settings not changed after a request is initiated

4 views
Skip to first unread message

Justin Stoller (JIRA)

unread,
Nov 15, 2019, 2:26:03 PM11/15/19
to puppe...@googlegroups.com
Justin Stoller moved an issue
 
Puppet / New Feature PUP-10142
Make Puppet settings not changed after a request is initiated
Change By: Justin Stoller
Key: SERVER PUP - 2618 10142
Project: Puppet Server
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Atlassian logo

Justin Stoller (JIRA)

unread,
Jan 6, 2020, 6:46:03 PM1/6/20
to puppe...@googlegroups.com
Justin Stoller commented on New Feature PUP-10142
 
Re: Make Puppet settings not changed after a request is initiated

Initially going through the code I looked to see if there were any refactors where we could pass the values of these settings into the methods that require information about the settings, or initialize different versions of the existing objects/subsystems that use them, storing these objects in the context and switching between them from calling code rather than munging the settings object. I failed to see how to refactor the existing objects w/o partitioning most of the server side code from the serialization through the compiler and down to the lexer. That set of changes seemed beyond the scope of this work.

 

From there I investigated two less ideal ways to make these settings threadsafe. One was to move the settings in question into the context (https://github.com/puppetlabs/puppet/pull/7746). The other was to attempt to make the settings context itself threadsafe (https://github.com/puppetlabs/puppet/pull/7745). After some discussion we decided to go with moving the settings into the context because of two reason: ultimately we want the settings to be immutable with the context holding mutable info, and the settings code is entangled enough that we were concerned about edge cases with the threadsafe settings approach.

 

However, there were some additional changes/gotchas with the context approach that we highlighted. I may be missing some here but if memory serves me they are:

  1. We need to keep the settings api to be backwards compatible.
    1. When a user attempts to read a moved setting a deprecation warning should be emitted and the actual value should be looked up in the context.
    2. When a user attempts to set a moved setting a deprecation warning should be emitted and the context should have the new value pushed onto it.
  2. Attempting to set any setting should result in a deprecation warning.
  3. I unfortunately don't remember what, if anything, we came up with regarding clearing settings?
  4. I do know we mentioned having alternate implementations for when running in a multithreaded environment (eg JRuby vs MRI) though I don't remember why or what changes in behavior were expected between them?
Reply all
Reply to author
Forward
0 new messages