On Thu, 11 Apr 2019, Adam Spiers wrote:
Ed Leafe <ed@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