Hey everyone, thanks for your feedback. We appear to see some support for all options except #1. That one is apparently universally despised.
I'll try and summarize the discussion. Pros get a + plus and cons a - dash. Option 2: Override ENC environment but only from the commandline. + convenient override + CLI invocation works as expected (by most) - config options behave differently from CLI vs. config file, which is confusing - explicitly setting the default on the CLI is different from skipping it or doing it in the config, which is surprising Option 2a: + convenient override + configuration options in files and parameters behave identically - explicitly setting the default in the config has other semantics than skipping it, which is surprising Option 3: + ENC is important for most masterless folks, who will want it to override local shenanigans + easily overridden via --node_terminus=plain + regular use case: ENC is chosen via parameter anyway for masterless, not for any `apply` run, via dedicated script, and should overrule environment from the config then + apply behaves more like agent (omg consistency) - will confuse users who pass an environment which won't take effect All things considered, we find ourselves in a fine position to choose our poison. There were more votes from the 2/2a camps, but also good points from RI in favor of 3. This leads me to believe that whatever we choose, a priority should be for `apply` to be very vocal about which environment is in effect, and how it was chosen. I don't think we have so much as a debug message right now. I propose a notice to always comment on the environment. Perhaps even a warning when the user is apparently trying to do something that can't work. I was just about to suggest just taking 2a for all the votes it received and for being the closest to current behavior (minus insanity). But then the list of arguments in favor of 3 is rather impressive. Its negatives aren't too bad, and can be mitigated through UI design. Call to the 2/2a supporters - are you at all swayed by those? Cheers, Felix On 10/09/2014 11:13 AM, R.I.Pienaar wrote: > > ----- Original Message ----- >> From: "Erik Dalén" <erik.gustav.da...@gmail.com> >> To: "puppet-dev" <puppet-dev@googlegroups.com> >> Sent: Thursday, October 9, 2014 8:02:47 AM >> Subject: Re: [Puppet-dev] How should apply behave under an ENC >> I vote for option 2 or 3. >> But against 2a. I think differentiating between a config file that >> specifies the default value (environment=production), and one that leaves >> it out (to get the default value) seems really odd behaviour. >> >> Note that this whole thing only applies if you have node_terminus=exec in >> the main or user sections of the config file, and your ENC actually returns >> a environment. So if you want to ignore your ENC you can also just use >> --node_terminus=plain on the command line. > 2 or 3, but I think 3 should win. > > Configuring an ENC with puppet apply is probably not the most common thing or > something one would enable everywhere apply is used. I found people who use > masterless would have a shell script to do those runs or maybe run puppet with > a specific config file - leaving normal puppet apply test.pp type behaviour as > is. Either way they would enable the masterless mode used to manage the > machine > using a special set of steps and those steps would include enabling an ENC > > So for me at least if I configure apply to use an ENC then that ENC should be > authoritative. > > > >> On 6 October 2014 03:30, Felix Frank <felix.fr...@alumni.tu-berlin.de> >> wrote: >> >>> Hi all, >>> >>> when we recently fixed a regression that had to do with directory >>> environments and ENC (PUP-3258) I noticed that the handling is weird >>> when the ENC actually picks an environment for the local machine. >>> >>> As far as I can tell, puppet apply ignored that until now. The apply >>> command used the configured environment, replaced its :manifest setting >>> with what's chosen on the commandline, and makes that the only available >>> environment. >>> >>> >>> https://github.com/puppetlabs/puppet/blob/fea22be6a957e62005cab649537b39af0d0bda74/lib/puppet/application/apply.rb#L185-190 >>> >>> Puppet 3.7.0 is less stringent in that regard. It retains the set of >>> available environments. >>> >>> >>> https://github.com/puppetlabs/puppet/blob/master/lib/puppet/application/apply.rb#L193 >>> >>> This apparently causes an error when the ENC returns an environment (any >>> environment), which happens just below the linked code line in apply.rb. >>> This environment is looked up, bypassing the override of the :manifest. >>> I suggested a fix for this: Force the node (external or not) to use the >>> overridden environment. >>> >>> >>> https://github.com/ffrank/puppet/commit/39b78a8d25fa96c98f81227cd3ef6b48010fab68 >>> >>> During PR triage (sorry for vanishing suddenly, something came up), we >>> got some doubts whether this was the right thing to do. It is probably >>> in keeping with former behavior, but it contradicts a decision that was >>> made wrt. a classic bug. >>> >>> http://projects.reductivelabs.com/issues/3910 >>> >>> When using agent, not apply, the puppet master may invoke an ENC. The >>> environment returned from the classifier takes precedence over any >>> :environment configuration on the agent (both file and commandline). >>> This is to allow users to use their ENC in contexts that are relevant >>> for security. >>> >>> We're now looking for feedback on whether apply should get the same >>> semantics, for masterless operation. >>> >>> There are three alternatives here that I can see: >>> >>> 1. Status quo - ruthlessly override whatever the ENC specifies. >>> 2. Flexible - use the ENC environment, but allow overriding it via --env >>> on the commandline >>> 3. Strict - always use the ENC environment (except for the overridden >>> :manifest) >>> >>> We might even go for a 2a, that would allow config files to override the >>> ENC as well (if we can easily discern such values from the defaults at >>> this point in the code). >>> >>> Personally, I feel that the strict behavior would be very inconvenient. >>> An attacker could likely circumvent the ENC after all, so the security >>> aspect doesn't really apply here. >>> >>> My vote is for the 2nd approach. >>> >>> Cheers, >>> Felix >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Puppet Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to puppet-dev+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/puppet-dev/5431F0B6.4070700%40Alumni.TU-Berlin.de >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> -- >> Erik Dalén >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email >> to puppet-dev+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/CAAAzDLensoriqr9h0Gc%3DTZGFBPui_XgqjLOeThG23LLwtm_wEg%40mail.gmail.com. >> For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/5446C4D4.4000302%40Alumni.TU-Berlin.de. For more options, visit https://groups.google.com/d/optout.
