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 - [email protected] <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 [email protected].
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.
