Last week I was investigating solutions for retrying IPC/RPC operations
in a provider I'm working on and discovered that the puppetlabs-aws
module does exactly what I was looking for with the retries gem. I
believe the typical pattern for a provider to require a gem is to
declare a new feature (for the gem) and then confine the provider to
that feature.  This means that I'd need to duplicate the :retries
feature from puppetlabs-aws into my module since there's no [desired]
module level dependency.  I'm concerned that it's "asking for trouble"
to have multiple module defining, and possibly redefining, the same feature.

Options I've considered:

1. Essentially, do nothing and gamble that if multiple modules in the
same environment redundantly define the same feature, nothing bad happens.
2. Modules adopt a convention to namespace features in some way to avoid
collisions.  Ie, `:retires` becomes `:aws_retires` or pedantically
`:puppetx_aws_retires`.
3. Add new confine functionality such that a feature is no longer needed
to place a dependency on a gem. Possibly using
Puppet::Util::Feature.load_library independently of the rest of the
features subsystem.
4. Factor the `:retries` feature out into it's own module, perhaps with
a DSL class to handle installation of the gem.
5. Add a new confine type that auto-creates a feature for each lib
dependency.

I'm sure there are other possible solutions that I have missed.

Of these, I suspect \3 is most robust solution. It would also be the
most disruptive.

\4 would be a fast and cheap solution but I dislike the prospect of
trivial dependency sprawl.

There probably should be some sort of guidelines established along the
lines of \2, if the usage of features in general grows in popularity,
but I don't feel its a good solution to duplicate features.  It only
insures that duplicate features have different names.

\5 doesn't completely solve the problem but it does reduce the
possibility of conflicting feature definitions and removes the need for
boilerplate features in modules.  It also appeared to have fairly low
implementation complexity so I went ahead and created a module for it.

https://github.com/jhoblitt/puppet-confinelibs

Using that module, the providers in puppetlabs-aws could declare

    confine libs: ["retries", "aws-sdk-core"]

and the :aws & :retries features would be unnecessary.

I'd like to hear others thoughts on the best solution here before I push
anything to the forge.

Cheers,

-Josh

--

-- 
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/553DD6FD.1070007%40hoblitt.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to