search

operator-framework / operator-lifecycle-manager

A management framework for extending Kubernetes with Operators
https://olm.operatorframework.io
Apache License 2.0
1.72k stars 546 forks source link

modify current status conditions to respect v1 conventions #2186

Open absynth76 opened 3 years ago

absynth76 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

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 commented 3 years ago

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 commented 3 years ago

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

akihikokuroda commented 3 years ago

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.