[Puppet Users] Re: Setting requirements using collection -vs- before/require meta-parameters
So it looks like we have a bug that I'm still trying to find in the
database, and I think it might be affecting you.
If you have a class that only declares other classes in it, and doesn't have
any resources in it, then it gets removed from the dependency graph.
Hello Nigel,
To test whether this bug is the cause, I added a file resource to the
node class. The updated node class is below. Almost all of the
other classes contain a similar file resource that is used to generate
a dokuwiki-formatted page showing parameters and values.
I rebuilt 'node02' six times while developing the classes. The node
class below remained unchanged.
The Class-DefinedType dependency below was not honored on two
rebuilds: Puppet attempted to install Package['java'] before the nfs
share containing the binary was mounted.
I noticed a second dependency failure within Class['role_frontend'].
It is a similar Class-DefinedType dependency, although reversed:
class role_frontend (...) {
...
Class['tomcat'] - Tomcat::Instance | |
...
}
I observed one deployment where Tomcat::Instance was applied before
Class['tomcat']. Both the Tomcat::Instance defined type and
Class['tomcat'] have at least one managed resource, the file resource
I use to create dokuwiki file fragments.
These dependency failures appear when I work on unrelated classes.
For example, the tomcat dependency above started failing
intermittently after I added Class['tomcat::logging'] as a managed
resource within Class['tomcat'].
These dependency failures are intermittent. They appear to occur
between Classes and Defined Types. They appear to occur for both the
collector- and 'before/require' -approach to specifying dependencies.
They occur even when the classes contain at least one managed
resource.
My only workaround is to run puppet twice. (The original workaround
of using collector and 'before' to specify dependencies also
intermittently fails.)
Please let me know if you want me to create a bug for this, or whether
you have debugging or workaround recommendations.
Regards,
Jon
---
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'],
}
# Documentation File
file{Node Documentation:
path= '/tmp/node_doc',
ensure = present,
content = 'Node Documentation Here',
}
}
--
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.
[Puppet Users] Re: Setting requirements using collection -vs- before/require meta-parameters
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.
Re: [Puppet Users] Re: Setting requirements using collection -vs- before/require meta-parameters
On Mon, Jun 27, 2011 at 9:36 AM, Jon Jaroker goo...@jaroker.com wrote: 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. So it looks like we have a bug that I'm still trying to find in the database, and I think it might be affecting you. If you have a class that only declares other classes in it, and doesn't have any resources in it, then it gets removed from the dependency graph. It's clearly a bug, and we're going to fix it. Is this possibly your problem? Does the description fit? -- 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.
