Bug #857
Behaviour of Puppet when multiple classes of the same name are defined
| Status: | Closed | Start: | ||
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | % Done: | 0% |
||
| Category: | language | |||
| Target version: | 0.24.7 | |||
| Affected version: | 0.24.4 | Branch: | ||
| Keywords: | ||||
| Votes: | 0 |
Description
When multiple classes of the same name are defined:
class mysql { notice(‘This is a load of the MySQL class’) }
class mysql { notice(‘This is a load of the second MySQL class’) }
class mysql { notice(‘This is a load of the third MySQL class’) }
According to Luke the contents of each new class of the same name are just added to the initial class and processed.
Testing indicates that this isn’t the behaviour and in fact only the first class is processed, i.e. using the above example the only notice returned is:
“notice: mysql: This is a load of the MySQL class”
I recommend that either this configuration throws an error – making classes unique – or the combination behaviour is fixed to include all content of each class.
History
Updated by Luke Kanies almost 3 years ago
- Status changed from 1 to 2
Hmm:
class one {
notify { "one": }
}
class one {
notify { "two": }
}
include one
And I get:
luke@phage(0) $ test.pp notice: one notice: two luke@phage(0) $
Strangely, I just ran your code and got the same behaviour you’re getting (that is, only the first notice). Even stranger, I added my ‘notify’ resources to these classes and got my new behaviour again with all three notices:
class mysql {
notice('This is a load of the [[MySQL]] class')
notify { one: }
}
class mysql { notice('This is a load of the second [[MySQL]] class')
notify { two: }
}
class mysql { notice('This is a load of the third [[MySQL]] class')
notify { three: }
}
include mysql
Returns
luke@phage(0) $ test.pp notice: Scope(Class[mysql]): This is a load of the [[MySQL]] class notice: Scope(Class[mysql]): This is a load of the second [[MySQL]] class notice: Scope(Class[mysql]): This is a load of the third [[MySQL]] class notice: two notice: three notice: one luke@phage(0) $
So, I don’t know what the bug is here, but there’s definitely a bug.
Updated by Luke Kanies over 2 years ago
Marking #966 as a duplicate.
Updated by Redmine Admin about 2 years ago
- Status changed from 2 to Accepted
Updated by Brice Figureau almost 2 years ago
- Affected version set to 0.24.4
jamtur01 wrote:
When multiple classes of the same name are defined:
class mysql { notice(‘This is a load of the MySQL class’) }
class mysql { notice(‘This is a load of the second MySQL class’) }
class mysql { notice(‘This is a load of the third MySQL class’) }
According to Luke the contents of each new class of the same name are just added to the initial class and processed.
Testing indicates that this isn’t the behaviour and in fact only the first class is processed, i.e. using the above example the only notice returned is:
“notice: mysql: This is a load of the MySQL class”
I recommend that either this configuration throws an error – making classes unique – or the combination behaviour is fixed to include all content of each class.
I just fixed it in the tickets/0.24.x/857 branch in my github repository: http://github.com/masterzen/puppet/tree/tickets%2F0.24.x%2F857
Updated by Brice Figureau almost 2 years ago
- Status changed from Accepted to Ready for Checkin
- Assignee changed from Luke Kanies to James Turnbull
Updated by James Turnbull almost 2 years ago
- Status changed from Ready for Checkin to Code Insufficient
- Assignee changed from James Turnbull to Brice Figureau
- Target version changed from 0.25.0 to 0.24.7
Can you please rebase to the current 0.24.x
Updated by Brice Figureau almost 2 years ago
- Status changed from Code Insufficient to Ready for Checkin
- Assignee changed from Brice Figureau to James Turnbull
Hi James,
Rebased against current 0.24.x. It seems to apply fine above #1402. It is still in the tickets/0.24.x/857 branch in my github repository: http://github.com/masterzen/puppet/tree/tickets%2F0.24.x%2F857
Updated by James Turnbull almost 2 years ago
- Status changed from Ready for Checkin to Code Insufficient
Updated by Brice Figureau almost 2 years ago
- Status changed from Code Insufficient to Ready for Checkin
Updated by James Turnbull almost 2 years ago
- Status changed from Ready for Checkin to Closed
Pushed in commit:“9f30306d2c768bad3327ecb7748669afb10cd4aa” in branch 0.24.x