The variable VersionInfo is supposed to be set by `go build -X ...` during link time but should not be modified at runtime.
This change ensures the underlying var is private and can only be accessed by a public getter.
* As charts receive information like the container image from
the cli it makes sense to also version the charts based on the cli
version.
* The pseudoversion is recalculated when running cmake.
* When merging changes from release branch to main,
a new commit is introduced to set the PROJECT_VERSION back
to 0.0.0, so that builds include a pseudoversion.
Because values in the charts might change in the future and
some values (like the image) are part of a valid upgrade we
need to load all values for an upgrade.
However, during upgrades we don't want to reapply user
input like the masterSecret. Therefore this patch splits the
application of user input and the static loading of chart values.
Upgrade check is used to find updates for the current cluster.
Optionally the found upgrades can be persisted to the config
for consumption by the upgrade-execute cmd.
The old `upgrade execute` in this commit does not work with
the new `upgrade plan`.
The current versions are read from the cluster.
Supported versions are read from the cli and the versionsapi.
Adds a new config field MicroserviceVersion that will be used
by `upgrade execute` to update the service versions.
The field is optional until 2.7
A deprecation warning for the upgrade key is printed during
config validation.
Kubernetes versions now specify the patch version to make it
explicit for users if an upgrade changes the k8s version.
In the light of extending our eKMS support it will be helpful
to have a tighter use of the word "KMS".
KMS should refer to the actual component that manages keys.
The keyservice, also called KMS in the constellation code,
does not manage keys itself. It talks to a KMS backend,
which in turn does the actual key management.
Run with: constellation upgrade execute --helm.
This will only upgrade the helm charts. No config is needed.
Upgrades are implemented via helm's upgrade action, i.e. they
automatically roll back if something goes wrong. Releases could
still be managed via helm, even after an upgrade with constellation
has been done.
Currently not user facing as CRD/CR backups are still in progress.
These backups should be automatically created and saved to the
user's disk as updates may delete CRs. This happens implicitly
through CRD upgrades, which are part of microservice upgrades.
* Merge enforced and expected measurements
* Update measurement generation to new format
* Write expected measurements hex encoded by default
* Allow hex or base64 encoded expected measurements
* Allow hex or base64 encoded clusterID
* Allow security upgrades to warnOnly flag
* Upload signed measurements in JSON format
* Fetch measurements either from JSON or YAML
* Use yaml.v3 instead of yaml.v2
* Error on invalid enforced selection
* Add placeholder measurements to config
* Update e2e test to new measurement format
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
* Include EXC0014 and fix issues.
* Include EXC0012 and fix issues.
Signed-off-by: Fabian Kammel <fk@edgeless.systems>
Co-authored-by: Otto Bittner <cobittner@posteo.net>
* Wrap KMS deployment in one main chart that
deploys all other services. Other services will follow.
* Use .tgz via helm-package as serialization format
* Change Release type to carry chart as byte slice
* Remove KMSConfig
* Use json-schema to validate values
* Extend release.md to mention updating helm charts
* Mini Constellation commands to quickly deploy a local Constellation cluster
* Download libvirt container image if not present locally
* Fix libvirt KVM permission issues by creating kvm group using host GID inside container
* Remove QEMU specific values from state file
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
Co-authored-by: Nils Hanke <nils.hanke@outlook.com>
