How We Think About and Use Smart Proxies Architecturally

[Bryan_Kearney]

I disagree. I’d like to treat Pulp as just a REST API endpoint with no extra insight whatsoever. That means you can run Pulp on a different environment (Kubernetes, OpenShift, $cloud, bare metal) than your Foreman/Katello. Then you can’t rely on kube.

Agree to different machine, but I dont see abstracting pulp out of katello. I think it wil know it is talking to a pulp backend. It can go async, rest, anything else.

[Justin_Sherrill]

[stbenjam] stbenjam https://community.theforeman.org/u/stbenjam
July 2

Bryan_Kearney:

There is a distinction here tho. DNS/DHCP is an interface with
different implementations behind it. Pulp is not a interface, it
is a sepcific service.

An abstraction isn’t necessary to get the benefits of a single auth
scheme, single port, and single API endpoint.

Is the suggestion here that we use the smart proxy service to proxy
calls? I would think the throughput we put through to a pulp server is
too much for a single process/single threaded service. If that is the
goal, we may need to expand out the infrastructure related to the smart
proxy server.

[ekohl]

Agree to different machine, but I dont see abstracting pulp out of katello. I think it wil know it is talking to a pulp backend. It can go async, rest, anything else.

There are some aspects in the code we have now. In the current proposed PR we would be starting to use the Proxy as service discovery: the proxy knows the URL to Pulp and Katello learns the Pulp URL from the Proxy when it registers / updates its features.

[ekohl]

I would think the throughput we put through to a pulp server is too much for a single process/single threaded service.

I suppose it’s a good thing that the Proxy isn’t single threaded then

[Justin_Sherrill]

Ah good, my memory must have been out of date !

[ehelms]

A counterexample is LDAP authentication. We use https://github.com/theforeman/ldap_fluff to abstract away the LDAP provider details, and Foreman uses the library directly. Would it be any simpler to just proxy the connection through smart-proxy? On the Foreman end, yes. However it’s also a PITA to force the user to deploy and configure a proxy on the LDAP system (which they might not have control of).

If we were to apply this to the Pulp thought model, would a user need a smart proxy on the LDAP system given the Foreman server today does not need to be there? You’d just need a smart proxy somewhere (could even be the default one) that is linked and talking to the LDAP system?

The proxy is used to extend foreman’s reach into foreign networks, i.e. a distributed architecture. There’s not a lot of reason to proxy the database, you only have one (and maybe a replica) and it’s local to the Foreman instance. I don’t think the discussion should be about “essentialness” or not, but whether or not it’s a component of which there can be multiple instances that need to be orchestrated. Pulp definitely falls into that category.

This is less true with remote database support right? And Pulp falls into a similar model in some respects. One master with many replicas. I think we look at Pulp child instances, and scale out a smart proxy makes sense.

Clients can’t talk to just any old pulp server because the metadata is different on every single one. #18717 would also need to get solved to have Foreman be aware of the concept.

If the different metadata issue were solved, would it change the approach?

I have seen the following uses which dont really line up with your definitions @ehelms:

1. Service interface definition : This is the DNS/DHCP use case. Create a single API and allow the proxy to implement different instances under the cover.

2. Service location federation : How to locate and scale out service.

3. Restification : Create a rest interface where none exists.

4. Network Proxies : Allow foreman to bridge network boundaries.

Yes, these are other facets of what the smart proxy is today. I was not intending to discount them. I should have clarified that I was somewhat trying to target 2 and 4 along with stack requirements. And I am trying to get at if we should be treating server from child deployments differently with Pulp or other services. Let me try to summarize the core questions we’ve got to:

1. Should a server deployment (Foreman core or with plugins) require a smart proxy to essentially function?
2. Should things like Pulp communication be unified through a Smart Proxy and thus require it’s existence?

[ehelms]

Ah good, my memory must have been out of date !

This site might help – https://www.newegg.com/Memory/Category/ID-17

[ekohl]

This is less true with remote database support right? And Pulp falls into a similar model in some respects. One master with many replicas. I think we look at Pulp child instances, and scale out a smart proxy makes sense.

One difference is who orchestrates the replicas. With remote databases there is one database URL. As I understand it, with Pulp we orchestrate the replicas.

[stbenjam]

This is less true with remote database support right? And Pulp falls into a similar model in some respects. One master with many replicas. I think we look at Pulp child instances, and scale out a smart proxy makes sense.

Clients in foreign networks talk to pulps that are local to them, just like the local TFTP, DHCP, and DNS servers. That’s been the Foreman model since very early on. But, we have a central pulp and it is special. It is more like the database in that regard, but it doesn’t really have to be architected that way.

I could also imagine a different design where all of the content actions happen through the smart proxy, and Katello’s issuing much simpler orchestration calls like create content view, publish, sync repo, etc and letting the proxies handle it all. I think in that model you could end up not being as monolithic, by potentially have multiple central pulps with different sets of content so it acts more like all of the other distributed services. Some of the intensive tasks like errata calculation could be more distributed, as well. I’m sure there’s all kinds of pitfalls in such a design, and I don’t even know if it’s a good idea.

Anyway, the proposed PR where we get the Pulp URL from the smart proxy seems fine to me, and I’m happy to admit Katello is special and live with how it is.

Clients can’t talk to just any old pulp server because the metadata is different on every single one. #18717 would also need to get solved to have Foreman be aware of the concept.

If the different metadata issue were solved, would it change the approach?

I don’t think it’d change how I think about smart proxies, but it’d solve the problem of scaling proxies with content.

[iNecas]

Wouldnt this be better with an async model? Fire and forget, let the backend service pick it up later?

The question is how the user/admin figures out the service is missing in action. There can be several reasons why the service is not up: perhaps it has not just been installed, or upgraded to required version, or it’s just down: and for this, it’s good to have the service catalogue, and the foreman-proxy register is actually used as one.

There are also situations, when we need the ext service not just for actions, but also for presentation, where the ‘fire and forget’ it not enough.

Therefore, the explicit assignment of resources to expected services helps dealing with UX, when the services we rely on are not there.

[iNecas]

As I understand things, with the current REX and Foreman Ansible architecture, the Smart Proxy is now an essential service? As in, they can not function without one, is that correct?

Well: you can’t do the remote command themselves. On the other hand, you can have just Ssh proxy, and you can do Ssh, but not Ansible, and vice-verse. But most importantly, you can install the remote execution plugin (just on server side), and you get all the UI working without ugly 500s, and once you setup everything and actually try to execute the job, you will be informed that there is no usable proxy to perform the job.

I think that’s a good model for all plugins that need some external service for its full functionality. I can imagine Katello working similar way, where you could enable just Katello and do the basic operation, while not allowing doing anything else until plugin in additional proxy (such as Pulp one).

The important property of this model is also, that it count’s on the fact, that the external services are not present from the day one and don’t have to be present 24/7, but the main server should still work in terms of not looking like broken.

Let’s think about Organization: today, you can’t create one and sync it to Canldpin later, once you install one. I can imagine, that instead, once you install Katello, it would indicate on the Organization, that it has not been fully synced, and suggesting to sync it to corrsponding Candlepin service (represented by proxy), perhaps letting the user know that they can’t use subscriptions functionality, until the Candlepin is around: on the other hand, they should still be able to install just Pulp and use it’s functionality to work with content: the clients would still be able to consume the content.