Puppet users - Jun 2013 - puppet agent errors for non included module.

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.

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
<jeremiahjester@gmail.com>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.

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.

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