-
Notifications
You must be signed in to change notification settings - Fork 461
OCPCLOUD-2514,OCPCLOUD-2516: Remove reliance on feature gates for cloud provider flags #4228
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OCPCLOUD-2514,OCPCLOUD-2516: Remove reliance on feature gates for cloud provider flags #4228
Conversation
In 4.15, the final CCM was promoted to out of tree, therefore this flag has been set to the empty string for all 4.15 kubelets. We no longer need to set the flag at all, under any condition.
|
@JoelSpeed: This pull request references OCPCLOUD-2514 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set. In 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. |
cdoern
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good but:
The latter part of this may need to be reverted in the future if templates regain a need for feature gates, but in theory it should be pretty easy to plumb back through by reverting the commit.
concerns me a bit. I know we put a lot of this plumbing around the MCC for the MCN featuregate. Is there any benefit to leaving this stuff in since we are adding some features behind FG in 4.16?
I deliberately put this as a separate commit as I wasn't sure if you'd want this unwound or not. Currently, there's nothing within the template controller that requires feature gates, so the PR cleans up the unused variables. I can however revert this last commit and the code still compiles, let me know which you'd prefer, to keep the plumbing or clean it up. Are you aware of any of the TP features needing to use the template controller? |
|
@JoelSpeed: This pull request references OCPCLOUD-2514 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set. This pull request references OCPCLOUD-2516 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set. In 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. |
yuqi-zhang
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be safe, one question on the containerruntimeconfigcontroller inline
| clusterVersionLister cligolistersv1.ClusterVersionLister | ||
| clusterVersionListerSynced cache.InformerSynced | ||
|
|
||
| featureGateAccess featuregates.FeatureGateAccess |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, it's a conflict, #4160 relies on this field to check if the API that containerruntime config watching for is featuregate enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you want to handle this then? I can drop the specific CRC parts, drop the whole commit, or Qi can handle the conflict if this merges first. Any preference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have strong feelings here, @QiWang19 what would work for you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we drop the specific CRC parts from this PR? so we don't have to have separate PR deleting and adding the same lines of code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reviewed the other PR and updated the unwinding here to not conflict, I've still removed from generateOriginalContainerRuntimeConfigs but as far as I can tell that shouldn't conflict with your PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JoelSpeed Thanks
| *mcfgv1.ControllerConfigSpec | ||
| PullSecret string | ||
| InternalRegistryPullSecret string | ||
| FeatureGateAccess featuregates.FeatureGateAccess |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the template/render controller controls any FG'ed items and there shouldn't be any plans to immediately, so I'm fine with this (but please correct me if I'm missing something)
1ae2c05 to
4680a9c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
updated changes look good, thanks! There's 2 minor verify failures that need to be fixed
| } | ||
| role := pool.Name | ||
| // Generate the original ContainerRuntimeConfig | ||
| originalStorageIgn, _, _, err := generateOriginalContainerRuntimeConfigs(templateDir, controllerConfig, role, featureGateAccess) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
verify is complaining that the function header still has featuregate being passed in
| ) | ||
|
|
||
| // Generate the original registries config | ||
| _, originalRegistriesIgn, originalPolicyIgn, err := generateOriginalContainerRuntimeConfigs(templateDir, controllerConfig, role, featureGateAccess) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same for the registriesConfigIgnition function
24fb177 to
adbd27b
Compare
|
For adbd27b, I can handle the conflict when after this merged. |
| func registriesConfigIgnition(templateDir string, controllerConfig *mcfgv1.ControllerConfig, role, releaseImage string, | ||
| insecureRegs, registriesBlocked, policyBlocked, allowedRegs, searchRegs []string, | ||
| icspRules []*apioperatorsv1alpha1.ImageContentSourcePolicy, idmsRules []*apicfgv1.ImageDigestMirrorSet, itmsRules []*apicfgv1.ImageTagMirrorSet, featureGateAccess featuregates.FeatureGateAccess) (*ign3types.Config, error) { | ||
| icspRules []*apioperatorsv1alpha1.ImageContentSourcePolicy, idmsRules []*apicfgv1.ImageDigestMirrorSet, itmsRules []*apicfgv1.ImageTagMirrorSet, featureGateAccess featuregates.FeatureGateAccess) (*ign3types.Config, error) { //nolint:revive |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now this is complaining about Category: unparam instead
Since Qi is fine with resolving conflicts, maybe it's easier to remove them. I'm fine either way
adbd27b to
c1553d7
Compare
|
@yuqi-zhang @QiWang19 I've got the nolint directive working, so Qi if you could unwind the nolint in your PR, that would be appreciated |
damdo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re-adding LGTM after lint fix
/lgtm
elmiko
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cdoern, damdo, elmiko, JoelSpeed, yuqi-zhang The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/test e2e-hypershift |
|
@JoelSpeed: The following test failed, say
Full PR test history. Your PR dashboard. 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 kubernetes/test-infra repository. I understand the commands that are listed here. |
|
@JoelSpeed Thanks for your consideration. |
|
[ART PR BUILD NOTIFIER] This PR has been included in build ose-machine-config-operator-container-v4.16.0-202403122214.p0.g562ef07.assembly.stream.el8 for distgit ose-machine-config-operator. |
In 4.15 the final feature gates were promoted for the CCMs, all in-tree code is now disabled and the decision as to whether the
--cloud-providerflag should be set to external has been simplified to a case of, which platform are we on.Additionally the
--cloud-configflag is no longer required at all.This PR removes the reliance on the feature gate, removes the cloud config flag and then removes a bunch of feature gates being passed around where they aren't needed.
The latter part of this may need to be reverted in the future if templates regain a need for feature gates, but in theory it should be pretty easy to plumb back through by reverting the commit.