Fedora Account System
Red Hat Associate
Red Hat Customer
When an Openshift Glusterfs provisioner asks for a new volume from Heketi, volumes are created with a naming convention of “vol_<UUID>” to ensure unique volume names. Managing hundreds of volumes with 'random' names makes gluster management and monitoring very problematic. Additionally, the "_" underscore in a volume name results in those volumes not being exportable via Gluster Swift. This request is to enable custom naming via a Storage Class parameter similar to: userFriendlyNames: "yes" If set, we can create volumes with a name built up of: "<OC-namespace>-<UUID>-<OC-PVCname>" (no use of underscores) It would be desirable if brick names belonging to that volume could inherit same naming format. Humble Chirammal kindly requested this RFE be assigned to him. This RFE is for an important Gluster opportunity and Sergi Jimenez Romero is the TAM for the account.
Humble, Volumes with underscores in names cannot be exported through Gluster Swift, this is a well known limitation, documented in our admin guide: https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.2/html-single/administration_guide/#Limitations4 Please, it would be very desirable to avoid underscores in volume names, as spoken. Is it not possible to use dash "-" as separator for proposed volume name: <namespace>-<UUID>-<pvcname> ? Thanks, Luis
(In reply to Luis Rico from comment #9) > Humble, > Volumes with underscores in names cannot be exported through Gluster Swift, > this is a well known limitation, documented in our admin guide: > https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.2/ > html-single/administration_guide/#Limitations4 > Please, it would be very desirable to avoid underscores in volume names, as > spoken. Is it not possible to use dash "-" as separator for proposed volume > name: <namespace>-<UUID>-<pvcname> ? > Thanks, Luis Ok. Let me give some context about the difficulty on implementing this. We definitely need UUID in the volume name and this UUID need to be fetched at time of volume deletion. If we form <namespace/pvc>-<UUID>-<pvc/namespace> pattern we are kind of giving the control to user to define the volume name. The problem with this approach is that, the user can define any name for pvc/namespace which contains "-" in it. For eg, 'claim-12345' is a valid PVC name [1]. so, this cause problems later when we fetch the volume UUID based on delimiter "-" and we may end up in wrong UUID fetch. However "_" is not allowed by RFC in these names. So, if we depend on "_" as a seperator we are safe. [1] a DNS-1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')
I could think of more char separators to avoid using underscore as separator, but not sure what are the rules or regex for Gluster Volume names. In the other hand, I also don't know if the limitation of volume names with underscores in Gluster Swift is easier to fix than using a strange char separator for volume names generated from OCP-Heketi. Could we use a double hyphen/dash "--" as separator or I'm saying something stupid?
Hi Humble! any update you could share with us on this one? Thanks.
(In reply to Sergi Jimenez Romero from comment #20) > Hi Humble! > > any update you could share with us on this one? Thanks. Yeah :), You are right on time! Friday the patch for custom volume name got merged in upstream. Now the volume names can be prefixed with your preferred string from storage class. I will give some more pointer on next bz update.
To document it: You can add a parameter called "volumenameprefix" in SC for ex: volumenameprefix: "dept-dev" If `volumenameprefix` storageclass parameter is set, the dynamically provisioned volumes are created in below format where `_` is the field seperator/delimiter: `customvolumeprefix_PVCname_randomUUID` Please note that, the value for this parameter cannot contain `_` in storageclass. This is an optional parameter. If not specified heketi will create volumes as it did till now.
(In reply to Humble Chirammal from comment #22) > To document it: > > You can add a parameter called "volumenameprefix" in SC > > for ex: > volumenameprefix: "dept-dev" > > > If `volumenameprefix` storageclass parameter is set, the dynamically > provisioned volumes are created in below format where `_` is the field > seperator/delimiter: > > `customvolumeprefix_PVCname_randomUUID` > > Please note that, the value for this parameter cannot contain `_` in > storageclass. This is an optional parameter. If not specified heketi will > create volumes as it did till now. Hi Humble, Thanks for the good news! When we spoke at the beginning of this RFE, we were speaking about using NameSpaceName_PVCname part of the Gluster volume name. As different NameSpaces/Projects can have same PVCnames, it could be useful the ability to differentiate from which namespace the PVC comes. Having a volumenameprefix at SC level doesn't help for that... only to know if this is coming, i.e. for CNS-Gold or CNS-Silver (or dev or prod as you example). Please, is that still possible? Thanks Luis
(In reply to Luis Rico from comment #23) > (In reply to Humble Chirammal from comment #22) > > To document it: > > > > You can add a parameter called "volumenameprefix" in SC > > > > for ex: > > volumenameprefix: "dept-dev" > > > > > > If `volumenameprefix` storageclass parameter is set, the dynamically > > provisioned volumes are created in below format where `_` is the field > > seperator/delimiter: > > > > `customvolumeprefix_PVCname_randomUUID` > > > > Please note that, the value for this parameter cannot contain `_` in > > storageclass. This is an optional parameter. If not specified heketi will > > create volumes as it did till now. > > Hi Humble, > Thanks for the good news! > When we spoke at the beginning of this RFE, we were speaking about using > NameSpaceName_PVCname part of the Gluster volume name. > As different NameSpaces/Projects can have same PVCnames, it could be useful > the ability to differentiate from which namespace the PVC comes. > Having a volumenameprefix at SC level doesn't help for that... only to know > if this is coming, i.e. for CNS-Gold or CNS-Silver (or dev or prod as you > example). > Please, is that still possible? Some more thoughts here, yes, however I kind of 'masked' namespace in volume name considering 2 things. *) The volume name becomes more lenghty *) if SC is dedicated for a namespace or if they want they can use 'volumenameprefix" with SC name or namespace name. I understand SC is a global thing though. Regardless, I have added `namespace` to above option as requested here: So, volumename becomes: `volumenameprefix`_namespace_pvcname_uuid` I hope this is what we want !! `volumenameprefix` is the only string which is 'given' for admin ( which is a must to trigger custom volume name) and they can fill any value for it, rest are automatically filled. I hope it close this RFE as you requested! Please share your thought if any.
Origin 3.9 PR # https://github.com/openshift/origin/pull/18326
The Origin 3.9 PR was merged yesterday!
(In reply to Humble Chirammal from comment #28) > The Origin 3.9 PR was merged yesterday! Thanks Humble!
A complete round of tests were performed on the new feature and the basic functionality works as expected. Hence moving to verified.
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-2018:0645
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days