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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
