On Wed, 6 Feb 2019, Chris Dent wrote:

A reminder that as discussed at the last placement extraction checkin meeting [1] we've got another one today at 1700 UTC. Join the #openstack-placement IRC channel around then if you are interested, and a google hangout url will be provided.

We did this. What follows are some notes.

TL;DR: We're going to keep the placement code in nova, but freeze it. The extracted code is unfrozen and open for API changes.

We did some warning up in IRC throughout the day, which may be useful context for readers:

* update on tripleo situation: http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-p... * update on osa situation, especially testing: http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-p... * leaving the placement code in nova: http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-p...

On the call we used the extraction etherpad to take notes and be an agenda: https://etherpad.openstack.org/p/placement-extract-stein-5

The main points to summarize are:

* Progress is going well in TripleO with regard to being able to deploy (by lyarwood) extracted placement but upgrades, especially CI of those upgrades is going to be challenging if not impossible in the near term. This is a relatively new development, resulting from a change in procedure within tripleo.

Not deleting the code from nova will help when the time comes, later, to test those upgrades.

* In OSA there have been some resourcing gaps on the work, but mnaser is currently iterating on making things go. cdent is going to help add some placement-only live tests (to avoid deploying nova) to the code mnaser is working (by mnaser, cdent).

As with tripleo, upgrade testing can be eased by leaving the placement code in nova.

* The nested VGPU reshaper work is undergoing some light refactoring but confidence is high that it is ready (by bauzas). Functional testing is ready to go too.

A manual test with real hardware was done some months ago, but not on the extracted code. It was decided that doing this again but we took it off the requirements because nobody has easy access to the right hardware[1].

* Based on the various issues above, and a general sense that it was the right thing to do, we're not going to delete the placement code from nova. This will allow upgrade testing

Both OSA and TripleO are currently able to test with not-extracted placement, and will continue to do so. A patch will be made to nova to add a job using OSA (by mnaser). Other avenues are being explored to make sure the kept-in-nova placement code is tested. The previous functional and unit tests were already deleted and devstack and grenade use extracted.

**The code still in nova is now considered frozen and nova's use of placement will be frozen (that is, it will assume microversion 1.30 or less) for the rest of Stein [2].**

* The documentation changes which are currently stacked behind the change to delete the placement code from nova will be pulled out (by cdent).

* The API presented by the extracted placement is now allowed to change. There are a few pending specs that we can make progress on if people would like to do so:

https://blueprints.launchpad.net/nova/+spec/alloc-candidates-in-tree https://blueprints.launchpad.net/nova/+spec/any-traits-in-allocation-candida... https://blueprints.launchpad.net/nova/+spec/mixing-required-traits-with-any-... https://blueprints.launchpad.net/nova/+spec/negative-aggregate-membership

Nobody has yet made any commitment to do this stuff, and there's a general sense that people are busy, but if there is time and interest we should talk about it.

We did not schedule a next check in meeting. When one needs to happen, which it will, we'll figure that out and make an announcement.

Thanks for your attention. If I made any errors above, or left something out, please followup. If you have questions, please ask them.

[1] Our employers should really be ashamed of themselves. This happens over and over and over again, across OpenStack, and is a huge drag on velocity.

[2] While technically it would be possible to do version discovery or version-guarded changes, to remove ambiguity and because nova is already overbooked and moving slowly, easier to just say "no" and leave it.