On Thu, Nov 15, 2012 at 9:46 AM, Jeff McCune <[email protected]> wrote:
> On Thu, Nov 15, 2012 at 12:24 PM, Andy Parker <[email protected]> wrote: > > On Tue, Nov 13, 2012 at 4:03 PM, Erik Dalén <[email protected] > > > > wrote: > > [snip] > > >> Wouldn't doing this would require configuration changes in some use > cases? > >> For example I have puppet masters that are clients to other puppet > masters > >> with a different CA, so in the master section I have a different ssldir. > >> With this change I would have to copy that to a "cert" and "ca" section > as > >> well. > > > > > > I don't think so. The application can still change what run_mode it is > going > > to use, but run_mode will mean "application setting section". I removed > the > > caching from the Settings so once the run_mode is changed, it should just > > start operating with that different set of configuration settings. > However, > > just like today, there can be all sorts of unintended consequences of > doing > > so. > > Does this still leave us in the difficult situation where the Faces > application file itself lives along the modulepath, so we use one > configuration file section to determine the module path, then the mode > (section) changes out from underneath us, and we use another section > to resolve the rest of the settings? How would a new action > augmenting the `puppet module` application behave in this situation? > Yeah, we are still in that situation. The settings that are seen during the run are not necessarily in line with what was used during application discover. There is actually even a slightly larger issue: the modulepath during discovery is being added to the ruby LOAD_PATH so that utility code can be loaded. This means that it may end up with things that it maybe "shouldn't" have access to because it started with one modulepath and then wanted to run in "master" mode to get a different modulepath. I don't think this is a problem for any existing applications, though, since I'm special casing master and agent to start in the current manner. > > >> I'm kind of okay with doing that, but it is definitely not a backwards > >> compatible change, so for puppet 4.0? :) > > > > > > I'd like to find a way that can fix this in 3.x. > > Yes, this effort will substantially improve faces, so it would be > great if we can get it into 3.x. Face actions often need to access > settings and faces are a big extension point for Puppet so I think > this fits well into the settings and code loading theme for Puppet > 3.1. > > -Jeff > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/puppet-dev?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
