RFC: Adding Katello to a Foreman install

#1

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.

Certificate handling

Certificate Redesign RFC

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.

Nested Organizations

Redmine Issue

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:

  1. 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
  2. Drop nested organizations all together from Foreman
  3. Allow any organization to import a manifest but scope the subscriptions to only that organization; sub-orgs would not see parent subscriptions

Foreman Proxy vs. Foreman Proxy with Content

Moved to it’s own RFC

Port discrepancy of smart proxy

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.

Proposal:

Tracker: #29667

  1. Move Candlepin to new port by default (e.g 9443) Redmine Issue
  2. Use 8443 by default for smart proxy HTTPS port everywhere Redmine Issue
  3. 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

Split up foreman-proxy-content

Moved to a Redmine Tracker

Installer

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.

Merge hooks

Moved to a Redmine Tracker

Merge migrations

Moved to a Redmine Issue

5 Likes
RFC: Smart Proxy, Foreman Proxy, Foreman Proxy with Content
Foreman Community Demo #77
Migrate Foreman to Foreman + Katello
#2

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.

#3

Like you mean the terminology? I am in.

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.

4 Likes
#4

Yes.

Yes, the HTTPS one. As far as I know, the HTTP port used is the same across both scenarios.

#5

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.

1 Like
#6

I hacked up https://github.com/ekohl/smart_proxy_rhsm which allows configuring the RHSM base URL in the config and expose this as a setting.

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).