On Nov 18, 2014, at 11:04 AM, Eric Sorenson <eric.soren...@puppetlabs.com>
wrote:
> 7. Umm.. I think that's all.
Wow thanks for all the responses, there are a ton of very good questions in
here -- some of them got answered inline and I think we rolled up the rest into
this little FAQ. which I''m sure will generate a new set of questions :)
0 - Which platforms will get FOSS AIO packages?
RHEL/Centos 5, 6, 7
Fedora 20, 21
Ubuntu 10.04, 12.04, 14.04
Debian Squeeze, Wheezy
Windows x86, x64
Commercial OS'es (Windows excepted) will get PE-only AIO
SLES 10, 11
Solaris 10,11
AIX
Mac OS X
1 - How do I manage gems with AIO ruby?
Use the AIO included gem binary. ('/opt/puppet/agent/bin/gem install
somerandomgem') To make this easier, we can either fix PUP-3688 or add a module
with a minimal 'puppet_gem' provider using the AIO path.
2 - Will there be security updates, etc?
Yes, absolutely.
3 - Will it include puppetdb-terminus?
Yes.
4 - What will the release cadence look like? What if I want to manage component
upgrades on a different cadence than upstream, e.g. just facter, or just hiera?
We're planning to provide three trains of packaging:
• Nightlies, that get built whenever there's a change in one of the
component repositories that passes through CI. These will essentially track the
latest, like the nightly repos do now.
• Roll-up releases that would track tagged versions of the component
repositories. This would work like having 'ensure => latest' pointed at the
current 'products' repository.
• PE releases that track stable releases and are coordinated with the
rest of the PE ecosystem, are QA tested, and have some set of backports /
commercial enhancements.
For power users who want more control than that, we’ll have documentation on
how to roll your own. The tooling to create AIO will itself be open-sourced so
you could build a package that picks the versions you want to include.
5 - Why not use a metapackage which has no content of its own, but has
requirements on specific versions of the other 'real' packages that contain the
actual programs?
• Avoiding a coordinated major version ship across all projects… We're
changing the layout on the filesystem (moving to opt) for a few reasons,
including shipping our own stack without conflicting with system libraries.
This kind of change shouldn't be done in a "y" release (of x.y.z). Components
that have been updated can’t mix/match with components that haven’t. Example: A
user has facter ensure => latest, but not puppet. They’ll get facter with the
new layout (and maybe the new PL-provided ruby, if its a dependency of the new
facter), but not puppet, and have a broken install. If the meta-package
provides facter, then users with ensure => latest on facter but not puppet will
have a completely new install of their whole stack. Neither of these are ideal.
To avoid any automatic installs, we could have facter *not* provide itself,
which is also probably not the route to go down. The AIO ensures users have
everything they need at the same time, and can just continue using the agent
after upgrade.
• We want to simplify the endpoint install experience for users. A
single endpoint puppet agent package is arguably among the simplest possible
deployment mechanisms.
• Meta-package only solves the problem for agents with a package
manager that can do remote dependency resolution. We want the install
experience for agents to be excellent/seamless regardless of the platform you
are running, and be the same experience across the board. Users installing a
Solaris 10 agent package shouldn’t have a different experience than users
installing a Debian 7 agent package.
6 - Will using AIO puppet/mco to upgrade AIO work?
Once we have AIO packages ready, we’ll be doing some testing of upgrade
scenarios.
7 - Why are you dropping 3.x agent compat with 4.0 master?
We didn’t take this decision lightly, and it came down to getting 4.0 features
out into people’s hands sooner rather than later.
Backward compatibility on the network in this case is a fair bit of work, which
we haven’t fully scoped, so in 4.0 we opted for the current tradeoff.
We recommend users take a “migrate, not update” approach to 4.0 upgrades, and
people taking this approach probably won’t much care about this change.
--eric0
--
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/061A6B6F-790A-4109-8A3D-B29051954E44%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.
