Hi all, as some of you have noticed, our target date in JIRA for Puppet 4 is
not too far off now. (We just moved it out from early December to early January
based on the remaining must-have workflow). While you can poke through tickets
to see exactly what's going in, it might be helpful to have a little higher
level overview of what is happening. Let me try to provide that as well as ask
some questions of things we're not sure about.
1. Ruby 1.8.7 support is going away.
2. To enable #1 but still support OSes that ship with 1.8.7, we're going to be
packaging and delivering Puppet 4 an an 'all-in-one' (AIO) package bundled
together with
- openssl
- ruby
- augeas
- ruby-augeas
- ruby-stomp
- ruby-shadow
- puppet
- mcollective
- facter
- hiera
- + misc supporting gems/libs (deep merge, yaml, etc)
(Question: are there other *agent side* components you feel are essential to
the functioning of the puppet stack?)
3. The AIO packages will have a filesystem layout that installs the programs
into /opt/puppetlabs/agent and the configs into /etc/puppetlabs/agent ; the
packages will be a different basename than puppet ('puppet-agent') so won't
install automatically on an upgrade, but *will* obsolete the puppet packages if
you decide to install them. AIO packages will be available from the Nightly
repos Real Soon Now[tm] and I expect Melissa or Haus will update when they're
up so everyone can poke at 'em.
4. We are planning to break cross-major-version compatibility over the network.
The amount of change we need to support in order to keep moving components to
the Puppet Server and out of Ruby is the main driver for this, but generally,
if you can't break compatibility on a major version boundary... when CAN you?
See PUP-3641 for the overview of that work.
5. The upgrade process would be as Chris described above, where you'd set up a
new server running puppet 4 (hey it's an opportunity to move your puppetmasters
to EL 7!) and point the new agents at it, leave the old ones running until
their agents are drained.
Question: What can/should we do to make that kind of transition go more
smoothly? (One idea that just struck me is to have the puppet4 agent have a
different default value for $server than 'puppet', so it wouldn't need
post-install configuration to point at the new server)
6. We're going to stop providing the puppetmaster/puppet-server (passenger)
packaging in favour of the puppetserver packages. There will still be
rack/passenger support in Puppet 4, but not in Puppet 5.
7. Umm.. I think that's all.
Eric Sorenson - [email protected] - freenode #puppet: eric0
puppet platform // coffee // techno // bicycles
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/FF17DBFD-7DB1-4241-AC3C-EE9520A2E1C9%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.
