Guard all deployment roles behind features where possible - #722
Conversation
|
This fails on parsing internal features that have no description. I've added a description to each now because it's the easiest and I like having descriptions. Should the metadata mandate this (implying a docs change) or make the feature parsing more robust? |
| @@ -29,11 +29,19 @@ | |||
| - role: postgresql | |||
There was a problem hiding this comment.
Should this get the same treatment?
There was a problem hiding this comment.
Not sure. In #527 I also tried postgresql_databases | length > 0 as a condition. I'd prefer to tackle that part separate from this because it's a bit more special.
There was a problem hiding this comment.
Let me ask another way. How is postgresql different than valkey? They are both dependencies of Foreman. In the case of a proxy, postgresql is a dependency of container gateway.
There was a problem hiding this comment.
But on a plain Foreman Proxy you don't have it at all. So yes, we can probably track it as dependencies of the right features but I thought the scope of this PR is already non-trivial.
There was a problem hiding this comment.
I think the general idea and changes make sense to me. I just think we might as well treat postgresql the same as the other backend services.
There was a problem hiding this comment.
I'd like to, but your comment makes it sound like you want it in this PR and I'd like to do it as a follow up. Mind if I follow up on it later?
There was a problem hiding this comment.
I suppose I don't, however, I am left feeling like this is an incomplete change without given how other backends like Valkey are handled with this change.
There was a problem hiding this comment.
Perhaps, but I have needed quite a few iterations to get tests to pass correctly. Keep the changes smaller was helpful. But after #726 I'll see how much of this remains.
| @@ -29,11 +29,21 @@ | |||
| - role: postgresql | |||
There was a problem hiding this comment.
Shouldn't this get the same treatment?
|
My previous guess of it failing on missing descriptions was wrong. In some cases it fails to call Passing
|
|
Proxy failed to pull from quay. Is this a more common occurrence? |
First time I have seen it. |
|
2 test failures: This tells me that It would be interesting to write a more dedicated test to check the behavior of foremanctl. This is because the |
2b5919d to
cbbddc2
Compare
|
Rebased now that #722 is in. |
|
This is an interesting failure: I think the |
cbbddc2 to
2e04227
Compare
|
🍏 now |
|
This needs another rebase. |
2e04227 to
996e2a4
Compare
This has no practical difference, but makes it consistent everywhere.
This allows composing the complete deployment and opens the path for a plain Foreman and/or Foreman Proxy.
This makes it easier to exclude them from tests.
996e2a4 to
4b19537
Compare
|
And rebased again |
Why are you introducing these changes? (Problem description, related links)
#511 and #527 both rely on having all roles to be fully disableable. This extracts the changes into their own PR.
What are the changes introduced in this pull request?
In the end, this PR should have no difference for end users. Everything is internal and building up. Each individual commit is designed to be readable and build up to the end goal to align both deployment scenarios as much as possible and prepare for a plain Foreman without actually doing that just yet deployment.
foremanctl featuresto list internal ones. We can debate the implementation, but this was the quickest.role: ...syntax so the later diffs are smaller and easier to readHow to test this pull request
Steps to reproduce:
Checklist