[epic] Support interaction similar to OLMv0's OperatorConditions upgrade blocking

[joelanford]

[OchiengEd]

/assign

[OchiengEd]

• [ ] Implement the OperatorConditions controller
• [ ] Pull and apply the OperatorConditions CRD from operator-framework/api repo
• [ ] Write tests for OperatorConditions controller
• [ ] Implement logging for OperatorConditions controller

[joelanford]

Note from @dinhxuanvu:

• OLMv0 has two different versions of this CRD. We need to make sure we understand the history of this API when we implement it for OLMv1.
• Follow the v2 convention for single writer to either spec or status.

[dinhxuanvu]

Just a note now that I remember "something".

We didn't do any CR conversion between v1 and v2 because we didn't use kube-storage-version-migrator or anything like that to do the conversion automatically. Even if the CR is stored under v1 initially in etcd, when the CR is served, it will have v2 tag/version as I apiserver automatically converts from v1 to v2 if the client is querying v2 endpoint. v2 is the storage version so upon writing back, it should be written as v2 in etcd moving forward. Both versions are serving versions to avoid breaking the operators' operation if they are using v1. v2 is adding a new field if IRCC so the conversion from v1 to v2 shouldn't lose any data.

[m1kola]

Since this ticket was re-purposed adding a bit more context.

It has been decided that we will not to carry over OperatorConditions API from OLMv0 to OLMv1. However we want an alternative API to be designed to support operators who make use of OperatorConditions today for the purpose of upgrade blocking (e.g. to minimise a chance of interruptions during data migrations). Is is now the goal of this ticket.

Previous research can be found in this defunct brief. There is also a list at the bottom of publicly available operators who in some shape or form have dependency on OperatorConditions API. This list might be helpful to understand the use cases.