On 03/21/2016 06:22 AM, Miguel Angel Ajo Pelayo wrote:
Hi,
I was doing another pass on this spec, to see if we could leverage
it as-is for QoS / bandwidth tracking / bandwidth guarantees, and I
have a question [1]
I guess I'm just missing some detail, but looking at the 2nd scenario,
why wouldn't availability zones allow the same exactly if we used one
availability zone per subnet?
What's the advantage of modelling it via a generic resource pool?
Hi Miguel,
On the (Nova) scheduler side, we don't actually care whether Neutron
uses availability zone or subnet pool to model the boundaries of a pool
of some resource. The generic-resource-pools functionality being added
to Nova (as the new placement API meant to become the split-out
scheduler RESTful API) just sees a resource provider UUID and an
inventory of some type of resource.
In the case of Neutron QoS, the first thing to determine would be what
is the resource type exactly? The resource type must be able to be
represented with an integer amount of something. For QoS, I *think* the
resource type would be "NIC_BANDWIDTH_KB" or something like that. Is
that correct? This would represent the amount of total network bandwidth
that a workload can consume on a particular compute node. Is that
statement correct?
Now, the second thing that would need to be determined is what resource
boundary this resource type would have. I *think* it is the amount of
bandwidth consumed on a set of compute nodes? Like, amount of bandwidth
consumed within a rack? Or some similar segmentation of a network, like
an aggregate, which is a generic grouping of compute nodes. If so, then
the bandwidth resource would be considered a *shared* resource, shared
among the compute nodes in the aggregate. And if this is the case, then
generic-resource-pools are intended for *exactly* this type of scenario.
Best,
-jay
__________________________________________________________________________
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
