Kubeflow operator versioning

[adrian555]

Adds to Operator Roadmap issue #193 to track:

Currently the kubeflow operator is hard coded with version 0.1.0. A new versioning mechanism needs to implement to avoid following issues:

• Kubeflow and kfctl have moved from 0.7 to 1.0, operator does not reflect such change.

• The version of the docker image for the operator is aipipeline/kubeflow-operator:v0.1.0 which was built with an older version of kfctl (aka. it was built with kfctl 0.7.0 instead of latest 1.0.0). When the version number of the docker image is fixed, it is not able to reflect any new kubeflow release.

• The CSV and other manifests kept in operatorhub.io also is outdated and out of sync.

We need a dynamic versioning mechanism for kubeflow operator to keep up with the kubeflow releases.

[issue-label-bot]

Issue-Label Bot is automatically applying the labels:

Label	Probability
kind/feature	0.78

Please mark this comment with 👍 or 👎 to give our bot feedback!
Links: app homepage, dashboard and code for this bot.

[vpavlin]

I keep thinking about this - does the operator and the manifests need to match? Since the operator could handle multiple versions of manifests as long as there are not crazy breaking changes, it might make sense to decouple these and not have to release the operator and manifests together.

Is it a plan for kfctl itself to be released with every manifests update and vice versa? @animeshsingh @jlewi

[jlewi]

I would not expect manifests and kfctl to be on different release cyles.

[animeshsingh]

A way to look at it is like KF Control Plane CLI + KF Configuration files which are needed for that CLI to work for a Kubeflow version. Now it maybe possible the CLI works with Configuration files with previous or next versions, but won't be something which project is testing or standing for. So ideally would not make sense to advertise so as well.

[vpavlin]

My question stems from seeing the same change in approach in Knative project (knative/operator#56) - they are decoupling manifests and the operator like Kubeflow does, but AFAIU they are also looking at decoupling the versions - i.e. the operator can handle multiple versions of manifests/knative and thus you do not need to rebuild and/or redeploy the operator for a small change in manifests and vice versa - you do not need a new version of manifests for a fix/feature in the operator.

It think with a fast moving project like Kubeflow is, it would make sense to think about similar approach and built in support for this.