Allow kopf.adopt to Communicate Resource Readiness to ArgoCD

[isarns]

Keywords

argocd, readiness

Problem

Description:

I am using the kopf.adopt(data) function in a Kopf operator to adopt another resource. However, I am encountering an issue with ArgoCD where it considers the parent resource to be ready even though the child resource is still processing.

Problem:

When kopf.adopt(data) is used to adopt a resource, ArgoCD treats the parent resource as ready before the child resource has completed its processing. This behavior is causing synchronization issues within our deployment pipelines.

Expected Behavior:

I would like to have a way to let ArgoCD know that the parent resource is not ready until the child resource has finished processing. This would ensure that ArgoCD only marks the parent resource as ready when all adopted child resources are fully processed.

Steps to Reproduce:

Use kopf.adopt(data) to adopt a child resource in a Kopf operator.
Deploy the parent resource using ArgoCD.
Observe that ArgoCD marks the parent resource as ready before the child resource has completed processing.

Environment:

Kopf version: 1.36.1
ArgoCD version: v2.9.0
Kubernetes version: 1.28

[nolar]

This bug —if it is a bug— is too specific to a particular third-party operator (ArgoCD in this case). I am not sure if Kopf has anything to do with it or should contain any ArgoCD-specific logic — mainly because there are too many third-party operators to support this way in a rather generic framework (i.e. Kopf).

On the technical side, adopt() does nothing more than just injecting a few keys into the resource's metadata, specifically into metadata.ownerReferences and metadata.labels (docs). As a fallback, you can inject those keys yourselves, but in ArgoCD's "proper way" to prevent the undesired side effects.

Can you please clarify:

• Do you have any details on which injected metadata keys cause this behaviour with ArgoCD?
• If you do kopf.append_owner_reference() instead of kopf.adopt(), does it help to avoid the bug? If so, the issue is likely with the labels propagation, which ArgoCD might misinterpret somehow as the status of the object (which is strange, but possible).
• Could it be ArgoCD's bug that causes it to treat the resource as "ready" when it gets a child/parent? E.g. if you do they same manipulation with kubectl patch CLI.

[isarns]

After reading more into this, I realized that I am missing the status.condition in my Custom Resource Definition (CRD). I believe ArgoCD uses this status to determine if the resource is healthy, progressing, or failed.

Based on my research, this issue seems related to #796 and possibly #514.

1. Injected Metadata Keys: I haven't identified specific metadata keys that cause this behavior with ArgoCD. However, it seems the absence of status.condition is a significant factor in ArgoCD's readiness check.

2. Using kopf.append_owner_reference(): I haven't tried using kopf.append_owner_reference() instead of kopf.adopt(). I will test this and see if it helps avoid the issue. If this resolves the problem, it might indeed indicate an issue with how labels are being propagated and interpreted by ArgoCD.

3. Potential ArgoCD Bug: I don't think so, it's probably the status and the conditions.

Thank you again for your assistance. I will provide an update after further testing.

[isarns]

I tried adding conditions to my CRD status like this:

iso8601utc = datetime.datetime.now(datetime.UTC).isoformat()
ready = [{
    "status": "True",
    "message": "IAM Role for Service Account created successfully",
    "reason": "Successful",
    "type": "Running",
    "lastTransitionTime": iso8601utc
}]
patch.status["conditions"] = ready

However, this did not update the healthy status in ArgoCD. I will follow the guidance provided in the ArgoCD documentation to add a health check.