On Fri, Nov 21, 2014 at 12:46 PM, Eric Sorenson < [email protected]> wrote:
> > On Nov 18, 2014, at 11:04 AM, Eric Sorenson <[email protected]> > 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 [email protected]. 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.
