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

P1 to decide how to surface this in v1beta3.

Is there any spec around this?

@timothysc See comments in https://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/labels/selector.go

I'm not sure we should rename to LabelSelector, because NodeSelector will also be a form of label selector.

I agree but I couldn't find a better name even if GeneralizedSelector looked better (finally everyone inside the project call in that way). If you've some ideas I can rename it.

My 2 cents, if PodSelector is the generic one and it should be used as the primary, then LabelSelector @sdminonne proposes, will do the trick. From there you can always create a specialized selector (such as NodeSelector) which will cover the subset of LabelSelector with application to specific resource.

On the side note, NodeSelector is just a field in PodSpec, whereas LabelSelector will be a type. Unless I'm missing something here.

I think I found the NodeSlector you were talking about in predicates.go, still I think above is true.

@smarterclayton @bgrant0607 @erictune - I am looking for some guidance on how to handle existing resources, so input appreciated.

I want to add an optional label and an optional field selector to LimitRange and ResourceQuota so an administrator can define constraints by varying dimensions. One dimension could be based on pod.spec.restartPolicy so pods derived from a Job could get different min/max/defaults defined than long running pods derived from a ReplicationController, same applies to ResourceQuota where I would want to quota differently based on anticipated time of footprint in cluster. The other dimension would be more open-ended based on end-user specified labels so things with database=mysql get quota differently than things with web=ruby for example.

Should I use the new label selector syntax as seen in apis/extensions/types.go or do I stick with the existing v1 syntax for existing resource types? I suspect I have to stick with the syntax as defined in v1/types.go but wanted confirmation before diving too deep.

@derekwaynecarr Use the new syntax. Copy/move LabelSelector to v1.

@bgrant0607 - thanks for the quick reply.

This is covered by more specific issues, so closing.