Issue #11339 has been updated by Jeff McCune.
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 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
<pre>
# 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']
</pre>
# Output
<pre>
$ 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
</pre>
----------------------------------------
Bug #11339: Class ordering bug?
https://projects.puppetlabs.com/issues/11339#change-69297
Author: Justin Honold
Status: Accepted
Priority: Normal
Assignee:
Category: language
Target version: 2.7.x
Affected Puppet version: 2.7.9
Keywords:
Branch:
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?
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
