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
* 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.
* `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
Previously the chart's values were not set, relying on the
values that are already present in the cluster and reusing
those. This does not work as e.g. the image values
are only set while loading the charts. Also, the templates
are not rendered correctly without all values set.
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.
* 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.