Open Stack

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. Enforcing it would
require some form of code.

> 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.

If people have additional ideas and thoughts please feel free to
keep it alive.


[1] https://etherpad.openstack.org/p/placement-ptg-train

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent