Open Stack

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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>