On Mon, 22 Jun 2015, Jason Slagle wrote:
On 6/22/15, 3:08 PM, "Vince Skahan" <vinceska...@gmail.com> 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.soren...@puppetlabs.com - freenode #puppet: eric0
puppet platform // coffee // techno // bicycles
