Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When remapping namespaces, PVs without snapshots don't get their ClaimRefs remapped. #3707

Closed
sseago opened this issue Apr 20, 2021 · 7 comments · Fixed by #3708
Closed

When remapping namespaces, PVs without snapshots don't get their ClaimRefs remapped. #3707

sseago opened this issue Apr 20, 2021 · 7 comments · Fixed by #3708

Comments

@sseago
Copy link
Collaborator

sseago commented Apr 20, 2021

What steps did you take and what happened:
Restored a PV (without a snapshot) and the PVC it's bound to into a different namespace. The PVC was restored but "pending", with an error that the PV was bound to another claim. The reason for this is that the ClaimRef was not updated to the new namespace. The ClaimRef remapping is only currently done in restore/restore.go when there's a snapshot. It's also needed in the non-snapshot case.

What did you expect to happen:
Expected the PVC restored to the new namespace to be bound to its PV.

The output of the following commands will help us better understand what's going on:
(Pasting long output into a GitHub gist or other pastebin is fine.)

Anything else you would like to add:
Observed this on 1.5.2, but the problem exists on main as well

Environment:

  • Velero version (use velero version): 1.5.2
  • Kubernetes version (use kubectl version): 1.19
  • Cloud provider or hardware configuration: OpenShift on AWS

PR forthcoming, as I have a working local fix.

@sseago
Copy link
Collaborator Author

sseago commented Apr 20, 2021

Related to #2570 and #3007
The earlier PR/issue dealt with this for PVs with snapshots, but not for PVs without them.

@sseago
Copy link
Collaborator Author

sseago commented Apr 20, 2021

PR to fix this is at #3708

@stale
Copy link

stale bot commented Jul 11, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the staled label Jul 11, 2021
@sseago
Copy link
Collaborator Author

sseago commented Jul 12, 2021

Actually, this one shouldn't be considered stale. There's an open PR that fixes the issue currently under review, awaiting feedback from the questions I had asked in response to the first review.

@stale stale bot removed the staled label Jul 12, 2021
@stale
Copy link

stale bot commented Sep 10, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the staled label Sep 10, 2021
@sseago
Copy link
Collaborator Author

sseago commented Sep 10, 2021

Not stale -- PR has just been updated, but merging is on hold until 1.7 release branch is created.

@stale stale bot removed the staled label Sep 10, 2021
@stale
Copy link

stale bot commented Nov 10, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the staled label Nov 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants