RFC: Katello Alternate Content Sources

[ehelms]

@iballou

I don’t see why not. An ACS could be any filesystem or internet path. You only need to provide the certs, headers, and/or basic auth info required.

Can we add this use case to the RFC and/or via an issue to track this on the roadmap for ACS?

@iballou

When a user defines an HTTP proxy and creates repositories with it, Katello sticks the proxy info on the related Pulp remote. For ACSs, it’s the same thing. The remote needs the HTTP proxy info. I hadn’t thought of supporting it though, so thanks for the reminder. I’m thinking the ACS creation page could have an HTTP proxy selection just like the repo creation page.

Cool, this would make for a good story attached to the set of use cases so it’s tracked.

@iballou

Just “binary content” as the Pulp epic puts it. The metadata should always be coming from the repository, not the ACS. That way, the ACS could just be a networked folder of random RPMs.

This could be a good call out for when the docs get written for this, to help users understand that ACS does not mean all aspects of the content come from the ACS there are parts that still come from Pulp.