Bug 1421370 - OCP dynamic storage provisioning uses wrong storage backed to allocate PV when PVC is created dynamically on EC2
Summary: OCP dynamic storage provisioning uses wrong storage backed to allocate PV whe...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Storage
Version: 3.5.0
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
: ---
Assignee: Bradley Childs
QA Contact: Jianwei Hou
URL:
Whiteboard: aos-scalability-35
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-11 17:14 UTC by Elvir Kuric
Modified: 2017-02-13 16:08 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-13 16:08:15 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Elvir Kuric 2017-02-11 17:14:13 UTC
Description of problem:

dynamic storage provisioning does not respect storage backend defined in storage class when allocating PVC and allocate PVC from different storage backend than one specified in storageclass

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

installed software : 

atomic-openshift-3.5.0.17-1.git.0.c55cf2b.el7.x86_64
atomic-openshift-dockerregistry-3.5.0.17-1.git.0.c55cf2b.el7.x86_64
atomic-openshift-clients-redistributable-3.5.0.17-1.git.0.c55cf2b.el7.x86_64
atomic-openshift-clients-3.5.0.17-1.git.0.c55cf2b.el7.x86_64
atomic-openshift-utils-3.5.3-1.git.0.80c2436.el7.noarch
tuned-profiles-atomic-2.7.1-3.el7_3.1.noarch
tuned-profiles-atomic-openshift-node-3.5.0.17-1.git.0.c55cf2b.el7.x86_64
atomic-openshift-sdn-ovs-3.5.0.17-1.git.0.c55cf2b.el7.x86_64
atomic-openshift-master-3.5.0.17-1.git.0.c55cf2b.el7.x86_64
atomic-openshift-node-3.5.0.17-1.git.0.c55cf2b.el7.x86_64
atomic-openshift-tests-3.5.0.17-1.git.0.c55cf2b.el7.x86_64
atomic-openshift-pod-3.5.0.17-1.git.0.c55cf2b.el7.x86_64


How reproducible:

always 

Steps to Reproduce:

1. Install v3.5 on ec2 ( this issue was noticed with above packages ) 
2. Configure OCP to use ec2 as storage backend 

cloud-config:
    - /etc/origin/cloudprovider/aws.conf
    cloud-provider:
    - aws
  controllerArguments: 
    cloud-config:
    - /etc/origin/cloudprovider/aws.conf
    cloud-provider:
    - aws


3. next,configure CNS pods on same OCP installation ( cns-deploy -n <namespace> topology.json > 

4. Create storageclass and point it to use CNS 

apiVersion: storage.k8s.io/v1beta1
kind: StorageClass
metadata:
  name: elclass
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://172.25.108.77:8080"
  restuser: "admin"

---- 

# oc describe storageclass elclass 
Name:		elclass
IsDefaultClass:	No
Annotations:	<none>
Provisioner:	kubernetes.io/glusterfs
Parameters:	resturl=http://172.25.108.77:8080,restuser=admin
No events.
---- 
# curl http://172.25.108.77:8080/hello
Hello from Heketi

# oc get svc
NAME                      CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
deploy-heketi             172.25.108.77    <none>        8080/TCP   1d

5. Create PVC dynamically with PVC claim 

{
  "kind": "PersistentVolumeClaim",
  "apiVersion": "v1",
  "metadata": {
    "name": "pvcpers",
    "annotations": {
      "volume.alpha.kubernetes.io/storage-class": "elclass"
    }
  },
  "spec": {
    "accessModes": [
      "ReadWriteOnce"
    ],
    "resources": {
      "requests": {
        "storage": "5Gi"
      }
    }
  }
}

6. check 

# oc describe pvc < pvc name >
# oc describe pv < pv name > 

Actual results:

PVC will be allocated and it will use EBS storage backend and not CNS / gluster storage backend. In my test case 

# oc describe pvc pvcpers 
Name:		pvcpers
Namespace:	cnselko
StorageClass:	elclass
Status:		Bound
Volume:		pvc-1179c6c9-f066-11e6-a826-027132b7f605
Labels:		<none>
Capacity:	5Gi
Access Modes:	RWO
No events.


root@ip-172-31-4-145: ~ # oc describe pv pvc-1179c6c9-f066-11e6-a826-027132b7f605
Name:		pvc-1179c6c9-f066-11e6-a826-027132b7f605
Labels:		failure-domain.beta.kubernetes.io/region=us-west-2
		failure-domain.beta.kubernetes.io/zone=us-west-2b
StorageClass:	
Status:		Bound
Claim:		cnselko/pvcpers
Reclaim Policy:	Delete
Access Modes:	RWO
Capacity:	5Gi
Message:	
Source:
    Type:	AWSElasticBlockStore (a Persistent Disk resource in AWS)
    VolumeID:	aws://us-west-2b/vol-06b6895a3ebd96591
    FSType:	ext4
    Partition:	0
    ReadOnly:	false
No events.


Expected results:

PVC to be allocated per storage class definition 

Additional info:
if instead 

"volume.alpha.kubernetes.io/storage-class": "elclass"

is used 

      "volume.beta.kubernetes.io/storage-class": "elclass"

allocation works as expected - from CNS

Comment 1 Jianwei Hou 2017-02-13 00:45:29 UTC
With 'alpha' annotation, the PV will be provisioned irrespective of the storageclas. http://blog.kubernetes.io/2016/10/dynamic-provisioning-and-storage-in-kubernetes.html

Comment 2 Hemant Kumar 2017-02-13 16:08:15 UTC
Yeah the alpha annotation is in process of being phased out. It was a stop gap solution that didn't require a storageclass to be defined and hence any value you specify for "volume.alpha.kubernetes.io/storage-class" is immaterial (you can literally put "foobar" there and it will still work).

For creating PVs dynamically from storageclasses, you will have to use the "beta" annotation.


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