-
Notifications
You must be signed in to change notification settings - Fork 34
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
Check claimName on DV status #530
Conversation
43417c8
to
b24805f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change is ok but the commit is strange. The PVC is created by the DV. Isn't dv.PVC should be the created PVC by the DV?
I'll have to look at this again, I got fooled by the name of the object, this is not the CDI DataVolume, it's our DataVolume[1] wrapper... [1] forklift/pkg/controller/plan/kubevirt.go Line 1690 in 76efe8a
|
ok, so the wrapper is only populated when calling VirtualMachineMap |
It seems like dv.PVC is always nil because we don't create a DV from a PVC, this leads to failing to find the DV whenever the importer pod fails and it will restart forever instead of 3 times Signed-off-by: Benny Zlotnik <[email protected]>
Make it slightly less confusing Signed-off-by: Benny Zlotnik <[email protected]>
c2178e5
to
7ea8beb
Compare
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
Created #539 |
It seems like dv.PVC is always nil because we don't create a DV from a PVC, this leads to failing to find the DV whenever the importer pod fails and it will restart forever instead of 3 times