-
Notifications
You must be signed in to change notification settings - Fork 465
OCPBUGS-13547: [OCPCLOUD-2034] Update Library-go and API for new featuregate changes #3688
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
OCPBUGS-13547: [OCPCLOUD-2034] Update Library-go and API for new featuregate changes #3688
Conversation
|
/test unit |
|
Skipping CI for Draft Pull Request. |
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.
where is this used?
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.
Passed into controllercontext and then passed into the controllers that need it when we call createControllers
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.
This is just for testing? if so, please name it as such.
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.
It's not, in the kubelet feature gate this is used to determine if there is a difference between the default features and the current set of features, only when there is a different is the feature gate kubelet config generated
8cd33cc to
0c56e5d
Compare
|
/test unit |
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.
The controllers depend on the FeatureGate data so we should wait until they are synced before starting the controllers
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.
@deads2k Correct me if I'm wrong, but this has to match the value of version.Raw if it hasn't been substituted by a build time arg? (It currently doesn't, will fix)
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.
You shouldn't be adding resources from other groups to the scheme here, it causes confusion for the decoder (and was breaking/masking issues in tests). The correct thing to fix this is configv1.Install(scheme.Scheme) at some point in the process that was complaining
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.
Installer will now always create a feature gate manifest, the MCO now has to depend on that to make decisions during the bootstrap
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.
Passed into controllercontext and then passed into the controllers that need it when we call createControllers
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.
Some controllers don't use the fgAccess so it's ok for those ones to pass a nil through
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.
Should probably update this at some point to use the new configv1.FeatureGateName instead of a string
pkg/controller/template/render.go
Outdated
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.
Not all render configs will have the FGAccess, assume the featuregates are off in this case (shouldn't actually matter)
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.
These were removed from openshift/api
test/e2e-bootstrap/bootstrap_test.go
Outdated
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.
@deads2k any idea why this doesn't get set on a read?
0c56e5d to
8c032e1
Compare
|
/test bootstrap-unit |
|
Not expecting the e2e to pass until openshift/installer#6990 has merged |
e4ad6a7 to
9efe1b0
Compare
|
/retest-required |
|
So on upgrade, the MCO is logging some logs that may be useful, So the version injected for the MCO image in there does not appear to match the versions in the CVO, I wonder if this is a build time issue for CI jobs 🤔 |
8bb958b to
4a8f22c
Compare
|
To review kubelet-config related changes |
4a8f22c to
aa185fb
Compare
|
Retesting since openshift/installer#7160 has been merged now |
|
/test e2e-hypershift More fixes merged into HyperShift this morning, let's see how this goes |
These both went green now! I'm dropping the @sergiordlr Did you want to test the branch as it is now or wait until config operator is merged? They achieve the same thing so I think testing now should show the features issue we observed on friday is gone |
|
All tech preview jobs are green! |
|
Hypershift is green too! I'll work on getting the config operator change merged, but I think otherwise, once I drop that final commit, this is good to go Anyone got any final reservations? |
cea2567 to
3de0564
Compare
|
Config operator has now merged, so, I've re-pushed what the actual branch should look like without my hack in place, this is ready to merge as far as I'm concerned now |
|
Thanks Joel, good from my end. |
|
Adding lgtm as well, techpreview and MCO tests are passing on the PR. We will get to know later if we we missed something. Thanks Joel for all the hard work! Hold will be removed once qe has added qe-approved label. Since, master branch is not gated on qe laebl, we need to manually do this for pre-merge testing. |
jkyros
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.
Thanks Joel! I can't say enough about how much we appreciate your work here (vs us having to muddle through doing all of this on our own).
Things I feel are important to note here behavior-wise for the MCO team:
- the
machine-config-controllerandmachine-config-operatorwill bothexit 0immediately when feature gates change after the initial observation (this is probably good because it means we don't have to coordinate some sort of "are our operator and controller using the same set of feature gates" sort of thing) - the
machine-config-daemondoes not currently react to feature gates. While the operator/controller/daemon all share that samectrlcommon.CreateControllerContext()that starts the featuregate controller, the daemon never starts the config informer that feeds it (and I don't think the daemon has the RBAC anyway) so it doesn't react to featureGates and won't get interrupted (this is good, right now it doesn't need to)
The MCO probably should at least follow up by:
- migrating to klog and away from glog (rather than mix and match -- I assume klog should be the "winner" because it's better maintained)
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jkyros, JoelSpeed, sinnykumari 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 |
|
/retest-required |
|
Verified using IPI on GCP.
These tests passed after enabling the features:
We add the qe-approved label: /label qe-approved NOTE: We observed that after enabling TechPreviewNoUpgrade the MCO controller pod is restarted and it takes like 3 minutes to acquire the leader lease. Only in that case, if we remove the MCO controller pod the leader lease is acquired immediately. It is not considered a problem though. |
|
QE approved, so can remove the hold now, thanks for your work on this @sergiordlr |
|
/hold cancel |
|
@JoelSpeed: The following tests failed, say
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/test-infra repository. I understand the commands that are listed here. |
|
/retest-required |
|
@JoelSpeed: Jira Issue OCPBUGS-13547: Some pull requests linked via external trackers have merged:
The following pull requests linked via external trackers have not merged:
These pull request must merge or be unlinked from the Jira bug in order for it to move to the next state. Once unlinked, request a bug refresh with Jira Issue OCPBUGS-13547 has not been moved to the MODIFIED state. 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 kubernetes/test-infra repository. |
- What I did
Update library-go and openshift api.
Fixed up the type changes and the access to feature gates to use the new feature gate access defined in library-go.
Note this means feature gate enabled/disabled decisions are now made by CCO and not distributed by revendoring openshift/api everywhere.
Noticed a mistake in the scheme addKnownTypes, see comment I've left.
Details of feature gate changes in openshift/enhancements#1373
- How to verify it
E2E should pass, all units are passing too.
- Description for the changelog