Skip to content

Conversation

@JoelSpeed
Copy link
Contributor

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-provider flag should be set to external has been simplified to a case of, which platform are we on.
Additionally the --cloud-config flag 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.

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.
@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Feb 29, 2024
@openshift-ci-robot
Copy link
Contributor

openshift-ci-robot commented Feb 29, 2024

@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:

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-provider flag should be set to external has been simplified to a case of, which platform are we on.
Additionally the --cloud-config flag 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.

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.

Copy link
Contributor

@cdoern cdoern left a 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?

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Feb 29, 2024
@JoelSpeed
Copy link
Contributor Author

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 JoelSpeed changed the title OCPCLOUD-2514: Remove reliance on feature gates for cloud provider flags OCPCLOUD-2514,OCPCLOUD-2516: Remove reliance on feature gates for cloud provider flags Mar 1, 2024
@openshift-ci-robot
Copy link
Contributor

openshift-ci-robot commented Mar 1, 2024

@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:

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-provider flag should be set to external has been simplified to a case of, which platform are we on.
Additionally the --cloud-config flag 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.

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.

Copy link
Contributor

@yuqi-zhang yuqi-zhang left a 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re: containerruntimeconfigcontroller specifically, I know @QiWang19 has been working on #4160 as a FG'ed feature. Would that conflict at all?

Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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?

Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Member

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
Copy link
Contributor

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)

Copy link
Contributor

@yuqi-zhang yuqi-zhang left a 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

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Mar 11, 2024
}
role := pool.Name
// Generate the original ContainerRuntimeConfig
originalStorageIgn, _, _, err := generateOriginalContainerRuntimeConfigs(templateDir, controllerConfig, role, featureGateAccess)
Copy link
Contributor

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)
Copy link
Contributor

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

@openshift-ci-robot
Copy link
Contributor

/retest-required

Remaining retests: 0 against base HEAD da2a7ae and 2 for PR HEAD 4680a9c in total

@openshift-ci openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Mar 11, 2024
@QiWang19
Copy link
Member

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
Copy link
Contributor

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

@JoelSpeed
Copy link
Contributor Author

@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

Copy link
Member

@damdo damdo left a 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

Copy link
Contributor

@elmiko elmiko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Mar 12, 2024
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Mar 12, 2024

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@JoelSpeed
Copy link
Contributor Author

/test e2e-hypershift

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Mar 12, 2024

@JoelSpeed: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/okd-scos-e2e-aws-ovn c1553d7 link false /test okd-scos-e2e-aws-ovn

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.

@openshift-merge-bot openshift-merge-bot bot merged commit 562ef07 into openshift:master Mar 12, 2024
@QiWang19
Copy link
Member

@JoelSpeed Thanks for your consideration.

@openshift-bot
Copy link
Contributor

[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.
All builds following this will include this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants