Open Stack

[resend due to issues with our internal MTA]

Eric Fried <openstack at fried.cc> wrote: 
>>be worth considering tweaking the placement API so that only the driver 
>>can set/unset traits which it owns? 
>
>This would entail placement tracking some kind of "owner" attribute 
>(ahem, metadata) on traits. Or maintaining a list of driver-owned traits 
>per resource provider. Or <your idea here>. And then a way to establish 
>a different identity/policy for the virt driver than for the admin. And 
>then a way for the admin to override that anyway because stuff happens. 
>
>That ^, IMO, is the "more work than benefit" I led with. Happy to be 
>convinced otherwise if there's a (*much*) simpler way to achieve the 
>desired goal. 

Just thinking out aloud, but how about something as stupid as just 
maintaining that list of driver-owned traits in os_traits, and 
exposing a simple trait_is_driver_owned() function which returns a 
boolean?  Then the API implementation could simply check that and 
return 403 or whatever if the admin tries to mess with a driver-owned 
trait.

Although I'm assuming that there is already some mechanism in there 
for the API service to distinguish between admin callers and driver 
callers; if that assumption is wrong then maybe it would take too much 
more effort to add that. 

>>Although perhaps it would be better to at least spend 5 
>>minutes finding a good place in the docs to insert the Venn diagram: 
>>    https://pasteboard.co/I3iqqNm.jpg 
>
>Yes please. Bottom of [1] seems like the right place. 
>
>[1]
>https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#compute-capabilities-as-traits 

That idea was already rejected, otherwise it would be there already: 

https://review.openstack.org/#/c/644293/2/doc/source/admin/configuration/schedulers.rst@1523 

>But for heaven's sake, don't violate my privacy [2]. 
>
>[2]
>http://lists.openstack.org/pipermail/openstack-discuss/2019-April/thread.html#4651 

Sure, no need for that here ;-)  We can just add the raw .svg.