[Pulp-list] Blog - Preview: Creating a Pulp Plugin

[Nick Coghlan]

On 11/03/2011 01:22 AM, Jay Dobies wrote:
> http://blog.pulpproject.org/2011/11/02/preview-creating-a-pulp-plugin/
>
> I wrote up the first in a series of posts that talks about creating Pulp
> v2.0 plugins for anyone who wants to be on the bleeding edge of Pulp
> stuff. I still need to write up a description of the REST APIs to
> actually use it, but this should be enough to get anyone started who
> wants to play with writing a plugin.

That generally looks like a good fit with what we want to do in 
PulpDist, but I'm not sold on the idea of actually having to import and 
run Python code in order to get at the importer and distributor 
metadata, nor on the requirement to install (or symlink) Python code 
into a /var subdirectory to get the plugins to work.

Rather than a dedicated directory for the actual plugin code, have you 
considered a JSON based configuration model along the following lines 
(closer to the existing interface for the content type definitions):

     {"importers": [
         {
             "id"           : "sync-tree",
             "display_name" : "Directory tree importer",
             "types"        : ["file"],
             "plugin"       : "pulpdist.pulp_plugins.TreeImporter"
         },
         {
             "id"           : "sync-versioned-tree",
             "display_name" : "Directory tree importer (multiple 
independently updated versions)",
             "types"        : ["file"],
             "plugin"       : "pulpdist.pulp_plugins.VersionedTreeImporter"
         },
         {
             "id"           : "sync-snapshot-tree",
             "display_name" : "Directory tree importer (sequentially 
released versions)",
             "types"        : ["file"],
             "plugin"       : "pulpdist.pulp_plugins.SnapshotTreeImporter"
         },
         {
             "id"           : "sync-snapshot-delta",
             "display_name" : "Rsync delta generator (sequentially 
released versions)",
             "types"        : ["rsync-delta"],
             "plugin"       : "pulpdist.pulp_plugins.SnapshotDeltaImporter"
         },
         {
             "id"           : "sync-delta-tree",
             "display_name" : "Directory tree importer (sequentially 
released versions based on rsync delta files)",
             "types"        : ["file"],
             "plugin"       : "pulpdist.pulp_plugins.DeltaTreeImporter"
         }
     ]}

And then in a separate file in the distributors directory:

     {"distributors": [
         {
             "id"           : "publish-delta",
             "display_name" : "Rsync delta publisher",
             "types"        : ["rsync-delta"],
             "plugin"       : "pulpdist.pulp_plugins.DeltaDistributor"
         }
     ]}

The key changes would be to move the metadata out into static JSON 
files, and then include a "plugin" field in the metadata that tells Pulp 
where to find the actual Python class implementing the plugin. That way, 
all the restrictions on naming and file locations for plugins can go 
away (aside from the usual Python namespace rules) and the deployment 
model becomes simply:

   - install your Python package (including any Pulp plugins)
   - add JSON for new content types to /v/l/p/plugins/types
   - add JSON for new importers to /v/l/p/plugins/importers
   - add JSON for new distributors to /v/l/p/plugins/distributors

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Engineering Operations, Brisbane