Puppet - Bug #11339 Class ordering bug?

Transcription

1 Puppet - Bug #11339 Class ordering bug? 12/12/ :56 am - Justin Honold Status: Closed Start date: 12/12/2011 Priority: Normal Due date: Assignee: % Done: 0% Category: language Estimated time: 0.00 hour Target version: Affected Puppet version: Branch: Keywords: Description Using Puppet on CentOS 6 with Ruby foo module s init.pp: class foo { include foo::one, foo::two, foo::three Class['foo::one'] -> Class['foo::two'] -> Class['foo::three'] First I stop the Master, then start it interactively using debug and no-daemonize. Then I apply on a client, without including the foo class. Next I tell it to include the foo class. Results: Three runs, then two, then one. Here s the second run: One, then two, then three. With the second run, I also see these corresponding entries in the Master s debug output: debug: Adding relationship from Class[Foo::One] to Class[Foo::Two] with 'before' debug: Adding relationship from Class[Foo::Two] to Class[Foo::Three] with 'before' I expected this ordering to be picked up on the first run, but it only goes on the second and later. Bug? User error? 05/01/2016 1/5

2 Related issues: Related to Puppet - Bug # 8040: Classes should be able to contain other class... Closed 06/22/2011 Related to Puppet - Refactor # 3691: The Catalog should include both dependen... Duplicate 04/27/2010 History #1-12/12/ :46 pm - Anonymous - Category set to language - Status changed from Unreviewed to Investigating - Assignee set to Anonymous Jeff, I suspect this of being the class anchoring bug you discovered; can you look at this and confirm or deny that theory, then move this on appropriately please? #2-12/12/ :09 pm - Anonymous It looks a lot like it. Jusin, could you paste in your example manifest to this ticket? Do your classes contain any resources? If they don t, this is likely the problem I describe in # Jeff #3-12/12/ :10 pm - Anonymous - Status changed from Investigating to Needs More Information - Assignee changed from Anonymous to Justin Honold #4-12/12/ :37 pm - Justin Honold - Assignee changed from Justin Honold to Anonymous In this case, that init.pp is virtually all of it. This isn t pseudo-code; I made a foo module (and a bar module) to confirm my suspicions on this behavior. There is a one.pp, two.pp, and three.pp, but they re simply class declarations with a notify for debugging. Does that help? #5-08/17/ :17 am - Luke Kanies Is this not a duplicate of #8040? #6-08/17/ :35 am - Anonymous - Status changed from Needs More Information to Accepted - Assignee deleted (Anonymous) - Target version set to 2.7.x Luke Kanies wrote: Is this not a duplicate of #8040? 05/01/2016 2/5

3 Not exactly but it s definitely similar and I notice they re already related. #8040 is about class containment, particularly when a container class has no concrete resources of its own. This bug appears to be a straight ordering problem. There is no class containment in this example. I imagine #8040 as a butterfly flying out of a jar; the butterflies being classes and the jar being a top level class container. (Justin, I m assuming each of three foo::one, foo::two, foo:three classes each contain a single resource declaration like this: Module # pbcopy < "${WORKSPACE/${WORKSET/modules/foo/manifests/init.pp" class foo::one { notify { 'foo::one': class foo::two { notify { 'foo::two': class foo::three { notify { 'foo::three': class foo { include foo::one, foo::two, foo::three # The notice order on the screen should be one, two three Class['foo::one'] -> Class['foo::two'] -> Class['foo::three'] Output $ puppet apply --modulepath "${WORKSPACE/${WORKSET/modules" -e 'include foo' notice: Finished catalog run in 0.04 seconds #7-08/17/ :49 am - This does look particularly worrisome. This doesn t appear to be the anchor issue, and it looks like the problem manifests itself only in some situations. The trouble is, the canonical scenario of following the autoloader conventions and recommendations triggers the bug. And the bug results in the exact opposite of what is specified. #8-08/17/ :50 am - Anonymous Here s the code I ran against: $ rake (in /workspace/puppet-2.7.x) * puppet ticket/2.7.x/15464_a_gemfile_would_improve_contributor_on-boarding rc3-60-g07f0b0e 07f0b0e * facter ticket/1.6.x/15464_a_gemfile_would_improve_contributor_on-boarding g0b49eae 0b49eae * hiera 1.x 1.0.0rc4-6-g3b89fbe 3b89fbe * rspec-puppet master v g4afd64e 4afd64e * puppetlabs_spec_helper ticket/master/15464_a_gemfile_would_improve_contributor_on-boarding g12e e9794 * fog v0.7.2 c7ec7c9 05/01/2016 3/5

4 * rbvmomi master N/A 5dc0ca3 * stdlib 3.x e99a7 * hiera_puppet v0.3.0 v e70f3 * mount_providers master d0dabe * pe_mcollective master g64c c6523 * pe_accounts master c16 * pe_compliance master dddc001 * cloud_provisioner master gf68dacd f68dacd * cloud_provisioner_vmware master v g6eaab64 6eaab64 * hiera_puppet v0.3.0 v e70f3 * json gem N/A * mocha gem N/A * multi_json gem N/A * rack gem N/A * rspec gem N/A * rspec-core gem N/A * rspec-expectations gem N/A * rspec-mocks gem N/A * rspec-puppet gem N/A #9-08/17/ :57 am - Luke Kanies Hmm. Actually, in reading more closely, it looks like the OP thinks that inclusion should result in a specific class ordering, but it doesn t necessarily. This might be not a bug. #10-08/17/ :00 am - Anonymous - Status changed from Accepted to I don t think this is a bug in Puppet. I m going to close this ticket, but please feel free to re-open if you disagree with my conclusion after reviewing this information and suggested fix. If you change your init.pp manifest to be the following this problem should go away: (Relationships should be specified inside the class definition, not outside. $ git diff diff --git a/manifests/init.pp b/manifests/init.pp index b8d2fa3..ae33fc a/manifests/init.pp ,7 class foo::three { class foo { include foo::one, foo::two, foo::three + # The notice order on the screen should be one, two three + Class['foo::one'] -> Class['foo::two'] -> Class['foo::three'] 05/01/2016 4/5

5 -# The notice order on the screen should be one, two three -Class['foo::one'] -> Class['foo::two'] -> Class['foo::three'] $ puppet apply --modulepath "${WORKSPACE/${WORKSET/modules" -e 'include foo' notice: Finished catalog run in 0.04 seconds #11-08/17/ :02 am - Justin Honold I don t think inclusion should result in specific class ordering, I think specific class ordering should result in specific class ordering Class['foo::one'] -> Class['foo::two'] -> Class['foo::three'] This wasn t picked up on the first run, but was on the second run, and each run afterward. The bug was filed in 2011, though. Since then, I ve been putting such stanzas inside the class itself. I also haven t had cause to test it since then, but perhaps it was related to being in the global scope. #12-08/17/ :03 am - Justin Honold Simulpost! Relationships should be specified inside the class definition, not outside. Yep, I think that s what it was. Thx! #13-10/11/ :06 pm - Anonymous - Target version deleted (2.7.x) 05/01/2016 5/5

6