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+unsubscr...@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.
