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
controller: sched: detect and use cluster properties
The fix has landed in OCP 4.18, make sure this is reflected to
consume the new default of schedulerInformer in case it is not set by
the user.
Previously the version parsing relied on the assumption that the
platform version is of type stable (e.i 4.19.9, 4.20.2 ..) but this is
incorrect because the cluster may be deployed with different types of
builds and each requires its own processing logic, which must know the
first supported build for each type. Ensure that the different types are
recognized and processed as required.
Design notes:
moved platforminfo in a separate package, still internal.
Previously, it was a private controller helper. Moved into a new packge
mostly because didn't want to pollute controllers with version check.
Added a Properties sub-struct vs add straight into the PlatformInfo
the value. This is debatable. We don't plan to add more properties,
so why to bother? Thing is, I can't remember a time on which I added
a specific flag or field top-level and never regret later on.
At very least we have namespaced properties which is nicer.
I acknowledge the tension between not overcomplicate things, not do
things "just in case" (there is no future expansion on the radar)
but still if we don't namespace things early on, it's harder to
retrofit. So went with this approach this time, but again, is debatable.
The same line of thought lead to implement the version check in a
specific, non-generic way tailor made for this case, exactly because
we don't see more usecases coming so generalizing felt overkill.
The summarization is thus that the **internal** API was made extensible
(even if we don't see extensions happening) because APIs are harder to
change, so "just in case" has more merit here. The implementation, on
the other hand, is simpler to change and addresses only the problem at
hand.
PlatformInfo is heavily overused. Should probably be ClusterInfo.
Co-authored-by: Shereen Haj <[email protected]>
Signed-off-by: Francesco Romani <[email protected]>
(cherry picked from commit b4608c3)
(cherry picked from commit 94371a5)
unfixedVersion, _:=platform.ParseVersion("4.18.0") // can't (and we must not even if we can) rewrite history
772
+
futureFixedVersionZstream, _:=platform.ParseVersion("4.18.26") // we must never regress
773
+
futureFixedVersion, _:=platform.ParseVersion("4.21.0") // we must never regress
770
774
771
-
ginkgo.DescribeTable("should configure by default the informerMode to the expected when field is not set", func(reconcilerPlatInfoPlatformInfo, expectedInformerstring) {
775
+
ginkgo.DescribeTable("should configure by default the informerMode to the expected when field is not set", func(reconcilerPlatInfoplatforminfo.PlatformInfo, expectedInformerstring) {
ginkgo.DescribeTable("should allow to update the informerMode to be Dedicated after an overridden default", func(reconcilerPlatInfoPlatformInfo) {
836
+
ginkgo.DescribeTable("should allow to update the informerMode to be Dedicated after an overridden default", func(reconcilerPlatInfoplatforminfo.PlatformInfo) {
0 commit comments