Open Stack

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-placement.2019-02-06.log.html#t2019-02-06T14:19:59
* update on osa situation, especially testing:
   http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2019-02-06.log.html#t2019-02-06T15:30:46
* leaving the placement code in nova:
   http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2019-02-06.log.html#t2019-02-06T16:43:19

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-candidates-query
   https://blueprints.launchpad.net/nova/+spec/mixing-required-traits-with-any-traits
   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.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent