[nova] review guide for the bandwidth patches

Balázs Gibizer balazs.gibizer at ericsson.com
Fri Jan 18 18:07:16 UTC 2019


Thank your for the productive call. Here is a short summary about the 

* There will be a new microversion in nova for creating (and deleting) 
a server with ports having resource request. If such request is sent 
with any old microversion then nova will reject the request. Nova will 
reject not just the create request with old microvesion but all the 
requests that would lead to an inconsistent resource view. These are: 
create, attachInterface, resize, migrate live-migrate, evacuate, and 
unshelve of an offloaded server.

* Delete server having resource aware ports will be supported with old 
microversion. Nova will delete the whole consumer in placement anyhow.

* There will be a second new microversion (probably in Train) that will 
enable move operations for server having resource aware ports. This 
microversion split will allow us not to block the create / delete 
support for the feature in Stein.

* The new microversions will act as a feature flag in the code. This 
will allow merging single use cases (e.g.: server create with one ovs 
backed resource aware port) and functionally verifying it before the 
whole generic create use case is ready and enabled.

* A nova-manage command will be provided to heal the port allocations 
without moving the servers if there is enough resource inventory 
available for it on the current host. This tool will only work online 
as it will call neutron and placement APIs.

* Server move operations with the second new microversion will 
automatically heal the server allocation.


On Mon, Jan 14, 2019 at 6:16 PM, Balázs Gibizer 
<balazs.gibizer at ericsson.com> wrote:
> On Wed, Jan 9, 2019 at 5:56 PM, Balázs Gibizer
> <balazs.gibizer at ericsson.com> wrote:
>>  On Wed, Jan 9, 2019 at 11:30 AM, Balázs Gibizer
>>  <balazs.gibizer at ericsson.com> wrote:
>>>   On Mon, Jan 7, 2019 at 1:52 PM, Balázs Gibizer
>>>   <balazs.gibizer at ericsson.com> wrote:
>>>>>     But, let's chat more about it via a hangout the week after 
>>>>> next
>>>>>    (week
>>>>>     of January 14 when Matt is back), as suggested in
>>>>>  #openstack-nova
>>>>>     today. We'll be able to have a high-bandwidth discussion then
>>>>>  and
>>>>>     agree on a decision on how to move forward with this.
>>>>    Thank you all for the discussion. I agree to have a real-time
>>>>    discussion about the way forward.
>>>>    Would Monday, 14th of Jan, 17:00 UTC[1] work for you for a
>>>>    hangouts[2]?
>>  It seems that Tuesday 15th of Jan, 17:00 UTC [2] would be better for
>>  the team. So I'm moving the call there.
> Sorry to change it again. I hope this is the final time. Friday 18th 
> of
> Jan, 17:00 UTC [2].
> The dicussion etherpad is updated with a bit more info [3].
> Cheers,
> gibi
> [1] https://hangouts.google.com/call/oZAfCFV3XaH3IxaA0-ITAEEI
> [2]
> https://www.timeanddate.com/worldclock/fixedtime.html?iso=20190118T170000
> [3] https://etherpad.openstack.org/p/bandwidth-way-forward
>>  Cheers,
>>  gibi
>>  [1] https://hangouts.google.com/call/oZAfCFV3XaH3IxaA0-ITAEEI
>>  [2]
>> https://www.timeanddate.com/worldclock/fixedtime.html?iso=20190115T170000

More information about the openstack-discuss mailing list