-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Update Strategy only when workload changes in ManifestWork #133
New Update Strategy only when workload changes in ManifestWork #133
Conversation
Signed-off-by: Jian Qiu <[email protected]>
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 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 |
type ServerSideApplyConfig struct { | ||
... | ||
// IgnoreFields defines a list of json paths in the resource that will not be updated on the spoke. | ||
IgnoreFields []string `json:"ignoreFields,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the IgnoreFields
take effect when OnSpokeChange is NoOverride
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, so when something changes in ignoreFields in the mw, the work-agent will not update resource all the time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still don't quite understand, will IgnoreFields ignore OnSpokeChange? No matter OnSpokeChange is Override or NoOverride, changes on the manifestworks will not updated to the spoke? why do we need the OnSpokeChange
for ServerSideApply
?
when apply the resource to the spoke cluster will add an annotation with the key `open-cluster-management.io/object-hash`. | ||
The value of the annotation is the computed hash of the resource spec in the `ManifestWork`. Later when another actor | ||
updates the resource, the work-agent will at first check if the object-hash mismatches with the current resource spec | ||
in the `ManifestWork`. If it is the same, the resource will not be updated so the change from spoke is ignored. When |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we explain the behavior of "Delete" when OnSpokeChange
is set to NoOverride
here? It seems when the resource is deleted, object-hash is removed and the resource will be applied again?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the resource itself will be deleted, so does the annotation. The annotation will be kept if the deleteOption is Orphan, and in this case, I do not think we need to remove the annotation.
enhancements/sig-architecture/132-work-update-only-when-spec-change/README.md
Outdated
Show resolved
Hide resolved
enhancements/sig-architecture/132-work-update-only-when-spec-change/README.md
Outdated
Show resolved
Hide resolved
enhancements/sig-architecture/132-work-update-only-when-spec-change/README.md
Outdated
Show resolved
Hide resolved
enhancements/sig-architecture/132-work-update-only-when-spec-change/README.md
Outdated
Show resolved
Hide resolved
|
||
In addition, in `ServerSideApplly` strategy, we would also introduce a new `ignoreDifferences` options similar as what | ||
is defined in argoCD (https://argo-cd.readthedocs.io/en/stable/user-guide/diffing/). Such that user can choose to not | ||
let work-agent patch certain resource fields. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will also be able to resolve the zero creationTime in metadata problem, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it could, but it means we will not revert the change on the spoke by another actor.
|
||
```go | ||
type UpdateConfig struct { | ||
// OnSpokeChange defines whether the resource should be overriden by the manifestwork it is changed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// OnSpokeChange defines whether the resource should be overriden by the manifestwork it is changed | |
// OnSpokeChange defines whether the resource should be overridden by the manifestwork once it is changed |
type ServerSideApplyConfig struct { | ||
... | ||
// IgnoreFields defines a list of json paths in the resource that will not be updated on the spoke. | ||
IgnoreFields []string `json:"ignoreFields,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still don't quite understand, will IgnoreFields ignore OnSpokeChange? No matter OnSpokeChange is Override or NoOverride, changes on the manifestworks will not updated to the spoke? why do we need the OnSpokeChange
for ServerSideApply
?
< I still don't quite understand, will IgnoreFields ignore OnSpokeChange? No matter OnSpokeChange is Override or NoOverride, changes on the manifestworks will not updated to the spoke? why do we need the OnSpokeChange for ServerSideApply? with OnSpokeChange, the work-agent will still update manifests when the resource in the manifestwork is updated. IgnoreFields makes a finer granularity control on certain fields in the resource, so that even if these fields is changed in manifestwork resource or spoke, the work-agent will not update the resource. |
Signed-off-by: Jian Qiu <[email protected]>
8d590cf
to
c9f8bdf
Compare
Signed-off-by: Jian Qiu <[email protected]>
349a287
to
e0b390b
Compare
/lgtm |
/unhold |
cc9e453
into
open-cluster-management-io:main
fixes #132