Description of problem: Please provide a way to use iSCSI persistent volumes as the persistent volume for the image registry when the registry is not going to be scaled. Use case: The customer only has access to storage solutions like NetApp Solidfire, which only provides iSCSI volumes, and hence the persistent volumes created are only able to have ReadWriteOnce permissions. The option of creating an NFS server as an alternate volume is discouraged by Red Hat Support (https://access.redhat.com/solutions/3428661 ) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Configure the image-registry operator to be managed. 2. Provide iscsi persistent volumes via NetApp Solidfire. 3. Get an error from the image-registry operator indicating that it doesn't have the right permissions. Actual results: Image Registry Operator throws the following error: 'Unable to apply resources: unable to sync storage configuration: PVC image-registry-solidfire-storage does not contain the necessary access mode (ReadWriteMany)' Expected results: Being able to have an iSCSI persistent volume for the Image Registry Additional info: Please note: 1. iSCSI persistent volumes are fully supported in OCP 4.3 as per the release notes: https://access.redhat.com/documentation/en-us/openshift_container_platform/4.3/html-single/release_notes/index#ocp-4-3-storage 2. The alternative to create a virtual machine that provides NFS is discouraged by Red Hat Support: https://access.redhat.com/solutions/3428661
We have an existing RFE for this use case [1] and are adding a feature in OCP 4.4 that will enable it [2]. Using RWO is possible by bringing your own PVC and backing volume [3] - however the current rollout strategy for the registry's deployment prevents the volume from being mounted during upgrade. The new feature will allow admins to set the rollout strategy to "Recreate", which allows the RWO PV to be mounted into the new registry pod on upgrade. [1] https://issues.redhat.com/browse/RFE-489 [2] https://issues.redhat.com/browse/DEVEXP-523 [3] https://docs.openshift.com/container-platform/4.3/registry/configuring-registry-storage/configuring-registry-storage-baremetal.html#registry-configuring-storage-baremetal_configuring-registry-storage-baremetal
This was fixed and verified by https://issues.redhat.com/browse/DEVEXP-523. Do you want to have it backported to 4.3?
(In reply to Oleg Bulatov from comment #3) > This was fixed and verified by https://issues.redhat.com/browse/DEVEXP-523. > > Do you want to have it backported to 4.3? Yes, please. Since that's the version that is actually out. Thank you, very much in advance.
Verified on 4.4.0-0.nightly-2020-02-06-230833: $ oc get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE registrypvc Bound pvc-b933321c-244f-41af-bad1-876544d1e9ad 1Gi RWO iscsi-targetd-vg-targetd 15m $ oc get pods NAME READY STATUS RESTARTS AGE cluster-image-registry-operator-df4ccc5c9-jzhnj 2/2 Running 0 121m image-registry-5b75d4844d-pqdpk 1/1 Running 0 12m node-ca-8dhdb 1/1 Running 0 118m node-ca-9bh7d 1/1 Running 0 118m node-ca-kllc4 1/1 Running 0 118m node-ca-knzln 1/1 Running 0 121m node-ca-nnxqs 1/1 Running 0 121m node-ca-p5494 1/1 Running 0 121m
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/RHBA-2020:0581