I'm trying so hard to catch up the discussion since I lost few.., it is
really hard...
In my mind , I'm always thinking the request group is only about binding
the trait and the resource class together. Also thinking about whether we
need a explicit tree structure to describe the request. So sounds like
proximity parameter right to me.
2018-04-19 6:45 GMT+08:00 Eric Fried <openst...@fried.cc>:
> > I have a feeling we're just going to go back and forth on this, as we
> > have for weeks now, and not reach any conclusion that is satisfactory to
> > everyone. And we'll delay, yet again, getting functionality into this
> > release that serves 90% of use cases because we are obsessing over the
> > 0.01% of use cases that may pop up later.
>
> So I vote that, for the Rocky iteration of the granular spec, we add a
> single `proximity={isolate|any}` qparam, required when any numbered
> request groups are specified. I believe this allows us to satisfy the
> two NUMA use cases we care most about: "forced sharding" and "any fit".
> And as you demonstrated, it leaves the way open for finer-grained and
> more powerful semantics to be added in the future.
>
> -efried
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
