On Wednesday, October 8, 2014 1:43:09 PM UTC-5, Andy Parker wrote:
> My proposal allows
>
> package { 'mysql-gem': name => mysql, provider => gem, ensure =>
> installed }
> package { 'mysql': ensure => installed }
>
> Such statements would have previously collided because both would have
> created a reference of Package[mysql]. My proposal is that the
> Package[mysql-gem] no longer gets aliased as Package[mysql], which means
> that the collision never occurs.
>
> John is right that this approach is a little bit like throwing in the
> towel. It does drop some of the uniqueness constraints that have been part
> of puppet for a while, but only in the case where an author has decided
> that they don't want those constraints, specifically in cases where the
> author has determined that the title should be different from the namevar.
> It does open up some unwanted catalogs, specifically things like:
>
> package { 'remove-mysql': name => mysql, ensure => absent }
> package { mysql: ensure => installed }
>
> Is protecting against that absolutely needed?
>
>
Are third-party packages desirable? Seriously, if I am to accept
third-party packages without extensive code review (which I might not do
anyway, I grant), then there's no way I I can accept that the module
author, at his sole discretion, can slip in an unwanted duplicate
resource. Yes, I *do* want to be protected against the same physical
resource being managed via multiple distinct logical Resources. I *like*
that.
> ## How does exec do this?
>
> Exec is an interesting type. It doesn't seem to play by the rules of the
> other types. For example you can do:
>
> exec { "one": command => "/bin/echo hi" }
> exec { "two": command => "/bin/echo hi" }
>
> This works in spite of the fact that "command" is the namevar for exec (if
> you leave out command, it defaults to the title). How does it do this?
>
> The answer is that you can mark a type as "not isomorphic" (the default is
> that they are "isomorphic"). The only thing that this seems to control is
> to stop creating that pesky alias that gets in the way! There is a bit of
> documentation about this at
> https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type.rb#L58-L61
>
>
Do not confuse the interface with the implementation. Execs are "not
isomorphic" because different instances with the same command do not manage
the same physical resource. That support for that status is implemented so
simply is not relevant to the issue at all.
> Another solution is to mark package as not isomorphic as well. Based on
> other comments, user is also not isomorphic. Neither is tidy. Maybe others
> as well. Doing this would achieve the same thing as my original suggestion.
>
That drives to the crux of the issue: packages and users are partially
isomorphic but partially not. Package resources for certain providers
(e.g. yum, apt) certainly are isomorphic when grouped by provider.
Moreover, yum- and rpm-provided packages together form a single isomorphic
group, so strict grouping by provider doesn't work. On the other hand, at
least some providers (gem, pip) could divide isomorphic groups even more
finely.
Users are an even thornier issue. Inasmuch as user information may be
recorded in various places and forms, each with its own provider, (system)
Users can be construed as non-isomorphic. From the perspective of modeling
requirements on the system, however, only one User resource for each
username matters, and I need to be able confidently to model the properties
of *that* user. Having to guess which one it is is not appealing.
>
> Other Topics covered so far
> -------------------------------------
>
> There have been a lot of other proposals floated. They either don't
> address the issue, or they don't solve it in any fashion that is complete
> enough based on various cases I've seen.
>
> ## Introduce a new pkgname parameter
>
>
>
> I see this solution as equivalent to what I proposed above.
>
Agreed.
>
> ## Primary/Secondary packages
>
> The proposals to have "primary" and "secondary" package types and split
> the providers seems like a losing battle to me. There just isn't a clear
> distinction. For instance RPM is on a lot of different OSes, but isn't the
> primary packaging system (SLES?). Often users want to manage both ruby gems
> and python pips on the same node, but both are considered secondary package
> management tools.
>
What package type is "primary" is OS- and possibly system-dependent, but
that's nothing new. There *is* a clear distinction, else it never could
have worked for so long to use Package resources without specifying
providers explicitly.
As proposed, the SecondaryPackage type can accommodate instances with the
same (packaging-type-relative) package name but different packaging types
by using a provider so that it doesn't map to packaging type ( == package
namespace).
>
> ## Drop Package, have a type per provider
>
> The proposal for separate types entirely is interesting (and also throws
> in the towel). If I'm understanding it correctly we would stop trying to
> have a single type with multiple providers and instead have a single type
> has a single provider.
>
I had suggested the alternative of doing that for "secondary" packages.
I'm uncertain about anyone else, but my own idea never involved dropping
the Package type, which would still require multiple providers (but maybe
not as many as it has now).
> This would allow for the some more flexibility, but also makes writing
> reusable modules much more of a pain. You could no longer write:
>
> package { 'apache': ensure => installed }
>
>
As I said, I did not contemplate dropping the package type. It serves a
useful purpose.
> However, in practice I'm not sure that that has really worked out too
> well. Just take a look at what it really takes to install apache:
> https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/package.pp
>
> .
>
Even with all the mess involved in determining the correct properties of
any given Package, the Package resource still serves a useful role. It's a
good and well-known abstraction for real software packages, it serves as a
place to seat commonly-needed relationships, it generates events in a
standardized way, .... It's even pretty easy to use for people who aren't
concerned with supporting a great diversity of environments (which I think
you would find is a substantial fraction of users).
> ## Providers are subtypes of the Package type
>
> A variation of the last proposal is to allow types to be subtypes. What
> exactly that would mean isn't entirely clear.
>
Not clear to me, either.
> I think it is that rpm_package would inherit all of the
> parameters/properties of package, which is great! It allows rpm specific
> parameters to be on an RPM type. However, how to references work? Does this
> work:
>
> rpm_package { 'rpm-apache': name => 'apache', ensure => installed }
>
> file { '/etc/apache/httpd.conf': require => Package[apache] }
>
>
I had not supposed that allowing subtyping would involve supporting
polymorphic resource references or collectors. In part, that's because I
agree that result would not be substantially different than what we have
now.
> Thoughts
> ---------------
>
> I looked into removing the constraint on unique namevars after noticing
> that all examples of users trying to get around this problem involved them
> setting a unique title and a conflicting namevar. That indicated that the
> mental model of most users is that the titles need to be unique and the
> explicit namevar value is the escape hatch. We can make that expectation
> work by either dropping the aliasing for the namevar universally or by
> marking certain types as not-isomorphic.
>
Your observations agree with mine, but consider an alternative
interpretation: users on the whole don't understand the distinction between
title and namevar, nor especially the significance of the namevar as
distinguished from the significance of the title. It doesn't help that the
most common bona fide scenario for differing title and namevar seems to be
on Execs, which are excused from following some of the rules. I don't
think many users have a sufficiently-developed mental model of Puppet to
see namevars as an escape hatch, or as anything else, really. I suspect
many don't even recognize the that the concept exists. (Too many people
simply don't read docs.)
>
> The essence of this problem is that people are trying to describe
> completely valid configurations on a node, but the constraints imposed by
> puppet's modeling system does not allow these configurations.
>
Yes.
> A classic problem of type systems. My proposal allows some invalid
> configurations in addition to the valid configurations. I haven't seen any
> proposal yet that allows the valid configurations the people want as well
> as disallowing the invalid configurations.
>
The SecondaryPackage approach can do that, particularly if it is developed
and maintained in conjunction with Package, with the proviso that under
certain unlikely circumstances the conflict might not be recognized until
catalog application.
> Since this problem has gone on for so long, I'm not sure if we *will* find
> such a solution and so think we should just move ahead with either dropping
> the aliasing completely or making package non-isomorphic. I'd like to get
> this fixed in puppet 4.0.0. So as a way of driving to a conclusion: what
> would making package non-isomorphic break?
>
It would make Puppet unable to diagnose genuinely conflicting Package
declarations, possibly resulting in unwanted or unstable system
configurations, resource flapping, and even operational failure of managed
systems. Probably most relevant failure scenarios would involve
conflicting 'ensure' parameters. Some would likely involve the prevalent
antipattern of using defined() to try to work around package collisions,
either directly (the defined() check is no longer effective at all) or
indirectly (the defined() check triggers on resources it was not intended
to catch).
The most likely vector for introducing such failures into a Puppet
environment is the same one that is responsible now for introducing most
resource collisions: installation or update of third-party packages. It is
unlikely to be clear to users, however, that they need to look out for
(near-)silent package-related failures after working on their module
collections, nor are they likely to be patient about such problems when
they are discovered. This could be a significant setback for the module
ecosystem.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/8ed694c1-32f0-4a36-bd1d-09afeb65719b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
