3 The upgrade of the compute cluster components is managed via Flux
4 resources. Please refer to the [Flux](https://fluxcd.io) documentation
7 The upgrade of jump server components is described below. In general
8 the safest path will be to first clean the component and then deploy
9 it; not all components support in-place upgrades so skipping the clean
10 step may lead to a broken deployment.
12 Please refer to the upstream component documentation for information
13 about support of in-place upgrades.
17 The jump server controllers include Flux, Cluster API, Bare Metal
18 Operator, cert-manager, and Ironic.
20 The Makefile `controllers` and `controllers_clean` targets deploy and
21 clean the controllers. To upgrade, first:
23 make controllers_clean
25 followed by updating the ICN repository, and finally:
29 Individual controllers can be cleaned and deployed with the
30 `COMPONENT` and `COMPONENT_clean` targets. Refer to the top-level
31 `Makefile` for a complete list of controller targets.
35 The jump server tools include CLI tools used during deployment and
36 management of jump server controllers. The tools include kustomize,
37 clusterctl, flux, sops, and emcoctl.
39 There is no clean step necessary for tools. Deploying again simply
40 overwrites the existing tool versions:
46 > NOTE: Upgrade of the base K8s components using the method describe
47 > below is destructive. Any information about the compute clusters
50 The Makefile `management_cluster` and `management_cluster_clean`
51 targets deploy and clean the jump server K8s cluster. To upgrade,
54 make management_cluster_clean
56 followed by updating the ICN repository, and finally:
58 make management_cluster
62 > NOTE: Upgrade using the method describe below is destructive. Any
63 > information about the compute clusters will be destroyed.
65 The Makefile `jump_server` and `jump_server_clean` targets deploy and
66 clean the jump server. To upgrade, first:
68 make jump_server_clean
70 followed by updating the ICN repository, and finally: