Open Stack

On Fri, May 29, 2020 at 16:29, Balázs Gibizer 
<balazs.gibizer at est.tech> wrote:
> 
> 
> On Wed, May 20, 2020 at 13:50, Balázs Gibizer 
> <balazs.gibizer at est.tech> wrote:
>> 
>> 
>> On Tue, May 19, 2020 at 23:48, Sean Mooney <smooney at redhat.com> 
>> wrote:
>>> On Tue, 2020-05-19 at 21:55 +0200, Slawek Kaplonski wrote:
>>> 
> 
> [snip]
> 
> 
> Also I would like to tease out the Neutron team's opinion about the 
> option of implementing Option B on the neutron side. E.g.:
> * User request a min bw rule replacement
> * Neutron reads the current allocation of the port.device_id (i.e 
> instance_uuid) from placement
> * Neutron calculates the difference between the bw resource request 
> of the old min bw rule and the new min bw rule
> * Neutron adds this difference to the bw allocation of the RP 
> indicated by the value of port.binding_profile['allocation'] (which 
> is an RP uuid) and the PUTs the new instance allocation back to 
> placement. If the PUT /allocations call succeed the the rule 
> replacement is accepted and if the PUT /allocations fails then the 
> rule replacement is rejected to the end user.
> 

On the PTG we agreed that
* There will be an RFE on neutron to allow in-place min bandwidth 
allocation change based on the above drafted sequence
* Triggering a resize due to interface attach or port.resource_request 
change seems insane. In the future we might look at that from a 
different perspective. I.e. What if a resize could take a new parameter 
that indicates that the resize is not due to flavor change but due to 
bandwidth change.

Cheers,
gibi

[snip]

> 
> Cheers,
> gibi
> 
> 
>