> In general, I try and think of module dependencies and organization as
> a matter of composition. Discrete modules themselves should avoid
> establishing relationships with other modules. A module should,
> however, be diligent about managing the internal relationships of the
> classes and resources it defines.
>
> Ideally, Puppet itself would be more opinionated about the
> relationship of modules, and we're moving in that direction. Kelsey
> Alexander is working with Matt Robinson on things like #11979 [1]
> which gets us on the path to managing dependencies automatically. In
> the meantime, I document and leave it up to the end user to create
> another class that composes modules together. With your example, I'd
> do something like this as the end user. As the module author, I'd try
> and write mysql and ldap as if the other didn't exist.
I would love doing that and the proper way forward with this seems to
me to be stages.
Which leads me to the question, when does one use stages and when to
use dependency's between classes.
Stages look like they have great potention, but there use seems to be
lacking.
My stab at an answer would be:
Dependency between classes should be used within modules while stages
should manage the ordering between modules.
> # <modulepath>/site/manifests/dbserver.pp
> # This is what it means to be a database at the Acme.com site.
> class site::dbserver {
> class { ldap: }
> -> class { mysql: }
>
> }
In our case, without stages, This could easily grow to an dependency
chain of 20 to 30 classes.
>
> In this situation I'd update the composition in the site module. I'd
> also avoid inheritance if at all possible, but that's another story
> for another thread.
Agreed, to avoiding inheritence.
> For these reasons I try and think of the whole thing as a composition
> problem. The things being composed, modules, should try and avoid
> knowing implementation details about each other.
In general I agree with this, but I do think it would be usefull if a
module can expose functionality to other classes through defines.
The main reason for this is locality, mysql needs the firewall rule so
it defines the firewall rule. This improves the self-documenting
nature of the code, gives a clear overview of what the options are
when you want a mysql daemon (firewall, performance-monitoring,
alerting, maintenance crontabs) through an parameterized mysql class,
and simplifies the node definitions.
But this practice disagree's with the use of stages or would require
something like a staged_definition, a definition that can be called
from any stage but is run in a specified stage.
One example of this would be an iptables module which offers a define
that can be used by other modules to input rules for the firewall.
It could go a little something like this.
iptables.pp:
class iptables {
file{'/etc/firewall/baserules':}
service{"firewall":
ensure => running,
}
}
define open_internal_port(port) {
file{"/etc/firewall/${name}":
content = template("internal_rule.erb")
}
File["/etc/firewall/${name}"] ~> Service['firewall']
}
define open_external_port(port) {
file{"/etc/firewall/${name}":
content = template("external_rule.erb")
}
File["/etc/firewall/${name}"] ~> Service['firewall']
}
mysql.pp
class mysql( $firewall_mode = "closed" ) {
case $firewall_mode {
'closed' => {}
'internal' => { open_internal_port(3306) }
'external' => { open_external_port(3306) }
default => { fail("no valid firewall_mode specified: $
{firewall_mode}") }
}
}
>
> This sounds a lot like the Anchor pattern [2]. Are you trying to
> accomplish the same goal of classes encapsulating other classes in the
> dependency graph?
After reading the wiki, it is indeed the anchor pattern.
> Not easily. =) The anchor pattern is a bug, certainly, and so is the
> UX of having to manage dependencies so carefully and painfully. The
> good news is that we're actively working on it. If you could update
> any of the following bugs with your user stories and desires it will
> help shape the solution. 11832, 12243, 12246, 12249, 12250, 12251,
> 12253, 12255, 12256, 12257, 12258, 12259, 12260,
I will have a look at adding my user stories to those tickets.
Jos
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
