[openstack-dev] [placement] The "intended purpose" of traits
zbitter at redhat.com
Mon Oct 1 14:15:51 UTC 2018
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 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, I am assuming that placement will not offer an API that
allows both traits to be updated atomically. Those are problems that
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
 Resisting the urge to quote Stalin here.
More information about the OpenStack-dev