Open Stack

Chris Dent <cdent+os at anticdent.org> wrote: 
>On Thu, 11 Apr 2019, Adam Spiers wrote: 
>
>>Ed Leafe <ed at leafe.com> wrote: 
>>>The concept of “owning” particular traits isn’t in Placement. 
>>>Rather, it is in the domain of the service that is using 
>>>Placement. So any enforcement regarding which traits are 
>>>acceptable has to be on the calling end, not in the Placement API. 
>>
>>That feels like a slight jump in logic to me: the API can enforce 
>>ownership without being the authoritative source of truth for that 
>>ownership.  For example, as I just suggested elsewhere in this 
>>thread, (static) ownership of driver-provided traits could be 
>>tracked in os_traits.  Maybe that's a dumb idea; I'm not sure. 
>
>It's not a dumb idea, but it's not really an idea we want to pursue. 
>We've made an effort to keep both os-traits and os-resource-classes 
>as dumb and "symbol only" as possible, minimizing code and metadata. 
>Indicating ownership would require metadata. 

I was thinking of something like 

    DRIVER_TRAITS = [
        ot.COMPUTE_FOO,
        ot.COMPUTE_BAR,
        ...
    ]

which seems to me more like data than metadata, and would presumably 
meet the requirement to be dumb and "symbol only". 

In fact, even without that we could just test for the COMPUTE_ prefix 
and that would cover all but one segment of the Venn diagram 

    https://pasteboard.co/I3iqqNm.jpg

i.e. the "Should be unset if set by admin (but we're not there yet)" 
bit.

>Enforcing it would require some form of code. 

Sure.  I don't understand the policy code yet, but at a wild guess it 
would need separate policies for human admins vs. nova. 

>>Having said that ... 
>>>So yeah, “do nothing”. 
>>
>>I'm totally fine with this too ;-)  I only raised it because when I 
>>was developing the driver-owned capability traits code, people 
>>seemed somewhat concerned with the possibility of admins screwing 
>>things up. If the concern is minimal then I'm certainly not 
>>religious about adding extra safeguards. 
>
>Seeing as there's no huge drive for action on this topic, I've 
>marked this topic as decided ("do nothing") on the etherpad [1] and 
>we can ignore this thread henceforth. 

Well, there's still the small matter of where to include the Venn 
diagram.  As I wrote in a previous email (which you may have not seen; 
for some reason it didn't show up in the list archives yet), the idea 
of putting it at the bottom of 

    https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#compute-capabilities-as-traits

was already rejected, otherwise it would have been there already: 

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

But other than that, I'm fine with "do nothing".