* Add attestation type to config (optional for now)
* Get attestation variant from config in CLI
* Set attestation variant for Constellation services in helm deployments
* Remove AzureCVM variable from helm deployments
---------
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
* build: correct toolchain order
* build: gazelle-update-repos
* build: use pregenerated proto for dependencies
* update bazeldnf
* deps: tpm simulator
* Update Google trillian module
* cli: add stamping as alternative build info source
* bazel: add go_test wrappers, mark special tests and select testing deps
* deps: add libvirt deps
* deps: go-libvirt patches
* deps: cloudflare circl patches
* bazel: add go_test wrappers, mark special tests and select testing deps
* bazel: keep gazelle overrides
* bazel: cleanup bazelrc
* bazel: switch CMakeLists.txt to use bazel
* bazel: fix injection of version information via stamping
* bazel: commit all build files
* dev-docs: document bazel usage
* deps: upgrade zig-cc for go 1.20
* bazel: update Perl for macOS arm64 & Linux arm64 support
* bazel: use static perl toolchain for OpenSSL
* bazel: use static protobuf (protoc) toolchain
* deps: add git and go to nix deps
Co-authored-by: Paul Meyer <49727155+katexochen@users.noreply.github.com>
* Add missing flag to miniConstellation
* Add config merger to miniConstellation
* Soft fail if config can not be merged
* Remove config flattening
* Release spinner stop lock when stopping finished
---------
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
Co-authored-by: Nils Hanke <nils.hanke@outlook.com>
This is a measure to detect cases where an aTLS handshake is performed but the long running call is interrupted, leading to a retry of the init call.
Whenever the grpc connection state reaches ready, we know that the aTLS handshake has succeeded:
> READY: The channel has successfully established a connection all the way through TLS handshake (or equivalent) and protocol-level (HTTP/2, etc) handshaking, and all subsequent attempt to communicate have succeeded (or are pending without any known failure).
Applies the updated NodeVersion object with one request
instead of two. This makes sure that the first request does
not accidentially put the cluster into a "updgrade in progress"
status. Which would lead users to having to run apply twice.
* Move storage clients to separate packages
* Allow setting of client credentials for AWS S3
* Use managed identity client secret or default credentials for Azure Blob Storage
* Use credentials file to authorize GCS client
---------
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
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.
* replace tf destruction with new command
* move iam destroy cmd
* fix typos
* exit post test on error
* [remove] test failure on iam destroy
* Revert "[remove] test failure on iam destroy"
This reverts commit 99449c0cc0.
* [remove] test failure on terminate
* Revert "[remove] test failure on terminate"
This reverts commit 99c45bbc54.
* gofumpt
* `upgrade apply` will try to make the locally configured and
actual version in the cluster match by appling necessary
upgrades.
* Skip image or kubernetes upgrades if one is already
in progress.
* Skip downgrades/equal-as-running versions
* Move NodeVersionResourceName constant from operators
to internal as its needed in the CLI.
* introduce handleImageUpgrade & handleServiceUpgrade
* rename cloudUpgrader.Upgrade to UpgradeImage
* remove helm flag
* remove hint about development status
* Generate kubeconfig with unique name
* Move create name flag to config
* Add name validation to config
* Move name flag in e2e tests to config generation
* Remove name flag from create
* Update ascii cinema flow
---------
Signed-off-by: Daniel Weiße <dw@edgeless.systems>
* AB#2787 add debug logging to iam create command
* AB#2787 add test logger
* AB#2787 reword log
* separate debug output with empty line
Co-authored-by: Daniel Weiße <66256922+daniel-weisse@users.noreply.github.com>
---------
Co-authored-by: Daniel Weiße <66256922+daniel-weisse@users.noreply.github.com>
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.
Version validation checks that the configured versions
are not more than one minor version below the CLI's version.
The validation can be disabled using --force.
This is necessary for now during development as the CLI
does not have a prerelease version, as our images do.
