Katib: Move manifests development upstream #1432
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: yanniszark The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
yanniszark
force-pushed
the
feature-move-katib-manifests-upstream
branch
from
0658cc9
to
7c97e53
Compare
yanniszark
force-pushed
the
feature-move-katib-manifests-upstream
branch
from
7c97e53
to
5ce880a
Compare
|
/retest |
There was a problem hiding this comment.
Thank you for doing this @yanniszark!
Do we have a unique structure for the kustomize manifests for each kubeflow component ?
Or every WG should decide how to store manifest by themselves?
| @@ -0,0 +1,53 @@ | |||
| apiVersion: apps/v1 | |||
There was a problem hiding this comment.
Should we move all of the YAMLs from the manifests/v1beta1/katib-controller/base to the /manifests/v1beta1/components/<appropriate-component-name/ ?
Since we left the old structure for the manifests to not brake kfdef configs before we transfer to the v3 manifests ?
There was a problem hiding this comment.
I agree! I was suspecting something like this happened.
| @@ -0,0 +1,65 @@ | |||
| apiVersion: app.k8s.io/v1beta1 | |||
There was a problem hiding this comment.
Do we need to maintain these overlays ?
There was a problem hiding this comment.
For the application overlays, we are discussing about moving away from them soon:
kubeflow/manifests#1715
What we could do is put them in an installs/kubeflow kustomization, since they are used when Katib is installed alongside other Kubeflow components.
There was a problem hiding this comment.
@yanniszark So should we add the application overlay for Katib now or it's better to remove all labels and add them later with an Application, once we need it.
Since currently, many Katib labels are incorrect for the Application: kubeflow/manifests#1669.
There was a problem hiding this comment.
@andreyvelich in general, we are moving away from using the Application CR: kubeflow/manifests#1715 (comment)
For this PR, I would suggest leaving them as is. The initial plan is to just get the manifests under the control of the upstream repo (katib) and then we can make changes incrementally.
|
@andreyvelich those are some good questions. I tried to answer in the comments above. As for the final question:
We plan to propose a common way to organize manifests soon (step 4 in this plan kubeflow/manifests#1735). The first goal is to get the content of kubeflow/manifests back to the respective upstream repos. In general, applications are expected to provide kustomizations that can be used to install the application. |
yanniszark
force-pushed
the
feature-move-katib-manifests-upstream
branch
from
5ce880a
to
bfda6be
Compare
|
@andreyvelich I have made the changed suggested here:
Could you take another look? |
|
@yanniszark Thank you for the update!
|
| uri: /katib/ | ||
| route: | ||
| - destination: | ||
| host: katib-ui.$(katib-ui-namespace).svc.$(clusterDomain) |
There was a problem hiding this comment.
Will we get these values from the appropriate stack.
For example: https://github.com/kubeflow/manifests/blob/master/distributions/stacks/gcp/kustomization.yaml ?
There was a problem hiding this comment.
Yes exactly! Let's keep those as they are and we can introduce changes afterwards if we find it's not a good pattern.
yanniszark
force-pushed
the
feature-move-katib-manifests-upstream
branch
3 times, most recently
from
4b12a58
to
6a1f705
Compare
|
|
Thank you @yanniszark. |
|
@andreyvelich thanks, so what are the next steps for the CI? |
|
@yanniszark Yeah, please can you rebase and we can move forward? |
yanniszark
force-pushed
the
feature-move-katib-manifests-upstream
branch
from
6a1f705
to
aea241f
Compare
As part of the work of wg-manifests for 1.3 (kubeflow/manifests#1735), we are moving manifests development in upstream repos. This gives the application developers full ownership of their manifests, tracked in a single place. This commit copies the manifests for application `Katib` from path `apps/katib/upstream` of kubeflow/manifests to path `manifests/v1beta1` of the upstream repo (https://github.com/kubeflow/katib). Signed-off-by: Yannis Zarkadas <[email protected]>
Signed-off-by: Yannis Zarkadas <[email protected]>
yanniszark
force-pushed
the
feature-move-katib-manifests-upstream
branch
from
aea241f
to
f61c903
Compare
|
@andreyvelich great, I just rebased! |
|
Thanks @yanniszark. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: andreyvelich, yanniszark The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Issue Resolved
Resolves: #1431
Umbrella issue: kubeflow/manifests#1740
Description
As part of the work of wg-manifests for 1.3
(kubeflow/manifests#1735), we are moving manifests
development in upstream repos. This gives the application developers full
ownership of their manifests, tracked in a single place.
This PR copies the manifests for application
Katibfrom path
apps/katib/upstreamof kubeflow/manifests to pathmanifests/v1beta1of the upstream repo (https://github.com/kubeflow/katib).cc @kubeflow/wg-automl-leads