Puppet 5 changes

[Eric Sorenson]

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.

(As an aside, if you haven't yet tried Puppet Server, give it a shot. The docs are now integrated into the main puppet docs site and installation is super easy: https://docs.puppetlabs.com/puppetserver/latest/ )

The next question is what the timeframe looks like. I'm a little gun-shy around dates right now since the Puppet 4 effort has taken a lot longer than anyone anticipated. The greatest specificity I'm comfortable with is that it'll likely still be 2015 when it's released... probably.

Hopefully this helps plot a bit more concrete course for where this stuff is headed over the next couple of years. As always, please hit me back with any questions or concerns.

--eric0

Eric Sorenson - eric.s...@puppetlabs.com - freenode #puppet: eric0
puppet platform // coffee // techno // bicycles

[Martin Alfke]

Hi Eric,

On 06 Mar 2015, at 05:30, Eric Sorenson <eric.s...@puppetlabs.com> wrote:

> […]

> 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.
>

Will we still have the possibility of spinning up a second master process on an existing puppet master?
https://docs.puppetlabs.com/guides/install_puppet/upgrading.html#option-2-run-two-instances-of-puppet-master-at-once

Many thanks,


Martin

[Erik Dalén]

On Fri, 6 Mar 2015 at 05:30 Eric Sorenson <eric.s...@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.

[Trevor Vaughan]

+1 to OCSP support!

Trevor

--
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+...@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.

--

Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[Chris Price]

On Fri, Mar 6, 2015 at 6:41 AM, Erik Dalén <erik.gus...@gmail.com> wrote:

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.

This is definitely slated for Puppet 5.0/Puppet Server 3.0.

 

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.

I'm a huge fan of that suggestion... we'll at least look into it :)

[Felix Frank]

On 03/06/2015 05:30 AM, Eric Sorenson wrote:
> 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.

I guess that means that dynamic scoping of resource defaults will have
to linger until Puppet 6, yes?

This is not necessarily a problem - depending on how fast we get to
Puppet 5, we may not even have the solution ready in time, anyway.

On the other hand, I dearly hope that no Forge module currently relies
on dynamic scoping.

Cheers,
Felix

[Eric Thompson]

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.

I hadn't heard about this portion of puppet 5.  If some of these subcommands are going away do we have deprecation notices going into some y or z release of puppet 4?

 

--

Eric Thompson
eric.t...@puppetlabs.com
Senior Software Quality Assurance Engineer

[Chris Price]

On Fri, Mar 6, 2015 at 8:46 AM, Eric Thompson <er...@puppetlabs.com> wrote:

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.

I hadn't heard about this portion of puppet 5.  If some of these subcommands are going away do we have deprecation notices going into some y or z release of puppet 4?

One option that we've discussed is replacing the old commands with stubs that just print out some info about how to find / use the new versions.  Eric may have more thoughts re: deprecation notices, though.

[John Bollinger]

On Thursday, March 5, 2015 at 10:30:47 PM UTC-6, Eric Sorenson wrote:

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.

I'm doubtful of the validity of that hypothesis.  The use cases for `puppet apply` tend to be different from the use cases for agent / master.  If I wanted to try out Puppet for a scenario in which agent / master was the appropriate choice, or especially if the agent / master setup itself were part of what I wanted to evaluate, then `puppet apply` would simply not be a good alternative.

As light-duty as webrick may be, it has the virtue of being extremely easy get up and running.  I'm not specially tied to webrick itself, but I think Puppet benefits from having a lightweight, out-of-the-box server option.


John

[Trevor Vaughan]

I was going back and forth on this and I have to agree with John.

There have been several times where I pushed out a lightweight Puppet server on a VM running 512M RAM, 1 CPU, just to try something in a 'production-like' scenario.

I'm OK with losing Rack support, but a lightweight server instance is great for testing.

Trevor

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/d9061cc6-93a8-40fd-8572-d4fdfc9170cf%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Felix Frank]

Seconded. For debugging purposes, the webrick master is still useful as
well.

[Trevor Vaughan]

John, Felix, and I agree....marking on calendar....

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/54F9DFE0.7010503%40alumni.tu-berlin.de.

For more options, visit https://groups.google.com/d/optout.