Earlier this month I produced a blog post on something I was working
on to combine gabbi (the API tester used in placement, gnocchi,
heat, and a few other projects) with tempest to create a simple two
step process for having some purely YAML-driven and HTTP API-based
of any project that can test with tempest. That blog posting is at:
https://anticdent.org/gabbi-in-the-gate.html
I've got it working now and the necessary patches have merged in
tempest and gabbi-tempest is now part of openstack's infra.
A pending patch in nova shows how it can work:
https://review.openstack.org/#/c/613386/
The two steps are:
* Add a new job in .zuul.yaml with a parent of 'gabbi-tempest'
* Create some gabbi YAML files containing tests in a directory
named in that zuul job.
* Profit.
There are a few different pieces that have come together to make
this possible:
* The magic of zuul v3, local job config and job inheritance.
* gabbi: https://gabbi.readthedocs.io/
* gabbi-tempest: https://gabbi-tempest.readthedocs.io/ and
https://git.openstack.org/cgit/openstack/gabbi-tempest
and the specific gabbi-tempest zuul job:
https://git.openstack.org/cgit/openstack/gabbi-tempest/tree/.zuul.yaml#n11
* tempest plugins and other useful ways of getting placement to run
in different ways
I hope this is useful for people. Using gabbi is a great way to make
sure that your HTTP API is usable with lots of different clients and
without maintaining a lot of state.
Let me know if you have any questions or if you are interested in
helping to make gabbi-tempest more complete and well documented.
I've been approving my own code the past few patches and that feels
a bit dirty.
--
Chris Dent ٩◔̯◔۶ https://anticdent.org/
freenode: cdent tw: @anticdent
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
