On Fri, Jan 13, 2017 at 12:59 PM, Srinivas Naga Kotaru (skotaru) <
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>
> *Date: *Friday, January 13, 2017 at 4:10 AM
> *To: *Srinivas Naga Kotaru <skot...@cisco.com>
> *Cc: *"ccole...@redhat.com" <ccole...@redhat.com>, dev <
> 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> 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" <ccole...@redhat.com>
> *Date: *Thursday, January 12, 2017 at 1:25 PM
> *To: *Srinivas Naga Kotaru <skot...@cisco.com>
> *Cc: *dev <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> wrote:
>
> How to represent TB storage in PV? Is it Ti , similar to Gi?
>
>
>
> --
>
> *Srinivas Kotaru*
>
>
>
> *From: *<dev-boun...@lists.openshift.redhat.com> on behalf of Srinivas
> Naga Kotaru <skot...@cisco.com>
> *Date: *Wednesday, January 11, 2017 at 11:33 AM
> *To: *dev <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
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
> _______________________________________________
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
>
>
> --
>
> Kenjiro NAKAYAMA <nakayamakenj...@gmail.com>
> GPG Key fingerprint = ED8F 049D E67A 727D 9A44 8E25 F44B E208 C946 5EB9
>
> _______________________________________________
> dev mailing list
> 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
