Create manifests for new Katib UI

[kimwnasptd]

/kind feature

Describe the solution you'd like
Provide the required manifests for people to try out the new Katib UI #1421. The current UI should still be the default one people should install. These manifests would be identical to the ones for the existing UI, and the only difference will be the image.

These are the steps I can think of to achieve this:

1. Extend the CI/CD to also build an image for the new UI
   • should we use a new image registry?
   • should we use a distinct tag for the new image?
   • which part of the CD should we extend to achieve this?
2. Create a new yaml for the app's manifests
   • should this be another file in manifests/v1beta1/ui?

Anything else you would like to add:
I would like to help with this effort as much as possible, but I have some knowledge gaps for the implementation details for some of the steps.

@andreyvelich @gaocegege @johnugeorge could you give me some pointers for this?

[andreyvelich]

Thank you for creating this @kimwnasptd!

Create a new yaml for the app's manifests

I think we can create another component under /components/new-ui, similar to this: https://github.com/kubeflow/katib/tree/master/manifests/v1beta1/components/ui.

should we use a new image registry?

We can create new registry under `docker.io/kubeflowkatib/katib-new-ui

which part of the CD should we extend to achieve this

If we don't need to push new-ui image to the registry during our CI, we can specify --no-push flag to the Kaniko executor.
Then we don't need to specify registry in --destination: https://github.com/kubeflow/katib/blob/master/test/workflows/components/workflows-v1beta1.libsonnet#L426.
Is that correct @PatrickXYS ?

[PatrickXYS]

If we don't need to push new-ui image to the registry during our CI, we can specify --no-push flag to the Kaniko executor.

Right, if we don't push, then we don't have to care about --destination, it could whatever registry name.

[kimwnasptd]

I think we can create another component under /components/new-ui, similar to this: https://github.com/kubeflow/katib/tree/master/manifests/v1beta1/components/ui.

Makes sense, I'll create a short PR for this. It will be the existing manifests with only a change in the image.

We can create new registry under docker.io/kubeflowkatib/katib-new-ui

@andreyvelich sure! What is the process to push an image to docker.io/kubeflowkatib/katib-new-ui? If I add a ksonnet component [ I think this was the terminology ] for the new ui, similar to the one you linked above, would this be enough? The workflow would also need to push the image after it builds it so we most probably won't need the --no-push arg

[andreyvelich]

Makes sense, I'll create a short PR for this. It will be the existing manifests with only a change in the image.

Thanks!

@andreyvelich sure! What is the process to push an image to docker.io/kubeflowkatib/katib-new-ui? If I add a ksonnet component [ I think this was the terminology ] for the new ui, similar to the one you linked above, would this be enough? The workflow would also need to push the image after it builds it so we most probably won't need the --no-push arg

I will update push.sh and build.sh scripts to process new ui image.

[andreyvelich]

We included the new UI in the manifest and release scripts.