Puppet users - Sep 2013 - Puppet 3.2.2: Could not find declared class

Hi!
Every now and then I get the following error message in logs on one particular
host on my network:

"Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Puppet::Parser::AST::Resource failed with error ArgumentError: Could not find
declared class cachier at /etc/puppet/manifests/nodes.pp:285 on node
hostname1.site"

The next run the error disappears. In a couple of days I see the same message
with one difference - it says that it cannot find another class. So the class
name can vary. Host name is the same every time.

Do you know what can cause an error like this ? 

--
Best regards,
Sergey Arlashin

 


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

Hi Sergey,

I''ve noticed behavior similar to then when resource ordering is
specified
outside of a class; something like this:

#foo class
#
#
Class[''prereq''] -> Class[''foo'']
class foo() {
  #some stuff here
}

since that dependency isn''t occurring INSIDE the boundary of
Class[''foo''],
 there can be weirdness.

I''m not certain that''s what''s going on for you, but I
have seen that same
behavior in those instances.

HTH

W



On Thu, Sep 26, 2013 at 11:31 AM, Sergey Arlashin <
sergeyarl.maillist@gmail.com> wrote:
> Hi!
> Every now and then I get the following error message in logs on one
> particular host on my network:
>
> "Error: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Puppet::Parser::AST::Resource failed with error ArgumentError:
> Could not find declared class cachier at /etc/puppet/manifests/nodes.pp:285
> on node hostname1.site"
>
> The next run the error disappears. In a couple of days I see the same
> message with one difference - it says that it cannot find another class. So
> the class name can vary. Host name is the same every time.
>
> Do you know what can cause an error like this ?
>
> --
> Best regards,
> Sergey Arlashin
>
>
>
>
> --
> 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.

On Thursday, September 26, 2013 3:11:24 PM UTC-5, Wolf Noble
wrote:
>
> Hi Sergey,
>
> I''ve noticed behavior similar to then when resource ordering is
specified
> outside of a class; something like this:
>
> #foo class
> #
> #
> Class[''prereq''] -> Class[''foo'']
> class foo() {
>   #some stuff here
> }
>
> since that dependency isn''t occurring INSIDE the boundary of
Class[''foo''],
>  there can be weirdness.
>
> I''m not certain that''s what''s going on for you,
but I have seen that same
> behavior in those instances.
>
>
I have trouble believing that an error arising from such a cause would 
randomly appear and disappear as Sergey describes his doing.  Something 
must be changing on the master between runs.

With that said, there have been a few similar issues reported in the past; 
generally they seem to be triggered by manifest files being edited, and 
often they are resolved by restarting the master.  If Sergey''s master
is
running under Passenger then he may be getting new masters starting 
frequently enough to explain the problem disappearing.  I can''t
immediately
explain why the problem seems pinned to one node, but perhaps this will 
serve as a clue.


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.

On Thu, Sep 26, 2013 at 5:21 PM, jcbollinger
<John.Bollinger@stjude.org>wrote:
>
>
> On Thursday, September 26, 2013 3:11:24 PM UTC-5, Wolf Noble wrote:
>>
>> Hi Sergey,
>>
>> I''ve noticed behavior similar to then when resource ordering
is specified
>> outside of a class; something like this:
>>
>> #foo class
>> #
>> #
>> Class[''prereq''] -> Class[''foo'']
>> class foo() {
>>   #some stuff here
>> }
>>
>> since that dependency isn''t occurring INSIDE the boundary of
>> Class[''foo''],  there can be weirdness.
>>
>> I''m not certain that''s what''s going on for
you, but I have seen that same
>> behavior in those instances.
>>
>>
>
> I have trouble believing that an error arising from such a cause would
> randomly appear and disappear as Sergey describes his doing.  Something
> must be changing on the master between runs.
>
> With that said, there have been a few similar issues reported in the past;
> generally they seem to be triggered by manifest files being edited, and
> often they are resolved by restarting the master.  If Sergey''s
master is
> running under Passenger then he may be getting new masters starting
> frequently enough to explain the problem disappearing.  I can''t
immediately
> explain why the problem seems pinned to one node, but perhaps this will
> serve as a clue.
>
>
> John
>
What I''ve seen is that a dependency derived from catalog/nodeA, when
NOT
inside a class, can be inconsistently "inherited" by catalog/nodeB if
catalog compilation is occurring at the same time, or soon after A.

I''m not sure if this still occurs >3.x

-- 
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 Thursday, September 26, 2013 5:39:10 PM UTC-5, Wolf Noble
wrote:
>
>
>
>
> On Thu, Sep 26, 2013 at 5:21 PM, jcbollinger
<John.Bo...@stjude.org<javascript:>
> > wrote:
>
>>
>>
>> On Thursday, September 26, 2013 3:11:24 PM UTC-5, Wolf Noble wrote:
>>>
>>> Hi Sergey,
>>>
>>> I''ve noticed behavior similar to then when resource
ordering is
>>> specified outside of a class; something like this:
>>>
>>> #foo class
>>> #
>>> #
>>> Class[''prereq''] ->
Class[''foo'']
>>> class foo() {
>>>   #some stuff here
>>> }
>>>
>>> since that dependency isn''t occurring INSIDE the boundary
of
>>> Class[''foo''],  there can be weirdness.
>>>
>>> I''m not certain that''s what''s going on
for you, but I have seen that
>>> same behavior in those instances.
>>>
>>>
>>
>> I have trouble believing that an error arising from such a cause would 
>> randomly appear and disappear as Sergey describes his doing.  Something
>> must be changing on the master between runs.
>>
>> With that said, there have been a few similar issues reported in the 
>> past; generally they seem to be triggered by manifest files being
edited,
>> and often they are resolved by restarting the master.  If
Sergey''s master
>> is running under Passenger then he may be getting new masters starting 
>> frequently enough to explain the problem disappearing.  I
can''t immediately
>> explain why the problem seems pinned to one node, but perhaps this will
>> serve as a clue.
>>
>>
>> John
>>
>
> What I''ve seen is that a dependency derived from catalog/nodeA,
when NOT
> inside a class, can be inconsistently "inherited" by
catalog/nodeB if
> catalog compilation is occurring at the same time, or soon after A.
>
> I''m not sure if this still occurs >3.x
>  
>

That makes a certain amount of sense, for any declaration at top scope 
applies (in principle) to all nodes, regardless of which manifest file it 
appears in.  Puppet does not have a sense of file scope.

This does present a potential issue, however, in that Puppet does not 
necessarily parse every available manifest on every catalog compilation 
run.  Generally, it attempts to parse only those manifest files that it 
needs to do, as directed by ''import'' statements and the
autoloader.  If you
follow the prevailing best practices by using modules and relying 
autoloading, then you may therefore get a false sense of a file scope 
associated with your classes and definitions, or else get the impression 
that classes'' and definitions'' scopes extend to the top level
of the files
in which their definitions appear.

Relying on such a misunderstanding can get you into trouble.  In 
particular, Puppet may cache information between catalog compilations to 
avoid needlessly re-parsing the same manifests.  It in fact goes to some 
effort to track which manifests it needs to re-parse and which it
doesn''t.
The bug you describe -- if it is one -- is not that the top-scope 
declaration carries over from nodeA to nodeB, but rather that nodeB usually 
*doesn''t* get that declaration.

The take-home message here is that if a declaration does not apply to all 
nodes, then it is *incorrect* to put it at top scope, regardless of which 
file.  On the other hand, if such a declaration does apply to all nodes 
then at best it''s unwise to put it in a file other than site.pp or one
of
those unconditionally imported, directly or indirectly, by site.pp.

With all that said, we''ll have to wait for Sergey to evaluate whether
his
problem lies along those lines.


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.