Bug 1798759 - Provide a way to use iSCSI persistent volumes for the Image Registry
Summary: Provide a way to use iSCSI persistent volumes for the Image Registry
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Image Registry
Version: 4.3.0
Hardware: All
OS: All
unspecified
high
Target Milestone: ---
: 4.4.0
Assignee: Oleg Bulatov
QA Contact: Wenjing Zheng
URL:
Whiteboard:
Depends On:
Blocks: 1799447
TreeView+ depends on / blocked
 
Reported: 2020-02-05 22:17 UTC by Jose Kaz C R
Modified: 2020-05-04 11:34 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: the image-registry was using RollingUpdate strategy that is not compatible with RWO volumes Consequence: RWO volumes couldn't be used Fix: allow to pick the deployment strategy Result: the image-registry can be deployed with RWO volumes in non-high-available configurations (i.e. with only 1 replica)
Clone Of:
: 1799447 (view as bug list)
Environment:
Last Closed: 2020-05-04 11:34:08 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:0581 0 None None None 2020-05-04 11:34:29 UTC

Description Jose Kaz C R 2020-02-05 22:17:14 UTC
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

Comment 2 Adam Kaplan 2020-02-06 16:17:45 UTC
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

Comment 3 Oleg Bulatov 2020-02-06 16:58:53 UTC
This was fixed and verified by https://issues.redhat.com/browse/DEVEXP-523.

Do you want to have it backported to 4.3?

Comment 4 Jose Kaz C R 2020-02-06 17:03:24 UTC
(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.

Comment 6 Wenjing Zheng 2020-02-07 04:27:34 UTC
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

Comment 8 errata-xmlrpc 2020-05-04 11:34:08 UTC
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


Note You need to log in before you can comment on or make changes to this bug.