On 27/01/09 16:51, Luke Kanies wrote:
> On Jan 25, 2009, at 4:26 PM, Brice Figureau wrote:
>
>> On 25/01/09 22:06, Luke Kanies wrote:
>>
>>> I think you're right about the tagging being inconsistent but related
>>> to definitions; tags are supposed to be applied recursively, such
>>> that
>>> whatever class/definition contains the resource should have its tags
>>> copied to the resource. However, I bet this doesn't actually work
>>> out
>>> all that well, and, particularly, I bet that you're finding that if a
>>> class has already been evaluated its tags are maybe not propagating
>>> correctly.
>> Yes, I think that's the issue. But I also seem to have it on classes
>> along with definitions.
>
> Classes and definitions are equivalent in this respect.
>
>> My bootloader::common example I pasted above has the following
>> manifest:
>>
>> node "debian" inherits "server" {
>> ...
>> }
>>
>> node "server" inherits "base" {
>> ...
>> include bootloader::grub
>> ...
>> }
>>
>> and then I have a bootloader module:
>>
>> class bootloader::common {
>> # there is nothing
>> }
>>
>> class bootloader::grub inherits bootloader::common {
>> ... a few file resource to build the grub menu.lst ...
>> }
>>
>> The tag issue I'm having is on the bootloader::common class.
>>
>> Let me know what I can do to debug this. I tried to follow the tags
>> path
>> throughout the compilation, but that's not really easy...
>
> I think I figured it out; the problem is that
> Puppet::Parser::Resource's add_scope_tags method is called in
> finish(), instead of before evaluation.
>
> In the simplest case you have this kind of structure:
>
> start Class[main]
> start Node[server]
> start Node[base]
> add tags from Node[server]
> add tags from Class[main]
>
> In other words, the inner classes copy their parent's tags before the
> parent copies its parent tags. This means that a given class will
> normally only get its immediate parent's tags.
>
> Where that doesn't happen, I expect, is when you have multiple classes
> evaluated at a given scope. In the above system, if you had two
> classes at the level of Node[base], then the first one wouldn't get
> the Class[main] tags but the second one would, because Node[server]
> would have called add_scope_tags when it was finished.
It seems I'm completely lost :-(
Here is my manifest:
class bootloader::common {}
class bootloader::grub inherits bootloader::common {
notify { "grub": }
}
node "base" { }
node "server" inherits "base"
{
include bootloader::grub
}
node "debian" inherits "server" {}
I instrumented the master to print when a resource is evaluated and when
it is tagged from whom and with which tags (the ==> line is in
Puppet::Parser::Resource.evaluate, and all the other ones in add_scope_tags)
The first run I get:
===>EVALUATING Class[main]
tagging Class[main]
getting tags from Class[main]
with: ["class", "main"]
===>EVALUATING Node[debian]
tagging Node[debian]
getting tags from Class[main]
with: ["class", "main"]
===>EVALUATING Class[bootloader::grub]
tagging Class[bootloader::grub]
getting tags from Node[server]
with: ["node", "server"]
===>EVALUATING Node[server]
tagging Node[server]
getting tags from Class[main]
with: ["class", "main"]
debug: Class 'server' already evaluated; not evaluating again
===>EVALUATING Node[base]
tagging Node[base]
getting tags from Class[main]
with: ["class", "main"]
debug: Class 'base' already evaluated; not evaluating again
===>EVALUATING Class[bootloader::common]
tagging Class[bootloader::common]
getting tags from Node[server]
with: ["node", "server", "class", "main"]
debug: Class 'bootloader::common' already evaluated; not evaluating again
tagging Notify[grub]
getting tags from Class[bootloader::grub]
with: ["class", "bootloader::grub", "bootloader", "grub", "node",
"server"]
And on the *second* run (same puppetmaster):
===>EVALUATING Class[main]
tagging Class[main]
getting tags from Class[main]
with: ["class", "main"]
===>EVALUATING Node[debian]
tagging Node[debian]
getting tags from Class[main]
with: ["class", "main"]
===>EVALUATING Class[bootloader::grub]
tagging Class[bootloader::grub]
getting tags from Node[server]
with: ["node", "server"]
===>EVALUATING Class[bootloader::common]
tagging Class[bootloader::common]
getting tags from Node[server]
with: ["node", "server"]
debug: Class 'bootloader::common' already evaluated; not evaluating again
===>EVALUATING Node[server]
tagging Node[server]
getting tags from Class[main]
with: ["class", "main"]
debug: Class 'server' already evaluated; not evaluating again
===>EVALUATING Node[base]
tagging Node[base]
getting tags from Class[main]
with: ["class", "main"]
debug: Class 'base' already evaluated; not evaluating again
tagging Notify[grub]
getting tags from Class[bootloader::grub]
with: ["class", "bootloader::grub", "bootloader", "grub", "node",
"server"]
Notice that on the second run we evaluated both classes *before* the
nodes they are included into. That means the upper tags can't flow done
since we didn't yet call add_scope_tags for those nodes.
I first thought that calling finish from evaluate was in cause (ie my
rationale was that we can finish only after everything is evaluated). So
I removed it (finish is called ultimately at the end of the complation
process) but it didn't change anything.
I'm now looking to code I'm really not familiar with (ie compiler and
catalog). My understanding at this stage is that the order of the
vertices changes from run to run, and as such evaluate_definition
doesn't evaluate all the classes/nodes in the same order each time.
That means either we don't add the graph vertex in the same order each
time, or that ruby hash are not consistent (ie adding 3 different keys
in always the same order doesn't always have the same order).
I know there is no order guarantee in Puppet, but I thought it applied
to parsing (and building the AST), not it's evaluation. Maybe I'm wrong
and it's a lost battle...
/me still puzzled :-(
--
Brice Figureau
Days of Wonder
http://www.daysofwonder.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
