[nova] review guide for the bandwidth patches
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
>>>>> of January 14 when Matt is back), as suggested in
>>>>> today. We'll be able to have a high-bandwidth discussion then
>>>>> 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 work for you for a
>> It seems that Tuesday 15th of Jan, 17:00 UTC  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
> Jan, 17:00 UTC .
> The dicussion etherpad is updated with a bit more info .
>  https://hangouts.google.com/call/oZAfCFV3XaH3IxaA0-ITAEEI
>  https://etherpad.openstack.org/p/bandwidth-way-forward
>>  https://hangouts.google.com/call/oZAfCFV3XaH3IxaA0-ITAEEI
More information about the openstack-discuss