Closed
Description
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)
Metadata
Metadata
Assignees
Labels
Type
Projects
Relationships
Development
No branches or pull requests
Activity
meirf commentedon Jul 4, 2014
I've started working on this. I will submit a PR over the next day or so.
timothysc commentedon Jul 8, 2014
If folks intend to use labels for constraint matching, there will likely need to be comparison operators.
bgrant0607 commentedon Jul 9, 2014
@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 commentedon Jul 9, 2014
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 commentedon Jul 9, 2014
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 commentedon Jul 9, 2014
You could also view it as
requirements = distance(podX) < 3
bgrant0607 commentedon Jul 9, 2014
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 commentedon Jul 9, 2014
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:
timothysc commentedon Jul 9, 2014
@thockin ok I'll buy the idea of not trying to overload labels.
I'll try to hash it out on #367 then.
bgrant0607 commentedon Jul 9, 2014
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 commentedon Jul 9, 2014
I proposed the SQL method on NVP sets earlier today.
thockin commentedon Jul 9, 2014
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:
173 remaining items