Allow kopf.adopt to Communicate Resource Readiness to ArgoCD about kopf HOT 4 CLOSED

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.

from kopf.

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.

from kopf.

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.

from kopf.

To anyone that would need something like that in the future.

code

• Upon creating/updating your resources, update the status of the object handled to a false value or example ready: false + add the adopted resource name for example adopted: best-pvc-everrr.
• Create a @kopf.timer for your resource, add a when and check that ready: false.
• In the timer, get the adopted child resource and reads its status, when his status will show ready: true update your resource to ready: true

Argocd

You can look at ArgoCD documentation

what eventually I did was

data:
  application.resourceTrackingMethod: annotation
  resource.customizations: |
      <API>/<KIND>:
        health.lua: |
          hs = {}
          if obj.status ~= nil then
            if obj.status.conditions ~= nil then
              for i, condition in ipairs(obj.status.conditions) do
                if condition.type == "Ready" and condition.status == "True" then
                  hs.status = "Healthy"
                  hs.message = condition.message
                  return hs
                end
              end
            end
          end
          hs.status = "Progressing"
          hs.message = "Waiting"
          return hs

I'm sure this is not the best health.lua but it does the job.

from kopf.