[openstack-dev] [qa] How to apply submit Nova v3 API tempest tests
cbkyeoh at gmail.com
Fri Aug 2 14:27:30 UTC 2013
On Fri, 02 Aug 2013 09:29:48 -0400
David Kranz <dkranz at redhat.com> wrote:
> On 08/02/2013 01:23 AM, Christopher Yeoh wrote:
> > times we run these tests in
> > > the gate once this gets merged. I think it would be best to go
> > > about
> > this as smaller patches in a
> > > longer series, just adding the v3 tests, instead of copying and
> > pasting. But, that has it's own
> > > tradeoffs too. I think you should probably bring this up on the
> > mailing list to get other opinions
> > > on how to go about adding the v3 tests. I feel that this needs a
> > wider discussion.
> > I think that the part 1/part 2 approach is the best way to go for
> > the tempest tests. For the Nova changes we had a policy of
> > reviewing, but not approving the part 1 patch until the part 2
> > patch had been approved. So there is no extra gate load until its
> > ready for v3.
> Chris, I think there is some background missing on exactly what this
> part 1/part 2 approach is. I can imagine some things but it would be
> better if you just gave a brief description of what you did in the
> nova code.
Sorry I should have explained better. The part1/part2 approach is to
split porting some code from v2 to v3 into two separate changesets:
- the first changeset only involves copying entire files from a v2 to
- in the context of tempest the second changeset makes the required
modifications so the test run will run correctly against the v3
rather than the v2 api. There often will be lots of minor changes
involved such as handling attribute renaming, different return codes,
actions moving to methods etc.
The first changeset should only be approved when the second one is.
> > As for the extra gate load, the extra v3 tests are an issue longer
> > term but I think we're hoping the parallelisation work is going to
> > save us :-)
> Well it will have to. As long as trunk is supporting v2 and v3 we
> have to run both I think.
I think one fallback alternative would be to have a VM in the gate
which tests against the v2 api and one which tests against the v3 api.
More information about the OpenStack-dev