fix(ctrl): Change reconciliation of int in error

[gansheer]

Description

When the integration is in Error with the Kit condition in error, then if the integration kit referenced is still in error then finish the reconciliation process without any change to the integration.

Fix the health trait to avoid panic errors.

Release Note

Change reconciliation of integration in error

[github-actions]

🐫 Thank you for contributing!

Code Coverage Report ✔️ - Coverage unchanged.

[github-actions]

🐫 Thank you for contributing!

Code Coverage Report ✔️ - Coverage unchanged.

[gansheer]

I am moving it back to draft to make a first PR with E2E test on existing behavior.

[github-actions]

🐫 Thank you for contributing!

Code Coverage Report ✔️ - Coverage unchanged.

[gansheer]

So let's recap a little:

The solution proposed is to stop early on the process (before it get to the apply part) when the following conditions are ALL met:

• Integration status contains a condition IntegrationConditionKitAvailable with status Error
• Integration status phase is Error
• IntegrationKit status phase is Error (the one declared by the Integration)

From the e2e test I gathered the following:

• an Integration with invalid or unknown dependencies : any fix will generate a new Integration Kit => solution OK
• an Integration with unknown component in route : the IntegrationKit is not generated until all component are known => solution OK
• an Integration with route compilation error : the IntegrationKit was already generated successfully and any change in the route won't have any impact on the IntegrationKit => solution OK

I really don't see any use case where an IntegrationKit in Error will be able to recover without the creation of a new one. Is there such a process or something that could act directly on an IntegrationKit CR without acting from the Integration CR ?

@squakez @lburgazzoli

[lburgazzoli]

So let's recap a little:

The solution proposed is to stop early on the process (before it get to the apply part) when the following conditions are ALL met:

* Integration status contains a condition `IntegrationConditionKitAvailable` with status `Error`

* Integration status phase is `Error`

* IntegrationKit  status phase is `Error` (the one declared by the Integration)

do we expose in some ways (conditions, phase) at what stage the reconciliation stops ?

[squakez]

LGTM, given that the test in #4815 are now passing.

[squakez]

@lburgazzoli given the new E2E test provided by @gansheer, I think we are safe to merge this PR. Basically we stop the latest reconciliation loop to apply traits when both the Integration and the Kit are in an error state. Hence, there is no reason to continue applying trait logic. Do you have any further concern?

[gansheer]

do we expose in some ways (conditions, phase) at what stage the reconciliation stops ?

None that I could tell for the Integration CR. As for the IntegrationKit CR its reconciliation after 5 failed builds and I suppose you could consider the status.failure field as an indication that the reconciliation is stopped.