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.

2 Likes
#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.

1 Like
#3

Recently had a deployment where I was serving content on an external IP and only reachable by publishera on the internal IP

Only issue I had seen in the past is the ansible plugin returns the hostname as defined in the hardcoded config and I swore before it would return those same names of collections were published with the old name and then you changed the name

This also has implications for serving on https and HTTP at the same time