Fixes #34897 - select ACS HTTP proxies per smart proxy

[ianballou]

What are the changes introduced in this pull request?

HTTP proxies for alternate content sources are now per-smart-proxy. The idea is that users will likely want ACSs on each smart proxy to have a different HTTP proxy. At the moment, all ACSs in Pulp that are part of a Katello ACS will share the same HTTP proxy, regardless of the assigned smart proxies. It probably wouldn't make sense for a content proxy in Asia to use the same HTTP proxy as a content proxy in North America.

So, the user can select an "ACS HTTP Proxy" for each smart proxy. This is done on the smart proxy edit page.

The user can also now select if they want their ACS to use HTTP proxies at all.

ACS remote configuration will be updated at refresh time to make managing remote update errors better. The smart proxy page doesn't handle async actions very well, so updating the remote at smart proxy configuration time could lead to a missed error. On the flip side, if the error happens during refresh, the user is more likely to see it.

Considerations taken when implementing this change?

1. Should simplified ACSs inherit the HTTP proxies from the parent repositories?

• I think it would be a good future RFE, but I'm not certain that users will find it necessary. I feel like it would be unlikely that users would want different HTTP proxies for each ACS. Typically they would use one global HTTP proxy, which this PR supports.

2. Should a test remote be created at smart proxy update time?

• I'm thinking that creating test ACS remotes is not worth it for HTTP proxies because we're editing 'n' remotes rather than just one. At sync time, if a remote fails to update, the user can look at the error in Dynflow and likely figure out that something is wrong with the HTTP proxy config.

What are the testing steps for this pull request?

1. Register a smart proxy
2. Create an HTTP proxy (just install squid and then use http://fqdn:3128) on the Katello server and the smart proxy.
3. Set the HTTP proxies on both smart proxies according to (2)
4. Create custom and simplified ACSs

• Toggle on "Use HTTP Proxies"

5. tail -f /var/log/squid/access.log on both the server and the smart proxy
6. Refresh the ACSs and watch the squid logs for requests
7. Create an on-demand repo that uses the same RPMs as the ACSs
8. Sync the repo and watch the squid logs for requests
9. Toggle "Use HTTP Proxies" on and off and make sure the Pulp remotes do indeed get updated
10. Take a look at the overall ACS HTTP Proxy workflow. Does it blend in well with existing HTTP proxy workflow?

Questions:

1. The "Use HTTP Proxies" display on the ACS details is putting the boolean on a new line. I have yet to figure out why. The JSX seems identical for the similar "Verify SSL" on the same page.

TODO

• [ ] Write tests

[theforeman-bot]

Issues: #34897

[sjha4]

The "Use HTTP Proxies" display on the ACS details is putting the boolean on a new line. I have yet to figure out why. The JSX seems identical for the similar "Verify SSL" on the same page.

Digging into this. The UI does look a little off the way it set up currently.

Create an on-demand repo that uses the same RPMs as the ACSs Sync the repo and watch the squid logs for requests

Not sure I am seeing this happening. I duplicated a repo that is part of a simplified ACS product and synced the duplicate repo and I would expect it to log requests to the HTTP proxy.

[ianballou]

Not sure I am seeing this happening. I duplicated a repo that is part of a simplified ACS product and synced the duplicate repo and I would expect it to log requests to the HTTP proxy.

I meant to say "immediate" there. Do you see things logged if you download RPMs? Also, you may have cached those RPMs already in Pulp, which might also explain a lack of downloads across the proxy.

If it's still being weird, check the Pulp ACS remote and see if the HTTP proxy did indeed make it to the remote. Keep in mind that you need to refresh the ACS again to see the remote get updated.