Open Stack

On 28/09/18 1:19 PM, Chris Dent wrote:
>> They aren't arbitrary. They are there for a reason: a trait is a 
>> boolean capability. It describes something that either a provider is 
>> capable of supporting or it isn't.
> 
> This is somewhat (maybe even only slightly) different from what I
> think the definition of a trait is, and that nuance may be relevant.
> 
> I describe a trait as a "quality that a resource provider has" (the
> car is blue). This contrasts with a resource class which is a
> "quantity that a resource provider has" (the car has 4 doors).

I'm not sure that quality vs. quantity is actually the right distinction 
here... someone could equally argue that having 4 doors is itself a 
quality[1] of a car, and they could certainly come up with a formulation 
that obscures the role of quantity at all (the car is a sedan).

I think the actual distinction you're describing is between discrete (or 
perhaps just enumerable) and continuous (or at least innumerable) values.

What that misses is that if the car is blue, it cannot also be green. 
Since placement absolutely should not know anything at all about the 
meaning of traits, this means that clients will be required to implement 
a bunch of business logic to maintain consistency. Furthermore, should 
the colour of the car change from blue to green at some point in the 
future[2], I am assuming that placement will not offer an API that 
allows both traits to be updated atomically. Those are problems that 
key-value solves.

It could be the case that those problems are not considered important in 
this context; if so I'd expect to see the reasons explained as part of 
this discussion.

cheers,
Zane.

[1] Resisting the urge to quote Stalin here.
[2] https://en.wikipedia.org/wiki/New_riddle_of_induction