[openstack-dev] [placement] The "intended purpose" of traits
jaypipes at gmail.com
Mon Oct 1 17:36:30 UTC 2018
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.)
> 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 , 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... :)
>  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.
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev