* Wait for CRDs to be available and ready
When restoring CRDs, we should wait for the definition to be ready and
available before moving on to restoring specific CRs.
While the CRDs are often ready by the time we get to restoring a CR,
there is a race condition where the CRD isn't ready.
This change waits on each CRD at restore time.
Signed-off-by: Nolan Brubaker <brubakern@vmware.com>
* Pruning unknown fields
In CRD apiversion v1beta1, default preserveUnknownFields=true.
In CRD apiversion v1, the preserveUnknownFields can only be false.
Otherwise, the k8s validation bumps out error message for the
invalid preserveUnknownFields value.
Deploy Velero on k8s 1.16+ with CRD apiversion v1beta1, the
k8s cluster converts apiversion from v1beta1 to v1 automatically.
Fully backup and restore the cluster, restore bumps out error message
due to the preserveUnknownFields=true is not allowed on k8s 1.16+.
Since the CRD structural schema had been defined, enable the preserveUnknownFields
to false to solves the restore bumps out error message on k8s 1.16+.
Signed-off-by: JenTing Hsiao <jenting.hsiao@suse.com>
* Add changelog
Signed-off-by: JenTing Hsiao <jenting.hsiao@suse.com>
(for some reason, basic Kubernetes is able to run a Debian based container with nobody:nobody but
docker run and VMware WCP fail which should be expected behavior)
Signed-off-by: Dave Smith-Uchida <dsmithuchida@vmware.com>
Velero client config file should have restricted file permissions to be
read/write-able for the user that creates it--similiar to files like
`.ssh/id_rsa`
Refer to OTG-CONFIG-009: Test File Permission
> Impoper file permission configuration may result in privilledge
escalation, information explousure, DLL injection, or unauthorized file
access.
Therefore, files permission must be properly configured with minium
access permission by default.
[source](https://www.owasp.org/index.php/Test_File_Permission_(OTG-CONFIG-009))
Ticket: #1758
Signed-off-by: John Naulty <johnnaulty@bitgo.com>
* Check for nil LastMaintenanceTime in dueForMaintenance
ResticRepository.dueForMaintenance causes a panic in the velero pod
("invalid memory address or nil pointer dereference") if
repository.Status.LastMaintenanceTime is nil. This fix returns 'true'
if it's nil, so the repository is due for maintenance if LastMaintenanceTime
is nil *or* the time elapsed since the last maintenance is greater than
repository.Spec.MaintenanceFrequency.Duration
Signed-off-by: Scott Seago <sseago@redhat.com>
* changelog for PR#2200
Signed-off-by: Scott Seago <sseago@redhat.com>
* update revision of go-hclog to match go.mod requirement
Signed-off-by: Steve Kriss <krisss@vmware.com>
* update prometheus dep to prepare for go module migration
Signed-off-by: Steve Kriss <krisss@vmware.com>
Install restic with CPU/Memory limits is optional.
If velero cannot parse resource requirements, use default value instead.
After that, the administrator won't get confused that something recovered failed.
Signed-off-by: JenTing Hsiao <jenting.hsiao@suse.com>
Ashish Amarnath
Jonas Rosland
Steve Kriss
Carlos Panato
Carlisia Campos
Nolan Brubaker
JenTing Hsiao
Patrik Cyvoct
David L. Smith-Uchida
John Naulty
Scott Seago
Prajyot-Parab
Shuwei Hao