Skip to content

Container Gateway support - #611

Open
ianballou wants to merge 4 commits into
theforeman:masterfrom
ianballou:container-gateway
Open

Container Gateway support#611
ianballou wants to merge 4 commits into
theforeman:masterfrom
ianballou:container-gateway

Conversation

@ianballou

@ianballou ianballou commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

Why are you introducing these changes? (Problem description, related links)

The smart_proxy_container_gateway plugin is required for users to consume container content from smart proxies with Pulp.

What are the changes introduced in this pull request?

  • Adds support for the container gateway plugin to be configured with foreman-proxy.

How to test this pull request

Steps to reproduce:

Checklist

  • Tests added/updated (if applicable)
  • Documentation updated (if applicable)

@ehelms

ehelms commented Jul 2, 2026

Copy link
Copy Markdown
Member

You can rebase this now that deploy-proxy work has been merged.

@ianballou
ianballou force-pushed the container-gateway branch from f17d982 to fe6f89e Compare July 2, 2026 19:10
@ianballou

Copy link
Copy Markdown
Contributor Author

Linking up theforeman/foreman-oci-images#53

@ianballou
ianballou marked this pull request as ready for review July 9, 2026 16:02
@ianballou

Copy link
Copy Markdown
Contributor Author

Katello doesn't support the container gateway correctly yet. In its code, it expects the Pulp smart proxy to have the container gateway feature, but instead, the container gateway feature is on the non-Pulp smart proxy (since there are two per smart proxy host).

@ianballou ianballou changed the title Experiment: Container Gateway support Container Gateway support Jul 13, 2026
@ianballou

Copy link
Copy Markdown
Contributor Author

From my last comment - if this merges, containerized Katello + Container Gateway won't be any more broken than it is today, since Katello simply won't find the container gateway capsule and will skip the sync.

@ianballou
ianballou force-pushed the container-gateway branch from fe6f89e to 96d5351 Compare July 15, 2026 14:16
Comment thread src/roles/httpd/defaults/main.yml Outdated
Comment thread src/roles/httpd/templates/foreman-ssl-vhost.conf.j2
Comment thread src/features.yaml
description: iop services
dependencies:
- rh-cloud
container-gateway:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These feels like it should be part of the "content/container" feature or a dependency of it... but only in the proxy use case.

@ianballou ianballou Jul 15, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, that makes sense to me.

@ianballou ianballou Jul 15, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I gave this some thought. What is the "proxy" use case we're talking about here? It's foreman-proxy-content specifically. That is the only time we want to install the container gateway. I thought about having a dependency relationship with a conditional on the use of foreman-proxy-content, but that seems like a roundabout way to achieve the same result as just having the container gateway be a part of the foreman-proxy-content flavor.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, while there isn't a direct relationship between the container gateway and content/container, there is a connection between them created by the foreman-proxy-content flavor.

@ehelms ehelms Jul 21, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there is no Pulp or there is no Pulp with container content present, does this feature work? What happens if a container-gateway is deployed without Pulp or Pulp with container content on the same server?

We can go this route for now, if we need to, to allow the feature to work, but I would ask that we track doing the dependency relationship properly across foremanctl and Katello.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The container gateway does require Pulp, so from the standpoint of looking into deploying a smart proxy manually via features it would make sense for there to be some dependency there. I'm trying to weigh the complexity for the short term of using the foreman-proxy-content flavor as the glue between Pulp and container gateway since we seem to be putting a lot of emphasis into it being "the" smart proxy deployment at the moment.

But I totally agree that the dependency should be linked more generally for users constructing their own capsules without using the foreman proxy content flavor. I can think up an issue for that that covers what we'd need to achieve the dependency with a conditional on the foreman-proxy context.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm cooking something up, I'll push a commit soon.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, so while I am going to push something that links these dependencies - I currently see no way for an admin to build a foreman-proxy-content without using the flavor, which means the dependency link is purely for sanity rather than user benefit. At least for now.

The Pulp feature and its content types (besides ostree) are all internal, so I don't see how a user can use the foreman-proxy feature to build their own foreman-proxy-content. I suppose this may get smoothed out in the future.

Comment thread src/roles/foreman_proxy/templates/settings.d/container_gateway.yml.j2 Outdated
@ianballou
ianballou force-pushed the container-gateway branch from 96d5351 to 77b9f9f Compare July 15, 2026 18:49
@ianballou
ianballou force-pushed the container-gateway branch from 77b9f9f to 2e2f69e Compare July 16, 2026 19:07
Comment thread src/vars/base.yaml Outdated
@ianballou
ianballou force-pushed the container-gateway branch from 2e2f69e to f1b98dd Compare July 23, 2026 14:22
@ianballou

Copy link
Copy Markdown
Contributor Author

@ehelms I reorganized the DB connection string variables so an Ansible role user can set the individual components or the entire string manually if they wish.

I also added an integration test along with a temporary container image to see it working while we wait for theforeman/foreman-oci-images#53.


# Container gateway settings
foreman_proxy_container_gateway_pulp_endpoint: "https://{{ ansible_facts['fqdn'] }}"
foreman_proxy_container_gateway_db_host: "{{ container_gateway_database_host }}"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These aren't really defaults if they are defined by variables from somewhere else. I would expect default values as strings here, and for database.yml to then define the left hand side.

Comment thread src/vars/database.yml Outdated
container_gateway_database_password_file: "{{ obsah_state_path }}/container-gateway-db-password"
container_gateway_database_password: "{{ lookup('ansible.builtin.password', container_gateway_database_password_file, chars=['ascii_letters', 'digits']) }}"
container_gateway_database_host: "{{ database_host }}"
container_gateway_database_port: "{{ database_port }}"

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would expect these to all be the foreman_proxy_ scoped variable names -- https://github.com/theforeman/foremanctl/pull/611/changes#r3639114753

@sjha4

sjha4 commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Ran a test for enabling container_gateway with foremanctl deploy-proxy on this branch on an existing proxy deployment and it worked well for me..Was able to run a backup as a follow up test and it correctly identified container_gateway and backed up the pulp and container_gateway DBs. 👍🏼

Update: Was able to test the proxy backup/restore on top of this and it worked well. #684 (comment)

@ianballou

Copy link
Copy Markdown
Contributor Author

@ehelms I'm wrapping my head around the proper organization of the variables your asking about, but I made a push in response to your comments.

I need to look into the failing tests, probably some expectations in other tests that I did not update.

@ianballou

Copy link
Copy Markdown
Contributor Author

I pushed a change that makes the container gateway a dependency of content/container for all cases not matching "Foreman", which I assume here would mean smart proxy.

I did this because foreman-proxy can be on Foreman or not on Foreman. Thus, the only marker of a "foreman-proxy-content" machine is the "foreman-proxy-content" flavor. The flavor alone is not enough to say there is a dependency between content/container and the container gateway, so my next best idea is to use the lack of Foreman in a deployment to mean that we are talking about a "foreman proxy content".

This change means that we have a new concept of "unless" for features that are incompatible with each other. To accomplish this, I turned feature dependencies into dictionaries that can have "unless" as a list of incompatible plugins.

@ianballou
ianballou force-pushed the container-gateway branch from b59f7dc to ce04a83 Compare July 24, 2026 15:38
@ianballou
ianballou force-pushed the container-gateway branch from ce04a83 to fa6d7ed Compare July 24, 2026 15:47
@ehelms

ehelms commented Jul 24, 2026

Copy link
Copy Markdown
Member

There are similar conversations happening in #519 (comment)

CC @ekohl @jeremylenz @shubhamsg199

The tension here is we have a single definition of features and then multiple scenarios that can apply:

  • Features that only apply to Foreman server
  • Features that apply to Foreman server and external proxy
  • Features that apply to only external proxy

@ianballou

Copy link
Copy Markdown
Contributor Author

I had difficulty writing this new feature in a way that didn't assume "no Forman == Forman proxy content" because the only real indicator of this that I could find is the use of the flavor. On top of that, the dependency linking feels unhelpful with current foremanctl because of this huge reliance on the flavor.

I think the fact that flavors include internal only features is part of the problem. If we want flavor use to be optional, then they should not include internal features that cannot be enabled outside of the flavors. If we don't want flavors to be optional, then I think it should be fine for them to be a first class part of the feature dependency chain.

@ehelms

ehelms commented Jul 24, 2026

Copy link
Copy Markdown
Member

I think the fact that flavors include internal only features is part of the problem. If we want flavor use to be optional, then they should not include internal features that cannot be enabled outside of the flavors. If we don't want flavors to be optional, then I think it should be fine for them to be a first class part of the feature dependency chain.

I would agree -- flavors should not specify internal features at least based on my understanding of internal features.

The current design is that a flavor is required as it defines the baseline, unchangeable properties of the deployment. However, I do not see why features need to know about flavors.

Should features know about "server" and "proxy" -- I think so. I still strongly contend there are two foundational entities: server and proxy. And it matters which one is the target. That's why right now we have two distinct deployment commands.

So from my point of view:

  • Flavors should explicitly apply to either deploy or deploy-proxy but not both.
  • Features should be marked as applying to one of the the three scenarios I mentioned previously.

@ianballou

Copy link
Copy Markdown
Contributor Author

I was considering if we could simply add boolean values to each feature to declare what deployment scenario(s) each support.

katello:
  description: Content and Subscription Management plugin for Foreman
  foreman:
    plugin_name: katello
  hammer: katello
  dependencies:
    - tasks
    - pulp
    - candlepin
  deploy_on_foreman: true
  deploy_on_foreman_proxy: false

container-gateway:  
  description: Container registry gateway for smart proxy
  internal: true
  foreman_proxy:
    plugin_name: container_gateway
  deploy_on_foreman: false
  deploy_on_foreman_proxy: true

Are there other features that can only be installed on external foreman proxies?

@ianballou
ianballou force-pushed the container-gateway branch from fa6d7ed to 18f3b80 Compare July 27, 2026 20:28
* Update container gateway tests to match
* Update features in yaml to be dictionaries
@ianballou
ianballou force-pushed the container-gateway branch from 18f3b80 to e6cf948 Compare July 29, 2026 14:26
@jeremylenz

Copy link
Copy Markdown
Contributor

Are there other features that can only be installed on external foreman proxies?

templates and registration are two! I mean, I guess you could install them on your foreman server, but they're not really relevant since they just proxy api endpoints.

@ianballou

Copy link
Copy Markdown
Contributor Author

Before I make any changes, I'd like opinions on adding the feature incompatibility feature I have here (unless) versus making deployment methods a first-class indicator of which features should go on foreman/proxy/both.

I like using deployment methods as an indicator since checking for the existence of foreman feels like a workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants