Since Felix seems not to have gotten around to doing this in the past
couple of days, or else was unable to do so,
On Jan 24, 3:28 am, Felix Frank <felix.fr...@alumni.tu-berlin.de>
wrote:
>
> there was a discussion in the "can we deprecate defined() in Telly"
> thread about how we can even begin to design Forge modules without it.
>
> A recurring problem is that multiple modules rely on certain packages,
> and there is no good model (yet) to unite their resource declarations.
> Therefore it's a common (although imho disgusting) workaround to do
> things like
> if !defined(Package[foo]) { package { "foo": ensure => installed } }
>
> On 01/20/2012 11:34 PM, Cody wrote:
>
> > Defining all somewhat common packages in a central location becomes
> > unrealistic when you no longer "control" the code that is in every
> > module you use. If you obtain five modules from the forge and they
> > all require a specific package and so all define that package your not
> > going to convince, nor is it a good design to require everyone to move
> > the package definitions from that collection of modules. They need to
> > function as a collection out of the box.
>
> Agreed. How can this be accomplished?
I'm not sure it can be, though I have some ideas for how we can do
better than we do now.
To start, consider the extreme case where modules have conflicting
essential requirements. For example, they require packages that
declare conflicts with each other, or they differ about whether some
service must be enabled or disabled. Such modules cannot *ever* work
correctly together, out of the box or otherwise, therefore it is
impossible to achieve a system that ensures that any random collection
of modules will automatically work together.
Furthermore, I think that its probably the wrong goal that even
compatible modules should always work together automatically. The
goal should be that compatible modules work together without
modification, but it is altogether reasonable for that to require
extra code somewhere else (e.g. extra classes assigned to the node,
intermodule relationships defined, etc.).
> Perhaps there needs to be some kind of "Forge common" module that by
> policy can only ever declare virtual resources (packages are a prominent
> example).
> A user who wishes to retain the capability of using modules from the
> Forge would be required to install this common module, and replace their
> own resource declarations with realizations of the common resources.
> For this to work, it's definitely a plus that you can override
> attributes in collections:
> Package<| title == "apache2": |> { ensure => "2.2.12" }
> ...although that does bear some caveats. Does this still work in recent
> versions?
>
> If we can take this for granted, all Forge modules can adhere to that
> same standard.
>
> This is a rough sketch of how things might possibly work, and surely has
> lots of wrinkles of its own. Still, I'm quite sure we need a proper way
> to rid ourselves of the horror that is the parse order dependent check
> for defined resources ;-)
If we must rely only on features already present in Puppet, then I
think that's heading in the right direction. I doubt it's feasible to
rely on a single "Forge Common" module, however. Aside from the
problem of maintaining a "Common" module as other modules are created
and maintained, there is also the same essential problem I began with:
different modules may have conflicting requirements.
With respect to a given module, we need to distinguish between two
three types of resources:
1) Resources owned by that module
2) All other resources
Modules provide definitions of resources that they own. For the most
part, those definitions should be virtual to avoid unnecessary inter-
module coupling, but some resources are reasonable to define
concretely. Modules may realize virtual resources belonging to other
modules (without necessarily needing to know which module actually
provides the definition), but they must not override properties of
resources they do not own.
The set of resources owned by a module and the set of other resources
it depends on are parts of its external interface, and modules whose
sets of owned resources overlap are inherently incompatible. Because
of that source of incompatibility, modules should seek to keep their
lists of owned resources small. But how, then, can optional inter-
module dependencies be handled, or equivalently, how can a module be
made able both to interoperate and to stand on its own? I see two
elements to this:
1) It is the site's responsibility to ensure that all "other"
resources required by each module in use be provided. That is the
role that Felix's "Forge Common" module is aimed at, though I don't
much care for that particular solution. Instead, I think in many
cases it will be necessary for sites to provide at least some resource
definitions via local custom modules.
2) Modules can ease the task for users by providing *optional* classes
virtually defining some or all of the "other" resources they need.
Where there are no conflicts to deal with, users could assign those
classes to nodes along with the module's main classes, and thereby
avoid any need to define the needed resources themselves.
John
--
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.
