> On May 1, 2015, at 08:14, jcbollinger <[email protected]> wrote:
>
> 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 unnatural to interpret "puppet-agent" as more
> general.
Correct.
>
> * 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.
The fact that component naming and versioning has suffered horribly is part of
why we are here today, yes.
> 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”.
Isn’t Puppet a tool for carrying this cognitive load itself? Once I’ve defined
an exact package version to be installed somewhere, based on research and
testing, I generally “forget about” the meta details until something goes wrong
that forces me to remember/re-learn these details because these sorts of
Religious Wars about Versioning as well as cross-entity version tracking means
that “nothing” has the same version on my system as it advertised on the tin.
That the very toolset that helps me manage such things has suddenly succumbed
to the very pox it helps me manage is as ironic as a Park Slope haircut.
> There is a vast gulf between "it's unnecessary to know" and "it's difficult
> to determine or understand”.
^^ That right there.
> * 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.
No one — and by this I actually mean “not a single living soul upon the Earth”
— has ever woken up and said “I *want* to memorize the versioning scheme of the
toolkit I use to do my job, across ${number} of different components today”
unless they were studying for a certification, test, etc. People *have* woken
up and said “I want to use ${toolkit_that_I_do_my_job_with} today”, even if
that was not what they called the toolkit. With that said, the principle that
the Hiera version number should be subordinate to the Puppet version number _on
some level_ is not an unreasonable one, and happens to be the answer I advocate
for personally. I do agree that the AIO/${installer} version should always
correspond to the release of the nominal headlining product.
> * 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.
I am also pretty baffled that this is considered hard, or even a matter for
debate. Principle of Least Surprise, or just have the contents match the tin.
> 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).
This is the ideal, IMHO — “pkg-add-command -install puppet-4-server.pkg”
installs everything one needs to run a fully-functional environment.
“pkg-add-command -install puppet-4-client.pkg” successfully hides from the
end-user what’s being installed, _recognizes what’s being installed and acts
accordingly_ (see other thread about file permissions and puppet user active
today), and is no more complicated than that if there is no need. If one cares
to make sure that items that CAN be upgraded out-of-bundle “match”, the
—framework-version command previously suggested (or similar) can be leveraged
to make sure everything assertively and denotatively matches. At a certain
level of support/upgrade planning/etc, then individual component names and
numbers become interesting again, but KBs or the like should exist to assist in
those circumstances.
>
> * 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.
Drawing a distinction for the user between either of these mechanisms and
“Puppet”, on any level, is artificial and confusing to the end user. If you
come over to my house for dinner and we’re talking about the car you came over
in, it either is new, interesting, or I’m being polite — I don’t actually care
if you came in a Honda or a Toyota, on most levels.
Cheers,
jcf
--
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/1EBA4A79-6E9D-4D48-B0DA-DD080AD97F63%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
