Sorry for the double post, but I just remembered the new way of doing if
defined(). A function was added to stdlib called ensure_resource
https://github.com/puppetlabs/puppetlabs-stdlib/blob/master/lib/puppet/parser/functions/ensure_resource.rb
.
Looking at it, and how it is used, it's just another if defined().
Trevor
On Wed, Feb 19, 2014 at 8:28 AM, Trevor Vaughan <tvaug...@onyxpoint.com>wrote:
> One of the things that was proposed in the past was allowing different
> modules to declare the same resource iff it was declared identically in all
> cases.
>
> It was shot down as promoting bad practices but so was if defined() and
> the fact is that we *need* that because I can't have service { 'foo':
> ensure => running } in two modules.
>
> Yes, of course the correct way to do things is to abstract out each
> portion that is not on your critical path and have parameters that allow
> you to selectively manage it thereby alleviating the issues with if
> defined(), etc...
>
> But, everyone has jobs to do and may not be able to spend much time
> refactoring for other users.
>
> I *do* think that all Puppet Labs sponsored/approved modules should allow
> for the following to be selectively managed/included by a module at a
> minimum:
>
> * Firewall
> * PAM
> * Service
> * Web
>
> In general, I've found that if you make these optional, you stand a pretty
> good chance of staying out of people's way and letting them manage those
> portions their way while still taking advantage of your module.
>
> All that said, I still want to be able to declare multiple identical
> resources and have it "just work".
>
> Trevor
>
>
> On Wed, Feb 19, 2014 at 6:16 AM, Daniele Sluijters <
> daniele.sluijt...@gmail.com> wrote:
>
>> Hi everyone,
>>
>> As I was browsing through a few modules on the Forge I noticed that more
>> and more people seem to have taken to the `if ! defined(Package['name'])
>> {}` to ensure their module doesn't cause a duplicate resource declaration
>> with another module, third party or your own, that is also managing that
>> package.
>>
>> From a purist perception this should never happen in the first place as
>> there are suddenly two modules declaring the same resource. Unfortunately
>> this is often what it comes down to when you pull in a few modules from the
>> Forge or Github, especially with things like build-essential that a
>> multitude of different things might need. In turn this makes using
>> third-party modules more difficult because they might introduce issues like
>> these that, especially for newcomers to the platform, are troublesome to
>> fix.
>>
>> I was hoping we could devise a solution, at least for package resources,
>> that would allow multiple declarations of the package and have those
>> declarations resolve themselves. I'm specifically focussing on package
>> here because that's the most common source of trouble, things like an
>> rbenv, rvm and pyenv module all declaring that they need 'build-essential'.
>>
>> My initial thought was that a package could have two states, hard and
>> soft where a state => hard, definition of a package would always trump any
>> other definitions of a package in a soft state. The question then becomes,
>> how do you deal with multiple soft states of the same package which
>> basically boils down to you can't have multiple declarations of the same
>> thing, so we're back to square one.
>>
>> My other thought was that perhaps it should be possible to `require =>
>> Package['name']` from any resource and if that resource isn't declared in
>> the catalog spawn the resource ourselves but if it is defined that
>> declaration is used. I'm not sure how we could deal with scenario's where
>> someone requires said package but we explicitly define it as absent in our
>> manifests.
>>
>> Please spare me the "they're being wrong on the internet" speech, I'm
>> well aware of it but the truth of the matter is you'll never be able to
>> coordinate the community in such a way that this issue doesn't pop up. I'm
>> not really concerned about experienced Puppet users/developers that can
>> solve this for themselves, more about the less developer oriented operator
>> that has to use Puppet for whatever reason. Another approach would be to
>> really curate the modules up on the Forge but I doubt anyone feels like
>> doing that or has the time for it.
>>
>> I'm not sure if it's even desirable or possible to solve this issue in
>> the first place but I was curious if anyone has given any more thought to
>> this?
>>
>> --
>> Daniele Sluijters
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-dev/234c5510-c2b2-4786-ac76-68a73bf55e7d%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699
> tvaug...@onyxpoint.com
>
> -- This account not approved for unencrypted proprietary information --
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVTeS%3DrxdTZ7iUPjjuUJ3-ef2qhx%3DZR3KxazK46kh5a1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
