Add satellite flavor for downstream deployments by zjhuntin · Pull Request #628 · theforeman/foremanctl

zjhuntin · 2026-07-07T13:21:50Z

Summary

Adds a satellite flavor (src/vars/flavors/satellite.yml) with the feature set for Satellite deployments
Enables: foreman, katello, content/{ansible,container,rpm}, hammer, remote-execution, rh-cloud, iop, theme-satellite
Compared to katello flavor: drops content/deb and content/python, adds features that Satellite ships by default

Details

The theme-satellite feature requires a corresponding entry in features.yaml (or features.d/) to take effect. Without one, it is silently ignored.

Usage:

foremanctl deploy --flavor satellite --initial-admin-password=changeme

Test plan

Deployed with --flavor satellite on a CentOS 9 VM — all features resolved, 0 failures
Verified foremanctl features shows correct enabled/available features
Verified hammer ping — all services healthy
CI tests pass

🤖 Generated with Claude Code

Gauravtalreja1 · 2026-07-07T13:45:26Z

+  - foreman
+  - katello


foreman-proxy feature can be added to this list

as with hammer, I think that is something people should be actively opt in for?
content distribution to external proxies works without the feature, so in many architectures it won't be needed

for now I do not have foreman-proxy enabled by default.

I think it should be identical to what we've currently with rpm based installations and we should have similar features pre-enabled on satellite deploy for existing users, where foreman-proxy and hammer are enabled by default
@ekohl @vijay8451 wdyt?

Yes, I do think that.

One of our goals with foremanctl and containers was to encourage users to deploy external proxy/capsule/thing when they need functionality that is not available within the core Foreman(+Katello) stack rather than getting a local proxy by default. So that they have to make the choice whether to have it locally or not actively.

Upgrades will result in the same functionality, but the baseline feature set doesn't necessarily have to replicate what we had before.

For example, as a best practice, hammer should be installed on and used from a separate node. We should discourage admins from sshing in as root and using a CLI on the same machine that the service exists on. That's just a good security posture for us to encourage users to have. Should we block this? No. But it shouldn't be the default behaviour IMO.

One of our goals with foremanctl and containers was to encourage users to deploy external proxy/capsule/thing when they need functionality that is not available within the core Foreman(+Katello) stack rather than getting a local proxy by default. So that they have to make the choice whether to have it locally or not actively.

I think this is a good discussion topic. It will mean that by default you won't have a working remote execution setup. Is that what we expect?

Upgrades will result in the same functionality, but the baseline feature set doesn't necessarily have to replicate what we had before.

Agreed

For example, as a best practice, hammer should be installed on and used from a separate node. We should discourage admins from sshing in as root and using a CLI on the same machine that the service exists on. That's just a good security posture for us to encourage users to have. Should we block this? No. But it shouldn't be the default behaviour IMO.

This is IMHO a good thing, but I wonder about the documentation impact. Today we often document the Hammer procedure. Should we modify those to all to refer to a chapter to install Hammer (somewhere)?

+1 to everything Ewoud said here. I think users will expect the same plugins and features to be enabled on a containerized install that they used to get with the classic installer. If that's not going to be the case, our documentation should be loud about that.

zjhuntin · 2026-07-07T16:30:08Z

tested the most recent version and that worked as well 😄

evgeni · 2026-07-07T16:49:40Z

    help: Base flavor to use in this deployment.
    choices:
      - katello
+      - satellite


IMHO a Satellite user should not be able to select Katello, and a Katello user not Satellite

But we don't need to solve this right now

ekohl · 2026-07-09T18:28:36Z

How should we approach testing this? In 2198602 @arvind4501 introduced flavor based tests. Are we going to duplicate all katello tests for satellite? Should we also deploy this in CI to verify it works?

zjhuntin · 2026-07-10T05:44:38Z

@ekohl I looked into this with Claude's help.

I don't think duplicating the tests/flavor/katello/ tests into a tests/flavor/satellite/ directory makes much sense here. The two tests there — images_test.py and postgresql_test.py — verify that the foreman, pulp, and candlepin container images, databases, and users are present. Those are all guaranteed by the katello feature's dependency chain in src/features.yaml, and both flavors enable it. The assertions would be identical.

I think the directory-based flavor tests work well for foreman-proxy-content, where the deployment topology is fundamentally different and you need different assertions for the same kinds of checks. But when two flavors share the same Katello stack and only differ in which optional features are layered on top, tying tests to the flavor name means every new flavor that deploys Katello needs its own copy of the same tests.

The feature marker approach seems like a better fit here. @pytest.mark.feature('katello') ties the tests to what they actually depend on — the Katello stack being deployed — rather than which flavor was selected. This is already how candlepin_test.py, katello_api_test.py, and client_test.py work.

I'd propose:

Move the two tests/flavor/katello/ files into the shared test directory with @pytest.mark.feature('katello') decorators
Keep tests/flavor/ for foreman-proxy-content where the structural differences justify it
Add a satellite-tests CI job (single centos/stream9 run with --flavor satellite)

zjhuntin · 2026-07-10T05:47:00Z

I went ahead and pushed a commit with what I think this would look like so we can see if CI passes.

zjhuntin · 2026-07-10T06:16:20Z

Realized, that won't work as we don't serve the package. I'm not 100% sure how we can test this totally here. Is it okay without foreman_theme_satellite here?

arvind4501 · 2026-07-10T07:00:18Z

For the testing part, if we wil have exactly similar tests for katello and satellite flavor, then i would make change to https://github.com/theforeman/foremanctl/blob/master/tests/conftest.py#L267 to such that it runs katello specific tests when any of katello and satellite flavor is deployed. and similarly i would do for capsule flavor as well. i think this would require some mapping in same something like

FLAVOR_TEST_DIRS = {
    'katello': ['katello', 'satellite'],
    'foreman-proxy-content': ['foreman-proxy-content', 'capsule'],
}

zjhuntin · 2026-07-12T19:06:21Z

Switched to @arvind4501's approach — added a FLAVOR_TEST_DIRS mapping in conftest.py so the satellite flavor runs the katello test directory. Also cleaned up the commit history.

zjhuntin · 2026-07-20T20:26:20Z

Circling back on the two open threads here:

1. Feature set defaults (hammer, foreman-proxy)

Eric's point about encouraging users to deploy proxy externally and install hammer on a separate node makes sense from a security posture perspective. But Ewoud and Jeremy raise a valid concern — users migrating from foreman-installer will expect the same features to be available out of the box. If we change the defaults, we need to be deliberate about it and make sure documentation reflects what's different and why.

What should the actual outcome be here? Should the satellite flavor ship with hammer and foreman-proxy enabled by default to match existing user expectations, or should we take this as an opportunity to set new defaults and document the change prominently?

2. Testing theme-satellite

The theme-satellite feature is in the satellite flavor, but rubygem-foreman_theme_satellite isn't available in the repos that the upstream container images are built from. The nightly foreman image at quay.io/foreman/foreman only includes plugins listed in the FOREMAN_PLUGINS build arg in foreman-oci-images, and foreman_theme_satellite isn't one of them.

This means CI can't actually deploy with --flavor satellite as-is — the theme plugin won't be found. The best thing I can come up with is: Accept that upstream CI tests the satellite flavor without the theme (maybe skip/ignore theme-satellite if the plugin isn't available).

But I can also understand not liking that. Is there another alternative option?

zjhuntin · 2026-07-20T20:30:59Z

Rebased on master to pick up the post_install refactor from #641. Also added the satellite flavor to the post-install message condition so it shows the admin credentials after deploy, same as katello.

adamruzicka · 2026-07-22T15:37:37Z

+            --add-feature azure-rm \
+            --add-feature google \
+            --add-feature bmc


Shouldn't those be part of the flavor or am I misinterpreting why those would get enabled?

right now they are optional, because it's a bit undecided which features will get enabled by default on new installs. this PR gives enough building blocks for future adjustment :)

evgeni · 2026-07-27T12:55:21Z

      - katello
+      - satellite


We should not allow users to select between katello and satellite.

In #643 I started with a PoC how this could work

Feel free to implement this part in a follow up tho.

evgeni · 2026-07-27T12:58:23Z

The test failures in the Satellite test seem related. Holler if you need help deciphering them.

The satellite flavor provides a feature set matching what RPM-based Satellite ships by default, enabling proper downstream test coverage with foremanctl. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Map the satellite flavor to run katello flavor tests via FLAVOR_TEST_DIRS in conftest.py, so satellite deployments automatically pick up katello-specific test assertions. Add a satellite-tests CI job that deploys with --flavor satellite. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

The post_install refactor in theforeman#641 gated the credentials message on flavor == katello. The satellite flavor deploys the same Foreman stack and needs the same message. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

evgeni · 2026-07-28T14:43:26Z

+      - name: Downgrade openssl
+        run: |
+          for vm in quadlet client; do
+            vagrant ssh "$vm" -- sudo dnf downgrade -y openssl openssl-libs
+          done


this is not needed anymore, it was removed in #659

adamruzicka · 2026-07-30T08:22:23Z

+  - content/rpm
+  - remote-execution
+  - rh-cloud
+  - theme-satellite


since #694 is already in

Suggested change

- theme-satellite

- theme-satellite

- webhooks

evgeni · 2026-07-31T10:10:17Z

@zjhuntin do you have time to further work on this? Or do you need any help?
I don't think this needs to be in perfect final form, but having a satellite flavor defined would allow us to continue working on the details in follow ups as those details emerge.

pr-processor Bot added the Not yet reviewed label Jul 7, 2026

zjhuntin force-pushed the satellite-flavor branch from 2d6d362 to cd76c02 Compare July 7, 2026 13:43

evgeni reviewed Jul 7, 2026

View reviewed changes

Comment thread src/vars/flavors/satellite.yml Outdated

pr-processor Bot removed the Not yet reviewed label Jul 7, 2026

evgeni reviewed Jul 7, 2026

View reviewed changes

Comment thread src/vars/flavors/satellite.yml Outdated

Gauravtalreja1 reviewed Jul 7, 2026

View reviewed changes

zjhuntin force-pushed the satellite-flavor branch 4 times, most recently from 91b2b95 to 08d9a70 Compare July 7, 2026 15:50

evgeni reviewed Jul 7, 2026

View reviewed changes

zjhuntin marked this pull request as ready for review July 8, 2026 14:53

pr-processor Bot added the Waiting on contributor label Jul 8, 2026

zjhuntin force-pushed the satellite-flavor branch from 08d9a70 to 93e0c81 Compare July 8, 2026 15:03

pr-processor Bot added Needs re-review and removed Waiting on contributor Needs re-review labels Jul 8, 2026

zjhuntin force-pushed the satellite-flavor branch from c15c197 to 93e0c81 Compare July 10, 2026 05:19

zjhuntin mentioned this pull request Jul 10, 2026

Add foreman_theme_satellite to foreman image plugins theforeman/foreman-oci-images#63

Closed

evgeni mentioned this pull request Jul 10, 2026

Refactor post_install role #641

Merged

2 tasks

zjhuntin force-pushed the satellite-flavor branch from fb0c9de to 1bfdd46 Compare July 12, 2026 19:05

zjhuntin force-pushed the satellite-flavor branch from 1bfdd46 to a7a7cb5 Compare July 20, 2026 20:30

adamruzicka reviewed Jul 22, 2026

View reviewed changes

evgeni mentioned this pull request Jul 23, 2026

Fix rex_pub_key retrieval for containerized Satellite SatelliteQE/robottelo#22139

Merged

ekohl reviewed Jul 27, 2026

View reviewed changes

Comment thread src/features.yaml

evgeni reviewed Jul 27, 2026

View reviewed changes

zjhuntin and others added 3 commits July 27, 2026 16:11

Add satellite flavor for downstream deployments

ef16c4d

The satellite flavor provides a feature set matching what RPM-based Satellite ships by default, enabling proper downstream test coverage with foremanctl. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Add theme-satellite feature definition

fc2d3b5

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

zjhuntin force-pushed the satellite-flavor branch from a7a7cb5 to 06e8f42 Compare July 27, 2026 20:12

Show post-install message for satellite flavor

7e05f73

The post_install refactor in theforeman#641 gated the credentials message on flavor == katello. The satellite flavor deploys the same Foreman stack and needs the same message. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

zjhuntin force-pushed the satellite-flavor branch from 06e8f42 to 7e05f73 Compare July 27, 2026 20:13

evgeni reviewed Jul 28, 2026

View reviewed changes

adamruzicka reviewed Jul 30, 2026

View reviewed changes

Uh oh!

Conversation

zjhuntin commented Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Details

Test plan

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Gauravtalreja1 Jul 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

zjhuntin commented Jul 7, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ekohl commented Jul 9, 2026

Uh oh!

zjhuntin commented Jul 10, 2026

Uh oh!

zjhuntin commented Jul 10, 2026

Uh oh!

zjhuntin commented Jul 10, 2026

Uh oh!

arvind4501 commented Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zjhuntin commented Jul 12, 2026

Uh oh!

zjhuntin commented Jul 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zjhuntin commented Jul 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

evgeni commented Jul 27, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

evgeni commented Jul 31, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

zjhuntin commented Jul 7, 2026 •

edited

Loading

Gauravtalreja1 Jul 8, 2026 •

edited

Loading

arvind4501 commented Jul 10, 2026 •

edited

Loading

zjhuntin commented Jul 20, 2026 •

edited

Loading