Bug 2211568
| Summary: | Image-upload hangs when access mode is not specified | ||
|---|---|---|---|
| Product: | Container Native Virtualization (CNV) | Reporter: | David Sedgmen <dsedgmen> |
| Component: | Storage | Assignee: | Adam Litke <alitke> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Natalie Gavrielov <ngavrilo> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.12.3 | CC: | yadu |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-06-21 12:49:41 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
It looks like caused by incompleted storage profile, could you please attach the storage class yaml and storage profile yaml? The storage profile has the same name as storage class. My Test environment has expired, so I not able to retrieve the SC any more. I replicated on 2 types storage profiles. One was using an upstream nfs provisoner https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner/blob/master/charts/nfs-subdir-external-provisioner/README.md Which generates a default SC and is meant to default to ReadWriteOnce. The other was iSCSI using the kubernetes.io/no-provisioner which I did try setting the access mode in, but it just dropped it. kind: PersistentVolume apiVersion: v1 metadata: name: iscsi-pv-01 uid: 548684e5-36e1-4686-90db-bfe5b5b7c04b resourceVersion: '41320730' creationTimestamp: '2023-06-01T00:26:44Z' finalizers: - kubernetes.io/pv-protection managedFields: - manager: kube-controller-manager operation: Update apiVersion: v1 time: '2023-06-01T00:26:44Z' fieldsType: FieldsV1 fieldsV1: 'f:status': 'f:phase': {} subresource: status - manager: kubectl-create operation: Update apiVersion: v1 time: '2023-06-01T00:26:44Z' fieldsType: FieldsV1 fieldsV1: 'f:spec': 'f:accessModes': {} 'f:capacity': .: {} 'f:storage': {} 'f:iscsi': .: {} 'f:fsType': {} 'f:iqn': {} 'f:iscsiInterface': {} 'f:lun': {} 'f:targetPortal': {} 'f:persistentVolumeReclaimPolicy': {} 'f:storageClassName': {} 'f:volumeMode': {} spec: capacity: storage: 100Gi iscsi: targetPortal: '*******' iqn: '*******' lun: 0 iscsiInterface: default fsType: ext4 accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: iscsi-ssd volumeMode: Filesystem status: phase: Available Hi, David Thanks for reporting the bug, but unfortunately we still need the storage class and storage profile yaml for future debugging. Please feel free to reopen it once you could get the storage class and storage profile information. *** Bug 2211571 has been marked as a duplicate of this bug. *** btw, could you please try the nfs with ReadWriteMany to see whether it is working? The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days |
Description of problem: Image-upload hangs when access mode is not specified because it will not create the pvc Version-Release number of selected component (if applicable): virtctl version Client Version: version.Info{GitVersion:"v0.58.1-57-gfa16ad5c8", GitCommit:"fa16ad5c8189c14e3adf4e757dbfbc68216af85f", GitTreeState:"clean", BuildDate:"2023-05-11T05:38:34Z", GoVersion:"go1.18.10", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{GitVersion:"v0.58.1-57-gfa16ad5c8", GitCommit:"fa16ad5c8189c14e3adf4e757dbfbc68216af85f", GitTreeState:"clean", BuildDate:"2023-05-11T05:40:21Z", GoVersion:"go1.19.6", Compiler:"gc", Platform:"linux/amd64"} kubevirt-virtctl-4.12.3-1137.el8.x86_64 OpenShift version: 4.12.11 How reproducible: Everytime Steps to Reproduce: 1. Setup either iscsi persistent storage or nfs dynamic provisioner 2. Try to create image dv Actual results: ~~~ [kni@localhost iscsi]$ virtctl image-upload dv openstack-base-img3 -n openstack --size 50Gi --image-path=/var/lib/libvirt/images/rhel-8.4-x86_64-kvm.qcow2 --insecure --storage-class=iscsi-ssd --block-volume PVC openstack/openstack-base-img3 not found DataVolume openstack/openstack-base-img3 created Waiting for PVC openstack-base-img3 upload pod to be ready... ^Z [1]+ Stopped virtctl image-upload dv openstack-base-img3 -n openstack --size 50Gi --image-path=/var/lib/libvirt/images/rhel-8.4-x86_64-kvm.qcow2 --insecure --storage-class=iscsi-ssd --block-volume [kni@localhost iscsi]$ bg [1]+ virtctl image-upload dv openstack-base-img3 -n openstack --size 50Gi --image-path=/var/lib/libvirt/images/rhel-8.4-x86_64-kvm.qcow2 --insecure --storage-class=iscsi-ssd --block-volume & [kni@localhost iscsi]$ oc get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE openstack-base-img Bound pvc-22c71b48-e6a9-47d0-8547-31e882791889 56811736720 RWX nfs-client-share 5h9m openstack-base-img2 Bound iscsi-pv-04 100Gi RWO iscsi-ssd 4h58m <---- one created with --access-mode ReadWriteOnce openstackclient-cloud-admin Bound pvc-95ad1133-63ef-4ddc-8d90-0fbaf9f56a02 4G RWO nfs-client 26h openstackclient-hosts Bound pvc-f49066ac-4824-46c1-81e4-ba181ec17ac3 1G RWO nfs-client 26h openstackclient-kolla-src Bound pvc-894cf9ac-8b1b-4816-947f-cb2026e1b410 1G RWO nfs-client 26h ~~~ Expected results: To use a default access-mode or to error out with a meaningful error Additional info: Seems to be a reversion of https://bugzilla.redhat.com/show_bug.cgi?id=2126104