[placement][ptg] Keeping osc-placement healthy
From the etherpad [1]:
* It is behind (in microversions) and sometimes hard to remember * It's functional tests require a working devstack, which is a bit meh * Maybe something like https://vcrpy.readthedocs.io/en/latest/ could help (reasonable given microversions) * (edleafe) It might be useful to have an osc-placement lead (czar? princess? mayor?) who can devote some of their time to this and help coordinate others. I might be able to rustle up some cycles. Not much to add to the above. What additional ideas to people have. Who (in addition to Ed) has some time to care about osc-placement? What do people think of vcrpy? What else? [1] https://etherpad.openstack.org/p/placement-ptg-train -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On 4/8/2019 11:37 AM, Chris Dent wrote:
* It is behind (in microversions) and sometimes hard to remember
Part of this is on the core team IMO. For nova compute API microversion changes we also require a corresponding change in python-novaclient since the client is capped at the microversion it supports, and that is used when doing version negotiation with the server to determine the default version to use for the CLI (which is a different behavior from openstack CLI which just defaults to 2.1 for everything). Anyway, the point is, we/I haven't considered a nova blueprint which adds a microversion as complete until the python-novaclient change is also merged. osc-placement has sort of missed this because of an out of sight / out of mind kind of situation. With StoryBoard tracking placement features we could definitely track something like the server side work in placement itself as a task and the osc-placement related change as another task, so the overall story isn't complete until both parts are done (or the CLI task is invalidated for whatever reason - not all microversions require CLI changes). Anyway, from a project management standpoint, it always helped me to know which nova blueprints weren't done yet because they still needed the CLI changes and then follow up on those.
* It's functional tests require a working devstack, which is a bit meh
I'm not familiar with vcrpy but a simple improvement if we're worried about the time it takes to spin up devstack for these functional jobs is simply trim down the list of enabled services in the devstack run. By default devstack is running with most everything [1] - for these tests we should be able to just enable keystone and placement. Granted I think devstack-gate modifies ENABLED_SERVICES a bit but you get the idea: we don't need glance/cinder/nova/neutron/etcd/tempest/horizon enabled in devstack for osc-placement functional tests. [1] https://github.com/openstack-dev/devstack/blob/a6e4e42fb3461b61e91ae63477462... -- Thanks, Matt
On Mon, 8 Apr 2019, Matt Riedemann wrote:
osc-placement has sort of missed this because of an out of sight / out of mind kind of situation. With StoryBoard tracking placement features we could definitely track something like the server side work in placement itself as a task and the osc-placement related change as another task, so the overall story isn't complete until both parts are done (or the CLI task is invalidated for whatever reason - not all microversions require CLI changes).
Yeah, I think we can probably help this situation if we follow the process I've started describing in https://docs.openstack.org/placement/latest/contributor/contributing.html#ne... where it says "Work items that are described in a spec should be reflected as tasks created on the originating story. Update the story with additional tasks as they are discovered." We should make sure that any osc-placement obligations are one of those tasks (and that should probably be a bullet in those docs).
* It's functional tests require a working devstack, which is a bit meh
I'm not familiar with vcrpy but a simple improvement if we're worried about the time it takes to spin up devstack for these functional jobs is simply trim down the list of enabled services in the devstack run. By default devstack is running with most everything [1] - for these tests we should be able to just enable keystone and placement.
Yes, that's probably a good idea to speed up the gate side of things, but what I'm hoping we could figure out is a way to make it so on the dev side of things we don't need a running devstack for the test -> fix iterative cycle. The majority of the actually useful tests in osc-placement are integration tests (but labeled functional) and thus rather costly to run for the sake of development. vcrpy or requests-mock could potentially help us create real functional tests. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On 4/8/2019 1:44 PM, Chris Dent wrote:
Yes, that's probably a good idea to speed up the gate side of things, but what I'm hoping we could figure out is a way to make it so on the dev side of things we don't need a running devstack for the test -> fix iterative cycle. The majority of the actually useful tests in osc-placement are integration tests (but labeled functional) and thus rather costly to run for the sake of development. vcrpy or requests-mock could potentially help us create real functional tests.
Hmm, what about using the PlacementFixture in the osc-placement functional tests? Nova's already doing that successfully for nova's functional tests. -- Thanks, Matt
On Mon, 8 Apr 2019, Matt Riedemann wrote:
On 4/8/2019 1:44 PM, Chris Dent wrote:
Yes, that's probably a good idea to speed up the gate side of things, but what I'm hoping we could figure out is a way to make it so on the dev side of things we don't need a running devstack for the test -> fix iterative cycle. The majority of the actually useful tests in osc-placement are integration tests (but labeled functional) and thus rather costly to run for the sake of development. vcrpy or requests-mock could potentially help us create real functional tests.
Hmm, what about using the PlacementFixture in the osc-placement functional tests? Nova's already doing that successfully for nova's functional tests.
Yeah, that's probably the most gain with least effort solution. I had it in my head that I wanted the tests to be with fixed/static API responses, but with PlacementFixture being as no-big-deal as it is, it is probably easier to use that. I'll make a story [1], annotate the ptg etherpad, and we can call this sub-thread a big win. [1] https://storyboard.openstack.org/#!/story/2005411 -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On 4/9/2019 6:00 AM, Chris Dent wrote:
I'll make a story [1], annotate the ptg etherpad, and we can call this sub-thread a big win.
\o/ -- Thanks, Matt
On 4/8/2019 12:05 PM, Matt Riedemann wrote:
Granted I think devstack-gate modifies ENABLED_SERVICES a bit but you get the idea: we don't need glance/cinder/nova/neutron/etcd/tempest/horizon enabled in devstack for osc-placement functional tests.
I did this and it works: https://review.openstack.org/#/c/651344/ It doesn't save a lot of time (looks like about 5 minutes or so on a 30 minute job) but it's cheap and easy until the PlacementFixture idea is worked on. -- Thanks, Matt
On Mon, Apr 8, 2019 at 11:38 AM Chris Dent <cdent+os@anticdent.org> wrote:
* It's functional tests require a working devstack, which is a bit meh * Maybe something like https://vcrpy.readthedocs.io/en/latest/ could help (reasonable given microversions)
I don't have much personal experience with it but Keystone uses betamax[0] in at least keystoneauth for recording/testing REST interactions. I recall Jamie talking about it, not sure who knows the most about it these days... dt [0] https://github.com/betamaxpy/betamax -- Dean Troyer dtroyer@gmail.com
Since this thread started there have been a few changes:
* It is behind (in microversions) and sometimes hard to remember
A new contributor has provided a microversion 1.22: https://review.openstack.org/#/c/651783/
* It's functional tests require a working devstack, which is a bit meh * Maybe something like https://vcrpy.readthedocs.io/en/latest/ could help (reasonable given microversions)
Based on Matt's suggestion I've changed the functional tests to use the PlacementFixture https://review.openstack.org/#/c/651939/ and it seems to work rather well.
* (edleafe) It might be useful to have an osc-placement lead (czar? princess? mayor?) who can devote some of their time to this and help coordinate others. I might be able to rustle up some cycles.
What do people think of the idea of czar for osc-placement? Someone who will keep it on the radar, thank kind of thing. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
participants (3)
-
Chris Dent
-
Dean Troyer
-
Matt Riedemann