I agree with Adrien. I think the solution will be something with a benefit for
the entire RAL.
The thought I have is of a solution that preserves the original behavior of
having a resource type auto-discover it’s preferred provider on a system. So in
this case, we could allow one resource per catalog that can auto discover its
provider. Then, any other resource will require an explicit provider to be
added.
package { ‘foo’:
ensure => installed,
}
package { ‘foo’:
ensure => installed,
provider => gem,
}
The next question would be how to reference the resource and display the
resource in the report. I figure at this point, just merge the provider name
and the title. I think I saw someone use ‘@‘ earlier, thats fine. Maybe a
tilde, or a double ‘@‘. Some form of delimiter, whatever, it’s only used for
referring to a title+provider internally, it should have no bearing on the name
of the resource used out on the agent.
Package[‘foo’]
- and -
Package[‘foo~gem’]
The final issue is what do we do when the auto-discovered provider overlaps
with a resource that contains and explicit provider. For example, in the same
catalog, a package resource managing ‘foo' that automatically finds its
provider on RHEL, and a package resource managing ‘foo' that explicitly has
‘provider => yum’. These two entries would overlap and express potentially
competing states for the same resource.
This is the part I’m not so sure about, since the provider qualification occurs
out on the agent. If we were only confining on facts, I’d say use the facts on
the master to confine, find overlaps, and fail the catalog; though that sounds
like a lot of work to me, and confinements aren’t always done on just facts
alone. Instead, we could resolve the automatic resource on the agent and then
ignore it in the event it overlaps with a resource that has an explicit
provider, but that feels messy. The only other action I can imagine is to fail
both resources on the agent and make note in the report.
There is one idea I do have to prevent overlap, if a resource only has a single
provider (for example, the host type), then we don’t allow explicit entries and
automatic entries in the same catalog. This does appear to be something we can
check at compilation time.
--
Tom Linkin
Professional Services Engineer
http://puppetlabs.com/
twitter: @trlinkin
Join us at PuppetConf 2014, September 23-24 in San Francisco -
http://bit.ly/pupconf14
Register now and save $350!
On Monday, March 10, 2014 at 11:07 AM, Adrien Thebo wrote:
> My concern with this solution is that it's a one time shim for a single type.
> Granted, it may work and could solve this particular problem. However I think
> this is a flaw in the RAL that has a number of touch points that also need to
> be fixed. This might be me being too idealistic but I think that we can fix
> this issue and improve the entire RAL rather than trying to make individual
> cases work as expected.
>
>
> On Mon, Mar 10, 2014 at 6:09 AM, Drew Blessing <drew.bless...@buckle.com
> (mailto:drew.bless...@buckle.com)> wrote:
> > I agree, it seems like this solution would be simple and effective. I am
> > almost positive there are other types that behave this way. It breaks
> > nothing and fixes everything, as far as I can see.
> >
> > On Saturday, March 8, 2014 2:48:21 PM UTC-6, Pedro Côrte-Real wrote:
> > > On Fri, Mar 7, 2014 at 10:15 PM, Adrien Thebo <adr...@puppetlabs.com>
> > > wrote:
> > > > Long story short, allowing multiple resources to exist with the same
> > > > title
> > > > but different providers is problematic.
> > >
> > > There's no reason to need to do that though. Package just needs to be
> > > able to override the package name without changing $name as that needs
> > > to be unique. So you should be able to do something like:
> > >
> > > package { 'somepackage-in-apt': ensure => present, pkgname =>
> > > 'somepackage', provider => apt, } package { 'somepackage-in-gem':
> > > ensure => absent, pkgname => 'somepackage', provider => gem, }
> > >
> > > Since we've used $pkgname instead of $name this doesn't have the
> > > uniqueness issue. I've looked around the code and this seems easy
> > > enough to do. The Package providers just need to do "pkgname ||= name"
> > > so the older stuff doesn't break.
> > >
> > > Can anyone find any fault with this solution? I've commented on these
> > > bug reports a lot of times and never gotten any answer to this. It
> > > seems pretty amazing that this bug still exists after so many years.
> > >
> > > Pedro
> > --
> > 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
> > (mailto:puppet-dev+unsubscr...@googlegroups.com).
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/puppet-dev/7eb053d7-be1b-47b0-8a72-73a57d898612%40googlegroups.com
> >
> > (https://groups.google.com/d/msgid/puppet-dev/7eb053d7-be1b-47b0-8a72-73a57d898612%40googlegroups.com?utm_medium=email&utm_source=footer).
> >
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Adrien Thebo | Puppet Labs
>
> --
> 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
> (mailto:puppet-dev+unsubscr...@googlegroups.com).
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CALVJ9SKe5JWSA%3D1syKLHownEOu87GkXRyr_fpw%3DSUuA4b2vWmw%40mail.gmail.com
>
> (https://groups.google.com/d/msgid/puppet-dev/CALVJ9SKe5JWSA%3D1syKLHownEOu87GkXRyr_fpw%3DSUuA4b2vWmw%40mail.gmail.com?utm_medium=email&utm_source=footer).
> For more options, visit https://groups.google.com/d/optout.
--
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/B8DB13F325924A03951959952FDEA7CB%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.
