This will be a larger than average RFC as it intends to cover every functional and conceptual area that needs attention to normalize Katello as a plugin within the Foreman ecosystem.
Katello and Foreman use different default certificate infrastructures which can prove difficult to reconcile when trying to add Katello to Foreman. Further, other forces such as optiona Puppet are driving a need for a base, default certificate setup for Foreman.
Katello does not support nested organizations, not only disabling them but throwing an error if they are enabled. The reason for this is the way that Katello maps Foreman organizations to Candlepin organizations one to one. Object scoping in Katello is locked to an organization. Manifest’s and subscriptions are tied to a single organization. Some possible solutions:
Mark organizations as “subscription” organizations and only allow certain operations on those organizations; or root organization is the only one tied to a Candlepin organization
Drop nested organizations all together from Foreman
Allow any organization to import a manifest but scope the subscriptions to only that organization; sub-orgs would not see parent subscriptions
Katello defaults smart-proxy to port 9090 since Candlepin uses 8443. Smart proxies by default use 8443 for HTTPS. Adding Katello to an existing Foreman today would require changing a users Smart Proxy port on the server. As well, for external proxies, Katello deploys the smart-proxy on 9090 because an Apache reverse proxy is deployed to 8443.
Move Candlepin to new port by default (e.g 9443) Redmine Issue
Use 8443 by default for smart proxy HTTPS port everywhere Redmine Issue
Move external Apache reverse proxy to 443 Redmine Issue
Convert reverse proxy on foreman proxy with content to registration gateway with smart proxy feature
Katello deploys a reverse proxy on external Foreman Proxies to allow hosts to register via subscription-manager through the proxy and get content such as GPG keys served by the main server.
Proposal
Elevate the reverse proxy deployed to a smart-proxy feature
Allows detection of reverse proxy within the smart-proxy UI and knowledge of which proxies have reverse proxies deployed
There is a broader development thread around changes to the installer that can be found here. There are some changes that can target bringing Foreman and Katello together within the installer ecosystem outlined here. Within our installer there are effectively two major scenarios: Foreman and Katello (forman-proxy-content scenario effectively belongs to Katello). We see a split between how those scenarios are handled from hooks to migrations.
IMHO this depends on making the registration gateway a smart proxy feature. That way Katello can reliably detect the URL (thanks to the installer setting the right config) to present to users without having to guess.
IMHO this is great for any Katello setup. It can also allow multi-homing where there’s a Foreman LAN and a client LAN. The reverse proxy can be presented on proxy.client-lan.example.com while Foreman Proxy listens on proxy.foreman-lan.example.com.
As someone who helps our documentation team to work on the content I am begging you for this. Also this will be friendly to users who previously found any content that is Satellite-related as thats exactly the term used there.
Million times yes.
Please specify which endpoint is on your mind, smart proxy has two: HTTP and HTTPS. I don’t care which one we are going to use as long as it’s the same for katello and non-katello installation.
Guys, if we are able to pull this one out, it’s huge win for our users upstream and downstream. Kudos, looks like a lot of work. Count me in with any changes needed on the smart-proxy side, SELinux, all my components I do take care of.
I find Nested Orgs a critical feature for keeping things in a sane and manageable setup. I would strongly oppose dropping Nested Orgs.
I’m not totally following option #1. May I request more details?
On the option #3 front, this would mostly work for me - but create a lot of overhead on setup. From an integration standpoint, would this result in multiple “subscription servers” in the RH entitlement window? I’m a bit worried the workflow would be confusing or create a lot of redundant looking objects. Any chance there could be code permitting the “parent org” to delegate some specific number of subscriptions to a “child org”? I realize that probably puts us back into the situation that caused this discussion initial - manifests and subscriptions are tied to a single org. I’m hopeful that explicit delegation rather than inheritance might clean up some bits - as I envision it, the “parent” would lose X entitlements and the “child” would then gain them.
I’d like it if someone would work on the Katello side of it. I’m not too familiar with that codebase, but I’ll gladly help. Once that’s there, I can also make sure the packaging and installer sides work.
This should be split this off to its own RFC (and Redmine issues).
