Story #3182
closedAs a plugin writer, I have an interface which gives me a persistant area of the filesystem just for my plugin's use
100%
Description
A plugin interface needs to be added to the plugin API that plugin writers can all to get the full path to a persistent, shared storage location.
A new storage.py should be made in the pulp repo at /plugin/pulpcore/plugin/storage.py
. It should provide an interface called get_plugin_storage_path()
that returns a string like /var/lib/pulp/shared/<the_plugin_name>
. So for the ansible Plugin, which is formally called pulp_ansible, that string would be /var/lib/pulp/shared/pulp_ansible/
when called from inside the pulp_ansible code.
We are using an interface so that in the future users could possibly configure this. For now all returned strings will start with /var/lib/pulp/shared/
. Also the full path returned must include a trailing slash since it's meant to be appended to.
The motivating use case is that some plugins like pulp_ostree and pulp_ansible need to use other tools, like python-ostree and python-git to sync data from the remotes. Those tools expect to be writing data to a place they manage. We could have them write to the temp dir, but then we have to have them add all of that indexed content to Pulp which removes some of the benefit those tools provide. Having them write to a dedicated area of the filesystem directly instead is the current plan.
Updated by bmbouter about 7 years ago
- Subject changed from As a plugin writer, I can manage a persistant area of the filesystem just for me to As a plugin writer, I have an interface which gives me a persistant area of the filesystem just for my plugin's use
- Description updated (diff)
Rewriting based on the MVP call from yesterday.
Updated by dkliban@redhat.com almost 7 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to dkliban@redhat.com
Updated by dkliban@redhat.com almost 7 years ago
The simplest implementation would require the caller to provide the plugin name when calling this method. A fancier implementation would use the inspect module to examine the call stack to determine which package the call came from. The latter is not very simple to implement because the inspect can only determine a module name and not the package that contains that module. Which implementation are we after in this story?
Updated by bmbouter almost 7 years ago
I think the simple option of having the caller provide the name is fine. The docs could encourage/suggest they use their app entry point name, like pulp_file
here
Updated by dkliban@redhat.com almost 7 years ago
- Status changed from ASSIGNED to POST
Added by dkliban@redhat.com almost 7 years ago
Added by dkliban@redhat.com almost 7 years ago
Revision ffa6b11f | View on GitHub
Problem: Artifacts can't store git repos
Solution: Provide shared persistent storage for all plugins.
This patch updates the plugin api with an interface for finding the path to a plugin's storage location.
Updated by dkliban@redhat.com almost 7 years ago
- Status changed from POST to MODIFIED
- % Done changed from 0 to 100
Applied in changeset pulp|ffa6b11f8474509c82974ad91dff6ec8b6e4e24a.
Updated by bmbouter about 5 years ago
- Status changed from MODIFIED to CLOSED - CURRENTRELEASE
Problem: Artifacts can't store git repos
Solution: Provide shared persistent storage for all plugins.
This patch updates the plugin api with an interface for finding the path to a plugin's storage location.
closes #3182 https://pulp.plan.io/issues/3182