>> I still want to use something like "Is capable of RAID5" and/or "Has >> RAID5 already configured" as part of a scheduling and placement >> decision. Being able to have the GET /a_c response filtered down to >> providers with those, ahem, traits is the exact purpose of that operation. > > And yep, I have zero problem with this either, as I've noted. This is > precisely what placement and traits were designed for.
Same. >> While we're in the neighborhood, we agreed in Denver to use a trait to >> indicate which service "owns" a provider [1], so we can eventually >> coordinate a smooth handoff of e.g. a device provider from nova to >> cyborg. This is certainly not a capability (but it is a trait), and it >> can certainly be construed as a key/value (owning_service=cyborg). Are >> we rescinding that decision? > > Unfortunately I have zero recollection of a conversation about using > traits for indicating who "owns" a provider. :( I definitely do. > I don't think I would support such a thing -- rather, I would support > adding an attribute to the provider model itself for an owning service > or such thing. > > That's a great example of where the attribute has specific conceptual > meaning to placement (the concept of ownership) and should definitely > not be tucked away, encoded into a trait string. No, as I recall it means nothing to placement - it means something to the consumers. A gentleperson's agreement for identifying who owns what if we're going to, say, remove things that might be stale from placement when updating the provider tree. --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
