FAQ
Does anyone know why i would get a module error for my 'base' module that
I'm not even including for a node? I'm explicitly NOT include the 'base',
yet puppet-client-t2 still errors when i pull it in. Snips from both are
below. Any ideas why this would happen?

Thanks,
JJ

====

site.pp file

[root@puppet-master-t1 puppet]# cat manifests/site.pp
node 'puppet-client-t1' {
include base
include base::firewall
}
node 'puppet-client-t2' {
include monitoring
}

puppet agent run on client...

jjest@puppet-client-t2 puppet]$ su -c "puppet agent -t"
Password:
Info: Retrieving plugin
Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
Info: Loading facts in
/var/lib/puppet/lib/facter/iptables_persistent_version.rb
Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
Info: Loading facts in /var/lib/puppet/lib/facter/ip6tables_version.rb
Info: Loading facts in /var/lib/puppet/lib/facter/iptables_version.rb
*Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Could not find data item rsfw_rules in any Hiera data file and no default
supplied at /etc/puppet/modules/base/manifests/firewall.pp:1 on node
puppet-client-t2.mcis.washington.edu*
*Warning: Not using cache on failed catalog*
*Error: Could not retrieve catalog; skipping run*


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

  • Wolf Noble at Jun 17, 2013 at 7:12 am
    Hi JJ,

    I've seen this happen when class dependencies are placed outside the
    specific class' scope, ie:

    # default.pp
    #
    #
    Anchor['my_prereq::end'] -> Class['default']
    class{ 'default':
       notice 'default'
    }

    I've only seen this occur with anchors, but it's entirely possible it
    happens with other resources too..


    I've seen a node which uses class my_prereq, and class default run, and
    then another node run with neither of those classes in it's catalog, but
    the error about the unsatisfied relationship still displayed…

    I've not seen any other instances of this occur, but there may be other
    reasons for it to happen.
    HTH.

    W



    On Wed, Jun 12, 2013 at 3:52 PM, Jeremiah Jester
    wrote:
    Does anyone know why i would get a module error for my 'base' module that
    I'm not even including for a node? I'm explicitly NOT include the 'base',
    yet puppet-client-t2 still errors when i pull it in. Snips from both are
    below. Any ideas why this would happen?

    Thanks,
    JJ

    ====

    site.pp file

    [root@puppet-master-t1 puppet]# cat manifests/site.pp
    node 'puppet-client-t1' {
    include base
    include base::firewall
    }
    node 'puppet-client-t2' {
    include monitoring
    }

    puppet agent run on client...

    jjest@puppet-client-t2 puppet]$ su -c "puppet agent -t"
    Password:
    Info: Retrieving plugin
    Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
    Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
    Info: Loading facts in
    /var/lib/puppet/lib/facter/iptables_persistent_version.rb
    Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
    Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
    Info: Loading facts in /var/lib/puppet/lib/facter/ip6tables_version.rb
    Info: Loading facts in /var/lib/puppet/lib/facter/iptables_version.rb
    *Error: Could not retrieve catalog from remote server: Error 400 on
    SERVER: Could not find data item rsfw_rules in any Hiera data file and no
    default supplied at /etc/puppet/modules/base/manifests/firewall.pp:1 on
    node puppet-client-t2.mcis.washington.edu*
    *Warning: Not using cache on failed catalog*
    *Error: Could not retrieve catalog; skipping run*


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

    --
    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.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at Jun 17, 2013 at 3:48 pm

    On Monday, June 17, 2013 2:12:35 AM UTC-5, Wolf Noble wrote:
    Hi JJ,

    I've seen this happen when class dependencies are placed outside the
    specific class' scope, ie:

    # default.pp
    #
    #
    Anchor['my_prereq::end'] -> Class['default']
    class{ 'default':
    notice 'default'
    }
    It is incorrect to make that relationship declaration (via the chain
    operator) if there are any nodes that do not declare the specified anchor,
    because top-level declarations in *any* manifest file apply to all nodes.
    It is poor practice to make declarations at top level like that other than
    class and defined-type definitions, however, except sometimes in site.pp
    and manifests 'import'ed by it. When they appear in other places, Puppet
    may or may not see them during any given catalog run, but you must not
    assume that Puppet will fail to see them under any given circumstances.

    Thus, manifest files that are intended to be autoloaded should contain
    exactly one thing at top-level: the definition of the class or defined type
    that is the autoloading target.


    On the other hand, I would be surprised if a top-level dependency
    declaration caused a referenced class to be declared when it otherwise was
    not declared. That's not an issue in the example because a declaration of
    the class involved occurs in the same manifest, at the same level as the
    chain, so the class (but not necessarily the anchor) will always be
    declared if the relationship is declared. That could point to the actual
    problem, though: there may somewhere be just such a top-level declaration
    of class 'base::firewall'. Otherwise, it must be that class 'monitoring'
    declares class 'base::firewall', either directly or indirectly.


    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.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Wolf Noble at Jun 24, 2013 at 5:00 pm
    <snip>

    It is incorrect to make that relationship declaration (via the chain
    operator) if there are any nodes that do not declare the specified anchor,
    because top-level declarations in *any* manifest file apply to all
    nodes. It is poor practice to make declarations at top level like that
    other than class and defined-type definitions, however, except sometimes in
    site.pp and manifests 'import'ed by it. When they appear in other places,
    Puppet may or may not see them during any given catalog run, but you must
    not assume that Puppet will fail to see them under any given circumstances.
    I absolutely agree. I was not recommending this as something to do, merely
    stating that I've seen the exhibited behavior in that circumstance.


    Thus, manifest files that are intended to be autoloaded should contain
    exactly one thing at top-level: the definition of the class or defined type
    that is the autoloading target.


    On the other hand, I would be surprised if a top-level dependency
    declaration caused a referenced class to be declared when it otherwise was
    not declared. That's not an issue in the example because a declaration of
    the class involved occurs in the same manifest, at the same level as the
    chain, so the class (but not necessarily the anchor) will always be
    declared if the relationship is declared. That could point to the actual
    problem, though: there may somewhere be just such a top-level declaration
    of class 'base::firewall'. Otherwise, it must be that class 'monitoring'
    declares class 'base::firewall', either directly or indirectly.
    I have actually seen an error arise on a node with the cause being an
    ordering declaration occurring in a non-included class file, but outside
    the scope of that class. I suspect it may be a bug, however I've only
    encountered it while utilizing this antipattern.

    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.

    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJun 13, '13 at 1:19p
activeJun 24, '13 at 5:00p
posts4
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase