🐛 allow arbitrary config fields when calculating config hash #243
Conversation
haoqing0110
force-pushed
the
br_empty-spec
branch
2 times, most recently
from
13125cf
to
1c0fb7a
Compare
|
/assign @qiujian16 |
pkg/utils/helpers.go
Outdated
| func GetSpecHash(obj *unstructured.Unstructured) (string, error) { | ||
| if obj == nil { | ||
| return "", fmt.Errorf("object is nil") | ||
| } | ||
| spec, ok := obj.Object["spec"] | ||
| if !ok { | ||
| return "", fmt.Errorf("object has no spec field") | ||
| // handle cases like secret and configmaps | ||
| spec = obj.Object["data"] |
There was a problem hiding this comment.
what if an API that does not have data field and spec field?
There was a problem hiding this comment.
var spec will be nil and return a hash like case .For example, if a configmap removed data field, hash will update and trigger an upgrade.
There was a problem hiding this comment.
how about we remove status and metadata part and hash?
There was a problem hiding this comment.
Yes, sounds better. Have modified the code.
Signed-off-by: haoqing0110 <qhao@redhat.com>
haoqing0110
changed the title
haoqing0110
changed the title
haoqing0110
force-pushed
the
br_empty-spec
branch
from
e6cd3e1
to
1dceac9
Compare
| if err != nil { | ||
| return "", err | ||
| } | ||
|
|
||
| hash := sha256.Sum256(specBytes) | ||
| hash := sha256.Sum256(configBytes) |
There was a problem hiding this comment.
May be a fast non-cryptographic is good enough here?
https://github.com/zeebo/xxh3
There was a problem hiding this comment.
This seems to have better performance, but might not be suitable for the addon case, for example, a cluster-scoped config hash will be exposed to cma, mca and work, and might be cracked by an unexpected namespace-level user.
pkg/utils/helpers.go
Outdated
|
|
||
| specBytes, err := json.Marshal(spec) | ||
| // remove non config related fields, the remaining filed should be spec, data, other use defined fields or even empty | ||
| delete(obj.Object, "apiVersion") |
There was a problem hiding this comment.
This will modify the input object. Is that going to cause any unintended issue? May be a better choice is to perform a shallow copy into a new map and use that calculate hash?
cp := map[string]any{}
for k, v := range obj.Object {
switch k: {
case "apiVersion", "kind", "metadata", "status":
default:
cp[k] = v
}
}
There was a problem hiding this comment.
Thanks for raising this, have modified the code.
Signed-off-by: haoqing0110 <qhao@redhat.com>
haoqing0110
force-pushed
the
br_empty-spec
branch
from
1dceac9
to
1eb68cd
Compare
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: haoqing0110, qiujian16 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-merge-bot
bot
merged commit 974d337
into
open-cluster-management-io:main
…uster-management-io#243) * allow data field and empty field when calculating config hash Signed-off-by: haoqing0110 <qhao@redhat.com> * hash config fields Signed-off-by: haoqing0110 <qhao@redhat.com> --------- Signed-off-by: haoqing0110 <qhao@redhat.com>
…uster-management-io#243) * allow data field and empty field when calculating config hash Signed-off-by: haoqing0110 <qhao@redhat.com> * hash config fields Signed-off-by: haoqing0110 <qhao@redhat.com> --------- Signed-off-by: haoqing0110 <qhao@redhat.com> Signed-off-by: Jian Qiu <jqiu@redhat.com>
…uster-management-io#243) * allow data field and empty field when calculating config hash Signed-off-by: haoqing0110 <qhao@redhat.com> * hash config fields Signed-off-by: haoqing0110 <qhao@redhat.com> --------- Signed-off-by: haoqing0110 <qhao@redhat.com> Signed-off-by: Jian Qiu <jqiu@redhat.com>
…uster-management-io#243) * allow data field and empty field when calculating config hash Signed-off-by: haoqing0110 <qhao@redhat.com> * hash config fields Signed-off-by: haoqing0110 <qhao@redhat.com> --------- Signed-off-by: haoqing0110 <qhao@redhat.com> Signed-off-by: Jian Qiu <jqiu@redhat.com>
…uster-management-io#243) * allow data field and empty field when calculating config hash Signed-off-by: haoqing0110 <qhao@redhat.com> * hash config fields Signed-off-by: haoqing0110 <qhao@redhat.com> --------- Signed-off-by: haoqing0110 <qhao@redhat.com> Signed-off-by: Jian Qiu <jqiu@redhat.com>
…uster-management-io#243) * allow data field and empty field when calculating config hash Signed-off-by: haoqing0110 <qhao@redhat.com> * hash config fields Signed-off-by: haoqing0110 <qhao@redhat.com> --------- Signed-off-by: haoqing0110 <qhao@redhat.com> Signed-off-by: Jian Qiu <jqiu@redhat.com>
…259) * allow data field and empty field when calculating config hash * hash config fields --------- Signed-off-by: haoqing0110 <qhao@redhat.com> Signed-off-by: Jian Qiu <jqiu@redhat.com> Co-authored-by: Qing Hao <qhao@redhat.com>
Fix open-cluster-management-io/ocm#364 #237