Hello, Thank your for the productive call. Here is a short summary about the agreements: * 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. Cheers, gibi On Mon, Jan 14, 2019 at 6:16 PM, Balázs Gibizer <balazs.gibizer@ericsson.com> wrote:
On Wed, Jan 9, 2019 at 5:56 PM, Balázs Gibizer <balazs.gibizer@ericsson.com> wrote:
On Wed, Jan 9, 2019 at 11:30 AM, Balázs Gibizer <balazs.gibizer@ericsson.com> wrote:
On Mon, Jan 7, 2019 at 1:52 PM, Balázs Gibizer <balazs.gibizer@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