<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 20, 2016 at 4:25 PM, Miguel Angel Ajo Pelayo <span dir="ltr"><<a href="mailto:majopela@redhat.com" target="_blank">majopela@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Inline update.<br>
<span class=""><br>
On Mon, Apr 11, 2016 at 4:22 PM, Miguel Angel Ajo Pelayo<br>
<<a href="mailto:majopela@redhat.com">majopela@redhat.com</a>> wrote:<br>
> On Mon, Apr 11, 2016 at 1:46 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
</span><span class="">>> On 04/08/2016 09:17 AM, Miguel Angel Ajo Pelayo wrote:<br>
</span>[...]<br>
<div><div class="h5">>> Yes, Nova's conductor gathers information about the requested networks<br>
>> *before* asking the scheduler where to place hosts:<br>
>><br>
>> <a href="https://github.com/openstack/nova/blob/stable/mitaka/nova/conductor/manager.py#L362" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/stable/mitaka/nova/conductor/manager.py#L362</a><br>
>><br>
>>>      That would require identifying that the port has a "qos_policy_id"<br>
>>> attached to it, and then, asking neutron for the specific QoS policy<br>
>>>   [3], then look out for a minimum bandwidth rule (still to be defined),<br>
>>> and extract the required bandwidth from it.<br>
>><br>
>><br>
>> Yep, exactly correct.<br>
>><br>
>>>     That moves, again some of the responsibility to examine and<br>
>>> understand external resources to nova.<br>
>><br>
>><br>
>> Yep, it does. The alternative is more retries for placement decisions<br>
>> because accurate decisions cannot be made until the compute node is already<br>
>> selected and the claim happens on the compute node.<br>
>><br>
>>>      Could it make sense to make that part pluggable via stevedore?, so<br>
>>> we would provide something that takes the "resource id" (for a port in<br>
>>> this case) and returns the requirements translated to resource classes<br>
>>> (NIC_BW_KB in this case).<br>
>><br>
>><br>
>> Not sure Stevedore makes sense in this context. Really, we want *less*<br>
>> extensibility and *more* consistency. So, I would envision rather a system<br>
>> where Nova would call to Neutron before scheduling when it has received a<br>
>> port or network ID in the boot request and ask Neutron whether the port or<br>
>> network has any resource constraints on it. Neutron would return a<br>
>> standardized response containing each resource class and the amount<br>
>> requested in a dictionary (or better yet, an os_vif.objects.* object,<br>
>> serialized). Something like:<br>
>><br>
>> {<br>
>>   'resources': {<br>
>>     '<UUID of port or network>': {<br>
>>       'NIC_BW_KB': 2048,<br>
>>       'IPV4_ADDRESS': 1<br>
>>     }<br>
>>   }<br>
>> }<br>
>><br>
><br>
> Oh, true, that's a great idea, having some API that translates a<br>
> neutron resource, to scheduling constraints. The external call will be<br>
> still required, but the coupling issue is removed.<br>
><br>
><br>
<br>
<br>
</div></div>I had a talk yesterday with @iharchys, @dansmith, and @sbauzas about<br>
this, and we believe the synthesis of resource usage / scheduling<br>
constraints from neutron makes sense.<br>
<br>
We should probably look into providing those details in a read only<br>
dictionary during port creation/update/show in general, in that way,<br>
we would not be adding an extra API call to neutron from the nova<br>
scheduler to figure out any of those details. That extra optimization<br>
is something we may need to discuss with the neutron community.<br>
<div class="HOEnZb"><div class="h5"><span style="color:rgb(34,34,34)"></span></div></div></blockquote><div>What about the caller context? </div><div>I believe these details should be  visible for admin user only.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><span style="color:rgb(34,34,34)"> </span><br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
>> In the case of the NIC_BW_KB resource class, Nova's scheduler would look for<br>
>> compute nodes that had a NIC with that amount of bandwidth still available.<br>
>> In the case of the IPV4_ADDRESS resource class, Nova's scheduler would use<br>
>> the generic-resource-pools interface to find a resource pool of IPV4_ADDRESS<br>
>> resources (i.e. a Neutron routed network or subnet allocation pool) that has<br>
>> available IP space for the request.<br>
>><br>
><br>
> Not sure about the IPV4_ADDRESS part because I still didn't look on<br>
> how they resolve routed networks with this new framework, but for<br>
> other constraints makes perfect sense to me.<br>
><br>
>> Best,<br>
>> -jay<br>
>><br>
>><br>
>>> Best regards,<br>
>>> Miguel Ángel Ajo<br>
>>><br>
>>><br>
>>> [1]<br>
>>><br>
>>> <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-February/086371.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-February/086371.html</a><br>
>>> [2] <a href="https://bugs.launchpad.net/neutron/+bug/1560963" rel="noreferrer" target="_blank">https://bugs.launchpad.net/neutron/+bug/1560963</a><br>
>>> [3]<br>
>>> <a href="http://developer.openstack.org/api-ref-networking-v2-ext.html#showPolicy" rel="noreferrer" target="_blank">http://developer.openstack.org/api-ref-networking-v2-ext.html#showPolicy</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>