Using Django's url-building machinery instead of CONTENT_ORIGIN

Announcements
#1

As we work to better support deployments that are accessible from multiple hostnames, we have determined that it is best to use Django’s built in utilities for forming redirects. This has implications for both plugin writers and users.

Users will no longer be able to deploy pulpcore-api and pulpcore-content on different hostnames and/or ports.

Plugin writers will need to update their code to no longer rely on the value of CONTENT_ORIGIN to form redirects from pulpcore-api to pulpcore-content.

If you have any concerns about these changes, please comment on this thread.

1 Like
#2

I want to emphasize that this means we intend to drop support for deploying them on different network locations. A setup we suspect is used rarely to nowhere.

Also looking forward, this opens up the future possibility to get the content app as well as the api parts onto the same stack and maybe even into the same process (once async Django serves our content delivery needs). At least with pulp_container and pulp_ansible this split isn’t meaningful anymore today.