What if there was some standardised way modules expose a sort of list
of requirements or an API of some sort? I don't know how this would
work in practice since it just popped in my mind, but I imagine for
instance a monitoring module would expose some kind of hook that other
modules can check for, and if it is found then execute the code
pertaining to monitoring. It would mean a certain abstraction, so
instead of saying an external module needs to implement nagios-perl,
it would just ask for an external module to implement monitoring, and
pass certain parameters to it in order to get that monitoring
implemented. The nagios module would then be responsible for the
actual monitoring stuff.
Come to think of it, this wouldn't take care of the duplicate resource
stuff discussed here. Nevertheless I wanted to put out this thought
anyway as it seems to be a larger issue related to this.
As for the duplicate resource issue, what about a diff/merge strategy:
If duplicate resources are found, tehre are three options:
1. if the two resource were compared and found the same it would just
be allowed and logged to the user
2. if not found the same, merged and logged:
file{x: ensure => present} and
file {x: owner => root}
becomes
file {x: ensure => present, owner => root},
3. if merge conflicts are found (ensure => present and ensure =>
absent in the two definitions) we get an error.
Could that work?
Walter
On Tue, Jan 24, 2012 at 13:38, Tim Sharpe <t...@sharpe.id.au> wrote:
> The only "clean" way to handle this that I can think of off the top of my
> head
> is for Puppet to start silently discarding duplicate definitions and just
> using
> the first one it comes across (with perhaps a message being logged at info
> level so that it's not completely invisible).
>
> This is far from ideal but so are the other proposed solutions so far :)
>
> On Tuesday, 24 January 2012 at 10:20 PM, Matthias Saou wrote:
>
> On Tue, 24 Jan 2012 10:32:31 +0100
> Felix Frank <felix.fr...@alumni.tu-berlin.de> wrote:
>
> 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).
>
>
> This only takes care of the Forge case. The problem of having the same
> package being required in multiple places isn't limited to Forge, it's
> one I run into locally all the time (and I'm sure I'm not the only one).
>
> On top of that, once you try to cover multiple distributions where
> package names diverge, it starts getting hard. And once the packaging
> itself is different, as in (non-existing) sub-packages... there is no
> end (1).
>
> I don't have the slightest idea as to how all this could be solved in
> a clean way, but "requiring a common bit of high level code" isn't the
> global solution I'm myself hoping for.
>
> Matthias
>
> (1) Example where a nagios plugin requires the package for the nagios
> perl bindings. It's "nagios-perl" for most RPMs, but not split out and
> in the main "nagios-plugins" on Gentoo... then for any other plugin
> from nagios-plugins RPMs, such as "nagios-plugins-file_age", same
> thing. So you get a big mess with duplicate definitions for the main
> Gentoo "nagios-plugins" package, or you need yet another layer of high
> level code hack :-/
>
> --
> 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.
>
>
> --
> 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.
--
Walter Heck
--
follow @walterheck on twitter to see what I'm up to!
--
Check out my new startup: Server Monitoring as a Service @ http://tribily.com
Follow @tribily on Twitter and/or 'Like' our Facebook page at
http://www.facebook.com/tribily
--
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.
