On 10/01/2018 01:20 PM, Eric Fried wrote:
I agree that we should not overload placement as a mechanism to pass
configuration information ("set up RAID5 on my storage, please") to the
driver. So let's put that aside. (Looking forward to that spec.)
ack.
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.
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 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.
OK, I'll get back to that spec now... :) Best, -jay
[1] https://review.openstack.org/#/c/602160/I'm working on a spec that will describe a way for the user to instruct Nova to pass configuration data to the virt driver (or device manager) before instance spawn. This will have nothing to do with placement or traits, since this configuration data is not modeling scheduling and placement decisions. I hope to have that spec done by Monday so we can discuss on the spec. Best, -jay __________________________________________________________________________ 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__________________________________________________________________________ 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
__________________________________________________________________________ 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
