On 09/19/2018 08:25 AM, Chris Dent wrote:
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.
Yes. Your life will be much better if you do not make more legacy jobs.
They are brittle and hard to work with.
New jobs should either use the devstack base job, the devstack-tempest
base job or the devstack-tox-functional base job - depending on what
things are intended.
You might want to check out:
https://docs.openstack.org/devstack/latest/zuul_ci_jobs_migration.html
also, cmurphy has been working on updating some of keystone's legacy
jobs recently:
https://review.openstack.org/602452
which might also be a source for copying from.
* 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?
http://git.openstack.org/cgit/openstack/openstacksdk/tree/.zuul.yaml#n190
Has an example of disabling services, of adding a devstack plugin, and
of adding some lines to localrc.
http://git.openstack.org/cgit/openstack/openstacksdk/tree/.zuul.yaml#n117
Has some more complex config bits in it.
In your case, I believe you want to have parent: devstack-tempest
instead of parent: devstack-tox-functional
* 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.
This I don't have an answer for. I'm guessing this is something one
could do with a tempest plugin?
* 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?
Yup. Legacy devstack-gate based jobs are pretty terrible.
You can delete the entire post.yaml if you move to the new devstack base
job.
The base devstack job has a much better mechanism for gathering logs.
Thanks very much for any input.
[1] perf logging of a loaded placement:
https://review.openstack.org/#/c/602484/
__________________________________________________________________________
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
__________________________________________________________________________
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
