Hello Nigel,
Thank you for clarifying the syntax. I suspect that Puppet does not
apply this dependency consistently. The failure is intermittent. I
am using a clumsy workaround to avoid the dependency failure.
My manifest is written so that 'infrastructure' is separate from
'roles'. On my local workstation, I create a 'local' node using VM
Workstation. When this 'local' node connects, puppet should first
connect the NFS share, which contains the Sun Java binary. I then
assign a "frontend" role to this node. This "frontend" role has a
Java class that expects the binary to exist in the /share directory.
Here is the actual node-role assignment I am using on one of the
testing VMs where the dependency fails:
---------------------
node 'node02' inherits local {
S_nfs::Client <| |> -> Class['role_frontend']
class{ 'role_frontend':
add_sampledata => 'true',
}
s_nfs::client { '/opt/share':
action => 'mount',
share_server => '10.10.10.14',
share_source => '/c/UserSource/Linux',
before => Class['s_java', 'tomcat'],
}
}
---------------------
In the above, I am using BOTH forms of the dependency assignment. I
think this is wrong, but it has made the NFS->Class dependency work
consistently for the past few days.
When only one form of the dependency is used (either the 'collection'
or 'before'), then Class['java'] sometimes fails because the NFS
share is mounted AFTER the class is applied.
I believe that the issue is with Puppet because I make changes ONLY to
Class['s_java'] or Class['tomcat']. The node-role assignment above
does not changed.
As I develop the classes, I restore VM Workstation 'node02' to the
original 'clean' snapshot. This snapshot does not have the NFS share
mounted, so Puppet must first mount the NFS share. When only one form
of the dependency assignment is used, the Class['s_java'] is
incorrectly applied before the NFS mount about 30% of the time.
After adding both forms of the dependency (the 'collection' as well as
'before'), I have not had a failure for the past few days.
I believe my syntax is right and that the issue is specific to the
dependency. I wonder if a timeout is occurring before the NFS share
is mounted, but this timeout failure is not being reported. I am not
sure how to isolate the issue further, but the workaround has been OK.
Regards,
Jon
On Jun 25, 10:12 am, Nigel Kersten <ni...@puppetlabs.com> wrote:
> On Fri, Jun 24, 2011 at 5:44 PM, Jon Jaroker <goo...@jaroker.com> wrote:
> > Hello,
>
> > Could someone explain why a relationship implemented with a collection
> > is honored by Puppet, but a 'before' or 'require' meta-parameter fails
> > for the example below.
>
> > ------- THIS WORKS ------
> > Nfs::Client <| |> -> Class['myclass']
> > class { 'myclass': }
> > nfs::client { '/share':}
> > ------------------------
>
> > ---------- DEPENDENCY IS NOT HONORED BY PUPPET HERE -------------
> > class{'myclass': require => Nfs::Client['/share'] }
> > nfs::client{'/share':}
> > ------------------------
>
> > The nfs share must be mounted before packages can be installed in
> > Class['myclass']. Defining this relationship using 'before' or
> > 'require' meta-parameters did not succeed: In the bottom example,
> > Puppet would attempt to install packages contained in the class even
> > though the nfs share was not mounted.
>
> > I realize that the top example is applying the relationship to all
> > 'nfs::client' defined types (which is fine). But why should this
> > method work while the explicit 'before' or 'require' approach fail?
>
> At first glance I think that should work. What version of Puppet are
> you running?
>
> --
> Nigel Kersten
> Product, Puppet Labs
> @nigelkersten
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
