Open Stack

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