Project

Profile

Help

Story #4273

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 10 months ago. Updated 6 months ago.

Status:
MODIFIED
Priority:
Normal
Assignee:
Category:
-
Sprint/Milestone:
Start date:
Due date:
% Done:

100%

Platform Release:
Blocks Release:
Backwards Incompatible:
No
Groomed:
Yes
Sprint Candidate:
Yes
Tags:
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
No
Sprint:
Sprint 46

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.

Associated revisions

Revision 21576ca5 View on GitHub
Added by bmbouter 10 months ago

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

Revision 21576ca5 View on GitHub
Added by bmbouter 10 months ago

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

Revision a6f78fd4 View on GitHub
Added by bmbouter 10 months ago

Add the Handler and aiohttp.web.Application to API

Plugin writers need to be able to subclass-to-customize the Handler we
use. They also need to access the app instance users will configure to
run so plugin URLs can be served.

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

History

#1 Updated by bmbouter 10 months ago

  • Parent task set to #3693

#2 Updated by dkliban@redhat.com 10 months ago

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

#3 Updated by bmbouter 10 months ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to bmbouter

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

#4 Updated by bmbouter 10 months ago

  • Status changed from ASSIGNED to POST

#5 Updated by bmbouter 10 months ago

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

#6 Updated by gmbnomis 10 months 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/?

#7 Updated by bmbouter 8 months 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

#8 Updated by daviddavis 6 months ago

  • Sprint/Milestone set to 3.0

#9 Updated by bmbouter 6 months ago

  • Tags deleted (Pulp 3)

Please register to edit this issue

Also available in: Atom PDF