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.

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.


OpenStack Development Mailing List (not for usage questions)

Reply via email to