Closed sbernhard closed 3 years ago
This is an interesting idea. I have a few questions to help me think on it.
1) This couples the squid deployed to help with lazy content syncing to a squid used for passthrough proxying. What if I want one but not the other? 2) In puppet-foreman_proxy_content, a reverse proxy is deployed through Apache that in theory could route back to the main server. What is the advantage of squid in this case? Given it requires using a separate port as well? 3) How does one deploy this configuration to a proxy without deploying all of Pulp given it seems tightly coupled to puppet-pulp?
Thanks Eric for you question and your interest. To 1: I added the passthrough mode as a addition - means, the pulp streamer scenario for lazy content syncing should still work. To 2: I guess, because of SSL certificates to have a secure connection AND to authenticate on pulp (using the client cert) a reverse proxy can not be used. Additionally, I prefered to have the squid solution as its possible to verify that only requests of a given network to pulp master is allowed. Don't know if this is possible with apache.
I think I am not grasping the concept here. Let me recap my thoughts and you can steer me back on course. I interpreted this as a lightweight way to present content on a proxy so that hosts isolated could get content from the main server without having to have a full blown Pulp configured and syncing content.
This is correct.
During installation, all pulp node services are still configured. If you want, you can still sync the content to the pulp node (capsule) - maybe only parts. In the end, the client decides if the passthrough mode is used (= proxy configuration on the hosts is configured) or the pulp node.
Of course, it doesn't make sense to sync all the content to the pulp node and then use the passthrough mode. The intention is to use the passthrough mode and don't sync the content so that the content (rpms, debs) doesn't need to be duplicated.
---- Eric Helms schrieb ----
I think I am not grasping the concept here. Let me recap my thoughts and you can steer me back on course. I interpreted this as a lightweight way to present content on a proxy so that hosts isolated could get content from the main server without having to have a full blown Pulp configured and syncing content.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/theforeman/puppet-pulp/pull/372?email_source=notifications&email_token=AGCOEFOHMRT3QE4BN5CDQMTPZBL2PA5CNFSM4HTWEVCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXBM2KA#issuecomment-499305768, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGCOEFLEV7EHV2O37K43QXTPZBL2PANCNFSM4HTWEVCA.
ping @ehelms
ping @ehelms / @ekohl
can you please have a look at it again @ekohl ?
@sbernhard We have had a hard time wrapping our brains around this change and how it plays into the architecture. With Pulp 3 integration appearing in Katello releases, and these components no longer being present. Is this a change you still want to persue?
@ehelms The passthrough mode is feature often used by our customers. They like it a lot because they use a foreman proxy to make sure provisioning works in a specific network but don't waste storage as they just forward the requests to the rpm/deb packages.
For pulp3, we want to have similar / the same approach. Therefore, we will work on https://github.com/theforeman/puppet-foreman_proxy_content/pull/205, too.
This module is just for Pulp 2. No new features will be accepted in this module. It's only here for Katello 3.18 until that's EOL. https://github.com/theforeman/puppet-pulpcore is used for Pulp 3 and is completely different. For example, squid is not present.
This change implements a passthrough mode on a pulpnode (=capsule) to pulp master using the already existing squid proxy.
The advantage is, that many customers don't want to duplicate the pulp content but still have separated subnets. Therefore, we configured a squid proxy on the capsule to route all requests for pulp content (rpm, apt) to pulp master (=katello)
For using this at katello: