Skip to content
Open
30 changes: 29 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@
It exposes the access controlled web interfaces for Kubeflow components and more.

> ⚠️ __Note__ ⚠️
>
>
> We are currently moving the Kubeflow Dashboard codebase from [`kubeflow/kubeflow`](https://github.com/kubeflow/kubeflow) to this repository ([`kubeflow/dashboard`](https://github.com/kubeflow/dashboard)).
> Please see [`kubeflow/kubeflow#7549`](https://github.com/kubeflow/kubeflow/issues/7549) for more information.

Expand Down Expand Up @@ -38,6 +38,34 @@ Please refer to the [Installing Kubeflow](https://www.kubeflow.org/docs/started/

The official documentation for Kubeflow Dashboard can be found [here](https://www.kubeflow.org/docs/components/central-dash/).

## Migrate from V1

In the past, up until the Kubeflow 1.10 release, the components hosed in this repository were living in the
[`kubeflow/kubeflow`](https://github.com/kubeflow/kubeflow) repository.

To accomodate the migration, the first `v2.0.0` release of this repository contains the same artifacts
from the corresponding [`v1.10.0`](https://github.com/kubeflow/kubeflow/releases/tag/v1.10.0) tag from the `kubeflow/kubeflow` repo. This was done to ensure a smooth transition
between the components of the different repos. You can find more details about the migration in https://github.com/kubeflow/dashboard/issues/118.

### Prerequisites

1. A Kubeflow cluster with 1.10.0 or above
2. `kubectl` configured for access to the above cluster

### Script

You can use the following script to perform the migration from `v1.10.0` components to the `v2.0.0` ones from this repository. The script will
perform the following actions:
1. Remove the existing components of CentralDashboard, Profiles Controller and PodDefaults Webhook
* 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
Copy link
Contributor

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 (?)

Copy link
Member Author

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:

  1. PodDefaults have only the cert-manager overlay, which is currently the only supported way for creating the Webhook certificate
  2. Profiles use the kubeflow overlay, 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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


```bash
./scripts/upgrade_v1_to_v1.sh
```

## Community

Kubeflow Dashboard is part of the Kubeflow project, refer to the [Kubeflow Community](https://www.kubeflow.org/docs/about/community/) page for more information.
Expand Down
97 changes: 97 additions & 0 deletions scripts/upgrade_v1_to_v2.sh
Original file line number Diff line number Diff line change
@@ -0,0 +1,97 @@
#!/usr/bin/env bash
set -euo pipefail

SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )

echo "--------------------------------------------------------------------------------------"
echo "Running the upgrade script to migrate the Kubeflow Dashboard components to V2 release."
echo "--------------------------------------------------------------------------------------"

PROFILES_LABELS=kustomize.component=profiles
DASHBOARD_LABELS=app.kubernetes.io/component=centraldashboard
PODDEFAULT_LABELS=app.kubernetes.io/component=poddefaults

# Helper function for removing all K8s resources of a Kubeflow Component. This will include all resources
# relevant to the Deployment, but not CRDs. This is done to ensure we don't accidentally delete CRs
# (like PodDefaults) in user namespace.
remove-component() {
label=$1
namespace_resources="deployment service role rolebinding configmap serviceaccount virtualservice authorizationpolicy certificate secret"
cluster_resources="clusterrole clusterrolebinding mutatingwebhookconfigurations"

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
Copy link
Contributor

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!)

Copy link
Contributor

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

Copy link
Member Author

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

Copy link
Member Author

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

echo "Successfully removed all $resource objects"
done

for resource in $cluster_resources; do
echo "Removing all $resource objects..."
kubectl delete -l $label $resource
Copy link
Contributor

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!)

Copy link
Contributor

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

Copy link
Member Author

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

echo "Successfully removed all $resource objects"
done
}


echo -e "\nRemoving PodDefaults component..."
remove-component $PODDEFAULT_LABELS
echo -e "\nSuccessfully removed PodDefaults!"

echo -e "\nRemoving Profiles component..."
remove-component $PROFILES_LABELS
echo -e "\nSuccessfully removed Profiles!\n"

echo -e "\nRemoving Centraldashboard component..."
remove-component $DASHBOARD_LABELS
echo "Removing NetworkPolicy created by kubeflow/manifests repository..."
kubectl delete networkpolicy -n kubeflow centraldashboard || echo "No NetworkPolicy from manifests repository found. Continuing..."
echo -e "\nSuccessfully removed Centraldashboard!"

echo "-----------------------------------------------"
echo "Installing the updated Dashboard V2 components."
echo "-----------------------------------------------"

echo -e "\nApplying Dashboard component..."
Copy link
Contributor

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...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM! Addressed in be7d1cf

echo -e "--------------------------------"
kustomize build \
$SCRIPT_DIR/../components/centraldashboard/manifests/overlays/istio \
| kubectl apply -f -

echo "Waiting for Dashboard Deployment to become available..."
kubectl wait -n kubeflow \
--for=condition=Available \
deployment \
dashboard \
--timeout=5m
echo -e "Successfully applied the Dashboard component!"

echo -e "\nApplying PodDefaults component..."
echo -e "----------------------------------"
kustomize build \
$SCRIPT_DIR/../components/poddefaults-webhooks/manifests/overlays/cert-manager \
| kubectl apply -f -

echo "Waiting for PodDefaults Webhook Deployment to become available..."
kubectl wait -n kubeflow \
--for=condition=Available \
deployment \
poddefaults-webhook-deployment \
--timeout=5m
echo -e "Successfully applied the PodDefaults component!"

echo -e "\nApplying Profile Controller component..."
echo -e "-----------------------------------------"
kustomize build \
$SCRIPT_DIR/../components/profile-controller/config/overlays/kubeflow/ \
| kubectl apply -f -

echo "Waiting for Profiles Controller Deployment to become available..."
kubectl wait -n kubeflow \
--for=condition=Available \
deployment \
profiles-deployment \
--timeout=5m
echo -e "Successfully applied the Profile Controller component!"

echo -e "\nSuccessfully applied Dashboard V2 components!\n"