Bug 1421370
| Summary: | OCP dynamic storage provisioning uses wrong storage backed to allocate PV when PVC is created dynamically on EC2 | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Elvir Kuric <ekuric> |
| Component: | Storage | Assignee: | Bradley Childs <bchilds> |
| Status: | CLOSED NOTABUG | QA Contact: | Jianwei Hou <jhou> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.5.0 | CC: | aos-bugs, bengland, hekumar, jeder |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | aos-scalability-35 | ||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-02-13 16:08:15 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: | |||
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 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. |
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