Puppet

luke wrote:

Does this work if you don’t use the tags as a selection criterion?

That is, is it the use of tags that’s broken, or the collection itself?

I think it’s the tags, but I’d like confirmation.

No it’s not the tag. The following manifest doesn’t work either:

# site.pp
filebucket { server:
        server => "puppet"
}


define deftest ()
{
        warning("DEFTEST ${fqdn} on ${name}")
        file { "${name}":
                content => "${fqdn}"
        }
}


node "xen1.internal" {
  $part = "xen1"


        @@deftest {
                "/tmp/${part}":
        }
        Deftest <<| |>>
}

node "xen2.internal" {
  $part = "xen2"

        @@deftest {
                "/tmp/${part}":
        }
        Deftest <<| |>>
}

i.e. no /tmp/xen1 on xen1, a /tmp/xen1 on xen2, then a /tmp/xen2 on xen1. I modified puppetd to print the catalog YAML it receives to see if the problem was in the puppetmaster or puppetd itself (sorry I’m pretty new at ruby and puppet internals at the same time :–)) and definitely on the 3rd run (ie the run back on xen1) it produces:

!ruby/object:Puppet::TransBucket
name: :main
classes:
- xen1.internal
type: Class
children:
- !ruby/object:Puppet::TransBucket
  name: xen1.internal
  type: Node
  children:
  - !ruby/object:Puppet::TransBucket
    name: /tmp/xen2
    type: Deftest
    children:
    - !ruby/object:Puppet::TransObject
      line: 12
      name: /tmp/xen2
      type: file
      tags:
      - file
      - deftest
      - node
      - xen1.internal
      - class
      - main
      file: /etc/puppet/manifests/site.pp
      params:
        tag: test
        content: xen1.internal
  - !ruby/object:Puppet::TransBucket
    name: /tmp/xen1
    type: Deftest
    children: []

- !ruby/object:Puppet::TransObject
  line: 4
  name: server
  type: filebucket
  tags:
  - filebucket
  - server
  - class
  - main
  file: /etc/puppet/manifests/site.pp
  params:
    server: puppet

So I definitely get both resources, but only one is evaluated. Right now I’m trying to print more information form Puppet::Parser::Compiler to see what is different between both resources but I don’t know how to print object values (ie ala perl Data::Dumper or PHP print_r) to see objects internals.

Any idea where I should dig to understand the issue?

Thanks,

masterzen wrote:

So I definitely get both resources, but only one is evaluated.

If you’re getting both resources, it’s not a collection problem; in fact, if it’s in the yaml file, it’s definitely not a language or server problem at all.

Run puppetd with —evaltrace, maybe that will help clarify things.

luke wrote:

masterzen wrote:

So I definitely get both resources, but only one is evaluated.

If you’re getting both resources, it’s not a collection problem; in fact, if it’s in the yaml file, it’s definitely not a language or server problem at all.

I’m sorry, I might not have phrased correctly my conclusion due to my misunderstanding of puppet internals. I meant that the yaml catalog sent to puppetd contains both definition (ie the deftest) but only one has the underlying file resource child. The other one is only an empty shell (ie see in my previous post for the child: []).

Run puppetd with —evaltrace, maybe that will help clarify things.

Which gives on xen1 (3rd run):

info: Caching catalog at /var/lib/puppet/state/localconfig.yaml
notice: Starting catalog run
info: /Schedule[weekly]: Evaluated in 0.00 seconds
info: //Filebucket[server]: Evaluated in 0.00 seconds
info: /Schedule[daily]: Evaluated in 0.00 seconds
info: /Schedule[hourly]: Evaluated in 0.00 seconds
info: /Filebucket[puppet]: Evaluated in 0.00 seconds
info: /Schedule[puppet]: Evaluated in 0.00 seconds
info: /Schedule[never]: Evaluated in 0.00 seconds
info: //Node[xen1.internal]/Deftest[/tmp/xen2]/File[/tmp/xen2]: Evaluated in 0.03 seconds
info: /Schedule[monthly]: Evaluated in 0.00 seconds
notice: Finished catalog run in 0.16 seconds

And only one resource is evaluated (the one exported by xen2).

I still think the catalog creation/compilation in the puppetmaster is where the problem is. I’ll try to search in the code where the resource differs.

masterzen wrote:

I’m proposing a patch (against yesterday trunk) that solve the issue by analyzing during the collection the whole scope hierarchy to check if the current resource we are checking are descendant of a resource that would have matched the collection criterion.

This solves my current issue but I’m not sure if that’s the proper fix. I’m open to other suggestions :–)

I added the patch in the tickets/1472 branch in my github repository (masterzen/puppet). Direct access to the commit: http://github.com/masterzen/puppet/commit/9035d4b6dabe91ea2288f915497ad8d184368df8 Access to the branch: http://github.com/masterzen/puppet/commits/tickets/1472

luke wrote:

Hmm, if you’re right about what’s happening (sorry, don’t have time to reproduce), then I think the bug is that the defined resource is being evaluated even though it’s virtual. Neither virtual nor exported defined resources should be evaluated at all, meaning that they should never produce contained virtual or exported resources. That is, stage 2 in your described process shouldn’t happen if the definition is virtual.

No, that’s not exactly the issue. The issue is that collecting a define should collect underlying resources, which is not that happens (see below).

I just checked again, with the following minimal site.pp:

define deftest ()
{
   warning("DEFTEST ${fqdn} on ${name}")
   file { "/tmp/${name}":
     content => "test" 
   }
}

node "pouet.internal" {
  @@deftest {
    "pouet":
  }
  Deftest <<| |>>
}

I think you’d agree that, puppet should evaluate the deftest[pouet] resource on the node “pouet.internal” and issue the warning and create the /tmp/pouet file. That is not what happens (ie the warning is issued, but the file is not created).

I instrumented (ie lots of puts) and here is what happens:

1. The node is evaluated:

Compiler::add_resource Node[pouet.internal]
resource is now Node[pouet.internal] exp: 
Resource::evaluate Node[pouet.internal]
Resource::evaluating a definedtype Node[pouet.internal]

1. It gives the Deftest[pouet] virtual,exported resource:

Resource::initialize for pouet
resource::initialize set option type =  deftest
resource::initialize set option virtual =  true
resource::initialize set option scope =  Scope(Node[pouet.internal])
resource::initialize set option source =  pouet.internal
resource::initialize set option title =  pouet
resource::initialize set option params =  
resource::initialize set option exported =  true
Resource::exported=  true
Resource::exported=  force virtual and exported to true
resource::initialize set option line =  12
resource::initialize set option file =  /tmp/test/manifests/site.pp

1. the deftest[pouet] resource is added to the catalog

2. then, to the current collections

3. the collections are then evaluated (first pass of compiler::evaluate_generators):

Compiler::evaluate_generators pass: 0
Compiler::evaluate_collections (entering)
Compiler::evaluate_collections collections not empty
Compiler::evaluate_collections for #

1. Since deftest[pouet] is exported and virtual and matches the current collect selector, it is selected for collection:

Collector::collect_exported (entering)
Collector::collect_virtual for exported: true
Collector::collect_virtual can Deftest[pouet] be collected? true
Collector::collect_virtual can Node[pouet.internal] be collected? false
Collector::collect_virtual can Class[main] be collected? false
Collector::collect_exported resources Deftestcommit:pouet]
debug: Scope(Node[pouet.internal): Collected 1 Deftest resource in 0.01 seconds

1. Then, back to evaluate_generators, evaluate_definitions is called and tries to evaluate deftest[pouet] which is not virtual anymore (because we collected it):

Compiler::evaluate_collectionse # collection evaluation found sth
Compiler::evaluate_collections (leaving)
Compiler::evaluate_generators after eval_collections done? false
Compiler::evaluate_definitions for Deftest[pouet]
Compiler::evaluate_definitions for Deftest[pouet], not virtual

1. the deftest underlying resources are then evaluated and created as it should:

Resource::evaluate Deftest[pouet]
Resource::evaluating a definedtype Deftest[pouet]
evaluate_code for Deftest[pouet]
warning: Scope(Deftest[pouet]): DEFTEST arsenic.internal on pouet
Resource::initialize for /tmp/pouet
resource::initialize set option type =  file
resource::initialize set option virtual =  true
resource::initialize set option scope =  Scope(Deftest[pouet])
resource::initialize set option source =  deftest
resource::initialize set option title =  /tmp/pouet
resource::initialize set option params =  content => test
resource::initialize set option exported =  true
Resource::exported=  true
Resource::exported=  force virtual and exported to true
resource::initialize set option line =  6
resource::initialize set option file =  /tmp/test/manifests/site.pp
Compiler::add_resource File[/tmp/pouet]

You can see that File[/tmp/pouet] is now added to the catalog, which is right.

1. Then we’re going to have another pass in Compiler::evaluate_generators to collect/evaluate resources or define that could have been created in the previous pass:

Compiler::evaluate_generators after evaluate_definitions done? false
Compiler::evaluate_generators pass: 1
Compiler::evaluate_collections (entering)
Compiler::evaluate_collections collections not empty
Compiler::evaluate_collections for #

1. Guess what? There are some resources to collect:

Collector::collect_exported (entering)
Collector::collect_virtual for exported: true
Collector::collect_virtual can Deftest[pouet] be collected? true
Collector::collect_virtual can Node[pouet.internal] be collected? false
Collector::collect_virtual can File[/tmp/pouet] be collected? false
Collector::collect_virtual can Class[main] be collected? false
Collector::collect_exported resources 
debug: Scope(Node[pouet.internal]): Collected 0 Deftest resources in 0.00 seconds

Wait!! Something is wrong, it didn’t collect the File[/tmp/pouet], so this resource won’t ever be evaluated. Why is that: simply the resource type (File) doesn’t match the collected type (Deftest).

That’s why my patch goes beyond that to check that there is a parent defined resource that could match the type of the collected resource.

Hope that helps you understand the root issue.