Description of problem: When accidentally trying to create an UploadTokenRequest for a pvc that doesn't exist in the specified namespace. Version-Release number of selected component: hco v2.0.0-30 How reproducible: 100% Steps to Reproduce: Create an upload token for a pvc that doesn't exist in the specified namespace. Example yaml: apiVersion: upload.cdi.kubevirt.io/v1alpha1 kind: UploadTokenRequest metadata: name: upload-datavolume-token-2 namespace: kubevirt-hyperconverged spec: pvcName: upload-datavolume-2 Command: kubectl apply -f t2.yaml -o="jsonpath={.status.token}" Actual results: Error from server (BadRequest): error when creating "t2.yaml": the server rejected our request for an unknown reason (post uploadtokenrequests.upload.cdi.kubevirt.io) Expected results: Something of that sort: Error from server ... the specified pvc wasn't found in namespace <current-namespace>
There is a check if the PVC exists that use the error received from the API: https://github.com/kubevirt/containerized-data-importer/blob/master/pkg/apiserver/apiserver.go#L343 Note there is a log with the reason that the request was rejected: klog.Infof("Rejecting request for PVC %s that doesn't exist", pvcName) I will see if I can create a more detail message that will get back to the user. I don't think it is a medium severity/priority, should be low.
Hi Freddy, any updates on this one?
Pushing low severity bugs out to 2.4.
Alexander, could you help to give the update on this bug?
No updates, its low priority and not an easy fix, other things are taking priority.
Can you elaborate why it's not an easy fix? If we need to track this as an RFE in order to get it worked on that's fine but I'd like to at least understand how much effort it would take. We have been carrying this for too many releases.
Because everything we can do on our end, we already do. We check in the api server if the PVC exists, and if it does not, we return a 400 (BadRequest) with the error [0]. How or why kubectl turns that into "Error from server (BadRequest): error when creating "upload-token.yaml": the server rejected our request for an unknown reason (post uploadtokenrequests.upload.cdi.kubevirt.io)", I don't know. I can understand the BadRequest (thats the 400), but we do pass the error message as well, and that is not displayed. We might be able to figure out if there is something better we can send to the client so it can display the error message. That would be the part that is not an easy fix. [0] https://github.com/kubevirt/containerized-data-importer/blob/master/pkg/apiserver/apiserver.go#L312
If I remember correctly, creating a VM with an invalid spec gives us a more informative message. Can we do something similar in our case?
The difference between this case and a VM is that we don't have a CRD so cannot perform special validation. We don't have much opportunity to change the error as reported by the kubernetes API server as it currently is implemented. We could investigate if we can always grant the token and have the upload proxy server report a better error message instead when a valid token refers to a non-existent PVC. It also might be worth checking if we report a good error message when the PVC exists but is not bound.
Allowing the token to be created and having the proxy reject the request seems to work well.
Created the following token: $ cat token.yaml apiVersion: upload.cdi.kubevirt.io/v1alpha1 kind: UploadTokenRequest metadata: name: upload-dv namespace: recycle-pvs spec: pvcName: upload Still getting: kubectl apply -f token.yaml -o="jsonpath={.status.token}" Error from server (BadRequest): error when creating "token.yaml": the server rejected our request for an unknown reason (post uploadtokenrequests.upload.cdi.kubevirt.io)
I wonder if this could be due to the wrong container image being pulled into the compose. @awels can you compare the md5sums and see if this is the case.
@Natalie, can you provide me access to the cluster that has this problem?
@Natalie, perhaps it would be easier if you attempt to verify this again with the latest builds in case something was messed up with the compose.
If it fails again, can you give me access to the cluster so I can investigate the version of the container?
In the latest build (CNV 2.4), it works as expected. A. The token is created successfully. B. The upload fails with a message saying "rejecting Upload Request for PVC upload that doesn't exist"
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:3194