Storage class might fix this issue but am not convinced fully claiming a PV without using selector. It bypasses protection offer by storage label selectors. Again, we have to wait for 3.4 and upgrade 3.3. some more work.
-- Srinivas Kotaru From: Brad Childs <bchi...@redhat.com> Date: Friday, January 13, 2017 at 12:17 PM To: Srinivas Naga Kotaru <skot...@cisco.com> Cc: Nakayama Kenjiro <nakayamakenj...@gmail.com>, dev <dev@lists.openshift.redhat.com> Subject: Re: storage labels On Fri, Jan 13, 2017 at 2:05 PM, Srinivas Naga Kotaru (skotaru) <skot...@cisco.com<mailto:skot...@cisco.com>> wrote: Can you explain or point a documentation on how to use storage class? I don’t see any document on storage class yet, at least OSE 3.3. I heard that feature will be releasing in 3.4. Sorry I should have noticed your OSE 3.3 version. StorageClass is in 3.4 -bc -- Srinivas Kotaru From: Brad Childs <bchi...@redhat.com<mailto:bchi...@redhat.com>> Date: Friday, January 13, 2017 at 11:59 AM To: Srinivas Naga Kotaru <skot...@cisco.com<mailto:skot...@cisco.com>> Cc: Nakayama Kenjiro <nakayamakenj...@gmail.com<mailto:nakayamakenj...@gmail.com>>, dev <dev@lists.openshift.redhat.com<mailto:dev@lists.openshift.redhat.com>> Subject: Re: storage labels On Fri, Jan 13, 2017 at 12:59 PM, Srinivas Naga Kotaru (skotaru) <skot...@cisco.com<mailto:skot...@cisco.com>> wrote: Perfect, that answer and clarify. Thank you, Nakayama, I was able to bound a PV which has label selectors using a PVC which doesn’t have any selectors. This behavior completely makes useless our storage labeling strategy. We want to label few volumes (special volumes by cost/performance/size) to specific clients and want only that clients can use these PV using label selectors. Clients who don’t mention label selectors in PVC should bound general volumes This concerns us a lot. How to deal this issue? One way is to require every PVC to create with a selector. If you have a performance={fast, slow} then every PVC must create with a selector for performance=something. You could use StorageClass in a similar way. Special PVs that you want only certain users to use would belong to a specific StorageClass and general purpose PVs to another. You could then set the default StorageClass to the general purpose so users must specifically request PVs from the higher performance StorageClass. -bc -- Srinivas Kotaru From: Nakayama Kenjiro <nakayamakenj...@gmail.com<mailto:nakayamakenj...@gmail.com>> Date: Friday, January 13, 2017 at 4:10 AM To: Srinivas Naga Kotaru <skot...@cisco.com<mailto:skot...@cisco.com>> Cc: "ccole...@redhat.com<mailto:ccole...@redhat.com>" <ccole...@redhat.com<mailto:ccole...@redhat.com>>, dev <dev@lists.openshift.redhat.com<mailto:dev@lists.openshift.redhat.com>> Subject: Re: storage labels I think that following sentence in the docs is wrong(?). https://docs.openshift.com/container-platform/3.3/install_config/storage_examples/binding_pv_by_label.html "It is important to note that a claim must match all of the key-value pairs included in its selector stanza." In my understanding, it should mean that: OK === PV: labels: A: B X: Y PVC: matchLabels: A: B X: Y OK === PV: labels: A: B X: Y PVC: matchLabels: A: B NG === PV: labels: A: B PVC: matchLabels: A: B X: Y Regards, Kenjiro On Fri, Jan 13, 2017 at 6:47 AM, Srinivas Naga Kotaru (skotaru) <skot...@cisco.com<mailto:skot...@cisco.com>> wrote: Thanks, Clayton Is it necessary to have both selectors to match in PVC to bound to PV or any one matching selector enough? In my testing PVC able to bound even one label selector match although I have 2 selectors in my PV. Documentiaotn says otherwise … -- Srinivas Kotaru From: "ccole...@redhat.com<mailto:ccole...@redhat.com>" <ccole...@redhat.com<mailto:ccole...@redhat.com>> Date: Thursday, January 12, 2017 at 1:25 PM To: Srinivas Naga Kotaru <skot...@cisco.com<mailto:skot...@cisco.com>> Cc: dev <dev@lists.openshift.redhat.com<mailto:dev@lists.openshift.redhat.com>> Subject: Re: storage labels Yes On Jan 12, 2017, at 4:23 PM, Srinivas Naga Kotaru (skotaru) <skot...@cisco.com<mailto:skot...@cisco.com>> wrote: How to represent TB storage in PV? Is it Ti , similar to Gi? -- Srinivas Kotaru From: <dev-boun...@lists.openshift.redhat.com<mailto:dev-boun...@lists.openshift.redhat.com>> on behalf of Srinivas Naga Kotaru <skot...@cisco.com<mailto:skot...@cisco.com>> Date: Wednesday, January 11, 2017 at 11:33 AM To: dev <dev@lists.openshift.redhat.com<mailto:dev@lists.openshift.redhat.com>> Subject: storage labels Hi We are going to leverage storage labels feature with OCP 3.3. in storage label scenario, it seems PVC ignores PV capacity ( spec.capacity.storage) attribute and match depending on label selector in PV. Questions 1. If yes, then why do we need to specifiy storage attributes in PV and PVC? 2. If we have multiple sizes in single storage class, do we need to classify multiple lable selectors to match PVC claims? Like nfs-ssd-100gb for to match 100gb volumes, nfs-ssd-50gb for 50gb volumes? Am having different sizes of volumes in NFS, wondering single label enough or do I need to 1 label for same size volumes? -- Srinivas Kotaru _______________________________________________ dev mailing list dev@lists.openshift.redhat.com<mailto:dev@lists.openshift.redhat.com> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev _______________________________________________ dev mailing list dev@lists.openshift.redhat.com<mailto:dev@lists.openshift.redhat.com> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev -- Kenjiro NAKAYAMA <nakayamakenj...@gmail.com<mailto:nakayamakenj...@gmail.com>> GPG Key fingerprint = ED8F 049D E67A 727D 9A44 8E25 F44B E208 C946 5EB9 _______________________________________________ dev mailing list dev@lists.openshift.redhat.com<mailto:dev@lists.openshift.redhat.com> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
_______________________________________________ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev