Git-Mirrors/constellation
1
0
Fork 0
mirror of https://github.com/edgelesssys/constellation.git synced 2025-05-02 14:26:23 -04:00
Code Issues Projects Releases Packages Wiki Activity

docs: refer to apply command instead of init or upgrade apply (#2487)

Browse source 
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
This commit is contained in:
Daniel Weiße 2023-10-27 08:30:59 +02:00 • committed by GitHub
parent fff35bdb2a
commit f4bfbe3564
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
18 changed files with 49 additions and 40 deletions
Download patch file Download diff file Expand all files Collapse all files

2
dev-docs/workflows/debug-cluster.md
View file

@ -45,7 +45,7 @@ Create the cluster and deploy the debug images:
Finally run:
```sh
./constellation init
./constellation apply
```
## Access bootstrapper logs

2
dev-docs/workflows/release.md
View file

@ -62,7 +62,7 @@ Releases should be performed using [the automated release pipeline](https://gith
./constellation upgrade check --update-config
yq eval -i '.image="vX.YY.Z"' constellation-conf.yaml
./constellation config fetch-measurements
./constellation upgrade apply --yes --debug
./constellation apply --yes --debug
```
Then wait until the node / Kubernetes upgrades are finished by periodically checking:

8
dev-docs/workflows/versions-support.md
View file

@ -4,20 +4,20 @@ This explains the support and compatibility of the different versions that are p
## Microservice version
(the version that is referenced in the config during constellation init or referenced as target version during upgrade apply) must match the CLI version exactly (down to the version suffix). When planning an upgrade, the source version (current version before the upgrade is applied) may be up to one minor version older (allow upgrades from v2.8.x to v2.9.x).
(the version that is referenced in the config during `constellation apply`) must match the CLI version exactly (down to the version suffix). When planning an upgrade, the source version (current version before the upgrade is applied) may be up to one minor version older (allow upgrades from v2.8.x to v2.9.x).
The reason is this: The CLI embeds exactly one version of the helm charts (the version of the CLI). So whenever we deploy the helm charts, we can only use the embedded chart version.
The source version can only be older by one minor version to ensure we can perform safe upgrades where we can reasonably test what microservice versions will interact with other versions of CLI, OS images, other microservices.
## Kubernetes version
(the version that is referenced in the config during constellation init or referenced as target version during upgrade apply) must match one of the embedded k8s versions. We have a hardcoded list that is embedded in the CLI.
(the version that is referenced in the config during `constellation apply`) must match one of the embedded k8s versions. We have a hardcoded list that is embedded in the CLI.
When planning an upgrade, the source k8s version may be up to one minor version older (allow upgrades from k8s 1.25.x to 1.26.x).
The reason is this: The CLI embeds components for kubernetes version for the hardcoded list of supported k8s versions. So whenever we deploy a k8s version (during constellation init or constellation upgrade apply), the k8s components for the target version need to be available.
The reason is this: The CLI embeds components for kubernetes version for the hardcoded list of supported k8s versions. So whenever we deploy a k8s version (during `constellation apply`), the k8s components for the target version need to be available.
The source version drift is a general k8s recommendation: k8s was designed to withstand a version drift of one minor version in each component during a rolling upgrade.
## Image version
(the version that is referenced in the config during constellation init or referenced as target version during upgrade apply) must have the same major and minor version (but can have a different patch or suffix) when upgrading compared to the cli. Examples: CLI v2.8.2 could correctly upgrade to OS image v2.8.1 or v2.8.2-nightly-foo-bar.
(the version that is referenced in the config during `constellation apply`) must have the same major and minor version (but can have a different patch or suffix) when upgrading compared to the cli. Examples: CLI v2.8.2 could correctly upgrade to OS image v2.8.1 or v2.8.2-nightly-foo-bar.
When planning an upgrade, the source image version may be up to one minor version older (allow upgrades from v2.8.x to 2.9.x).
The reason is this: The CLI uses an API endpoint to query configuration and measurements for a configured target image. This generally allows for arbitrary image versions to be referenced/deployed by the CLI. However, to ensure safe upgrades, we always upgrade by at most one minor version and ensure that the CLI is at the same minor version that we target.
This allows us to test upgrades with only a reasonable amount of moving parts.