[ansible-operator] Status false when type/reason = Successful

[PYLochou]

Type of question

General operator-related help

Question

What did you do?

I develop an Ansible operator and let it manage its status (and I prefer that way - it will probably manage it better by itself).
However our testers recently complained about the following result:

    {
      "lastTransitionTime": "2023-07-25T07:14:46Z",
      "message": "Last reconciliation succeeded",
      "reason": "Successful",
      "status": "False",
      "type": "Successful"
    }

They would like to see "True" instead of "False" in the status field which would be more coherent with the actual results. (They use some script to check all statuses, my operator being just one amongst many, and wait for True I guess.)

What did you expect to see?

I'd rather expect something like:

    {
      "lastTransitionTime": "2023-07-25T07:14:46Z",
      "message": "Last reconciliation succeeded",
      "reason": "Successful",
      "status": "True",
      "type": "Successful"
    }

but maybe I missed something there.

What did you see instead? Under which circumstances?

We actually see status: False and don't understand why.

Environment

Operator type:

/language ansible

Kubernetes cluster type:

OpenShift

$ operator-sdk version

operator-sdk version: "v1.31.0"

$ kubectl version

Client Version: v1.28.1

Additional context

[OchiengEd]

Hi @PYLochou Would you please provide the the full status for your custom resource you observed the above behavior on? From the operator-sdk code, it seems while reconcile is ongoing, the Running condition would be set to true while the Successful condition would be set to false.

I may need to see all the conditions in the status block to be able to aptly determine if we are looking at a bug.

[PYLochou]

Thank you for the explaination, Edmund. You're right, at this moment there was a reconciliation running:

"conditions": [
    {
      "lastTransitionTime": "2023-07-24T14:02:37Z",
      "message": "",
      "reason": "",
      "status": "False",
      "type": "Failure"
    },
    {
      "lastTransitionTime": "2023-07-25T07:14:46Z",
      "message": "Last reconciliation succeeded",
      "reason": "Successful",
      "status": "False",
      "type": "Successful"
    },
    {
      "lastTransitionTime": "2023-07-24T14:06:40Z",
      "message": "Running reconciliation",
      "reason": "Running",
      "status": "True",
      "type": "Running"
    }
  ]

I'll transmit your explaination to our testers, thank you!

[PYLochou]

Another closely-related issue, if I may...?

On another run (with buggy input in the CR, hence the errors), they got the following conditions:

"conditions": [
    {
      "lastTransitionTime": "2023-07-24T08:59:32Z",
      "message": "",
      "reason": "",
      "status": "False",
      "type": "Successful"
    },
    {
      "ansibleResult": {
        "changed": 0,
        "completion": "2023-07-24T13:23:28.4525",
        "failures": 1,
        "ok": 96,
        "skipped": 68
      },
      "lastTransitionTime": "2023-07-24T13:23:29Z",
      "message": "Could not find the following secrets ['ibm-cp4ba-db-ssl-secret-for-svl']. Create it or them before installing the cloudpak.",
      "reason": "Failed",
      "status": "False",
      "type": "Failure"
    },
    {
      "lastTransitionTime": "2023-07-24T13:23:34Z",
      "message": "Running reconciliation",
      "reason": "Running",
      "status": "True",
      "type": "Running"
    }
  ]

and this time, for the type Failure, they are waiting for status True (which may seem logical), is it again because the reconciliation is running?

[OchiengEd]

Interesting find. So, it seems in the previous reconcile loop, the Failure condition was set to true and failure reason captured. However, on subsequent reconcile, the Failure condition is set to false and the Running condition was set to true.

I think, it is logical argument to leave the Failure condition as previously set since it is accurate as of time of recording. However, when marking the reconcile to be complete / successfully deployed, then the previous error could be reset.

[PYLochou]

Yes, I agree ("it is logical argument to leave the Failure condition as previously set since it is accurate as of time of recording") and remove it when the deployment gets successful. No False status should be set anytime on this one IMHO.

[OchiengEd]

Roger that. I will table this in the next meeting and see if there is consensus to make the change. I may explore creating a PR for this in the interim.

[OchiengEd]

The PR to solve this issue has been moved to the ansible-operator-plugins repository #14

[openshift-ci]

@PYLochou: The label(s) language/ansible cannot be applied, because the repository doesn't have them.

In response to this:

Type of question

General operator-related help

Question

What did you do?

I develop an Ansible operator and let it manage its status (and I prefer that way - it will probably manage it better by itself).
However our testers recently complained about the following result:

   {
     "lastTransitionTime": "2023-07-25T07:14:46Z",
     "message": "Last reconciliation succeeded",
     "reason": "Successful",
     "status": "False",
     "type": "Successful"
   }

They would like to see "True" instead of "False" in the status field which would be more coherent with the actual results. (They use some script to check all statuses, my operator being just one amongst many, and wait for True I guess.)

What did you expect to see?

I'd rather expect something like:

   {
     "lastTransitionTime": "2023-07-25T07:14:46Z",
     "message": "Last reconciliation succeeded",
     "reason": "Successful",
     "status": "True",
     "type": "Successful"
   }

but maybe I missed something there.

What did you see instead? Under which circumstances?

We actually see status: False and don't understand why.

Environment

Operator type:

/language ansible

Kubernetes cluster type:

OpenShift

$ operator-sdk version

operator-sdk version: "v1.31.0"

$ kubectl version

Client Version: v1.28.1

Additional context

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[everettraven]

@OchiengEd this was resolved by #35 right?