-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It is annoying to have everything in a single place that defines the state of your nodes but, as you point out, this seems to be the model if you're using an ENC and that seems to be the recommended practice across the mailing list for any sort of scale.
But, you don't need a functional ENC to make this work, you simply need to have
everything defined at the top level whether it be via node, higher
level class, or ENC.
The main issue here seems to be modules that are trying to be "too helpful"
from my reading of the mailing list.
It seems that many would like this to be an anti-pattern:
class foo {
if not defined(Class['bar']) {
include 'bar'
bar::baz { ... }
}
}
include 'foo'
Instead, you should be less helpful, and do the following:
include 'foo'
include 'bar'
bar::baz { ... }
So, instead of doing something like, say, setting up IPTables in your module
(thus creating a cross-module dependency), you should do all of this in
one monolithic place at the node level or a higher level aggregation class
level.
While this keeps your modules clean, it seems like a lot more effort to
maintain since the module for nginx should really know what ports it's using
and know how to set up its own firewall rules.
So, the tradeoff is an ENC vs. a large collection of cluttered classes at the
top level to make sure you don't have cross-module dependencies.
I'm not sure if either is better (or if either is any good at all) but they're
both functional.
The ability to tag modules as requiring other modules of a particular version
(ala CPAN, Gems, everything else....) would solve this issue as Puppet
would be able to check to make sure that you have the correct version of the
modules installed prior to compiling the catalog.
Trevor
On 01/30/2012 03:51 AM, Felix Frank wrote:
> Hi,
>
> On 01/28/2012 04:35 PM, Trevor Vaughan wrote:
>> Drawbacks:
>>
>> * Requires the user to have an explicit working knowledge of all
> modules and namespaces
>> * Adds a lot of random logic to the code (unless it becomes a
> metaparam of some sort)
>
> You skipped the most important drawback: Commitment to parameterized
> classes. The fact that there can be only one place that includes those
> classes, and that this singular place must have the whole picture of
> what requirements are met, is conceivably a show stopper from my point
> of view.
>
> This will work for people that have a functional ENC, I guess, but
> should that be a requirement for using Forge modules?
>
> Furthermore, how can modules hope to ever interoperate like this? If all
> module classes get parameterized, it will be outright impossible for one
> module to ever include another module's classes.
> Say module A includes class B::C. As soon as a user installs module A in
> addition to B, they have to clean their manifests of inclusions of B::C.
>
> On 01/29/2012 07:39 AM, Brian Gupta wrote:
>> It frightens me a bit that I think the "correct" solution, will be to
>> replicate what the distros are doing in Puppetforge. Basically turning
>> puppetforge into a massive cross distro metadata repo, with very strict
>> contribution standards and rules. This would involve strong rules for
>> curated modules that would require manpower to vet (and to
>> contribute the modules).
>
> I honestly don't see the problem. Imagine CPAN was limited to downloads
> of tarballs from the website (or even souce control checkouts). I
> disbelieve it would be as significant today as it has become.
> The same goes for Ruby Gems and all such systems.
>
> As this seems to be a recurring theme: Am I wrong to compare these to
> the Forge?
>
> Sincerely,
> Felix
>
- --
Trevor Vaughan
Vice President, Onyx Point, Inc.
email: tvaug...@onyxpoint.com
phone: 410-541-ONYX (6699)
pgp: 0x6C701E94
- -- This account not approved for unencrypted sensitive information --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBAgAGBQJPJoUxAAoJECNCGV1OLcyp7igH/0rroAjC8Ewc9Aw2bdE7gO0N
0KfvzYCTZtJLFTBeNIAErliWd9iR5W84H0j8KJGjPg18qcRcDHjC/hnf5+GV8lIS
6kG3EgwYwyDg8Xc0qAbWubJv7bJ29X4Fc8CCHkq13CkXFM/OqnKpUbXA6X6+o5a/
Hv5Z6WXQjPC7uCupwyqktkjj5sjwvdgniSvKsj6EK3bhGRyMsvJAzmDjucwcRNsM
vz6IG05aFJrYTUp0rZzTJf/HjIPgmD90puoXXSa/RVQnsb3WSw0AwYe1jBAHWap4
pDw+F2qrMdwc9XgQv4ZFFNp/A1OCFh21uW3B1D7XjM+U3QRpmXTKhX71lcqbX08=
=XRv1
-----END PGP SIGNATURE-----
--
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.
<<attachment: tvaughan.vcf>>
