-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Resources with tracking method annotation incorrectly marked as out-of-sync/requires pruning #8683
Comments
When we introduced this feature, we intended it to handle the case where some parent resource created a child resource but:
I think there might be two cases we need to consider:
I think to fix this, we need to create an artificial parent-child relationship using the tracking-id reference, similar to what we do with Service->Endpoints, PVC->PV. Then in your example, the |
BTW, correct me if I'm wrong, but I think the annotation tracking method is no worse than the instance label method. But now that we have sufficient metadata in the annotation, we actually can do better about creating artificial parent/child relationships than the instance label. In fact, I thought that was the entire point about incorporating the kind/namespace/name into the annotation. |
This is actually what the reproduction steps do (e.g. a new resource that does not have ownerReferences and carries copy of another resource's annotations). |
Yes, this is the case.
I'm not sure whether we should do that, because it could lead to some kind of loop hole. E.g. user with permissions to update a certain resource (e.g. to add some annotations) could now implicitly delete this resource through Argo CD. |
I share the same concern about the loophole. The same loophole would potentially already exist with our instance label tracking. However, I seem to recall that we have some protection mechanism that excludes resources that are impossible to be part of the application (e.g. in a namespace outside of the project boundaries) |
So this issue comes down to the following question: What should we do when we encounter a resource with our annotation-based tracking label, but that tracking label is not self-referential (it's pointing to some parent resource instead of itself)? Here are some options/proposals.
metadata:
annotations:
argocd.argoproj.io/compare-options: IgnoreExtraneous
argocd.argoproj.io/sync-options: Prune=false In general, I do not think we should be considering objects to be pruned, if it has our tracking annotation and the value is not self-referential. Because it is pretty obvious that the resource was automatically created, and not a managed resource from git. |
Thanks for your insight, @jessesuen. I'm also not in favor of option 1 and think the object should be somehow displayed to the user. The major use case for me is when an Operator creates resources and copies all labels and annotations from its Operand onto the resources it creates. So if you manage the Operand via Argo CD, and the Operator creates a ConfigMap during reconciliation, that ConfigMap will carry the same labels and annotations as the Operand, including Argo CD's tracking labels. Now, not all Operators create So I'm in favor of a combination of option 2 and 3 above:
I would also be fine to first go for the simple approach (e.g. displaying it as top-level resource) and if there's demand, we can see how to establish parent/child relationship from the UI's point of view. WDYT? |
I agree. I think showing it as a top-level resource is probably the most accurate and least surprising behavior. Option 2 (showing it as a child) might give a false impression that there is an ownership reference when there really is not. So my preference is for option 3 (top-level extraneous resource that will not be pruned or diffed). Perhaps in the future, we might have a UI option/toggle to delineate between resources that are true owners of child objects, and ones that are pseudo-children by virtue of labels/annotations carried over to offshoots. Sounds like we have a consensus about how to fix the issue. This bug/feature has become important to us since it affects our Crossplane UX, so I will prioritize fixing this for the next Argo CD release unless someone gets to it first. |
Maybe those "pseudo-children" could be displayed slightly different? Dotted borders, another background color, anything like that? |
Fix for this issue: #9791 |
I have a question.
|
The fix doesn't seem to work in v2.4.8. Here is a repo which can reproduce the issue: |
Video proof: Screen.Recording.2022-08-03.at.5.43.43.PM.mov |
I have found the bug and fixed it. Will write some e2e test around it and then submit a PR. |
In order to fix this, first argoproj/gitops-engine#436 should be merged. Then, I'll update #10198 to include new changes from gitops-engine. After that, we can cherry-pick both changes into their appropriate release branches. |
@ralf-cestusio Just as a heads-up, the upcoming v2.4.9 release will contain a proper fix for the pruning bug. |
Yes i saw the fix. Thank you for this really quick resolution! |
From an operator and user viewpoint, this is more confusing. We would have preferred the non-selfreferencing resource is shown as pseudo-child. When we see a top-level resource we expect that this resource is defined in the application source, but the copied resource is basically not. A pseudo-child relationship would have made it more clear, e.g. from which secret a copied secret originates. Which would be similar to the wanted behavior of #5082, so parent-child relationships are not strictly ownership references anymore. |
The distinction can be made from the sync status - a resource not existing in Git does not have a sync status, and the corresponding icon is also not displayed. I agree that rendering a parent/child relationship would be better, though. I think that we can use the resource that is fully qualified in the annotation to map to the "parent", but I need to think this through for a while. |
As an external operator which supports whole corporate teams with lesser experience, the distinction of the sync status on a top-level resource is not so obvious for most of the teams. They wouldn't expect a top-level resource to be non-synced resource at first look, and a small icon missing is not very clear from UX/accessibility standpoint vs. a clear parent-child relationship. A clear pseudo parent-child relationship will not raise the "what is wrong with my deployment, where does this resource come from, what do I need to with this, how do I handle this" questions I got. While a parent-child relationship is what it is: a resource they to not care about it explicitly. Maybe top-level non-synced resource vs. pseudo parent-child relationship can be configured as feature flag via |
Please feel free to open an enhancement request for this. |
Checklist:
argocd version
.Describe the bug
One of the goals of using annotations for resource tracking is, that the resource should only be considered managed if the values of the annotation match the properties of the resource. However, this does not seem to be the case.
To Reproduce
application.resourceTrackingMethod
toannotation
kustomize-guestbook
fromhttps://github.com/argoproj/argocd-example-apps
, with a target namespace ofguestbook
guestbook
, for example aConfigMap
:Expected behavior
The resource should be ignored because the properties of the resource don't match the values in the annotation. The resource should not be considered to be managed by Argo CD, and neither marked out of sync nor for be marked for pruning.
Screenshots
Version
Latest HEAD as of the time of issue creation:
Logs
The text was updated successfully, but these errors were encountered: