I have a patch in progress to add some simple integration tests to
placement:
https://review.openstack.org/#/c/601614/
They use https://github.com/cdent/gabbi-tempest . The idea is that
the method for adding more tests is to simply add more yaml in
gate/gabbits, without needing to worry about adding to or think
about tempest.
What I have at that patch works; there are two yaml files, one of
which goes through the process of confirming the existence of a
resource provider and inventory, booting a server, seeing a change
in allocations, resizing the server, seeing a change in allocations.
But this is kludgy in a variety of ways and I'm hoping to get some
help or pointers to the right way. I'm posting here instead of
asking in IRC as I assume other people confront these same
confusions. The issues:
* The associated playbooks are cargo-culted from stuff labelled
"legacy" that I was able to find in nova's jobs. I get the
impression that these are more verbose and duplicative than they
need to be and are not aligned with modern zuul v3 coolness.
* It takes an age for the underlying devstack to build, I can
presumably save some time by installing fewer services, and making
it obvious how to add more when more are required. What's the
canonical way to do this? Mess with {enable,disable}_service, cook
the ENABLED_SERVICES var, do something with required_projects?
* This patch, and the one that follows it [1] dynamically install
stuff from pypi in the post test hooks, simply because that was
the quick and dirty way to get those libs in the environment.
What's the clean and proper way? gabbi-tempest itself needs to be
in the tempest virtualenv.
* The post.yaml playbook which gathers up logs seems like a common
thing, so I would hope could be DRYed up a bit. What's the best
way to that?
Thanks very much for any input.
[1] perf logging of a loaded placement: https://review.openstack.org/#/c/602484/
--
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
