The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #11339

Class ordering bug?

Added by Justin Honold over 2 years ago. Updated over 1 year ago.

Status:ClosedStart date:12/12/2011
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:language
Target version:-
Affected Puppet version:2.7.9 Branch:
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

Using Puppet 2.7.9 on CentOS 6 with Ruby 1.8.7.

“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:

notice: foo::three
notice: /Stage[main]/Foo::Three/Notify[foo::three]/message: defined 'message' as 'foo::three'
notice: foo::two
notice: /Stage[main]/Foo::Two/Notify[foo::two]/message: defined 'message' as 'foo::two'
notice: foo::one
notice: /Stage[main]/Foo::One/Notify[foo::one]/message: defined 'message' as 'foo::one'

Three runs, then two, then one.

Here’s the second run:

notice: foo::one
notice: /Stage[main]/Foo::One/Notify[foo::one]/message: defined 'message' as 'foo::one'
notice: foo::two
notice: /Stage[main]/Foo::Two/Notify[foo::two]/message: defined 'message' as 'foo::two'
notice: foo::three
notice: /Stage[main]/Foo::Three/Notify[foo::three]/message: defined 'message' as 'foo::three'

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?


Related issues

Related to Puppet - Bug #8040: Classes should be able to contain other classes to provid... Closed 06/22/2011
Related to Puppet - Refactor #3691: The Catalog should include both dependency and containmen... Duplicate 04/27/2010

History

#1 Updated by Daniel Pittman over 2 years ago

  • Category set to language
  • Status changed from Unreviewed to Investigating
  • Assignee set to Jeff McCune

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 Updated by Jeff McCune over 2 years ago

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

-Jeff

#3 Updated by Jeff McCune over 2 years ago

  • Status changed from Investigating to Needs More Information
  • Assignee changed from Jeff McCune to Justin Honold

#4 Updated by Justin Honold over 2 years ago

  • Assignee changed from Justin Honold to Jeff McCune

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 Updated by Luke Kanies over 1 year ago

Is this not a duplicate of #8040?

#6 Updated by Jeff McCune over 1 year ago

  • Status changed from Needs More Information to Accepted
  • Assignee deleted (Jeff McCune)
  • Target version set to 2.7.x

Luke Kanies wrote:

Is this not a duplicate of #8040?

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: foo::three
notice: /Stage[main]/Foo::Three/Notify[foo::three]/message: defined 'message' as 'foo::three'
notice: foo::two
notice: /Stage[main]/Foo::Two/Notify[foo::two]/message: defined 'message' as 'foo::two'
notice: foo::one
notice: /Stage[main]/Foo::One/Notify[foo::one]/message: defined 'message' as 'foo::one'
notice: Finished catalog run in 0.04 seconds

#7 Updated by Jeff McCune over 1 year ago

@eric 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 Updated by Jeff McCune over 1 year ago

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  2.7.19rc3-60-g07f0b0e 07f0b0e
 * facter                   ticket/1.6.x/15464_a_gemfile_would_improve_contributor_on-boarding  1.6.11-8-g0b49eae     0b49eae
 * hiera                    1.x                                                                 1.0.0rc4-6-g3b89fbe   3b89fbe
 * rspec-puppet             master                                                              v0.1.4-2-g4afd64e     4afd64e
 * puppetlabs_spec_helper   ticket/master/15464_a_gemfile_would_improve_contributor_on-boarding 0.3.0-2-g12e9794      12e9794
 * fog                      0.7.2                                                               v0.7.2                c7ec7c9
 * rbvmomi                  master                                                              N/A                   5dc0ca3
 * stdlib                   3.x                                                                 3.0.1                 44e99a7
 * hiera_puppet             v0.3.0                                                              v0.3.0                06e70f3
 * mount_providers          master                                                              0.0.1                 2d0dabe
 * pe_mcollective           master                                                              0.0.45-2-g64c6523     64c6523
 * pe_accounts              master                                                              1.0.3                 0725c16
 * pe_compliance            master                                                              0.0.5                 dddc001
 * cloud_provisioner        master                                                              1.0.4-2-gf68dacd      f68dacd
 * cloud_provisioner_vmware master                                                              v1.0.0-5-g6eaab64     6eaab64
 * hiera_puppet             v0.3.0                                                              v0.3.0                06e70f3
 * json                     gem                                                                 1.7.4                 N/A    
 * mocha                    gem                                                                 0.10.5                N/A    
 * multi_json               gem                                                                 1.3.6                 N/A    
 * rack                     gem                                                                 1.4.1                 N/A    
 * rspec                    gem                                                                 2.10.0                N/A    
 * rspec-core               gem                                                                 2.10.1                N/A    
 * rspec-expectations       gem                                                                 2.10.0                N/A    
 * rspec-mocks              gem                                                                 2.10.1                N/A    
 * rspec-puppet             gem                                                                 0.1.4                 N/A    

#9 Updated by Luke Kanies over 1 year ago

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 Updated by Jeff McCune over 1 year ago

  • Status changed from Accepted to Closed

@Justin

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..ae33fc1 100644
--- a/manifests/init.pp
+++ b/manifests/init.pp
@@ -10,7 +10,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']
 }
 
-# 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: foo::one
notice: /Stage[main]/Foo::One/Notify[foo::one]/message: defined 'message' as 'foo::one'
notice: foo::two
notice: /Stage[main]/Foo::Two/Notify[foo::two]/message: defined 'message' as 'foo::two'
notice: foo::three
notice: /Stage[main]/Foo::Three/Notify[foo::three]/message: defined 'message' as 'foo::three'
notice: Finished catalog run in 0.04 seconds

#11 Updated by Justin Honold over 1 year ago

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 Updated by Justin Honold over 1 year ago

Simulpost!

Relationships should be specified inside the class definition, not outside.

Yep, I think that’s what it was. Thx!

#13 Updated by Andrew Parker over 1 year ago

  • Target version deleted (2.7.x)

Also available in: Atom PDF