modify current status conditions to respect v1 conventions

[absynth76]

Almost all CRD declared in operator lifecyle manager are in v1alpha1 version.
Until now it's enough but when it'll be migrated to v1, the conditions will have to respect conventions describe here:
https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties

This should be put in the backlog.

The current conditions are not integrated with the standard tools like ansible k8s or k8s_info modules (the "wait" parameter in particular cannot be used)

[exdx]

We plan on using conventional conditions for the v2 APIs of OLM but for the v1 APIs (the ones we have now), they are effectively as-is and we will probably not be changing the conditions.

The Operator and OperatorConditions APIs are newer and should use standard conditions, if not that would be considered something to change.

[awgreene]

Providing additional context for those new to the project that are interested in this issue.

The OperatorCondition.Status.Conditions array already uses the metav1.Condition type.

The Operator API uses its own implementation of the condition type as shown here which has a less restrictive structural schema than that belonging to the metav1.Condition struct.

Before the Operator API can transition to using the metav1.Condition type, we need to investigate if existing conditions will break. This can be done by:

• Updating the Operator CRD to use the metav1.Condition struct
• Updating OLM to use the new Operator API
• Install OLM with the new CRD, install a few operators, and check for Operator CR write failures due to schema validation

If the conditions written by OLM already adhere to the structural schema defined by the metav1.Condition struct, we're good to go. Otherwise, we'll need to update OLM to transition existing Operator CRs to valid metav1.Conditions schemas prior to updating the API, which should be possible given that the existing condition schema is less restrictive.

If you are interested in this bug fix, please reach out to us on the #olm-dev Channel on the Kubernetes Slack with any questions.

[absynth76]

I would suggest that you can also use a transition phase, where both conditions versions would be populated. This way, the deprecation of the non-standard conditions could happen later on.

[akihikokuroda]

I would like to investigate this. Would you assign this to me? Thanks!

[akihikokuroda]

The conditions in the operator are copy of condition of CustomResourceDefinition, Subscription, InstallPlan, and Deployment which have the same structure as the "v1alpha1" of the operator condition. The copy is done in this function. It probably does't make sense to update the operator condition to v1 until the source of the conditions are updated.