You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
featuregates: process gates after version is read from payload
Because of [OCPBUGS-30080](https://issues.redhat.com/browse/OCPBUGS-30080), we cannot easily determine running CVO version by a single `os.Getenv()`, like other operators can. CVO can determine its version from the initial payload it loads from disk though, but this happens a bit later in the code flow, after leadership lease is acquired and all informers are started. At that point we can provide the feature gate / featureset knowledge to the structures that need it: actual CVO controller and the feature changestopper, but these structures also need to be initialized earlier (they require informers which are already started). This leads to a slightly awkard delayed initialization scheme, where the controller structures are initialized early and populated with early content like informers etc. Later, when informers are started and CVO loads its initial payload, we can extract the version from it and use it to populate the feature gate in the controller structures. Because enabled feature gates are avaiable later in the flow, it also means part of the CVO code cannot be gated by a feature gate (like controller initialization, or initial payload loading). We do not need that now but it may cause issues later.
The high-level sequence after this commit looks like this:
1. Initialize CVO and ChangeStopper controller structures with informers they need, and populate CVO's `enabledFeatureGate` checker with one panics when used (no code can check for gates before we know them)
2. Acquire lease and start the informers
3. Fetch a FeatureGate resource from the cluster (using an informer) and determine the FeatureSet from it (needed to load the payload)
4. Load the initial payload from disk and extract the version from it
5. Use the version to determine the enabled feature gates from the FeatureGate resource
6. Populate the CVO and ChangeStopper controller structures with the newly discovered feature gates
Copy file name to clipboardExpand all lines: install/0000_00_cluster-version-operator_03_deployment.yaml
+1Lines changed: 1 addition & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -56,6 +56,7 @@ spec:
56
56
name: kube-api-access
57
57
readOnly: true
58
58
env:
59
+
# Unfortunately the placeholder is not replaced, reported as OCPBUGS-30080
59
60
- name: OPERATOR_IMAGE_VERSION
60
61
value: "0.0.1-snapshot"
61
62
- name: KUBERNETES_SERVICE_PORT # allows CVO to communicate with apiserver directly on same host. Is substituted with port from infrastructures.status.apiServerInternalURL if available.
0 commit comments