On Monday, April 27, 2015 at 4:30:00 PM UTC-5, Eric Sorenson wrote: > > > On Monday, April 27, 2015 at 9:34:13 AM UTC-7, jcbollinger wrote: >> >> >> [...] I think there's a combination of problems here. >> >> Let's take puppetserver first, because in some ways it's easiest. The >> version of puppetserver in the puppetserver-2.0.0 packages really is 2.0.0, >> thus software version code and package version code are consistent. The >> issue is that puppetserver 2.0.0 implements version 4.0.0 (I think) of >> "Puppet", where "Puppet" these days means the DSL, plugin API, and built-in >> type and function libraries. This is roughly analogous to version 31 of >> Firefox handling version 5 of HTML, but more confusing because it's new >> that there is a split between software version and -- I'm not even sure >> what to call it, but maybe "framework version". Inasmuch as puppetserver >> is taking over from the older Ruby implementation of the master, it may be >> that these numbers can be reconciled in the future. (See also below.) >> > > Puppet Server 2.0 doesn't implement any of the "DSL, plugin API, > type/function libraries" at all. All of those things exist independently of > puppet server, inside of the "core" Puppet codebase. You can assure > yourself of that by installing only the puppet-agent-1.0 AIO (or just > puppet-4.0.0.tar.gz for that matter) and running 'puppet apply', 'puppet > master', etc etc, without any puppet-server whatsoever. > >
I guess I'm not surprised to hear that you can run the Ruby puppetmaster from the code in the puppet-agent package, but it does muddy the waters even further, now casting doubt on the propriety of even the package *names*. If the puppet-agent package indeed contains Puppet's full Ruby stack (which isn't so easily separable into master and agent), then why is it not named simply "puppet"? If puppetserver does not stand on its own, then why is it the puppet-*agent* package on which it depends? > But your argument is not invalid! There *is* a piece which ties Puppet > Server 2.0 to Puppet 4, and that is the agent<->master network API. > Ok, good point, add "network API" to the definition of "framework". Also, I guess I misunderstood the scope of the puppetserver project. I had thought its purpose was to replace the master *altogether*, which would include catalog building. I guess, then, it substitutes only for the master's rack-based communication endpoint (which is just fine, and seems more sensible to me). > So you could totally advance the idea that there should be some > version-related coupling between those two projects. This is implicit right > now (or rather, it's expressed in package dependencies and text > documentation) and I understand your and Vince's desires to have this made > more explicit, by expressing it directly in the version numbers of each > project. > It's all about clarity in labeling. The name of the "puppetserver" package suggests that you need it to run a Puppet master (that being the server component in a master/agent setup). That is reinforced by the naming of the "puppet-agent" package, which I hope you will acknowledge does not suggest that it's a viable alternative for running a puppet master. > > The "Framework version" you're describing is exactly the concept we're > trying to express with the Collections repository (for future Googlers' > context, the explanatory blog post is at: > https://puppetlabs.com/blog/welcome-puppet-collections ). PuppetDB also > has some dependency tendrils, too, but its versioning is totally decoupled > from Puppet's. > No, I don't think "framework version" is the same concept at all. At least, the blog's description of collections doesn't say that to me. My reading is that collections are about packaging and component compatibility. Framework version is a major consideration on the compatibility end, but it is a lower-level and narrower concept than collections appear to be. Nevertheless, Bravo! on collections. It looks like they will be very helpful. > > >> The puppet-agent package is where the real fun starts. As best I can >> determine, the version number of the puppet-agent package is associated >> with the overall all-in-one installation image and packaging, as opposed to >> the software packaged within, the central piece of which is the Ruby >> implementation of the Puppet software (version 4.0.0 of that software in >> the puppet-agent-1.0.0 package). I do not understand this decision, as it >> seems to fly in the face standard package versioning practice. That aspect >> of it could certainly be fixed, however -- it should not produce any great >> difficulties to bump up the version number for the package to correctly >> agree with the version of the packaged software. >> > > I think this arose from a desire to express the versioning of the AIO as a > semver number which tracks the collection itself, independently from the > versions of the constituent projects. Since there is ruby, facter (both > flavours!), mcollective, hiera, augeas, it seemed wrong to pin the > puppet-agent number to puppet-the-project. But perhaps it was an error to > have a non-puppet-centric view of the world, since it's true that the > *purpose* of all those other things is really to deliver Puppet in a > batteries-included, supportable way. > Yes, understood, and *yes*. In the RPM world, at least, the package version number describes the software in the package; it is the release code that describes the packaging and any ancillary considerations. You could use semver for the release code if you wanted to do (e.g. puppet-4.0.0-1.0.0), though that seems like overkill to me. > > >> Then there's the question of standalone software packaged together with >> the agent, and the version numbers of those programs. In truth, I don't >> think the version number mismatch is a significant issue there if you >> accept all-in-one packaging to begin with. In my experience, it's pretty >> common for AIOs to bundle software with different version numbers, but it >> is unusual for such an AIO to be versioned differently than the bundle's >> focal software. I think this issue would be substantially mitigated just >> by making the version number of the puppet-agent package in fact match the >> version of the puppet agent software contained within. >> > > I think this and Vince's example below make sense at the initial release > point, but as we found when we attempt to match PE's version number to its > Puppet component, it very quickly degenerates into incoherence. As an > example, if it started out at puppet-agent-4.0.0 to match puppet-4.0.0, but > the only change in the next AIO package is to incorporate a feature update > in Facter (a hypothetical 2.5.0), we'd want to reflect that feature update > in puppet-agent-4.1.0. But should that then trigger a release of a > puppet-4.1.0 *even though nothing has changed in puppet*? > No, you'd want to signal such a change via the package's release code, not its version number. Or you could save yourself some trouble by providing the various components in separate packages, which would be a big win in my book. In addition to avoiding package versioning headaches, package-per-component could also afford users more and easier control over the details of the combination of components in use at their sites. And *that* seems like what Collections is (or should be) aiming at. Indeed, it seems to me that there is a lot of redundancy between Collections and AIO packaging. > > For what it's worth, I raised a bit of a stink a few months ago in the >> developers group about PL's decision to make Puppet 4 *depend* on an >> AIO-style installation image, but I was unable to persuade much of anyone. >> Given PL's decision to go that direction, AIO packaging is a natural >> result, albeit an unnecessary and unwelcome one. >> > > Well, it's more that Puppet Labs' packaging for Puppet 4 is an AIO-style > installer, not that Puppet 4 depends on AIO inherently. > > When we had this discussion on the dev list, no one from PL was prepared to promise that Puppet 4 would work correctly if not installed in an AIO-style image -- at a specific location, even. No one was even willing to accept as a formal goal that it should do, though some agreed it would be good if that could be accomplished. If indeed Puppet does not depend on an AIO-style installed image, then I am overjoyed! Is it indeed time for a happy dance? Also, your choice of wording may reflect a bit on the disconnect here. A "package" is not at all the same thing as an "installer", even on systems that have a weak or non-existent native idea of packages. More or less nobody but the software packager cares about the details of an installer, to the extent that a given package even contains one. Everybody else cares mostly about what's *in* the package, and that's primarily who package labeling is for. I think AIO nature (or not) of the installed image and AIO-style packaging and installation present largely orthogonal issues, however; I'd like to keep this thread's focus on the latter. > We're also working to open-source the packaging toolchain, so if it's not > so much the idea but the particular component versions (or the installation > root, as I've gotten some feedback hardcoding /opt doesn't work for some > people), you could roll your own. > Open-sourcing the packaging toolchain is great, and doing so will mitigate some of the issues surrounding the AIO packaging, but I don't think it addresses the key problems that we started with, which are mostly about how PL is presenting packages to the world, not about what the world can or should do to digest them more easily. > We've clearly done a less-than-stellar job at either (or both!) > understanding what people outside PL walls expect with regard to > versioning, or communicating why the numbers landed the way they did. Let's > think through changes to the current scheme in the context of the next 9-12 > months of major/feature/patch releases and figure out what's going to work > best. > > Thanks for being receptive to these concerns. It does appear that PL has gone a bit overboard on semver, and has perhaps focused too much on an internal view of the packaging and software delivery issue. I hope these issues can indeed be smoothed out over the course of the next months. John -- 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/2f5f29f0-bbd3-4435-929b-094c7ca54cc7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
