> It sounds like you might be saying, "I would rather not see encoded > trait names OR a new key/value primitive; but if the alternative is > ending up with 'a much larger mess', I would accept..." ...which? > > Or is it, "We should not implement a key/value primitive, nor should we > implement restrictions on trait names; but we should continue to > discourage (ab)use of trait names by steering placement consumers to..." > ...do what?
The second one. > The restriction is real, not perceived. Without key/value (either > encoded or explicit), how should we steer placement consumers to satisfy > e.g., "Give me disk from a provider with RAID5"? Sure, I'm not doubting the need to find providers with certain abilities. What I'm saying (and I assume Jay is as well), is that finding things with more domain-specific attributes is the job of the domain controller (i.e. nova). Placement's strength, IMHO, is the unified and extremely simple data model and consistency guarantees that it provides. It takes a lot of the work of searching and atomic accounting of enumerable and qualitative things out of the scheduler of the consumer. IMHO, it doesn't (i.e. won't ever) and shouldn't replace all the things that nova's scheduler needs to do. I think it's useful to draw the line in front of a full-blown key=value store and DSL grammar for querying everything with all the operations anyone could ever need. Unifying the simpler and more common bits into placement and keeping the domain-specific consideration and advanced filtering of the results in nova/ironic/etc is the right separation of responsibilities, IMHO. RAID level is, of course, an overly simplistic example to use, which makes the problem seem small, but we know more complicated examples exist. --Dan __________________________________________________________________________ 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