Multi-version support in xgboost-operator

[Jeffwan]

Currently, xgboost uses v1alpha1 API and it has separate folder https://github.com/kubeflow/xgboost-operator/tree/master/pkg/apis/xgboostjob/v1alpha1

However, controller folder doesn't have multi-version at the beginning, https://github.com/kubeflow/xgboost-operator/tree/master/pkg/controller has one controller implementation.

In order to upgrade to v1 and use latest kubeflow/common, what's your options on multi-version support? Seems Ant financial and Tencent are using this in prod environment, it would be better to safely apply new breaking changes.

1. only have new version of API like v1beta1 or v1, update controller implementation directly. This solution doesn't support multi-version, master won't be stable until we finish all the tests. If your environment has a stable version, I think it's still fine.

2. have a new folder for controller like below, each version of controller will use corresponding API version. With this, user can still build an alpha version. In the meanwhile, we can make changes to beta or v1.

pkg/controller
   v1alpha1/
   v1beta1/
   v1/

Any thoughts?
@merlintang @terrytangyuan @hustcat

[issue-label-bot]

Issue-Label Bot is automatically applying the labels:

Label	Probability
area/operator	0.72
kind/feature	0.88

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

[merlintang]

I check the TF-operator, it supports multiple version controller. https://github.com/kubeflow/tf-operator/tree/master/pkg. thus, if it is not too many works to do, we can implement the v1 version controller

[terrytangyuan]

Yes we should support multi version controllers which other operators are already doing. MPI Operator is improving its v1 controller as well that will be the candidate for graduation.

Maybe I can cut a v0.1.0 release first and then we can fork a v1 controller from the existing v1alpha1 controller?

[merlintang]

yes, cut the release is good.

[Jeffwan]

Yeah, cut a release will help, since project will have different folder for difference version, it's ok and we can still patch v1alpha1 version while working on v1 graduation.

So the plan is to graduate from v1alpha1 to v1 directly, no need to have v1beta, right?

[merlintang]

I think so.

…

On Wed, May 13, 2020 at 9:35 PM Jiaxin Shan ***@***.***> wrote: Yeah, cut a release will help, since project will have different folder for difference version, it's ok and we can still patch v1alpha1 version while working on v1 graduation. So the plan is to graduate from v1alpha1 to v1 directly, no need to have v1beta, right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#72 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAK5R6NWPNMULRNCG2SGQH3RRNYJ7ANCNFSM4NAIDOAA> .

[terrytangyuan]

Yeah, cut a release will help, since project will have different folder for difference version, it's ok and we can still patch v1alpha1 version while working on v1 graduation.

Exactly.

So the plan is to graduate from v1alpha1 to v1 directly, no need to have v1beta, right?

Yes.

[terrytangyuan]

I just cut a release here: https://github.com/kubeflow/xgboost-operator/releases/tag/v0.1.0

This includes your recent fix on logs but excludes the bump of k8s and controller runtime version.

[Jeffwan]

If anyone is interested in the migration, please leave a comment. Otherwise, I will pick it up.

[terrytangyuan]

@Jeffwan I can help set up the folder structures and skeleton code of the v1 controller and then everyone in the community who are interested can work together on maturing it.