Feature #7788
Puppet should allow rubygems to deliver new functionality
| Status: | Needs Decision | Start date: | 06/04/2011 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Nigel Kersten |
% Done: | 0% |
|
| Category: | plug-ins | |||
| Target version: | 2.7.x | |||
| Affected Puppet version: | Branch: | ripienaar/feature/master/7788 | ||
| Keywords: | ||||
| Votes: | 3 |
Description
It would be desirable to use Rubygems to install things like parser functions.
There might be cases where you only want a function on the master, pluginsync would copy it everywhere and everywhere might not have the dependencies needed to run it.
If the autoloader considered the rubygem search path while autoloading this should allow gems to extend puppet.
History
Updated by R.I. Pienaar 12 months ago
- Branch set to ripienaar/feature/master/7788
Updated by James Turnbull 12 months ago
- Category set to plug-ins
- Status changed from Unreviewed to In Topic Branch Pending Review
- Assignee set to Nigel Kersten
- Target version set to 2.7.0
Updated by Daniel Pittman 12 months ago
- Target version changed from 2.7.0 to 2.7.x
Damn. So, I was going through the last little steps in testing this after I merged it locally, before pushing, and we ran into a set of concerns that we don’t have time to address right now. Specifically, there are two concrete issues we are worried about here:
One, we are concerned that there might be cases where this adds the gem path, but not everything on the Ruby $LOAD_PATH, to the locations our autoloader (or one of the other open-coded implementations of the same) hunt for things on disk. That should be easy enough to verify, but we want (someone) to audit that before this gets merged.
Two, we are concerned that this potentially adds trouble when someone has two copies of Puppet installed, one through RubyGems, and the other through an OS package, or from source, or something like that. This introduces a new path that code can get loaded, and it isn’t at all clear which will win from the outside.
We have a cluster of other issues in the area, though: we need to be able to pluginsync faces and actions, as well as utility functions; we want to make sure we have consistent search paths to avoid the “face discovered, but can’t be loaded” showing up in another guise, and that sort of thing.
So, from discussion with Nigel and James we are going to hold this off for a bit: the code you have is correct, and ready to merge, and is going to stay there until we merge it as part of sorting out the rest of the mess around this area.
So, sorry: I wish I had thought of this earlier, or could more easily convince myself (and Nigel) that this was a safe step toward the ultimate goal right now, rather than having to delay landing it. :/ I really want to see this feature in.
Updated by Daniel Pittman 12 months ago
- Status changed from In Topic Branch Pending Review to Code Insufficient
Updated by Jeff McCune 12 months ago
On Mon, Jun 6, 2011 at 4:25 PM, tickets@puppetlabs.com wrote:
Two, we are concerned that this potentially adds trouble when someone has two copies of Puppet installed, one through RubyGems, and the other through an OS package, or from source, or something like that. This introduces a new path that code can get loaded, and it isn’t at all clear which will win from the outside.
This is already an issue today; people can’t have two versions of Puppet that exist in different parts of the $LOAD_PATH. It has been for a long time, so I don’t think this is a new concern, just a long standing old concern. =)
The answer is that they both win. You get types loaded from the “other” version and they fight each other.
-Jeff
Updated by James Turnbull 12 months ago
Agree on the load path but in this case we’re specifically adding the Gem path – something we’re not doing now – I’ve had puppet installed via gems and via package in the past without conflict.
Updated by Jan Ivar Beddari 9 months ago
I’d like to see this happen aswell.
Could it be done by creating Puppet-instance-specific paths using modules? http://janveldeman.wordpress.com/2008/04/14/project-specific-rubygems/ Probably not the most elegant solution.
Or a config setting with an explanation? In my (albeit small) Puppet kingdom catering for the dual install case seems less useful than this.
Updated by Gareth Rushgrove 8 months ago
Had a brief chat at puppetconf about this, specifically about making it easy to package new faces as gems and have them loaded automatically.
I decided to give the patch a whirl and hit a problem, specifically part of the implementation is deprecated when running under 1.9.2-p290
NOTE: Gem.all_load_paths is deprecated with no replacement. It will be removed on or after 2011-10-01.
Looks like Gem::Specification.each might be another approach, depending on which version of rubygems you need to support.
Updated by Nigel Kersten 4 months ago
Given we’re integrating ‘puppet module’ into Puppet, and assuming that we’re actually going to fulfill our promise to make it easy to distribute all the kinds of Puppet extension points (faces, facts, lib/whatever, providers) via modules, I’d love to get feedback from people on this ticket as to whether they think we really should deliver this functionality?
Updated by Nigel Kersten 4 months ago
- Status changed from Code Insufficient to Needs Decision
Updated by R.I. Pienaar 4 months ago
I think it still has value, unless you also let us control what gets pluginsynced to what places. With gems if we wanted some plugin on a subset of machines we just install it on those machines. With pluginsync thats not possible.
Updated by Daniel Pittman 4 months ago
R.I. Pienaar wrote:
I think it still has value, unless you also let us control what gets pluginsynced to what places. With gems if we wanted some plugin on a subset of machines we just install it on those machines. With pluginsync thats not possible.
How do environments fail to meet your needs here?
Updated by Nigel Kersten 4 months ago
That’s a big hammer to solve a small problem.
I guess to invert it, what’s the problem with distributing these plugins to all machines in a given environment? Is it that you end up with version conflicts of the same library? Are they sensitive in some other way?