Use declarative conditions for the CRE status.

[VannTen]

We reduce the API surface with less conditions, trying to describe the
state of our resource.
The API is built around the assumption that client only cares about
three things:

• Is there a built image available ? (-> can I run it ?)
• Is the image up to date ? (-> are my last changes in it ?)
• Is there an error ? (-> are my changes correct / is the cluster not
  working ?)

Open questions:

• I wonder if we need a fourth "transient" condition, BuildScheduled/equivalent ?
  Is there an use case (aka, a API client who cares) for it ?

This is only the API side, on which we should agree before adapting the reconciliation loop inside the controller.

I left out Thoth-related conditions for now, this should be additive and not modify the core logic of CRE, I think.

@goern @codificat

Related Issues and Dependencies

fixes: #130

This introduces a breaking change

• Yes

This should yield a new module release

• Yes

[sesheta]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[sesheta]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from vannten by writing /assign @vannten in a comment. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[goern]

How would we indicate, that the secret required for importing an image is not present, or if it is present, an auth failed?
Ready would be set to False, how would we show the reason why? via Condition.Reason?

What is the rationale for not having more fine-grain condition constants?

[VannTen]

In my opinion, failures causes are too open-ended to be a Reason of their own. I would use the Message field to indicate the precise cause of the failure (Thinking in term of client case, I expect the dashboard for examples to have one case for failing (displaying some "bad" icon) and then displaying the Message field directly). wdyt ?

[VannTen]

@goern Is your question answered ?

Should we move forward with this API ?

[goern]

/lgtm

[goern]

/close

[op1st-prow]

@goern: Closed this PR.

In response to this:

/close

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.