Open Stack

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