rizblie
commented
2 years ago Just adding the output of velero restic repo get wordpress-primary-8gzr6 -o yaml on the secondary cluster. Again it shows the failed restic init on a repo that already exists. Why is it doing an init?
apiVersion: velero.io/v1
kind: ResticRepository
metadata:
creationTimestamp: "2022-10-05T18:23:05Z"
generateName: wordpress-primary-
generation: 3
labels:
velero.io/storage-location: primary
velero.io/volume-namespace: wordpress
managedFields:
- apiVersion: velero.io/v1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:generateName: {}
f:labels:
.: {}
f:velero.io/storage-location: {}
f:velero.io/volume-namespace: {}
f:spec:
.: {}
f:backupStorageLocation: {}
f:maintenanceFrequency: {}
f:resticIdentifier: {}
f:volumeNamespace: {}
f:status:
.: {}
f:message: {}
f:phase: {}
manager: velero-server
operation: Update
time: "2022-10-05T18:23:26Z"
name: wordpress-primary-8gzr6
namespace: velero
resourceVersion: "39841"
uid: ddca26ef-88e9-4055-bb99-b778038b8cb7
spec:
backupStorageLocation: primary
maintenanceFrequency: 168h0m0s
resticIdentifier: s3:s3-us-east-2.amazonaws.com/043124067543-velero-primary/restic/wordpress
volumeNamespace: wordpress
status:
message: |-
error running command=restic init --repo=s3:s3-us-east-2.amazonaws.com/043124067543-velero-primary/restic/wordpress --password-file=/tmp/credentials/velero/velero-restic-credentials-repository-password --cache-dir=/scratch/.cache/restic, stdout=, stderr=Fatal: create repository at s3:s3-us-east-2.amazonaws.com/043124067543-velero-primary/restic/wordpress failed: client.BucketExists: Head "https://043124067543-velero-primary.s3.dualstack.us-west-1.amazonaws.com/": 301 response missing Location header
: exit status 1
phase: NotReady
sseago
blackpiglet
Lyndon-Li
reasonerjt
What steps did you take and what happened:
Setup
Steps
Errors from restore describe as follows:
I am confused by the fact that the restore action is executing a
restic init. The repository already exists, so it just needs an integrity check?See attached debug bundle.
My helm values file for velero on the secondary is as follows: (primary is similar but ReadWrite, and different role with same permissions)
What did you expect to happen:
I expected the Restic volume restore to work in the secondary region, just as it did in the primary region.
The following information will help us better understand what's going on:
If you are using velero v1.7.0+:
Please use
velero debug --backup <backupname> --restore <restorename>to generate the support bundle, and attach to this issue, more options please refer tovelero debug --helpIf you are using earlier versions:
Please provide the output of the following commands (Pasting long output into a GitHub gist or other pastebin is fine.)
kubectl logs deployment/velero -n velerovelero backup describe <backupname>orkubectl get backup/<backupname> -n velero -o yamlvelero backup logs <backupname>velero restore describe <restorename>orkubectl get restore/<restorename> -n velero -o yamlvelero restore logs <restorename>Anything else you would like to add: I am not sure if this is a bug, or if I am doing something wrong in my config. It works fine on the same cluster in the same region, so what is different about a different cluster/region that I may have required a different config parameter somewhere?
Environment:
velero version): 1.9.2velero client config get features):kubectl version): v1.23.10-eks-15b7512/etc/os-release): Amazon Linux 2Vote on this issue!
This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.