pulpcore.plugin.content
The Content app provides built-in functionality to handle user requests for content, but in some cases the default behavior may not work for some content types. For example, Container content requires specific response headers to be present. In these cases the plugin write should provide a custom Handler to the Content App by subclassing pulpcore.plugin.content.Handler.
Making a custom Handler is a two-step process:
subclass pulpcore.plugin.content.Handler to define your Handler’s behavior
Add the Handler to a route using aiohttp.server’s add_route() interface.
If content needs to be served from within the Distribution’s base_path,
overriding the content_handler()
and
content_handler_directory_listing()
methods in your Distribution is an easier way to serve this content.
Creating your Handler
Import the Handler object through the plugin API and then subclass it. Custom functionality can be provided by overriding the various methods of Handler, but here is the simplest version:
from pulpcore.plugin.content import Handler
class MyHandler(Handler):
pass
Here is an example of the Container custom Handler.
Registering your Handler
We register the Handler with Pulp’s Content App by importing the aiohttp.server ‘app’ and then adding a custom route to it. Here’s an example:
from pulpcore.content import app
app.add_routes([web.get(r'/my/custom/{somevar:.+}', MyHandler().stream_content)])
Here is an example of Container registering some custom routes.
Restricting which detail Distributions Match
To restrict which Distribution model types your Handler will serve, set the distribution_model field to your Model type. This causes the Handler to only search/serve your Distribution types.
from pulpcore.plugin.content import Handler
from models import MyDistribution
class MyHandler(Handler):
distribution_model = MyDistribution
pulpcore.plugin.content.Handler
- class pulpcore.plugin.content.Handler
A default Handler for the Content App that also can be subclassed to create custom handlers.
This Handler will perform the following:
Match the request against a Distribution
Call the certguard check if a certguard exists for the matched Distribution.
If the Distribution has a publication serve that Publication’s PublishedArtifacts, PublishedMetadata by the remaining relative path. If still unserved and if pass_through is set, the associated repository_version will have its ContentArtifacts served by relative_path also. This will serve the associated Artifact.
If still unmatched, and the Distribution has a repository attribute set, find it’s latest repository_version. If the Distribution has a repository_version attribute set, use that. For this repository_version, find matching ContentArtifact objects by relative_path and serve them. If there is an associated Artifact return it.
If the Distribution has a remote, find an associated RemoteArtifact that matches by relative_path. Fetch and stream the corresponding RemoteArtifact to the client, optionally saving the Artifact depending on the policy attribute.