On 4/20/2016 8:25 AM, Miguel Angel Ajo Pelayo wrote:
Inline update.
On Mon, Apr 11, 2016 at 4:22 PM, Miguel Angel Ajo Pelayo
<majop...@redhat.com> wrote:
On Mon, Apr 11, 2016 at 1:46 PM, Jay Pipes <jaypi...@gmail.com> wrote:
On 04/08/2016 09:17 AM, Miguel Angel Ajo Pelayo wrote:
[...]
Yes, Nova's conductor gathers information about the requested networks
*before* asking the scheduler where to place hosts:
https://github.com/openstack/nova/blob/stable/mitaka/nova/conductor/manager.py#L362
That would require identifying that the port has a "qos_policy_id"
attached to it, and then, asking neutron for the specific QoS policy
[3], then look out for a minimum bandwidth rule (still to be defined),
and extract the required bandwidth from it.
Yep, exactly correct.
That moves, again some of the responsibility to examine and
understand external resources to nova.
Yep, it does. The alternative is more retries for placement decisions
because accurate decisions cannot be made until the compute node is already
selected and the claim happens on the compute node.
Could it make sense to make that part pluggable via stevedore?, so
we would provide something that takes the "resource id" (for a port in
this case) and returns the requirements translated to resource classes
(NIC_BW_KB in this case).
Not sure Stevedore makes sense in this context. Really, we want *less*
extensibility and *more* consistency. So, I would envision rather a system
where Nova would call to Neutron before scheduling when it has received a
port or network ID in the boot request and ask Neutron whether the port or
network has any resource constraints on it. Neutron would return a
standardized response containing each resource class and the amount
requested in a dictionary (or better yet, an os_vif.objects.* object,
serialized). Something like:
{
'resources': {
'<UUID of port or network>': {
'NIC_BW_KB': 2048,
'IPV4_ADDRESS': 1
}
}
}
Oh, true, that's a great idea, having some API that translates a
neutron resource, to scheduling constraints. The external call will be
still required, but the coupling issue is removed.
I had a talk yesterday with @iharchys, @dansmith, and @sbauzas about
this, and we believe the synthesis of resource usage / scheduling
constraints from neutron makes sense.
We should probably look into providing those details in a read only
dictionary during port creation/update/show in general, in that way,
we would not be adding an extra API call to neutron from the nova
scheduler to figure out any of those details. That extra optimization
is something we may need to discuss with the neutron community.
Note that I think the only time Nova gets details about ports in the API
during a server create request is when doing the network request
validation, and that's only if there is a fixed IP address or specific
port(s) in the request, otherwise Nova just gets the networks. [1]
In the case of the NIC_BW_KB resource class, Nova's scheduler would look for
compute nodes that had a NIC with that amount of bandwidth still available.
In the case of the IPV4_ADDRESS resource class, Nova's scheduler would use
the generic-resource-pools interface to find a resource pool of IPV4_ADDRESS
resources (i.e. a Neutron routed network or subnet allocation pool) that has
available IP space for the request.
Not sure about the IPV4_ADDRESS part because I still didn't look on
how they resolve routed networks with this new framework, but for
other constraints makes perfect sense to me.
Best,
-jay
Best regards,
Miguel Ángel Ajo
[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-February/086371.html
[2] https://bugs.launchpad.net/neutron/+bug/1560963
[3]
http://developer.openstack.org/api-ref-networking-v2-ext.html#showPolicy
__________________________________________________________________________
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
[1]
https://github.com/openstack/nova/blob/ee7a01982611cdf8012a308fa49722146c51497f/nova/network/neutronv2/api.py#L1123
--
Thanks,
Matt Riedemann
__________________________________________________________________________
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
