Sorry it took so long to respond. Comments inline.
On 03/30/2018 08:34 PM, Eric Fried wrote:
Folks who care about placement (but especially Jay and Tetsuro)-
I was reviewing [1] and was at first very unsatisfied that we were not
returning the anchor providers in the results. But as I started digging
into what it would take to fix it, I realized it's going to be
nontrivial. I wanted to dump my thoughts before the weekend.
<BACKGROUND>
It should be legal to have a configuration like:
# CN1 (VCPU, MEMORY_MB)
# / \
# /agg1 \agg2
# / \
# SS1 SS2
# (DISK_GB) (IPV4_ADDRESS)
And make a request for DISK_GB,IPV4_ADDRESS;
And have it return a candidate including SS1 and SS2.
The CN1 resource provider acts as an "anchor" or "relay": a provider
that doesn't provide any of the requested resource, but connects to one
or more sharing providers that do so.
To be honest, such a request just doesn't make much sense to me.
Think about what that is requesting. I want some DISK_GB resources and
an IP address. For what? What is going to be *using* those resources?
Ah... a virtual machine. In other words, something that would *also* be
requesting some CPU and memory resources as well.
So, the request is just fatally flawed, IMHO. It doesn't represent a use
case from the real world.
I don't believe we should be changing placement (either the REST API or
the implementation of allocation candidate retrieval) for use cases that
don't represent real-world requests.
Best,
-jay
__________________________________________________________________________
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
