Replace phases in database status with events

[bobertrublik]

This PR removes the Phase field from DatabaseStatus and throws Kubernetes Events in its stead. An additional PR is required to remove phases from the CRD in the Helm chart.

Related issue:

• Get rid of phases in the database controller #59

Added

I decided to create a local variable var phase containing the current phase in the reconciliation process. This variable is f.e. used during logging or when the function manageError is called.

Removed

The metric promDBsPhase seemed obsolete to me and I removed it. I'm not 100% sure this was correct.

Open for feedback

I wasn't completely sure how to write the event messages and took some liberties there. Maybe someone could provide a few ideas.

[allanger]

I'm not sure if it actually makes sense, but maybe we can add phase to the context, then we won't need this var, and it should have the same lifettime as reconciliation.
And hopefully, if we later switch to the context logger, we'll be able to always access the phase (I hope)

[bobertrublik]

It looks like contexts are immutable which means we won't be able to modify the phase each time it changes.

When using contexts, it’s important to know that the values stored in a specific context.Context are immutable, meaning they can’t be changed. When you called the context.WithValue, you passed in the parent context and you also received a context back. You received a context back because the context.WithValue function didn’t modify the context you provided. Instead, it wrapped your parent context inside another one with the new value.

Source

[allanger]

I'm not sure about metrics, maybe @dabde or @hyunysmile know better.

[allanger]

To be honest, I wouldn't go with the phase variable, because I wanted to unify the manageError method so we don't have it in each controller. Because currently they look pretty much the same and we can use generics or interfaces to get there.

If we go with the phase var, the database's manageError will be different.

Since this phase is a part of the reconciliation, maybe we can put it to the DatabaseReconciler object. Then manageError could access it from the r.DbPhase or something like that

[allanger]

To be honest, I wouldn't go with the phase variable, because I wanted to unify the manageError method so we don't have it in each controller. Because currently they look pretty much the same and we can use generics or interfaces to get there.

If we go with the phase var, the database's manageError will be different.

Since this phase is a part of the reconciliation, maybe we can put it to the DatabaseReconciler object. Then manageError could access it from the r.DbPhase or something like that

But maybe nevermind for now, cause I guess my idea will not work that easy anyway. I'm fine with having var for time being

So from my side, only this one: #87 (comment)

[allanger]

I'm approving it. Since metrics are edited in a separate commit, we'll be able to revert it in case we'll turn out to need it