Bug 1386594 - [Doc RFE] Document guidelines/task information about using dynamically provisioned volumes while also using existing static volumes.
Summary: [Doc RFE] Document guidelines/task information about using dynamically provis...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: doc-Container_Native_Storage_with_OpenShift
Version: cns-3.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: CNS 3.4
Assignee: Bhavana
QA Contact: krishnaram Karthick
URL:
Whiteboard:
Depends On:
Blocks: 1385252
TreeView+ depends on / blocked
 
Reported: 2016-10-19 09:30 UTC by Anjana Suparna Sriram
Modified: 2017-01-23 07:22 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-23 07:22:33 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Anjana Suparna Sriram 2016-10-19 09:30:25 UTC
Additional info: 


Use Case #6: As an administrator who upgraded my CNS deployment from OpenShift Container Platform 3.3 to OpenShift Container Platform 3.4, I need to be able to create/use dynamically provisioned volumes while also using existing static volumes.

Comment 4 Bhavana 2016-11-08 10:16:45 UTC
Hi Humble,

I am sharing my understanding of the doc requirement. Please do share your suggestions regarding the same. In order to address Use Case #6 mentioned in the description:

1) Firstly, create two sub-section under Chapter 5 "Creating Persistent Volumes". This clearly bifurcates static and dynamic provisioning.
     5.1 - Static Provisioning of Volumes
     5.2 - Dynamic Provisioning of Volumes

This is addressed in the following google doc where we are documenting "Dynamic provisioning"

https://docs.google.com/document/d/16VFLcm2DUtEg__3-FbikKI0lmlkyf9e1BkxmUKz--zM/edit#

2) Add a note under "Static Provisioning of Volumes", saying that Dynamic provisioning of volumes is supported from CNS 3.4 and provide a link to "Dynamic Provisioning of Volumes"

 Similarly, for users who upgraded OpenShift Container Platform 3.3 to OpenShift Container Platform 3.4 and have static volumes, add a note under under "Dynamic Provisioning of Volumes" and provide link to "Static Provisioning of Volumes".

Let me know if this addresses the issue and please share your thoughts and comments.

Thanks.

Comment 5 Humble Chirammal 2016-11-09 09:53:55 UTC
> 
> I am sharing my understanding of the doc requirement. Please do share your
> suggestions regarding the same. In order to address Use Case #6 mentioned in
> the description:

I am unable to see Use Case #6 in the document.

> 
> 1) Firstly, create two sub-section under Chapter 5 "Creating Persistent
> Volumes". This clearly bifurcates static and dynamic provisioning.
>      5.1 - Static Provisioning of Volumes
>      5.2 - Dynamic Provisioning of Volumes
> 
> This is addressed in the following google doc where we are documenting
> "Dynamic provisioning"
> 
> https://docs.google.com/document/d/16VFLcm2DUtEg__3-FbikKI0lmlkyf9e1BkxmUKz--
> zM/edit#
> 
> 2) Add a note under "Static Provisioning of Volumes", saying that Dynamic
> provisioning of volumes is supported from CNS 3.4 and provide a link to
> "Dynamic Provisioning of Volumes"
> 
>  Similarly, for users who upgraded OpenShift Container Platform 3.3 to
> OpenShift Container Platform 3.4 and have static volumes, add a note under
> under "Dynamic Provisioning of Volumes" and provide link to "Static
> Provisioning of Volumes".
> 
> Let me know if this addresses the issue and please share your thoughts and
> comments.
> 

Its good to seperate the methods ( static and dynamic) and give pointers/reference from one to the other. Also I would encourage to make the 'common' part ( For ex: deployment) separate and refer it from 'static/dynamic' sections whenever needed. But others may have a different view. So, my suggestion would be to send a mail which describe the layout of the doc to rhs-containers requesting CNS team's and stakeholders feedback. so that we wont struggle at last minute to rearrange the things.

Comment 6 Bhavana 2016-11-09 11:11:35 UTC
Thanks Humble.

Chapter 4 (which comes before "creating persistent volumes") has all the details regarding setting up heketi server and a section for deploying containers. This could be used as a common part for both static and dynamic as suggested.

https://access.redhat.com/documentation/en/red-hat-gluster-storage/3.1/paged/container-native-storage-for-openshift-container-platform/chapter-4-setting-up-the-environment

I shall however share the doc with the container team to get everyone's view on the same.

Comment 7 Humble Chirammal 2016-11-14 10:17:58 UTC
(In reply to Bhavana from comment #6)
> Thanks Humble.
> 
> Chapter 4 (which comes before "creating persistent volumes") has all the
> details regarding setting up heketi server and a section for deploying
> containers. This could be used as a common part for both static and dynamic
> as suggested.
> 
> https://access.redhat.com/documentation/en/red-hat-gluster-storage/3.1/paged/
> container-native-storage-for-openshift-container-platform/chapter-4-setting-
> up-the-environment
> 
> I shall however share the doc with the container team to get everyone's view
> on the same.

ACK from me. However it would be really good if you can consolidate https://bugzilla.redhat.com/show_bug.cgi?id=1386676 and Troubleshooting Guide doc in a single one and send for the review.

Comment 10 krishnaram Karthick 2017-01-06 07:13:49 UTC
I see that https://bugzilla.redhat.com/show_bug.cgi?id=1386546 also tracks dynamic provisioning, I wonder if 1386546 is needed. 

In any case, I'm adding the comments I had for 1386546 here as well,

1) section 5.2.1,

After creating a Storage Class, a secret for heketi authentication must be creating before proceeding with the creation of persistent volume claim. 

should be,

After creating a Storage Class, a secret for heketi authentication must be created before proceeding with the creation of persistent volume claim. 

2) 

secretNamespace + secretName: Identification of Secret instance that containes

should be,

secretNamespace + secretName: Identification of Secret instance that contains

3) Under,  ⁠5.2.1.2. Creating Secret for Heketi Authentication

Create a secret file by executing the following command: 

should be,

Create a secret file, sample secret file is provided below

4) Similar to the above comment,

"Create a Persistent Volume Claim file by executing the following command: " has to be changed

5)  To verify that the persistent volume is mounted inside the container, execute the following command: 
# oc rsh busybox

The command provided only logs into the shell of the application pod. To check if the mountpoint exists, 'df' command has to be executed in the shell

Comment 11 Bhavana 2017-01-06 08:05:44 UTC
As added in https://bugzilla.redhat.com/show_bug.cgi?id=1386546#c13, these comments are addressed in that bug too. Hence moving this to on_qa

Comment 12 krishnaram Karthick 2017-01-10 09:21:13 UTC
More comments:

1) In order to stay consistent with the sample file present in /usr/share/heketi/templates/ - can we change the sample-gluster-endpoints.yaml as shown below instead of the one currently available in the doc.

cat /usr/share/heketi/templates/sample-gluster-endpoints.yaml 
apiVersion: v1
kind: Endpoints
metadata:
  name: glusterfs-cluster
subsets:
- addresses:
  - ip: 192.168.10.100
  ports:
  - port: 1
- addresses:
  - ip: 192.168.10.101
  ports:
  - port: 1
- addresses:
  - ip: 192.168.10.102
  ports:
  - port: 1

I think this is being taken care as part of https://bugzilla.redhat.com/show_bug.cgi?id=1408796#c3, but please ensure the changes are made.

2) The output of step 6 should be,

cat pv001.json 
{
  "kind": "PersistentVolume",
  "apiVersion": "v1",
  "metadata": {
    "name": "glusterfs-f8c612ee",
    "creationTimestamp": null
  },
  "spec": {
    "capacity": {
      "storage": "100Gi"
    },
    "glusterfs": {
      "endpoints": "TYPE ENDPOINT HERE",
      "path": "vol_f8c612eea57556197511f6b8c54b6070"
    },
    "accessModes": [
      "ReadWriteMany"
    ],
    "persistentVolumeReclaimPolicy": "Retain"
  },
  "status": {}

step 7's output should be,

cat pv001.json
{
  "kind": "PersistentVolume",
  "apiVersion": "v1",
  "metadata": {
    "name": "glusterfs-f8c612ee",
    "creationTimestamp": null,
    "labels": {
      "storage-tier": "gold"
    }
  },
  "spec": {
    "capacity": {
      "storage": "12Gi"
    },
    "glusterfs": {
      "endpoints": "glusterfs-cluster",
      "path": "vol_f8c612eea57556197511f6b8c54b6070"
    },
    "accessModes": [
      "ReadWriteMany"
    ],
    "persistentVolumeReclaimPolicy": "Retain"
  },
  "status": {}
}

and Introduce a step between 7 and 8 in the current doc. The step would be,

'create a persistent volume'

# oc create -f pv001.json

For example:

# oc create -f pv001.json
persistentvolume "glusterfs-4fc22ff9" created


3) The size mentioned in step 9 is 1Gi, can you please change it to 100Gi to stay consistent with the previous commands. i.e., the file should be as shown below.

 Create a persistent volume claim file. For example:

# cat pvc.json 
      
{
   "apiVersion": "v1",
   "kind": "PersistentVolumeClaim",
   "metadata": {
     "name":  "glusterfs-claim"
  },
   "spec": {
     "accessModes": [
       "ReadWriteMany"
    ],
     "resources": {
       "requests": {
         "storage": "100Gi"
      },
       "selector": {
       "matchLabels": {
         "storage-tier": "gold"
      }
    }
   }
  }
}

Comment 14 krishnaram Karthick 2017-01-10 12:24:32 UTC
Looks good to me, moving the bug to verified.


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