Change:
restclient "k8s.io/client-go/rest" kubeversion "k8s.io/component-base/version" "k8s.io/kubernetes/pkg/api/legacyscheme" <del> "k8s.io/kubernetes/pkg/apis/batch" </del> flowcontrolv1beta2 "k8s.io/kubernetes/pkg/apis/flowcontrol/v1beta2" <del> "k8s.io/kubernetes/pkg/apis/networking" apisstorage "k8s.io/kubernetes/pkg/apis/storage" </del> "k8s.io/kubernetes/pkg/controlplane/reconcilers" "k8s.io/kubernetes/pkg/controlplane/storageversionhashdata" <ins> "k8s.io/kubernetes/pkg/kubeapiserver" </ins> kubeletclient "k8s.io/kubernetes/pkg/kubelet/client" certificatesrest "k8s.io/kubernetes/pkg/registry/certificates/rest" corerest "k8s.io/kubernetes/pkg/registry/core/rest"

Discussion:
Storage version defaults to the preferred version for a given group, but can be overridden when constructing API server storage. This is done here: Reasons the preferred version might be overridden: A given resource/kind does not yet exist in the preferred version (like when introducing a new alpha type in an existing API group with more stable versions) A given resource/kind is continuing to store in etcd in an older version for compatibility with n-1 API servers The etcd integration test verifies that we're actually storing the correct versions in etcd, but the computation of the StorageVersionHash is not honoring the overridden version. on master, this code reports v1 CSIStorageCapacity: even though the etcd test verifies we're still persisting v1beta1 /kind bug /priority important-soon /sig api-machinery cc Originally posted by in
/cc
cc
hi I have found that on points to but here the points to here is screenshot from debug console ! As I am still new to the codebase, I am trying to understand why it is happening so. But we can say that because of this reason, test case below does not failed because the expected hash we put in file matches correctly with the onc we create in at line 404 I also believe that the value corresponding to key has been wrongly put same as Correct values are as follows. One caveat here is, hashes are calculated with appending resource but the key for lookup is based on resource . I hope this information will help in locating the issue. Meanwhile, I will also try to look why in is pointing to even though we override.
/assign
The problem reported by this issue should not exist, on apiserver startup, we can get the right overrided version v1beta1 for the csistoragecapacities from , since the code below overrided the storage version ! But in the test , it did not override the storage version, see the code below so this test case reports v1 CSIStorageCapacity is right. do you think that we should change the testcase to override the storage version again to keep consistent and dispel the confusion for StorageVersionHash ?
Yes you are right. If we add below testcase will surely fail as the hash will not match in this case.

So, we need to update hash in to
ah, good catch... so this is a test-only issue, but still one we need to resolve, so the unit test reflects reality of storage versions when you actually start a kube-apiserver
As this pr would remove the storageversion override so after this pr merged, the testcase would be just right, then we don't need another pr to fix the testcase again, right?
But alteast we should update the correct hash value corresponds to in
the test would still be exercising preferred version ordering without any overrides, which would still be incorrect, and would resurface problems as soon as another override is
/triage accepted