On Fri, Nov 21, 2014 at 12:46 PM, Eric Sorenson <
eric.soren...@puppetlabs.com> wrote:
>
> 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
>
Windows 7/8/2008/12?
> 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.
Maybe just patch up pe_gem module to be smarter? Otherwise a new puppet_gem
module requires a lot of module updates.
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.
>
That's really helpful, so essentially puppet omnibus.
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.
Thanks,
Nan
--
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/CACqVBqDKb8pV5zT8ER%2Bk3hiE6Om2mPs6yA6FnF6iNtvWxxkg0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
