Changes for chart/README.md: 36 added lines, 8 removed lines.
Original line number
Diff line number
Diff line
@@ -100,11 +100,11 @@ clusterSet:
managedClusters:
-name:managed-1
location:managed-1
kubeconfigSecretName:managed1-kubeconfig
kubeconfigSecretId:<hypo-registry-kubeconfig-id>
-name:managed-2
location:managed-2
kubeconfigSecretName:managed2-kubeconfig
kubeconfigSecretId:<hypo-registry-kubeconfig-id>
```
### Scheduler configuration
@@ -128,9 +128,9 @@ managedClusters:
| Parameter | Description |
|---|---|
| `managedClusters[].name` | Name of the ManagedCluster registered on the OCM Hub. |
| `managedClusters[].name` | Name of the ManagedCluster registered on the OCM Hub. Also the name of the Kubernetes Secret holding its kubeconfig. |
| `managedClusters[].location` | Location value assigned to the cluster through the `hypo.filter.location` ClusterClaim. |
| `managedClusters[].kubeconfigSecretName` | Name of the Kubernetes Secret containing the managed cluster kubeconfig. |
| `managedClusters[].kubeconfigSecretId` | HypO registry ID of the managed cluster kubeconfig. When deployed from HypO, the package manager fetches it and creates the Secret `<name>` before install. Not used by the chart templates. |
The `location` value is used by the scheduler when evaluating location-based scheduling requirements. It should match the location expected by the corresponding workload scheduling configuration.
@@ -138,16 +138,20 @@ The `location` value is used by the scheduler when evaluating location-based sch
The Helm setup and cleanup Jobs require access to the managed clusters to create and remove ClusterClaims.
If we deploy manually the Hlem chart and not from HypO, we need for each managed cluster, to create a Kubernetes Secret in the scheduler namespace containing its kubeconfig.
When deployed from HypO, the package manager creates these Secrets from `managedClusters[].kubeconfigSecretId` before installing the chart.
If we deploy manually the Helm chart and not from HypO, we need for each managed cluster, to create a Kubernetes Secret in the scheduler namespace containing its kubeconfig, named after the cluster's `name`.
This is the case for the OCM hub used by this repository's CI (see [The OCM hub used by the CI](#the-ocm-hub-used-by-the-ci)). The Secrets must stay in place there, since the setup Job reads them again on every `helm upgrade`.
The Secret names must match the `kubeconfigSecretName` values in `values.yaml`.
The Secret names must match the `managedClusters[].name` values in `values.yaml`.
### Private container registry
@@ -316,6 +320,30 @@ The Helm post-upgrade Job reapplies the managed cluster configuration, including
Verify the updated configuration using the checks in Section 7.
### The OCM hub used by the CI
The OCM hub and this chart (release `ocm-scheduler` in `hypo-scheduler-system`) are installed there by hand, once, before the first pipeline run. The hub is also used by the nightly tests.
The merge request pipeline only tests the Go code of the scheduler:
1. It builds the image `hypo-ocm-scheduler:<commit>`.
2. It sets it on the Deployment `ocm-scheduler-controller-manager` with `kubectl set image`. Helm is not used, and the chart, CRD and RBAC on the hub stay unchanged.
3. It runs the HypO OCM scenario (`@smoke-e2e-workflow-ocm`).
4. If the tests pass, the new image stays on the hub. If they fail, the previous image is put back.
Changes to the Helm chart, the CRD (`chart/ocm-scheduler-chart/crds/`) or the RBAC are applied to the hub by hand after the merge. Since the pipeline does not record the image in the Helm release, pass the image currently running on the hub, or Helm puts back the tag stored in the release (run from `chart/`):
```bash
TAG=$(kubectl get deploy ocm-scheduler-controller-manager -n hypo-scheduler-system \