Open Stack

>From the cross project etherpad [1]

-=-=-

* We've had two instances where nova functional tests have failed
   from what seems like an unrelated change in placement, but turns
   out to be something that impacts the behavior of the
   PlacementFixture, from placement, used by nova. Would be good to
   decide on a way to make this safer without having to run the
   entire nova functional test suite (and the functional suite of
   every other project that eventually uses the Fixture) on every
   placement change. Maybe a subset somehow? Or some other kind of
   magic? Another option may be what we've been doing: fixing
   problems as they come up. That might be OK.

     * https://bugs.launchpad.net/nova/+bug/1818560

     * https://bugs.launchpad.net/nova/+bug/1821092

* (gibi): Currently placement patches trigger grenade-py3 and
   tempest-full-py3 and both jobs takes around an hour to run. The
   nova-tox-functional test runs in about 20 minutes. So triggering
   nova-tox-functional for placement patches does not increase the
   length of the CI feedback loop.

     * True but the total cpu cost of testing a single placement
       patch is a thing we need to keep in mind. Zuul resources are
       scarce. It's not just how long we have to wait, but how long
       everyone has to wait for all patches. (Not saying we shouldn't
       do it, just that we need to consider that impact.) (gibi): I
       agree that overall cpu cost is a factor here.

     * [efried] ++ I think this is a solid idea, at least until we
       implement the next bullet.

* (gibi): Both above bug could be detected with some test on the
   placement side using the PlacementFixture in a way nova is using
   that fixture. It might not be easy to gather all the relevat usage
   patterns.

     * [efried] Agree with this. We don't have any testing of
       PlacementFixture in placement itself (until the below)

* [efried] Started simple unit testing here https://review.openstack.org/#/c/645255/

     * This probably doesn't do us much good wrt preventing weird
       gatebusters like the above.

-=-=-

This is generally agreed to be an issue we need to address and there
are ideas for how to fix it, so the things to resolve here are:

* Tuning the ideas to the best combination.
* Figuring out who is going to do it.

[1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement
-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent