-
Notifications
You must be signed in to change notification settings - Fork 4
Description
Using Will's PoC, bring in all Kubeflow manifests from aaw-argoflow-azure
Applications
Kubeflow Component | Completed by AAW ✅ | Assessed by CNS ✅ |
---|---|---|
jupyter-web-app | PR: | |
centraldashboard | PR: | |
pipelines | PR: | |
katib | PR: | |
namespaces | PR: | |
notebook-controller | PR: | |
pod-defaults | PR: | |
prob-notebook-controller | PR: | |
profiles | PR: | |
roles | PR: | |
seldon | PR: | |
kfserving | PR: | |
oidc-authservice | PR: | |
oidc-auth | PR: | |
knative | PR: | |
tf-training | PR: | |
pytorch-job | PR: | |
mxnet-job | PR: | |
mpi-job | PR: | |
spark-operator | PR: |
Workflow
Select a component
Compare with our kubeflow-manifests repo and your work on aaw-argoflow-azure
Check for any additional adjustments made in current cluster
Write a P.R. for the component and mark for review by CNS for anything maybe missing
Close off the component and proceed to next one
I did an initial PoC for how should deploy Kubeflow basically we should follow 1 to 1 how Kubeflow upstream organizes there folders and call the naming exactly. I then similar to how we did the other releases created a stacks folder which will call the different supported flows (AAW, Argo, and Upstream).
This way we can keep all your argoflow work and proceed methodically component by component, just how we did the other versions. Basically the mantra is always call the upstream resources at a pinned version (ie v1.4.1) using Kustomize and then we sprinkle in our deltas component by component. I was thinking we can go component by component and create an epic issue with a table with such columns as done by AAW by team and possibly then assessed by CNS. We could then get all this completed by 2 weeks or so.