Refactor the EventingBackend CRD

[nachtmaar]

Description

While reviewing the Proposal reimplement backend-crd.md #667 I discovered a few things on the EventingBackend CR which can be improved IMHO.

Tasks:

As part of this issue we should:

• [ ] Agree if we want to perform any of the proposed changes to the EventingBackend CR
• [ ] Implement the changes or create follow-up tickets (if the change is too big)

Changes

Rename the eventingbackend.status.eventingReady field

Before: status.eventingReady After: status.ready

NOTE: This was discussed here. The team mostly agreed to the renaming, but it was out of scope for the proposal (because the proposal did not touch existing fields of the EventingBackend CR).

Reasoning for the renaming

The status of the EventingBackend looks like this:

status:
  backendType: nats
  conditions:
  - lastTransitionTime: "2022-05-06T08:35:11Z"
    reason: Backend ready
    status: "True"
    type: Backend Ready
  - lastTransitionTime: "2022-05-06T08:35:11Z"
    reason: Publisher proxy deployment ready
    status: "True"
    type: Publisher Proxy Ready
  - lastTransitionTime: "2022-05-06T08:35:11Z"
    reason: Subscription controller started
    status: "True"
    type: Subscription Controller Ready
  eventingReady: true

I feel that the name eventingReady is not ideal. eventingReady is true if all conditions are true (just some syntactic sugar on the API). I propose to rename it from eventingReady to ready. The name EventingBackend also mentions that it is about eventing. There is no reason (for me) to mention the extra prefix eventing.

Change the EventingBackend label

Before: kyma-project.io/eventing: backend After: eventing.kyma-project.io/backend: <backend> where backend=(nats|bab)

NOTE: This was discussed here. The team agreed to the renaming, but it was out of scope for the proposal (because the proposal did not touch existing fields of the EventingBackend CR).

Reasoning for the renaming

The status of the EventingBackend looks like this:

apiVersion: eventing.kyma-project.io/v1alpha1
kind: EventingBackend
metadata:
  labels:
    kyma-project.io/eventing: backend

We recently introduced the label eventing.kyma-project.io/backend: <backend> where backend=(nats|bab). The label is quite handy because it can already be used to identify the correct EPP instance (for the given <backend>). We can bring this label to the EventingBackend as well. The vision would be that we can query all eventing components for a given at some point: eventing-publisher-proxy deployment, eventing backend controller, eventing secrets, etc. Atm the label is pretty useless because every EventingBackend CR has the same label value.

[github-actions[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[kyma-bot]

This issue or PR has been automatically marked as stale due to the lack of recent activity. Thank you for your contributions.

This bot triages issues and PRs according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 7d of inactivity since lifecycle/stale was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Close this issue or PR with /close

If you think that I work incorrectly, kindly raise an issue with the problem.

/lifecycle stale

[k15r]

The Backend CRD will be replaces by the new Eventing CRD (from the modularization topic)

[kyma-bot]

This issue or PR has been automatically marked as stale due to the lack of recent activity. Thank you for your contributions.

This bot triages issues and PRs according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 7d of inactivity since lifecycle/stale was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Close this issue or PR with /close

If you think that I work incorrectly, kindly raise an issue with the problem.

/lifecycle stale

[k15r]

replaced by eventing cr (modularization)