Issue #8040 has been updated by Nick Fagerlund.
A proposed solution has come up a few times in convo w/ Dan Bode, and I want to
make sure it's captured here:
Why not just say that resource-like declarations (`class {'myclass':}`) always
cause containment? This should be possible without conflicting with any
existing semantics.
- Multiple non-nested containment is scary because of dependency cycles, and we
don't want to allow it. Fine: Resource-like declarations already only allow you
to declare a class once, so that's taken care of for free.
- Include should continue to not cause containment, and I think that's sane.
- I've tried and tried to come up with a situation where you'd want to cause a
class to be contained but NOT have the class be wholly "owned" by its
container. I can't think of one.
- This would also make resource-like declarations act more like normal
resources, which is cool.
(This would almost definitely reveal currently hidden dependency cycles in
peoples' code. That means we should implement it in a major version with a
temporary pref to turn the behavior off, just so people can upgrade and start
fixing their breakages one at a time. Ideally, the deactivated version of the
behavior would log warnings when it sees things that would be cyclic.)
----------------------------------------
Bug #8040: Classes should be able to contain other classes to provide a self
contained module
https://projects.puppetlabs.com/issues/8040#change-79941
Author: Jeff McCune
Status: Accepted
Priority: Normal
Assignee:
Category: compiler
Target version:
Affected Puppet version: 2.6.0
Keywords: anchor containment contain graph modules module self-contained
dependency reuse usability forge
Branch:
# Overview #
As a module author, I want to build collections of classes for end users
shipped as a module.
As a module end-user, I want to manage resources before and that require the
collection of classes as a self contained unit of functionality.
For example, the end user wants to use a module I write in the following way:
<pre>
node default {
class { 'java': }
->
class { 'activemq': }
->
class { 'mcollective: }
}
</pre>
Where java, activemq, and mcollective are all discrete modules with multiple
classes each. For example, a each module has a class for the packages, a class
for the configuration files, and a class for the running service if there is a
service.
With Puppet 2.6, when a class declares another class, the classes are not
related to each other in any way, containment or dependency.
# Expected Behavior #
The example illustrates the expectation that all resources in the activemq
module are managed after all resources in the java module and before all
resources in the mcollective module.
# Actual Behavior #
Without the Anchor Pattern, when class activemq::service is declared from
within class activemq, the resources float away and are not transitively
related to java or mcollective.
# Suggested Implementation #
It has been expressed that it may be a viable solution for module authors to be
able to specify containment edges in the graph from within the Puppet DSL.
With Puppet 2.6.x and 2.7.x this is not possible. The Anchor Pattern works
around this problem by specifying relationship edges to a resource contained
within the composite class.
# Work Around #
The Anchor Pattern is the current work around for Puppet 2.6.x When a class
declares other classes, it should contain them using this pattern:
<pre>
class activemq {
anchor { 'activemq::begin': }
anchor { 'activemq::end': }
class { 'activemq::package':
require => Anchor['activemq::begin'],
}
class { 'activemq::config':
require => Class['activemq::config'],
notify => Class['activemq::service'],
}
class { 'activemq::service':
before => Anchor['activemq::end'],
}
}
</pre>
--
Jeff McCune
Puppet Labs
@0xEFF
--
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.
