-
Notifications
You must be signed in to change notification settings - Fork 30
feat: migration script for V1 to V2 components #162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Kimonas Sotirchos <[email protected]>
Signed-off-by: Kimonas Sotirchos <[email protected]>
Co-authored-by: Julius von Kohout <[email protected]> Signed-off-by: Kimonas Sotirchos <[email protected]>
Co-authored-by: Julius von Kohout <[email protected]> Signed-off-by: Kimonas Sotirchos <[email protected]>
Co-authored-by: Julius von Kohout <[email protected]> Signed-off-by: Kimonas Sotirchos <[email protected]>
Co-authored-by: Julius von Kohout <[email protected]> Signed-off-by: Kimonas Sotirchos <[email protected]>
Co-authored-by: Julius von Kohout <[email protected]> Signed-off-by: Kimonas Sotirchos <[email protected]>
Co-authored-by: Julius von Kohout <[email protected]> Signed-off-by: Kimonas Sotirchos <[email protected]>
Co-authored-by: Julius von Kohout <[email protected]> Signed-off-by: Kimonas Sotirchos <[email protected]>
Co-authored-by: Julius von Kohout <[email protected]> Signed-off-by: Kimonas Sotirchos <[email protected]>
|
Thanks for the review @juliusvonkohout! Does the script functionality also looks good to you, or do you have any suggestions? |
For me it is fine and optional so |
|
/ok-to-test |
andyatmiami
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really great work getting this spec'd out @kimwnasptd
I have some general questions/comments/observations - but nothing imho critically impacting ...
Will wait for your response/follow up on some of the outstanding questions before I engage in attempting to run this bad boy 💯
scripts/upgrade_v1_to_v2.sh
Outdated
| echo -e "\nWill remove namespaced resources with labels: $label" | ||
| for resource in $namespace_resources; do | ||
| echo "Removing all $resource objects..." | ||
| kubectl delete -n kubeflow -l $label $resource |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would we want the --wait=true flag specified on this to ensure the resource(s) are really really gone before proceeding?
could also then specify --timeout=?s to something reasonable (whatever that would be!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not totally sold myself on this - but I wonder if we'd also want to throw a --ignore-not-found=true flag on there as well..
in the event this script bailed for a wild variety of reasons outside our control... ignore-not-found would make subsequent runs less problematic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, both are good suggestions as the assumptions of users would be that previous resources would have been completely removed.
I'll update accordingly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding --ignore-not-found, I think we shouldn't need this one.
kubectl delete will not return a non-zero exit code if we try to delete objects based on labels. It would though if we would try to delete an object with its name. That's why in this line we have the ||
https://github.com/kubeflow/dashboard/pull/162/files#diff-afd68f06993c6a5670eb569a6764c40acaafa880d46db67999c93e5adadb1a14R48
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
scripts/upgrade_v1_to_v2.sh
Outdated
|
|
||
| for resource in $cluster_resources; do | ||
| echo "Removing all $resource objects..." | ||
| kubectl delete -l $label $resource |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would we want the --wait=true flag specified on this to ensure the resource(s) are really really gone before proceeding?
could also then specify --timeout=?s to something reasonable (whatever that would be!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not totally sold myself on this - but I wonder if we'd also want to throw a --ignore-not-found=true flag on there as well..
in the event this script bailed for a wild variety of reasons outside our control... ignore-not-found would make subsequent runs less problematic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added be7d1cf to address this one
| * The script will not remove any CR (Custom Resource) or CRD (Custom Resource Definition), to ensure no data loss | ||
| * Only Kubernetes resources relevant to the Deployments will be removed (Deployment, ServiceAccount, Service etc) | ||
| * The [`NetworkPolicy`](https://github.com/kubeflow/manifests/blob/v1.10-branch/common/networkpolicies/base/centraldashboard.yaml) from the `kubeflow/manifests` repo, of the CentralDashboard, will be removed | ||
| 2. Install the manifests from this repository for the Dashboard, Profiles Controller and PodDefaults webhook |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Asking b/c I have no idea - but is it "safe" to assume the overlays this script is using when deploying to any potential client (?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say yes, for:
- PodDefaults have only the
cert-manageroverlay, which is currently the only supported way for creating the Webhook certificate - Profiles use the
kubeflowoverlay, which is what we want to install in this case (platform)
The only one with a bit of a debate would be the dashboard, as the script uses the kserve overlay (had a bug, and was using istio) which in turn expects KServe to be deployed.
Adding a small note in the README. LMKWDYT
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
scripts/upgrade_v1_to_v2.sh
Outdated
| echo "Installing the updated Dashboard V2 components." | ||
| echo "-----------------------------------------------" | ||
|
|
||
| echo -e "\nApplying Dashboard component..." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor nitpick - feel free to disagree.. but it seems to me we should deploy Dashboard last as its unusable until profile-controller is running...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM! Addressed in be7d1cf
Co-authored-by: Andy Stoneberg <[email protected]> Signed-off-by: Kimonas Sotirchos <[email protected]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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 |
Co-authored-by: Andy Stoneberg <[email protected]> Signed-off-by: Kimonas Sotirchos <[email protected]>
Signed-off-by: Kimonas Sotirchos <[email protected]>
Signed-off-by: Kimonas Sotirchos <[email protected]>
939ac4b to
5cf0e01
Compare

Closes #154
Note: This should be merged/reviewed only after we've merged the PRs for #154 (comment)
/cc @juliusvonkohout @thesuperzapper @andyatmiami