Description of problem: At present the dynamic provisioner does not have the capability of taking input from the admin and define a specific volume type for a storage class. Dynamic provisioner should expose this feature to the storage admin. Version-Release number of selected component (if applicable): CNS 3.5 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This functionality has been added to Kube via https://github.com/kubernetes/kubernetes/pull/38579 . -snip-- from patch to show the usage. +* `volumetype` : The volume type and it's parameters can be configured with this optional value. If the volume type is not mentioned, it's up to the provisioner to decide the volume type. +For example: + 'Replica volume': + `volumetype: replicate:3` where '3' is replica count. + 'Disperse/EC volume': + `volumetype: disperse:4:2` where '4' is data and '2' is the redundancy count. + 'Distribute volume': + `volumetype: none` + --/snip--
This is backported to Origin by PR # https://github.com/openshift/origin/pull/12556
This functionality is available atleast from OCP version openshift v3.5.0.14+20b49d0.
Humble, can you also provide detail on how to create a distribute-replicate volume? When volumetype is set as 'none', volume is created out of a single brick. How should we define volume type for distribute and distribute replicate?
(In reply to krishnaram Karthick from comment #6) > Humble, > can you also provide detail on how to create a distribute-replicate volume? > When volumetype is set as 'none', volume is created out of a single brick. > How should we define volume type for distribute and distribute replicate? afaict, the decision is to support replicate 3 volumes in cluster. If that is the case, you can specify `replicate:3` in SC parameter list and make sure the backend volume is always have 3 replicas. In documentation we will mention, eventhough its possible to enable different volume types, the supported volume is of 'replica 3' .
Validation of this feature is completed. Moving this bug to verified.
Hi Ashiq, Humble: Updated the doc text. Kindly review and sign-off to be included in the errata.
I am not quite sure that we want this documented at all, because afaict, only replica-3 remains supported for CNS 3.5. So at least, in the doc text "Previously, Replica 3 volume was supported..." does not seem sufficient. In fact, replica-3 is still supported, and nothing else. So we have a new switch in the storage class, that we can only use to specify the default explicitly, in order to stay supported... what's the point? Apologies, I don't want to sound dismissive but I don't see the point.
(In reply to krishnaram Karthick from comment #6) > Humble, > can you also provide detail on how to create a distribute-replicate volume? > When volumetype is set as 'none', volume is created out of a single brick. > How should we define volume type for distribute and distribute replicate? The "volumeType" that can be set in kubernetes (storageClass), is NOT the same as the volume type of a gluster. It is the durability type that you can specify for heketi. E.g., you can only specify the replica aspect of a distribute-replicate volume. Heketi will figure out the number of replica sets for you. I.e if you go with the default of replica-3, you don't know in advance, and you can't control whether you get a 1x3, a 2x3, 3x3 or .... nx3 volume. This has not changed. The only change is that we can specify the durability type in the storage-class (under the name of volumeType).
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/RHEA-2017:1116