Puppet users - Mar 2013 - execution order not being honored with ->

I''m using Puppet 3.1.1 in standalone mode.  I''m running
"puppet apply" like this:

    basedir="$( dirname $( readlink -f "${0}" ) )"
    puppet apply \
        --detailed-exitcodes \
        --modulepath=${basedir}/modules \
        --hiera_config=${basedir}/hiera.yaml \
        ${basedir}/manifests/site.pp

site.pp looks like this (verbatim):

    node default {
        include "role::${::nibiru_app_name}"

        if $nibiru_region != ''vagrant'' {
            include dns_workarounds

            Class[''dns_workarounds''] ->
Class["role::${::nibiru_app_name}"]
        }

    }

modules/dns_workarounds/manifests/init.pp is similar to this:

    class dns_workarounds {
        host {''b3-proj-dev-03.example.com'': ip =>
''10.1.128.18''}
        host {''b3-proj-dev-04.example.com'': ip =>
''10.1.128.19''}
        host {''b3-proj-dev-05.example.com'': ip =>
''10.1.128.20''}

    }

nibiru_app_name comes from facter.  The dns_workarounds class is just a bunch of
host resource definitions that I have to add before everything else runs, due to
some wonky DNS.  I''m able to get a successful Puppet run, but
I''m finding that not all of the host resources defined in
dns_workarounds are being processed before the role is processed.  I see the
following on stdout:

    Notice:
/Stage[main]/Dns_workarounds/Host[b3-proj-dev-05.example.com]/ensure: created
    Notice: /Stage[main]/Role::Base/Package[python-pip]/ensure: ensure changed
''purged'' to ''present''
    Notice: /Stage[main]/Dns_workarounds/Host[login.dev.example.com]/ensure:
created

So far I haven''t had a problem with the puppet apply failing due to the
out-of-order resource processing, but I''m sure it''ll bite me
eventually.  Am I declaring the ordering correctly with -> ?  I also tried
just using "require dns_workarounds" in the if block, but
that''s giving me the same result.

Thanks,
Brian

--
Brian Lalor
blalor@bravo5.org


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

If your role class declares other classes you probably being bitten 
by http://projects.puppetlabs.com/issues/8040. That is, and classes 
declared in the role class are not confined by the dependency graph.
It''s
something they''re working on fixing, but in the meantime, the
recomendation
is to use the anchor 
pattern. http://projects.puppetlabs.com/projects/puppet/wiki/Anchor_Pattern. 
The achor resource type comes from the stdlib, IIRC.

On Wednesday, March 27, 2013 11:07:04 AM UTC-7, blalor
wrote:
>
> I''m using Puppet 3.1.1 in standalone mode.  I''m running
"puppet apply"
> like this: 
>
>     basedir="$( dirname $( readlink -f "${0}" ) )" 
>     puppet apply \ 
>         --detailed-exitcodes \ 
>         --modulepath=${basedir}/modules \ 
>         --hiera_config=${basedir}/hiera.yaml \ 
>         ${basedir}/manifests/site.pp 
>
> site.pp looks like this (verbatim): 
>
>     node default { 
>         include "role::${::nibiru_app_name}" 
>
>         if $nibiru_region != ''vagrant'' { 
>             include dns_workarounds 
>
>             Class[''dns_workarounds''] -> 
> Class["role::${::nibiru_app_name}"] 
>         } 
>
>     } 
>
> modules/dns_workarounds/manifests/init.pp is similar to this: 
>
>     class dns_workarounds { 
>         host {''b3-proj-dev-03.example.com'': ip =>
''10.1.128.18''}
>         host {''b3-proj-dev-04.example.com'': ip =>
''10.1.128.19''}
>         host {''b3-proj-dev-05.example.com'': ip =>
''10.1.128.20''}
>
>     } 
>
> nibiru_app_name comes from facter.  The dns_workarounds class is just a 
> bunch of host resource definitions that I have to add before everything 
> else runs, due to some wonky DNS.  I''m able to get a successful
Puppet run,
> but I''m finding that not all of the host resources defined in 
> dns_workarounds are being processed before the role is processed.  I see 
> the following on stdout: 
>
>     Notice:
/Stage[main]/Dns_workarounds/Host[b3-proj-dev-05.example.com]/ensure:
> created 
>     Notice: /Stage[main]/Role::Base/Package[python-pip]/ensure: ensure 
> changed ''purged'' to ''present'' 
>     Notice:
/Stage[main]/Dns_workarounds/Host[login.dev.example.com]/ensure:
> created 
>
> So far I haven''t had a problem with the puppet apply failing due
to the
> out-of-order resource processing, but I''m sure it''ll bite
me eventually.
>  Am I declaring the ordering correctly with -> ?  I also tried just
using
> "require dns_workarounds" in the if block, but that''s
giving me the same
> result. 
>
> Thanks, 
> Brian 
>
> -- 
> Brian Lalor 
> bla...@bravo5.org <javascript:> 
>
>
>
-- 
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 puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

On Mar 27, 2013, at 2:32 PM, Ellison Marks <gtyaoi@gmail.com> wrote:
> If your role class declares other classes you probably being bitten by
http://projects.puppetlabs.com/issues/8040. That is, and classes declared in the
role class are not confined by the dependency graph. It''s something
they''re working on fixing, but in the meantime, the recomendation is to
use the anchor pattern.
http://projects.puppetlabs.com/projects/puppet/wiki/Anchor_Pattern. The achor
resource type comes from the stdlib, IIRC.

Thanks, Ellison.  Yes, other classes are declared.  This really violates the
principle of least surprise.  I''ll give the anchors a try today,
hopefully.

--
Brian Lalor
blalor@bravo5.org


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

On Thursday, March 28, 2013 5:21:51 AM UTC-5, blalor
wrote:
>
> On Mar 27, 2013, at 2:32 PM, Ellison Marks <gty...@gmail.com
<javascript:>>
> wrote:
>
> If your role class declares other classes you probably being bitten by 
> http://projects.puppetlabs.com/issues/8040. That is, and classes declared 
> in the role class are not confined by the dependency graph. It''s
something
> they''re working on fixing, but in the meantime, the recomendation
is to use
> the anchor pattern. 
> http://projects.puppetlabs.com/projects/puppet/wiki/Anchor_Pattern. The 
> achor resource type comes from the stdlib, IIRC.
>
>
> Thanks, Ellison.  Yes, other classes are declared.  This really violates 
> the principle of least surprise.  I''ll give the anchors a try
today,
> hopefully.
>

I understand that you were surprised by the behavior, but you need to 
understand what''s going on here.  Although classes (and definitions)
are
sometimes described as "containers", they are not *exclusive*
containers
when it comes to classes.  Multiple classes and definitions may all declare 
the same class, so there would be an even bigger mess (of dependency 
cycles) if all relationships were automatically forwarded from classes to 
their declared classes.

Indeed, a key thing to understand is that classes are containers for *
resources*, but classes themselves should not be considered resources.  
Implementation details notwithstanding, classes behave rather differently 
than ordinary resources.  They are especially distinguished by having no 
client-side behavior whatsoever, and even more so by the fact that they *do*have
significance to the master.  Then there''s the whole multiple
declaration thing.  There are some other behavior differences that could 
surprise you, too, if you don''t distinguish classes from resources.

Although I usually make this recommendation for different reasons, it is a 
good idea to avoid using resource-like, parameterized-style class 
declarations (class { ''foo'': ... }) and instead declare
classes via the
''include'' (or ''require'') function.  Bind
custom class parameter values via
hiera where needed, or even drop class parameters altogether and just use 
hiera explicitly.  This has functional benefits, but in this case I''m 
recommending it as a means to help you remember that classes are not 
(normal) resources.


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