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

OchiengEd commented 2 months ago

/assign

OchiengEd commented 1 month ago

[ ] 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 commented 1 month ago

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 commented 1 month ago

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.

operator-framework / operator-controller

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