USHIFT-6178 Enable Custom FeatureGates#5723
USHIFT-6178 Enable Custom FeatureGates#5723openshift-merge-bot[bot] merged 14 commits intoopenshift:mainfrom
Conversation
pkg/controllers/kube-apiserver.go
Outdated
| hardcodedFeatureGates := []string{"UserNamespacesSupport=true", "UserNamespacesPodSecurityStandards=true"} | ||
| featureGateArgs = append(featureGateArgs, hardcodedFeatureGates...) |
There was a problem hiding this comment.
Could we have a conflict here? Configuration allows disabling UserNamespacesSupport and UserNamespacesPodSecurityStandards.
There was a problem hiding this comment.
This is now protected against by preventing the user to specify these values in the ushift config.
| }, | ||
| { |
There was a problem hiding this comment.
| }, | |
| { | |
| }, | |
| { | |
| name: "feature-gates-custom-no-upgrade-with-empty-enabled-and-disabled-lists", | |
| config: func() *Config { | |
| c := mkDefaultConfig() | |
| c.ApiServer.FeatureGates.FeatureSet = "CustomNoUpgrade" | |
| c.ApiServer.FeatureGates.CustomNoUpgrade.Enabled = []string{} | |
| c.ApiServer.FeatureGates.CustomNoUpgrade.Disabled = []string{} | |
| return c | |
| }(), | |
| expectErr: true, | |
| }, | |
| { |
adding a test for the suggestion check I added last week
There was a problem hiding this comment.
@agullon Thanks! For the sake of time, would you mind submitting this as a follow-up PR? Else CI will have to test the change, and then retest again for merge, which would take a long time.
| maxFiles: 10 | ||
| # profile is the OpenShift profile specifying a specific logging policy | ||
| profile: Default | ||
| featureGates: |
There was a problem hiding this comment.
I started wondering - if FGs are propagated, but someone would want to apply kubelet FG, should we move it out of apiServer and make it global to avoid confusion?
There was a problem hiding this comment.
That's a very good point. I had shifted FGs under kube-apiserver to smooth the passthrough logic, but it doesn't solve the problem you rightly pointe out. I'll give this a second look and get back to you
There was a problem hiding this comment.
Enabling a kubelet FG on the kube-apiserver and disabling it in the kubelet config results in the FG being disabled. This is b/c the kubelet goes against convention by prioritizing the config file over all other config vectors (CLI flags, KAS propagation).
This is only an issue if the user were to set contradictory featureGate values in the microshift config.
copejon
left a comment
There was a problem hiding this comment.
Darn it, I thought I'd made the comment as a one off, not a review.
This commit introduces a comprehensive document detailing the data flow of the API server configuration, tracing the path from the `apiServer` field in the MicroShift configuration file to its ingestion by the kube-apiserver. It includes a UML sequence diagram illustrating the configuration steps, key data structures, and the transformation of configuration values into command-line flags. Additionally, it updates the configuration structure to support feature gates, enhancing the API server's customization capabilities.
… as invalide Setting `featureSet: CustomNoUpgrade` with empty enabled/disabled lists should be invalid. Otherwise, the supposedly valid custom setting would cause a supported cluster to treat itself as unsupported: blocking FG unsetting and cluster upgrades. Co-authored-by: Alejandro Gullón <agullon@redhat.com>
…ble valudation replaced array prims with set.Sets for cleaner array comparisson added validation for edge case where user attempts to set required feature-gates. It is no longer allowed fixed critical issue with lock file management that caused deletion of custom configs to skip lock file checks
…readability refactored featureGateLockManagement() by moving hasCustomFeatureGates to after the lockFile-exists check because if the lock exists, it by default has / had custom featureGates.
|
/test ocp-full-conformance-serial-rhel-eus |
|
@copejon: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: copejon, pacevedom The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/verified by @copejon, ci |
|
@copejon: This PR has been marked as verified by DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
No description provided.