[placement][nova][ptg] Protecting driver-provided traits
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 = [
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
i.e. the "Should be unset if set by admin (but we're not there yet)"
>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  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
was already rejected, otherwise it would have been there already:
https://review.openstack.org/#/c/644293/2/doc/source/admin/configuration/schedulers.rst at 1523
But other than that, I'm fine with "do nothing".