On Thursday, April 30, 2015 at 11:32:43 AM UTC-5, Michael Stanhke wrote: > > Rather than reply and quote lots of points, I'll just bring up a few > things which could help clarify our goals. I'm sure not everybody will > agree or love all of them, we know there are compromises here but attempted > to make choices with the user's benefit and ease of use in mind. > > * The package is called puppet-agent because Puppet is more than the tool > puppet at this point. It's an ecosystem. It's a suite of tools working > together to manage infrastructure and applications. The agent is the word > that means "all the stuff you need to run an endpoint in this ecosystem." >
This conversation serves as evidence that that's *not* a universally accepted meaning for the word "agent", and I'd be surprised to find that more people interpreted "puppet-agent" that way than interpreted plain "puppet" that way. Surely it's natural to interpret "puppet-agent" as something more specific than "puppet", and decidedly *un*natural to interpret "puppet-agent" as more general. > > * We wanted to get away from our users having to carry the cognitive load > of understanding each component we have, what it does and what versions > work well together or have conflicts, what dependencies are required, and > where do I get those? > > Those are worthy goals. Unfortunately, the present scheme isn't there yet. Witness, for example, the misunderstanding about whether the "puppetserver" package is needed or wanted for running a master. Moreover, the effort to lighten the cognitive load has produced an undesirable opacity to what is installed and why, and ultimately a *cognitive dissonance* for people who probe that, or who have already shouldered the cognitive load (i.e. many existing users). That is essentially where this thread started, even if we've only now begun throwing around the word "cognitive". There is a vast gulf between "it's unnecessary to know" and "it's difficult to determine or understand". > * The bits inside the agent should be able to be more of a single user > experience. A key message for this point was when the head of technical > docs said "Nobody wakes up in the morning and says 'I want to hiera > today'". We want the user experience to be easy to manage and work with. > That doesn't mean that if somebody wants to get into the > bits/packages/projects/source they shouldn't be able to -- we just don't > want that to be a requirement. > > The head of technical docs was *wrong*, at least in the sense of the implied comparison to "I want to puppet today". People can and do use Hiera as a standalone tool, and some do care about which version is in use at their site. Likewise for some of the other components. It's true, however, that the "puppet" tool is the headliner in this story. That's why it was a poor idea to put anything else's version number on the AIO package. > * Version numbers - they are hard. We restarted at 1.0 because it was a > new thing. Eric and I were talking yesterday and maybe it would have made > more sense to put it at 4; however because of the argument that he made > earlier in the thread, there are cases where that could create other types > of confusion. > I don't think that reflects a firm grasp of the nature of the problem. The issue is that the "new thing" here is not the thing that the package's version number should be describing in the first place. I don't care about the newness of AIO layout and packaging, and I don't expect many others will either. People don't install Puppet for its packaging. I do care about the versions of various components of the system, but not everyone will, and anyway, we have already established that an AIO package's version number is not a good vehicle for communicating information about versions of auxilliary components. *Focus on what's important*. To your audience. It would be ideal if every component that is developed on its own cycle and therefore has its own version number were delivered in its own package. Package management systems and installation frameworks have long had mechanisms for dealing with the relationships among these. Indeed, Fedora is following exactly this approach for their own Puppet packaging. We covered it already on the dev list, but packaging the various components separately does not need to present a complicated installation experience. Furthermore, it solves some of the other issues that have been raised, especially with respect to versioning the collection as a whole (which ceases to be relevant). > * Somewhere in the thread somebody asked about Puppet's new filesystem > layout and if things would work in another location. I've seen Fedora > already pick up the puppet 4 source and package it right up for their > distro, so I think that's working. [1] > > Excellent, thank you. > * The packaging toolchain will be opened up. We're not quite there yet > because there are some hard-coded assumptions that need to be abstracted > away. We also need some documentation and examples -- otherwise that's > going to be a difficult climb. > > I'm pleased to hear that's on its way. > * I'm not sure if introducing Collections and the AIO and Puppet 4 all at > the same time helped with cognitive load. I'm sorry if that hasn't worked > out. Collections from a user's perspective are mostly a package repo. The > AIO is the end point. Puppet 4 is a subcomponent of that, which can be a > bit confusing. We'll be working on our messaging, tooling and way we talk > about this to make the largest amount of people happy. > > I recognize that collections manifest to users primarily as a package repo. I'm trying to point out that the distinction being drawn between that and AIO packaging is artificial. Collections would easily serve as an excellent framework and vehicle for everything the AIO seems to be trying to accomplish, only better. 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/14d1fce5-0317-43b9-aa01-7fa3d64efec0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
