Story #4273: As a plugin writer, I can import the Content app, subclass it, and register that with the aiohttp app instance which is a singleton - Pulp

Actions

Send by e-mail Copy link

Story #4273

closed

Story #3693: Lazy for Pulp3

As a plugin writer, I can import the Content app, subclass it, and register that with the aiohttp app instance which is a singleton

Added by bmbouter about 6 years ago. Updated about 5 years ago.

Status:

CLOSED - CURRENTRELEASE

Priority:

Normal

Assignee:

bmbouter

Category:

Sprint/Milestone:

3.0.0

Start date:

Due date:

% Done:

100%

Estimated time:

Platform Release:

Groomed:

Yes

Sprint Candidate:

Yes

Tags:

Sprint:

Sprint 46

Quarter:

Description

Several things need to be done:
1. Import the ContentHandler into the plugin API
2. Create a singleton interface in pulpcore.plugin.content.app that returns the aiohttp.web.Application as a singleton.
3. A guaranteed place for plugins to have their content app code imported from. This will be imported like the viewsets are by core. This happens already during django configuring during the content app's startup.

Actions

Copy link

Updated by bmbouter about 6 years ago

Parent issue set to #3693

Actions

Copy link

Updated by dkliban@redhat.com about 6 years ago

Groomed changed from No to Yes
Sprint Candidate changed from No to Yes
Sprint set to Sprint 46

Actions

Copy link

Updated by bmbouter about 6 years ago

Status changed from NEW to ASSIGNED
Assignee set to bmbouter

This is the critical path for the content app being usable by plugins.

Added by bmbouter about 6 years ago

Revision 21576ca5 | View on GitHub

Adds importing of the 'content' module

The 'content' module needs to be auto-imported when the content app starts so that loading is added to its startup sequence with this PR. Importing is all we have to do and aiohttp's registration mechanisms take over.

https://pulp.plan.io/issues/4273 re #4273

Added by bmbouter about 6 years ago

Revision 21576ca5 | View on GitHub

Adds importing of the 'content' module

https://pulp.plan.io/issues/4273 re #4273

Actions

Copy link

Updated by bmbouter about 6 years ago

Status changed from ASSIGNED to POST

PRs available at: https://github.com/pulp/pulp/pull/3807 and https://github.com/pulp/pulpcore-plugin/pull/22

Actions

Copy link

Updated by bmbouter about 6 years ago

Status changed from POST to MODIFIED
% Done changed from 0 to 100

Applied in changeset commit:pulpcore-plugin|a6f78fd4bd77bca6203f1dace88949c3ba773d46.

Actions

Copy link

Updated by gmbnomis almost 6 years ago

I tested this using pulp_cookbook (to implement the live API as part of the content app) and it works! However, I have a couple of questions/remarks:

1. What is the URL scheme a plugin should use? (unless the content type forces something specific like Docker). I used /<plugin_name>/content/ in order to avoid conflicts with other distributions.

2. I can't seem to adapt the base_url field of the Distribution accordingly. https://github.com/pulp/pulp/blob/cf30f2e9a77f7ad935184c5cbe58dfad788febc3/pulpcore/app/serializers/fields.py#L157 seems to hard code the base url and the Distributor Serializer/Viewset are not part of the plugin API.

3. PathNotResolved should be made available in the plugin API as derived content handlers may want to use it.

4. Minor point: A distribution is now served both at /pulp/content/ (not working for cookbook content) and /pulp_cookbook/content/. Can I inhibit visibility under /pulp/content/?

Actions

Copy link

Updated by bmbouter almost 6 years ago

I'm finally getting around to incorporating this good feedback.

gmbnomis wrote:

I tested this using pulp_cookbook (to implement the live API as part of the content app) and it works! However, I have a couple of questions/remarks:

1. What is the URL scheme a plugin should use? (unless the content type forces something specific like Docker). I used /<plugin_name>/content/ in order to avoid conflicts with other distributions.

Do you think we should document a recommended URL scheme?

2. I can't seem to adapt the base_url field of the Distribution accordingly. https://github.com/pulp/pulp/blob/cf30f2e9a77f7ad935184c5cbe58dfad788febc3/pulpcore/app/serializers/fields.py#L157 seems to hard code the base url and the Distributor Serializer/Viewset are not part of the plugin API.

I filed this issue here: https://pulp.plan.io/issues/4437

3. PathNotResolved should be made available in the plugin API as derived content handlers may want to use it.

I filed this issue here: https://pulp.plan.io/issues/4436

4. Minor point: A distribution is now served both at /pulp/content/ (not working for cookbook content) and /pulp_cookbook/content/. Can I inhibit visibility under /pulp/content/?

I filed this issue here: https://pulp.plan.io/issues/4435

Actions

Copy link