Open Stack

Hi,

Thx for starting this thread.
I can share some thoughts from the Neutron point of view.

On Tue, May 19, 2020 at 04:08:18PM +0200, Balázs Gibizer wrote:
> Hi,
> 
> [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally
> kept short, let's try to discuss it or even conclude it before the PTG]
> 
> As a next step in the minimum bandwidth QoS support I would like to solve
> the use case where a running instance has some ports with minimum bandwidth
> but then user wants to change (e.g. increase) the minimum bandwidth used by
> the instance.
> 
> I see two generic ways to solve the use case:
> 
> Option A - interface attach
> ---------------------------
> 
> Attach a new port with minimum bandwidth to the instance to increase the
> instance's overall bandwidth guarantee.
> 
> This only impacts Nova's interface attach code path:
> 1) The interface attach code path needs to read the port's resource request
> 2) Call Placement GET /allocation_candidates?in_tree=<compute RP of the
> instance>
> 3a) If placement returns candidates then select one and modify the current
> allocation of the instance accordingly and continue the existing interface
> attach code path.
> 3b) If placement returns no candidates then there is no free resource left
> on the instance's current host to resize the allocation locally.
> 
> 
> Option B - QoS rule update
> --------------------------
> 
> Allow changing the minimum bandwidth guarantee of a port that is already
> bound to the instance.
> 
> Today Neutron rejects such QoS rule update. If we want to support such
> update then:
> * either Neutron should call placement allocation_candidates API and the
> update the instance's allocation. Similarly what Nova does in Option A.
> * or Neutron should tell Nova that the resource request of the port has been
> changed and then Nova needs to call Placement and update instance's
> allocation.

In this case, if You update QoS rule, don't forget that policy with this rule
can be used by many ports already. So we will need to find all of them and
call placement for each.
What if that will be fine for some ports but not for all?

> 
> 
> The Option A and Option B are not mutually exclusive but still I would like
> to see what is the preference of the community. Which direction should we
> move forward?

There is also 3rd possible option, very similar to Option B which is change of
the QoS policy for the port. It's basically almost the same as Option B, but
that way You have always only one port to update (unless it's not policy
associated with network). So because of that reason, maybe a bit easier to do.

> 
> 
> Both options have the limitation that if the instance's current host does
> not have enough free resources for the requested change then Nova will not
> do a full scheduling and move the instance to another host where resource is
> available. This seems a hard problem to me.
> 
> Do you have any idea how can we remove / ease this limitation without
> boiling the ocean?
> 
> For example: Does it make sense to implement a bandwidth weigher in the
> scheduler so instances can be spread by free bandwidth during creation?
> 
> 
> Cheers,
> gibi
> 
> 
> [0] https://etherpad.opendev.org/p/nova-victoria-ptg
> 
> 
> 

-- 
Slawek Kaplonski
Senior software engineer
Red Hat