-
Notifications
You must be signed in to change notification settings - Fork 259
Read featuregates from cluster state #1468
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
Read featuregates from cluster state #1468
Conversation
| c.lock.Lock() | ||
| defer c.lock.Unlock() | ||
|
|
||
| c.observationCount++ |
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.
Does this need to be incremented every time? I guess since this isn't going to happen often you'd expect this number to be small, but I was wondering if the initialFeatureGatesObserved could be the signal, seems there's a duplication right now
if c.observationCount == 0 {
return nil, nil, fmt.Errorf("featureGates not yet observed")
}
This bit for example would be the same as checking if the initial feature gates have been observed.
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.
Does this need to be incremented every time?
Yeah, it might be possible to rewrite on the channel. Let's be sure I get this unified before we merge anything.
| initialFeatureGatesObserved chan struct{} | ||
| featureGatesHaveChangedSinceFirstObserved chan struct{} |
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.
Just trying to clarify why we use channels, IIUC these are being used as signals to other threads, the motivation for these being channels over bools is that you don't need a RWMutex around the values if they are channels?
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.
Just trying to clarify why we use channels, IIUC these are being used as signals to other threads, the motivation for these being channels over bools is that you don't need a RWMutex around the values if they are channels?
Yes it is for signals to other threads. Using channels allows for waiting, which is not as easy with bools. For example, this is easy to make with channels, hard to make reactive with bools.
select{
case <- featureGateAccessor.InitialFeatureGatesObserved():
enabled, disabled, _ := featureGateAccessor.CurrentFeatureGates()
klog.Infof("FeatureGates initialized: enabled=%v disabled=%v", enabled, disabled)
case <- time.After(1*time.Minute):
klog.Errorf("timed out waiting for FeatureGate detection")
return fmt.Errorf("timed out waiting for FeatureGate detection")
}| // possible (probable?) future additions include | ||
| // 1. support level (Stable, ServiceDeliveryOnly, TechPreview, DevPreview) | ||
| // 2. description |
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 like the idea of a support level in here, would give a point for users to observe what features are now on that were before, diffing the historic versions.
Something that is in the list that is Stable would only need to be included for 1 release right? As once we go to stable we can remove the gating logic once we've gone through the upgrade?
We are going to need some detailed documentation about process and expectations for our engineers around this process I think
| return newConfigValue, nil | ||
| } | ||
|
|
||
| func FeaturesGatesFromFeatureSets(fg *configv1.FeatureGate) ([]string, []string, error) { |
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.
note to self, you still want this for operators that have items on the bootstrap host.
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.
note to self, you still want this for operators that have items on the bootstrap host.
no you won't. They'll update to read the manifest from the installer.
36a15c9 to
654236c
Compare
|
comments addressed, code simplified, unit test added. other than the fake bump, this should be ready. |
654236c to
7cca762
Compare
JoelSpeed
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.
Other than some additional documentation, I think this looks ready to go
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 file is a little light on godoc for the functions, structs and interfaces, I think given we hope many people adopt this, some inline documentation would be helpful. Anything exported should have something so that pkg.go.dev is useful
7cca762 to
d4a93d4
Compare
…gate detection mechanism
d4a93d4 to
19d1252
Compare
|
rebased and comments added. Will open a new PR with proof once openshift/cluster-config-operator#288 merges |
|
@deads2k: 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/test-infra repository. I understand the commands that are listed here. |
|
/lgtm |
|
/hold Will check the proof PR before merge |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: deads2k, JoelSpeed 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 |
|
/hold cancel Proof PR got a successful install and can see logs indicating success in CCO and KCMO |
For openshift/enhancements#1373
Part 2 of a multi-step plan to make individual featuregates observable via the API. This was previously avoided because when featuregates get promoted from TechPreview to Default, during an upgrade, an old operator may try to enable a TechPreview variant of a feature.
This can be addressed by keying the featuregates by version. Let's see how ugly that will be in practice now that we have a decent build-out of library-go.
Unit tests are still owed. Proof is still owed. cluster-config-operator controller is still owed.
/hold
This is proving the concept, not to be merged until it shows as working end-to-end.
Other steps include
/assign @JoelSpeed