I was thinking more in terms of an exception handler:
package { "foo": ensure => installed, exceptDefined => skip}
Or something of that nature. This could also be used in other
situations where you want to bypass default behaviors. We've seen
situations where users want to apply a file if it exists in the module
but otherwise proceed without errors. This could be done like so:
file {"$foo": ensure => present, source => "${foo}.txt", exceptAbsent => skip}
On Tue, Jan 24, 2012 at 1:28 AM, Felix Frank
<felix.fr...@alumni.tu-berlin.de> wrote:
> Hi,
>
> 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?
>
> 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 ;-)
>
> Cheers,
> Felix
>
> --
> 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.
