Feature #11209
Add forge package provider
| Status: | Closed | Start date: | 12/06/2011 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Ryan Coleman | % Done: | 0% | |
| Category: | - | Spent time: | - | |
| Target version: | - | |||
| Keywords: | Affected URL: | http://forge.puppetlabs.com/rcoleman/puppet_module | ||
| Branch: | ||||
Description
You know it occurs to me that if we added a way to return the list of installed modules we could make a package provider out of the puppet module face.
def exists? check for existence of module end def instances end def create add module - defaults to Forge but can be overridden? end def delete Remove installed module end
The bits missing are:
- Method to compare versions
- How to handle modified modules – warn, replace, override, configurable etc Based on hash/version?
Quick-hit on a user story from Ryan (ticket #16400).
As a Puppet user
I want to interact with Forge modules as Puppet resources
So that I can automate the creation of new Puppet Masters with Puppet
Related issues
History
#1
Updated by Nigel Kersten over 1 year ago
My concern here is that we need something a little more native and well integrated in terms of pushing puppet modules using puppet to puppet masters who are then serving out those modules.
This may be overblown, and we can totally shoe-horn this in safely to the package provider, but that’s my main concern.
#2
Updated by Nigel Kersten over 1 year ago
- Status changed from Needs Decision to Needs More Information
- Assignee deleted (
Nigel Kersten)
I’m still unsure whether it makes sense to model modules as packages in puppet manifests, rather than offering some other way to keep modules automatically updated on a given master/agent.
We need more of a plan here before we can do anything.
#3
Updated by Barry Pitman about 1 year ago
- I’m not sure about the technical implications, but this would make re-using modules from puppet forge a lot easier.
#4
Updated by Ken Barber about 1 year ago
Moving ticket to Puppet project, as the module tool is now deprecated in favour of the tool located in core.
#5
Updated by Ken Barber about 1 year ago
- Project changed from Puppet Forge to Puppet
- Category changed from 93 to module tool
#6
Updated by Ken Barber about 1 year ago
I’d honestly rather see this incubate as a puppet module first, whatever we decide (I know – the recursive irony!).
#7
Updated by Ryan Coleman 10 months ago
For record keeping, here’s a 1-hour prototype that Pieter crafted. It has roughly zero testing, no further code commitment, doesn’t work with runmodes, likely doesn’t work with environments and has other bugs we haven’t even seen yet.
https://gist.github.com/f9693523d9055aa4fee3
We’ll certainly want to do something like this in the future, it’s just a matter of time and priorities.
—Ryan
#8
Updated by Nigel Kersten 8 months ago
- Project changed from Puppet to Puppet Forge
- Category deleted (
module tool) - Assignee set to Ryan Coleman
#9
Updated by Ken Barber 7 months ago
- Description updated (diff)
#10
Updated by Ryan Coleman 6 months ago
- Affected URL set to http://forge.puppetlabs.com/rcoleman/puppet_module
The prototype mentioned below has made it onto the Forge where I hope it will get some community love as we wait for some time to focus on it ourselves. Though it’s just a prototype, I consider the ball rolling enough to close this ticket. Please reopen if there’s disagreement on that.
http://forge.puppetlabs.com/rcoleman/puppet_module
Ryan Coleman wrote:
For record keeping, here’s a 1-hour prototype that Pieter crafted. It has roughly zero testing, no further code commitment, doesn’t work with runmodes, likely doesn’t work with environments and has other bugs we haven’t even seen yet.
https://gist.github.com/f9693523d9055aa4fee3
We’ll certainly want to do something like this in the future, it’s just a matter of time and priorities.
—Ryan
#11
Updated by Ryan Coleman 6 months ago
- Status changed from Needs More Information to Closed