As far as I understand the function GetSpecHash is used to generate a hash with the Spec content of a k8s resource. This hash is stored in the status of ManagedClusterAddOn and used by the framework to know if the current state of ManifestWorks is up to date. The problem is that when we use as config resources k8s resources that don't have a Spec field such as ConfigMaps or Secrets.
To Reproduce
Deploy a ManagedClusterAddOn that has in its config a ConfigMap or Secret
Expected behavior
The framework should not discriminate these two resources and it should handle them properly
In response to [this](https://github.com/open-cluster-management-io/addon-framework/issues/237#issuecomment-2003844016):
>/close
>
>this has been fixed
Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
Describe the bug
As far as I understand the function
GetSpecHash
is used to generate a hash with theSpec
content of a k8s resource. This hash is stored in the status of ManagedClusterAddOn and used by the framework to know if the current state of ManifestWorks is up to date. The problem is that when we use as config resources k8s resources that don't have aSpec
field such as ConfigMaps or Secrets.To Reproduce
Deploy a
ManagedClusterAddOn
that has in its config a ConfigMap or SecretExpected behavior
The framework should not discriminate these two resources and it should handle them properly
Additional context
Problem is with https://github.com/open-cluster-management-io/addon-framework/blob/71f1b13cbb6356279d5ae49667324ef5f9b7c3e0/pkg/utils/helpers.go#L354-L371