Bug 1415736

Summary: [RFE] Let admin select the cluster for a volume in dynamic provisioner.
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Humble Chirammal <hchiramm>
Component: kubernetesAssignee: Humble Chirammal <hchiramm>
Status: CLOSED ERRATA QA Contact: krishnaram Karthick <kramdoss>
Severity: medium Docs Contact:
Priority: medium    
Version: cns-3.4CC: akhakhar, annair, asriram, hchiramm, jarrpa, madam, mliyazud, mzywusko, pprakash, rcyriac, rreddy, rtalur, vinug
Target Milestone: ---   
Target Release: CNS 3.5   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
With this update, 'clusterid', a new storage class parameter is added in Red Hat Gluster Storage Dynamic Provisioner configuration. which enables in selecting a cluster for dynamically provisioning volumes. This allows an administrator to define the storageclass according to a cluster ID or a list of cluster ID passed as comma separated value. For example, if there are are two clusters, one with fast SSDs and another with IDE disks, an administrator can define a storage class to provision volumes from only SSD cluster by specifying SSD cluster ID in a specific storage class definition and vice versa.
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-04-20 18:49:44 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:
Bug Depends On:    
Bug Blocks: 1415595    

Description Humble Chirammal 2017-01-23 15:18:40 UTC
Description of problem:

At present we dont have a way to mention from which 'cluster' of CNS the volume has to be provisioned. Adding this ( optional) feature gives more flexibility for the admin to define QoS based on his setup.


Version-Release number of selected component (if applicable):

CNS 3.4

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Humble Chirammal 2017-01-31 12:08:43 UTC
Example usage in Storage class:

+  clusterid: "630372ccdc720a92c681fb928f27b53f"
   resturl: "http://127.0.0.1:8081"
   restuser: "admin"
   secretNamespace: "default"
   secretName: "heketi-secret"
 ```
 

+* `clusterid`: `630372ccdc720a92c681fb928f27b53f` is the ID of the cluster which above mentioned endpoint `glusterfs-cluster` refer. This endpoint should hold the ip addresses of all the nodes of cluster with id `630372ccdc720a92c681fb928f27b53f`.

Comment 3 Humble Chirammal 2017-02-09 11:03:04 UTC
This functionality is available atleast from OCP version openshift v3.5.0.14+20b49d0.

Comment 4 krishnaram Karthick 2017-04-10 08:13:12 UTC
Validation of this feature is completed. Admin can define the storageclass according to a clusterid or a list of cluster id passed as comma separated value.

Moving this bug to verified.

Comment 6 Humble Chirammal 2017-04-13 12:06:46 UTC
This is not a finalized draft, I am requesting michael to look at this. However my point is that this feature should be use case driven.

--snip--

This release add a new storage class parameter called 'clusterid' in Gluster Dynamic Provisioner configuration. With this, selecting a cluster for a dynamically provisioning volumes made possible. This allows an administrator to define the storageclass according to a cluster ID or a list of cluster ID passed as comma separated value. For eg# If there are are two clusters where one with fast SSDs and another with IDE disks, admin can define a storage class to provision volumes from only SSD cluster by specifying SSD cluster ID in a specific storage class definition vice versa.

--/snip--

Comment 10 errata-xmlrpc 2017-04-20 18:49:44 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/RHEA-2017:1116