Open Stack

I was presenting an example using VM-ish resource classes, because I can
write them down and everybody knows what I'm talking about without me
having to explain what they are.  But remember we want placement to be
usable outside of Nova as well.

But also, I thought we had situations where the VCPU and MEMORY_MB were
themselves provided by sharing providers, associated with a compute host
RP that may be itself devoid of inventory.  (This may even be a viable
way to model VMWare's clustery things today.)

-efried

On 04/16/2018 01:58 PM, Jay Pipes wrote:
> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev