Skip to content

Generalize label selectors #341

Closed
Closed
@bgrant0607

Description

@bgrant0607

Right now, our label selectors support conjunctions of exact matches of key-value pairs. We should support conjunctions of:

  • key exists
  • key is in (set of values)
  • key is not in (set of values)

Exact match can be expressed using "is in".

This would allow selectors such as:

service is in (foo),
environment is not in (qa),
stage is in (daily, weekly)

Activity

meirf

meirf commented on Jul 4, 2014

@meirf
Contributor

I've started working on this. I will submit a PR over the next day or so.

timothysc

timothysc commented on Jul 8, 2014

@timothysc
Member

If folks intend to use labels for constraint matching, there will likely need to be comparison operators.

bgrant0607

bgrant0607 commented on Jul 9, 2014

@bgrant0607
MemberAuthor

@timothysc Could you please provide a motivating example for comparisons? We could accept integer ranges, including open ranges. However, the restrictive selection semantics are careful chosen to facilitate set overlap detection, efficient indexing and reverse indexing, and human understandability.

timothysc

timothysc commented on Jul 9, 2014

@timothysc
Member

It is my understanding that Labels 'currently' only apply to pods. If labeling were extended to Kublets then users could define things such as:

rank = memory
(implies sort, meaning < operator required)

requirements = memory > 4GB
(Only land my pod on machines with > 4GB)

bgrant0607

bgrant0607 commented on Jul 9, 2014

@bgrant0607
MemberAuthor

Ok, thanks. As I commented in #367 , labels / constraints shouldn't be used for resource-based placement or binpacking. The scheduler should place pods based on their minimum resource requirements and resources available.

timothysc

timothysc commented on Jul 9, 2014

@timothysc
Member

You could also view it as

requirements = distance(podX) < 3

bgrant0607

bgrant0607 commented on Jul 9, 2014

@bgrant0607
MemberAuthor

Labels are explicit and literal.

Locality requirements need to be expressed at a higher level. Expressing them as individual hard constraints on pods is likely to lead to a greedy scheduler to paint itself into a corner.

Scheduling is a nuanced service, with workload-specific and provider-specific objectives and constraints, topological and architectural considerations, security concerns, dependencies, QoS and fairness considerations, workload interference, etc. Let's not try to shoehorn too much into the label mechanism.

thockin

thockin commented on Jul 9, 2014

@thockin
Member

I really think scheduling resources and scheduling constraints are two
different things, both useful, but not the same.

For your other example, distance to another pod, I would also not suggest
labels. Labels are relatively static and low in cardinality. Asking for
distance to another pod (for some definition of distance) may be a legit
constrainy but doesn't sound like labels to me.

I also started with the expectation that label selectors would be an
arbitrary expression, including regex matching or prefix/suffix matching.
But I did not come up with a solid use case for more than simple sets.

Tim
On Jul 8, 2014 5:45 PM, "Timothy St. Clair" notifications@github.com
wrote:

It is my understanding that Labels 'currently' only apply to pods. If
labeling were extended to Kublets then users could define things such as:

rank = memory
(implies sort, meaning < operator required)

requirements = memory > 4GB
(Only land my pod on machines with > 4GB)

Reply to this email directly or view it on GitHub
#341 (comment)
.

timothysc

timothysc commented on Jul 9, 2014

@timothysc
Member

@thockin ok I'll buy the idea of not trying to overload labels.
I'll try to hash it out on #367 then.

bgrant0607

bgrant0607 commented on Jul 9, 2014

@bgrant0607
MemberAuthor

Regular expressions and prefix/suffix matching are hostile to the goals I mentioned earlier. We should not support them. The escape hatch is attaching a new label using whatever arbitrary computation you wish to decide where to attach it, or to dump the data into a database and use SQL or whatever.

timothysc

timothysc commented on Jul 9, 2014

@timothysc
Member

I proposed the SQL method on NVP sets earlier today.

thockin

thockin commented on Jul 9, 2014

@thockin
Member

I am behind on email, so I promise to digest the other threads tonight :)
On Jul 8, 2014 7:22 PM, "Timothy St. Clair" notifications@github.com
wrote:

I proposed the SQL method on NVP sets earlier today.

Reply to this email directly or view it on GitHub
#341 (comment)
.

173 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/apiIndicates an issue on api area.area/usabilitypriority/important-soonMust be staffed and worked on either currently, or very soon, ideally in time for the next release.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @timothysc@soltysh@liggitt@smarterclayton@mikedanese

        Issue actions

          Generalize label selectors · Issue #341 · kubernetes/kubernetes