Maybe post to puppet-dev to get the developer's feedback? On Thu, Oct 2, 2014 at 10:54 AM, Chris Pitman <[email protected]> wrote:
> Hey everyone, > > I'm hoping someone can enlighten me here: Why is it so hard/complicated to > use third party gems when developing a custom provider? It seems to me that > pulling in gems should be priority #1, since it allows providers to > leverage a lot of development already done in the ruby community. > > However, right now it is complicated: > > 1. I have to get my users downstream to install gem dependencies before > using any resources related to the provider. There is no way for me to > annotate the module itself for these dependencies, and no support for > automatically pulling them down. > You can install gem dependency on the client as part of the puppet run. This was added around 2.7: http://projects.puppetlabs.com/issues/14822 But there are some issues that require clearing the ruby gem path cache: https://tickets.puppetlabs.com/browse/PUP-1879 I don't always have the latest puppet version, so this was a work around (as always should be accompanied with horrible disclaimer): # Try one last time since PUP-1879 isn't always available: unless defined? ::Faraday Gem.clear_paths unless defined? ::Bundler require 'faraday_middleware' end @connection = ::Faraday.new(url) I was hoping in the type to autorequire class where the packages were installed, but was only able to get normal resources to work: autorequire(:package) do 'faraday_middleware' end 2. "Features" offer very limited capability (as far as I understand), and > are poorly documented. The only documentation is on how to link providers > and types using features, not on how to require ruby libraries. There is no > way for anything other than a type to specify requiring a feature. For > example, what if a provider requires a gem? > The method missing code for Puppet.features.<feature_name>? is not just for checking gem availability, it also attempts to load the gem: require 'some_feature' if Puppet.features.some_feature? PUP-3032 adds a new setting. For the agent it should be always_cache_features=false, and =true for performance reasons on the server: https://tickets.puppetlabs.com/browse/PUP-3032. 3. "Features" only protect part of the lifecycle. Even without a feature > present, puppet still attempts to resolve auto-require relationships. This > makes sense based on how things work, but what am I supposed to do if I > need a third party gem there? > > 4. Some gem dependencies need to be present on both the puppet master (in > the master's environment) and on the node. There is no way for me to > transparently take care of this for users. > Yeah, this one is annoying, and the best solution I can come up with at the moment is a master manifest, or a master gemfile in the site module. Also there's no way to have multiple gem versions on the master. The new puppet-server project is suppose to offer more isolation, but I'm not exactly sure how it will be able to do this. So, am I just missing something? Is there some secret hook in the puppet > source that makes dealing with gems better? Should I just start > distributing this provider as a package, and ignore "puppet module", r10k, > etc? Or are there any changes coming down the pipeline that will make this > work better? > Yes, I agree we should have better tools, puppet module and r10k seems like good candidates. We need to agree how to specify master specific gems in the module metadata, and hopefully not something that reinvents the wheel. HTH, Nan -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CACqVBqAr-pOnfdvykGKqY%2B%3DLhFJUf6_25E6BJodJuBM9zpYdbw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
