On Fri, 6 Mar 2015 at 05:30 Eric Sorenson <eric.soren...@puppetlabs.com> wrote:
> Hi all, this may seem a bit far-out since we haven't pushed Puppet 4 > completely out of the nest, but I wanted to talk about some plans for the > next cycle of breaking changes/deprecations that are headed for Puppet 5. > > There are two main areas of change, both related to continuing to move > server-side functionality into Puppet Server: the certificate authority and > the network stack. There may be other semver-major breaks that get rolled > in, but at this point we're planning to deliberately NOT have language > changes that would necessitate revising modules. > > Currently there are two separate certificate authority implementations, > one in Ruby and one in Clojure. Puppet 5 will consolidate onto the new > Clojure CA, removing the Ruby CA code and building new command-line tools > to interact with it. (See SERVER-270 for the design/requirements work > here.) This is cool because right now there are a few overlapping / > conflicting subcommands like `puppet ca`, `puppet cert`, `puppet > certificate_request`, etc that are pretty inconsistent, and it'll be great > to have the chance to clean them up. > > Similarly, on the network stack, we want to consolidate on the > jetty/puppet-server/jruby stack as the single way to run Puppet masters, so > the built-in webrick support and Rack support layer will ride off into the > sunset. The webrick one shouldn't be too controversial: it causes a lot of > people to start off on a bad path because it tips over so easily. My > hypothesis is if you're just dipping a toe in the water to try out Puppet, > running standalone with `puppet apply` is probably going to work better > than a webrick agent/server setup. > > But I'm interested in hearing opinions on the Rack deprecation, especially > if there are significant functionality gaps between what people are > currently doing in your Passenger setup and what's possible with Puppet > Server. Overall it's obviously easier to support fewer, more opinionated > ways of running a Puppet infrastructure but not if it comes at the price of > breaking stuff without adequate replacement. There have already been some > pretty substantial improvements to Puppet Server based on feedback like > SERVER-18, so conversations like "Hey I'm doing this cool thing with nginx > right now, will that still work?" are really helpful. > We would need support for If-Modified-Since headers to be able to switch. Using a custom Apache config to get them working under the passenger CA (serving all CA files by apache using mod_rewrite instead of going through the Ruby code). We mostly use that for knowing when to update the CRL though, so some better mechanism for that like OCSP would work as well. Also a solution to https://tickets.puppetlabs.com/browse/SERVER-115 is really needed. It can sort of be solved in the Ruby version by only using a single worker instance. But really I think it would be good if the whole cert request stuff could use some standard protocol like SCEP so other CA implementations like Dogtag or even Active Directory would work as well as the puppet-server one. -- 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/CAAAzDLeRBPWsLcevR-t9rn7HW%3Dxp69Au1tQepZBKBKgN06RXOg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
