Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>