[discussion] Separate the operator and UI dashboard

[gaocegege]

This repository has two components: operator and dashboard, I think if we could separate these two components since they are designed to be decoupled.

[jimexist]

+1 for that, I think UI dashboard can now live in its own repo. What do you think? @wbuchwalter

[wbuchwalter]

I don't have any objection. We discussed this at the beginning with @jlewi and always assumed it would be separate at some later point.
My only concern currently is around breaking changes in github.com/kubeflow/tf-operator/pkg/apis/tensorflow/v1alpha1. Today the dashboard is part of the release process of tf-operator so it's very easy to know whether a change broke the dashboard. Would we still be able to detect this easily with our current CI system if they lived in separate repos?

[gaocegege]

I think it could be done after we release a version and then dashboard does not need to adapt the HEAD of the operator.

[jimexist]

once the release and lifecycle convention of tf-operator is known and widely observed this can be done (and it should be).

[jimexist]

@jlewi wondering do we have a release schedule at least GitHub-wise for this repo? So that many dependent Golang repos can have sensible expectations, etc.

[gaocegege]

wondering do we have a release schedule at least GitHub-wise for this repo? So that many dependent Golang repos can have sensible expectations, etc.

I agree that we could just release a version in github, to keep a usable version here.

[wbuchwalter]

Yes if we wait for versionning before doing this I'm fine with it.

[jlewi]

Our testing infrastructure (checkout.sh supports checking out multiple repos.

You just specify the environment variable "EXTRA_REPOS". You can specify a commit/branch/tag to checkout.

So our E2E tests can specify which version of each repo to test; e.g. we could test kubeflow/kubeflow HEAD wit kubeflow/tf-operator HEAD or HEAD with tag 0.1 etc...

[gaocegege]

Do we have integration test for operator and the dashboard?

[ScorpioCPH]

+1

[gaocegege]

Proposal for separating operator and dashboard

Motivation

See #389

Goals

• Separate operator and dashboard
• Build integration test for dashboard

Migration

We need to create a new repository tfjob-dashboard and:

• Remove dashboard/frontend/build from git ignore file
• Remove dashboard from developer_guide.md
• Migrate dashboard directory to the new repository
• Update the code in build_and_push.py and release.py to the new repository
• Remove the dashboard from dir_excludes in py_checks.py
• Remove the dashboard from docker image and create a dependent image for the dashboard
• Update the image in tf-job-operator-chart
• Update the image for dashboard in kubeflow/kubeflow

[gaocegege]

I am glad to help to migrate the dashboard to the new repository for better maintainance. And there is a list of TODOs, PTAL @jlewi @wbuchwalter

If you think it works I think we could open a new repository and begin the work.

I think we could keep it in operator and do the migration work, after all things done we could update the chart in operator and image in kubeflow/kubeflow.

[jlewi]

Do we really need a new repository? Every repository has a fairly high maintenance cost.

We can still do all the other changes; e.g. put it in a separate Docker image.

[gaocegege]

OK, SGTM

[jlewi]

Assuming we keep the UI and operator in the same repository for now but in different directories.

What changes are needed to better separate the two.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.