I've already stated my opinions on the AIO packages, and as long as the gems are still available, I can maintain the systems that I currently maintain. I don't like that the puppetserver will be special and need to use the puppetlabs packages, but I can live with it.
When you have Linux systems with CentOS 5, Debian 6 thru sid, Ubuntu 10.4-14.04, running on i386, AMD64, armv6 (RaspberryPi), and then a bunch of Mac OS workstations that range from 10.6 thru 10.11, the gem packages are the only consistent way of controlling which version is installed. I'm a little concerned with the new C++ based facter and what headaches that's going to cause. I do look forward to testing out puppet 4.2! 4.0 had no easy upgrade path. The newer puppetserver helped by translating the old API calls to the new calls, but 4.1 was still not production ready with it's major issues with handling facts and puppetdb. With all the issues that puppet 4 has had, along with the introduction of the AIO packages, upgrading from puppet 3 has been a non-starter. On Tuesday, June 23, 2015 at 6:03:50 PM UTC-7, Eric Sorenson wrote: > > On Mon, 22 Jun 2015, Jason Slagle wrote: > > On 6/22/15, 3:08 PM, "Vince Skahan" <vince...@gmail.com <javascript:>> > wrote: > > > >> On Thursday, June 18, 2015 at 4:18:37 PM UTC-7, Ken Bowley wrote: > >>> This is better than what is currently being used, but I'm strongly in > the AIO > >>> idea to be stupid. Split it into multiple packages and use proper > >>> dependencies like every other sane packaging system has done for a > long, long > >>> time. > >>> > >>> If all you do is bump the version of facter, then only have me > download and > >>> install the meta package that depends on the new facter, and the new > facter > >>> package, not everything. > >> > >> Agree. Thought I'd chime in (late) as the original poster. > >> > >> Versioning starting with 4.x is a good start, but I still think your > AIO > >> approach is wrong. > >> > >> Have collector rpms that 'require' the pieces of the puzzle and package > >> hiera/etc. in individually bundled standalone packages. If you do > that: > >> * you can keep versioning facter to 2.x.y if you want > >> * you can keep versioning puppetserver any way you want > >> * and just version the collection (bundle, pick a term) with the 4.x.x > >> identifier you want to publicize as release-4.x.x > > If all anybody had to deal with were $osfamily==redhat systems, I feel > pretty > certain this is exactly what we'd do. But it's just not. Just to start > from > first principles, the primary goals of the packaging project were: > > - unify the agent across open-source and PE so testing, delivery, and > upgrades > are as smooth as possible > - provide a consistently great out-of-the-box experience so you can get > fresh > Puppet versions with "batteries included" on any supported OS > > I love metapackages too, but short of porting yum to Windows, Mac OS X, > and > Solaris I don't see how they meet those requirements. > > >> To update the client, 'yum update puppet' and have it update the > sub-pieces it > >> needs (hiera/mco/etc.) > > So this happens today, it's just in all in one package :) > > >> To update the server, 'yum update puppetserver' and have it do the > server > >> piece. > > And this is actually what happens today. > > >> Lastly, if it's me, I would not bundle the agent/client stuff 'in' the > >> puppetserver package. I would 'require' the client-stuff to be > co-installed > >> with the server stuff using the packaging mechanisms the os providers > already > >> give you. > > This is also what happens today; there is no agent stuff in the > puppetserver > package. > > >> (in other words, release 'empty' rpms that require x and y and z - > works > >> great if you don't cause dependency hell by getting too fancy) > > > FWIW, +1 from me too. It seems like a lot of places that do packaging > like > > this end up doing it this way. > > Fair enough. > > > If I¹m only doing a security update to facter, I shouldn¹t have to > replace a > > gigantic bundle with whatever else it pulls In. I can see you release > > management people hating this later, as well as security teams. > > So the puppet-agent package is 17 megabytes on EL7, so "gigantic" is a bit > of > an overstatement here. Agreed that the release pipeline is more > complicated, > and I can definitely understand the desire to just update the one thing > that > needs a bugfix. > > > I suspect this confusion will hinder deployment the AIO packaging is > > certainly in the cons category for us. > > I really want to understand this, because it's a big deal. (My life goal > at > this point is to get as many people as possible upgraded to Puppet 4, so > anything that gets in the way of that is a problem!) There's been a bunch > of > different points in the thread, some of them about the numbering and some > about the packaging itself; what would reduce the confusion for you? > > 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 Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/2e605337-f027-4c62-905b-0cab9ff3da75%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
