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

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

@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.

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)

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.

You could also view it as

requirements = distance(podX) < 3

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.

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)
.

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

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.

I proposed the SQL method on NVP sets earlier today.

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)
.