1. Check the error when waiting for restice daemonset to be ready, so
the timeout will be reported
2. Add support for gcp provider and fail early if the provider is
unknown
Signed-off-by: Daniel Jiang <jiangd@vmware.com>
This PR added a subcommand `velero debug`, which leverages `crashd` to
collect logs and specs of velero server components and bundle them in a
tarball.
Signed-off-by: Daniel Jiang <jiangd@vmware.com>
Do this for two reasons:
1. Verify the functionalities for installation and uninstllation of CLI
2. We want to add upgrade test case which needs to install different versions of velero, calling libraries is impossible for this
fixes#4062
Signed-off-by: Wenkai Yin(尹文开) <yinw@vmware.com>
* Add document for TLS error 116
When using a custom S3 compatible server, backups/restore may fail with
TLS error 116. This happens because the S3 server expects Velero to
send client certificate during SSL TLS v1.3 handshake.
You will need to modify your S3 server settings to turn off client
certificate authentication.
Signed-off-by: Himanshu Mehra <himanshu.mehra91@gmail.com>
* Add document for TLS error 116
When using a custom S3 compatible server, backups/restore may fail with
TLS error 116. This happens because the S3 server expects Velero to
send client certificate during SSL TLS v1.3 handshake.
You will need to modify your S3 server settings to turn off client
certificate authentication.
Signed-off-by: Himanshu Mehra <himanshu.mehra91@gmail.com>
* Address comments from reviewers
Signed-off-by: Himanshu Mehra <himanshu.mehra91@gmail.com>
Wait the namespace deletion completed before removing the CRDs when uninstalling the velero
Fixes#3974
Signed-off-by: Wenkai Yin(尹文开) <yinw@vmware.com>
a timestamp. If two requests were happening very close together for the
same backup, the second would fail randomly.
Signed-off-by: Dave Smith-Uchida <dsmithuchida@vmware.com>
Fix the random failure by increasing the timeout and introducing few minor refactor/bug fixes
Fixes#3970
Signed-off-by: Wenkai Yin(尹文开) <yinw@vmware.com>
Instead of converting the unstructured item to check for the presence of
the `kube-aggregator.kubernetes.io/automanaged` label, use this label in
the `AppliesTo` to enable the restore logic to select the item. This
means that any item that matches the selector will have restore skipped.
Also add a new test case to the restore action test to check that label
selectors are applied correctly.
Signed-off-by: Bridget McErlean <bmcerlean@vmware.com>
It was discovered during Velero 1.6.3 upgrade testing that Velero was
restoring `APIService` objects for APIs that are no longer being served
by Kubernetes 1.22. If these items were restored, it would break the
behaviour of discovery within the cluster.
This change introduces a new RestoreItemAction plugin that skips the
restore of any `APIService` object which is managed by Kubernetes such
as those for built-in APIs or CRDs. The `APIService`s for these will be
created when the Kubernetes API server starts or when new CRDs are
registered. These objects are identified by looking for the
`kube-aggregator.kubernetes.io/automanaged` label.
Signed-off-by: Bridget McErlean <bmcerlean@vmware.com>
* Use appropriate CRD API during readiness check
The readiness check for the Velero CRDs was still using the v1beta1 API.
This would cause the readiness check to fail on 1.22 clusters as the
v1beta1 API is no longer available. Previously, this error would be
ignored and the installation would proceed, however with #4002, we are
no longer ignoring errors from this check.
This change modifies the CRD readiness check to check the CRDs using the
same API version that was used when submitting the CRDs to the cluster.
It also introduces a new CRD builder using the V1 API for testing.
This change also fixes a bug that was identified in the polling code
where if the CRDs were not ready on the first polling iteration, they
would be added again to the list of CRDs to check resulting in
duplicates. This would cause the length check to fail on all subsequent
polls and the timeout would always be reached.
Signed-off-by: Bridget McErlean <bmcerlean@vmware.com>
* Remove duplicate V1 CRD builder and update comment
Signed-off-by: Bridget McErlean <bmcerlean@vmware.com>
Add the image pull secret to the service account when deploying velero and kibishii to avoid the image pull limit issue of Docker Hub
Fixes#3966
Signed-off-by: Wenkai Yin(尹文开) <yinw@vmware.com>
The backup name must be no more than 63 characters otherwise we'll get error on vSphere platform:
Failed to create snapshot record: Snapshot.backupdriver.cnsdp.vmware.com \"snap-8945e7df-069e-4f56-aeb5-75b1dd87547f\" is invalid: metadata.labels: Invalid value: \"backup-bsl-e7a1d0f3-2f29-4d80-9184-6214dac91d96-e7a1d0f3-2f29-4d80-9184-6214dac91d96\": must be no more than 63 characters"
Signed-off-by: Wenkai Yin(尹文开) <yinw@vmware.com>
If the Velero CLI can't discover the Kubernetes preferred CRD API
version, use the flag --crds-version to determine the CRDs version.
Signed-off-by: JenTing Hsiao <jenting.hsiao@suse.com>
As we add more E2E test cases, this'll cause the job takes a lot of time before checking pass for the pull requests, this commit changes the test cases(only basic cases) runs for PR
Signed-off-by: Wenkai Yin(尹文开) <yinw@vmware.com>