On Tuesday, May 9, 2017 at 7:31:30 AM UTC-5, jmp242 wrote:
>
> Not sure - maybe this is a horrible idea, but I've got a package I'm using
> that would ideally use the same reboot resource as all my other packages,
> but in this case is in it's own class because there are several steps that
> are more complicated than just applying the package. On many VMs and test
> computers, this worked, but on ~7 it fails being unable to find the
> required resource in the other class. I'm trying to upgrade using
> chocolatey packages our Autodesk Inventor products:
> class inventor {
> require yum, packages
>
> So at the start I require my packages class, so the resource should be
> defined there (called reboot'before') and seems to be on most computers.
> package { 'vc2015':
> ensure => absent,
> provider => 'chocolatey',
> require => Reboot['before'],
> }
>
> However, on about 7 computers out of ~80, I get that it can't find the
> reboot resource. I tried doing Packages::Reboot['before'], but that didn't
> work either...
>
Resources are global once declared. If the form you present works for some
machines but not for others, therefore, it seems logical to conclude that
the wanted resource is not declared on the systems where it fails.
And indeed, the points out a serious flaw in your approach: if you depend
directly on a resource declared (or expected to be declared) by a different
class, then you implicitly depend on that class being declared. If, as in
this case, you do not also place an *explicit* dependency on that, then you
are at risk of that dependency not being met. On the other hand, if you do
place the explicit dependency (e.g. by include-ing or require-ing the
class) then you are probably better off expressing the ordering
relationship in terms of the class, not the resources it declares.
I note in passing, however, that there is another, separate, potential
problem here: the correct name for the resource type for use in a resource
reference. The fully-qualified name should always be used, but since there
is no Reboot among the resource types included with core Puppet, I'm
uncertain what the fully-qualified name would be in this case. If it is a
native type then its name is in the anonymous namespace. If it is a
defined type, then its fully-qualified name depends on how it was declared,
but it *should* have been declared in a module, with its name assigned to
the module's namespace. In any event, which class declares a particular
resource instance has nothing whatever to do with how that instance can be
referenced.
>
> Is this even supposed to work? I'm using Puppet Agent 1.8.1 on the client,
> which is Windows 7 x64 SP1. Chocolatey 10.2 for business but this seems a
> straight puppet resource / syntax error for me.
>
It can work, but it would be better to create a class whose only job is to
ensure that the machine is rebooted, and for every other class that
conceives a need to reboot to (1) declare that class (using one of the
include-like forms) and (2) establish an appropriate ordering relationship
with the class. It is better for classes to avoid dependencies on the
internals of other classes; if you do it at all, you should at least avoid
doing it across module boundaries.
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/45679f16-5f42-4e09-a78c-3201c937ec41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
