FAQ
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.

Search Discussions

  • Ellison Marks at Mar 27, 2013 at 6:32 pm
    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.
  • Brian Lalor at Mar 28, 2013 at 10:21 am

    On Mar 27, 2013, at 2:32 PM, Ellison Marks 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.
  • Jcbollinger at Mar 28, 2013 at 1:46 pm

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedMar 27, '13 at 6:07p
activeMar 28, '13 at 1:46p
posts4
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2021 Grokbase