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
Status:
CLOSED - CURRENTRELEASE
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.
- Parent issue set to #3693
- Groomed changed from No to Yes
- Sprint Candidate changed from No to Yes
- Sprint set to Sprint 46
- Status changed from NEW to ASSIGNED
- Assignee set to bmbouter
This is the critical path for the content app being usable by plugins.
- Status changed from ASSIGNED to POST
- Status changed from POST to MODIFIED
- % Done changed from 0 to 100
Applied in changeset commit:pulpcore-plugin|a6f78fd4bd77bca6203f1dace88949c3ba773d46.
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/?
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
- Sprint/Milestone set to 3.0.0
- Status changed from MODIFIED to CLOSED - CURRENTRELEASE
Also available in: Atom
PDF
.
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