As a plugin writer, I have an interface which gives me a persistant area of the filesystem just for my plugin's use
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.
#1 Updated by bmbouter almost 2 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.
#5 Updated by email@example.com almost 2 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?
Please register to edit this issue