Pulp

I would like to consider adding a new aspect to the plugin API: giving them a space to expose REST endpoints. This would give the plugin writer more freedom to implement the APIs they attempt to mimic. An example of a long term improvement would be that we could merge Crane into the regular pulp_docker plugin.

This should be pretty trivial to do using Django's `include` feature.

amacdona@redhat.com wrote:

I would like to consider adding a new aspect to the plugin API: giving them a space to expose REST endpoints. This would give the plugin writer more freedom to implement the APIs they attempt to mimic. An example of a long term improvement would be that we could merge Crane into the regular pulp_docker plugin.

This should be pretty trivial to do using Django's `include` feature.

I generally like this idea, but with one minor change, which is that the views provided directly by plugins might well be REST endpoints, but could potentially be any django view, and should maybe not be exposed under the '/api/v3/' endpoint.

amacdona@redhat.com wrote:

I would like to consider adding a new aspect to the plugin API: giving them a space to expose REST endpoints. This would give the plugin writer more freedom to implement the APIs they attempt to mimic. An example of a long term improvement would be that we could merge Crane into the regular pulp_docker plugin.

+1 to doing something which could bring Crane into the pulp_docker plugin.

Can the planning for inclusion of REST API endpoints in the plugin API become its own Redmine task. I'm planning to reserve this one for the creation of the pulp.plugin base classes. I'm doing a rewrite to the task contents to have it read as such and I don't want this idea to get lost.

amacdona@redhat.com wrote:

This should be pretty trivial to do using Django's `include` feature.

Agreed

Here is what I was thinking for the design. The base objects in pulp.plugins should consider these approaches:

Validation interface

• Platform validation is done on the base object using the validation interface
• Additional validation can be provided on subclassed objects using the validation interface which should call the parent object too
• I recommend doing it similar to the 3 step validation of Django models use. https://docs.djangoproject.com/en/1.10/ref/models/instances/#validating-objects

Instantiation

• The platform will instantiate the concrete object, e.g. YumImporter which would be a subclass of Importer
• An instantiated object, e.g. YumImporter will have all data from the rest call generically bound to it
• The platform will call the validation interface on the concrete object before calling into it

Call Pattern

• Few or no arguments will be passed along with the call into the concrete object which hands control over to the plugin code
• All data will be bound ahead of time as part of instantiation