[INCOMPLETE] Introduce plain foreman-proxy flavor#527
Conversation
This sets up a directory structure where an entire directory gets a feature mark. This makes it easy to skip entire feature tests.
This guards it behind the feature flag, allowing the tests to be skipped if the feature is disabled. For example, on a standalone foreman-proxy.
This moves Candlepin and Pulp behind the feature flags. Candlepin is only deployed on Foreman with Katello servers while Pulp is deployed on Katello enabled servers.
This makes it easier to exclude them from tests.
The tests still run which needs to be addressed.
| @@ -0,0 +1,3 @@ | |||
| --- | |||
| flavor_features: | |||
| - foreman-proxy | |||
There was a problem hiding this comment.
Should this also include pulp(in mirrror mode) as part of flavor defaults?
There was a problem hiding this comment.
Looking at https://github.com/theforeman/foremanctl/pull/527/changes#diff-2fc200de05abc2d83ea118cae7634c213de69b3e8640146a18644935bfce14f2R78-R80 , pulp does not seems to be deployed in proxy flavor
There was a problem hiding this comment.
I interpreted plain foreman-proxy as a vanilla Foreman without Katello.
There was a problem hiding this comment.
ah okay, i misinterpreted it as foreman-proxy-content
There was a problem hiding this comment.
Even though we don't have it today, my goal here was to really isolate each sub-system and only test the relevant bits.
There was a problem hiding this comment.
Yes, I was exploring cases where our current test stategy(test enabled features) could fail, and one of the thing i came across is katello, katello itself is a feature which contains both pulp and candlepin, but in case of foreman-proxy-content, we need pulp not candlepin and in that scenario we need to isolate pulp and candlepin
There was a problem hiding this comment.
I interpreted plain foreman-proxy as a vanilla Foreman without Katello.
By plain do you mean standalone? i thought it as only proxy is deployed on a machine not foreman + proxy
| - "'redis' in enabled_features" | ||
| - role: candlepin | ||
| when: | ||
| - "'foreman' in enabled_features" |
There was a problem hiding this comment.
| - "'foreman' in enabled_features" |
Does not katello make sure foreman feature alredy exist? i can't think of a scenario where katello exist without foreman
There was a problem hiding this comment.
Then how do you want to make sure that candlepin isn't deployed on the proxy machine?
There was a problem hiding this comment.
I think, for plain foreman and foreman-proxy(without content), we can say skip pulp and candlepin roles if katello is not in enabled_features
There was a problem hiding this comment.
Does not katello make sure foreman feature alredy exist? i can't think of a scenario where katello exist without foreman
What I had in mind was that katello is the content feature. On a machine with foreman it also deploys candlepin. On a machine without foreman it just deploys pulp (in mirror mode). That's why both foreman and katello are listed. Also note that pulp is only gated on katello being enabled.
There was a problem hiding this comment.
On a machine without foreman it just deploys pulp (in mirror mode)
i did not think about that, what if we deploy a standalone foreman-proxy(without content), which neither has foreman and katello? i think we did not had a particular scenario for this case in foreman-installer too, but a hack to do this https://docs.theforeman.org/nightly/Installing_Proxy/index-foreman-el.html#installing-a-smart-proxy-server
There was a problem hiding this comment.
i think we did not had a particular scenario for this case in foreman-installer too, but a hack to do this https://docs.theforeman.org/nightly/Installing_Proxy/index-foreman-el.html#installing-a-smart-proxy-server
Correct, we never completed theforeman/foreman-installer#262 but I can see use cases for it. We've had questions about a Remote Execution-only Foreman Proxy, without all of the content.
| - postgresql_databases | length > 0 | ||
| - role: redis | ||
| when: | ||
| - "'redis' in enabled_features" |
There was a problem hiding this comment.
I think, This will always be false as internal features are not included in enabled_features , thus CI breaks at dynflow containers
There was a problem hiding this comment.
its calculated as flavor_features + features and both does not contain redis until we do --add-feature redis
There was a problem hiding this comment.
That's why it's marked as INCOMPLETE. This is very much in the idea phase.
There was a problem hiding this comment.
Ok, i just wanted to get to the reason of test failures on the pr and how can that effect current tests markers, so i can then look for new apporch, but yeah
| - postgresql_databases | length > 0 | ||
| - role: redis | ||
| when: | ||
| - "'redis' in enabled_features" |
There was a problem hiding this comment.
IMHO this should use the role attribute of our feature metadata, not some weird when in construct.
| - "'redis' in enabled_features" | ||
| - role: candlepin | ||
| when: | ||
| - "'foreman' in enabled_features" |
There was a problem hiding this comment.
IMHO this should use the role attribute of our feature metadata, not some weird when in construct.
3 participants
Why are you introducing these changes? (Problem description, related links)
This introduces a foreman-proxy flavor so it's easy for users to deploy this. It explores the problem space, but is nowhere complete.
I'm sharing this now for visibility and hope others can take lessons from it.
What are the changes introduced in this pull request?
How to test this pull request
Steps to reproduce:
Checklist