I can only imagine how much time has been lost over the years trying to
support ruby 1.8.7. I think this is a great move as long as we can still
install puppet using gems under a newer ruby. Will the ffi gem be part of
the AIO package?
I won't even bother creating a ticket for a bug I just stumbled upon that
is only found with using puppet under ruby 1.8.7.
Corey
On Tuesday, November 18, 2014 11:04:14 AM UTC-8, Eric Sorenson wrote:
>
> 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 - eric.s...@puppetlabs.com <javascript:> - 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 puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/8f6ad323-fdd3-4611-85d1-1dd1a1b8238f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
