Open Stack

On Fri, 2019-04-12 at 13:57 +0100, Adam Spiers wrote:
> 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,
>         ...
>     ]
a simple list like this seams resonable to me but im not conviced this
shoudl live in os-traits. this set would vary per driver.
the virdrivers dont just set traits that are  confied to the COMPUTE_ prefix 
and i dont think the drivers should own everything in the  hardware namespace.
https://github.com/openstack/os-traits/tree/master/os_traits/hw

> 
> 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 
so to not shoot ourselves in the foot in the future im not sure we want
to assume that everything under the compute namespace would never be added
by and by an operator.

but on the other had looking at the traits in https://github.com/openstack/os-traits/tree/master/os_traits/compute
i think all the current ones are things that likely only the virt driver would set.

if we want to enforce that restion it would be betteer to start now before we add somethign
that could be reused for a differnt usecase.
>     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". 
>