Puppet users - Jun 2011 - Setting requirements using collection -vs- before/require meta-parameters

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?

Jon

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Fri, Jun 24, 2011 at 5:44 PM, Jon Jaroker <google@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Mon, Jun 27, 2011 at 9:36 AM, Jon Jaroker <google@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

>
> 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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wed, Jun 29, 2011 at 9:54 AM, Jon Jaroker <google@jaroker.com> wrote:
>
> Please let me know if you want me to create a bug for this, or whether
> you have debugging or workaround recommendations.
>
I''ll read your post a bit more closely later on today, but a quick
suggestion would be to use the --graph output on the puppet node, and
visually inspecting the .dot graph files to see if the relationships
you''ve
defined are being applied in the way you think they should be.

That often sheds light on a dependency problem.

http://docs.puppetlabs.com/guides/faq.html#how-do-i-use-puppets-graphing-support

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.