On Thu, Sep 20, 2018 at 11:11:12AM +0900, Ghanshyam Mann wrote: > ---- On Wed, 19 Sep 2018 23:29:46 +0900 Monty Taylor <mord...@inaugust.com> > wrote ---- > > On 09/19/2018 09:23 AM, Monty Taylor wrote: > > > 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. > > +1. All the base job from Tempest and Devstack (except grenade which is in > progress) are available to use as base for legacy jobs. Using > devstack-temepst in your patch is right things. In addition, you need to > mention the tox_envlist as all-plugins to make tempest_test_regex work. I > commented on review.
No, all-plugins is incorrect and should never be used. It's only there for legacy support, it is deprecated and I thought we pushed a patch to indicating that (but I can't find it). It tells tox to create a venv with system site-packages enabled and that almost always causes more problems than it fixes. Specifying the plugin with TEMPEST_PLUGINS will make sure the plugin is installed in tempest's venv, and if you need to run a tox job without a preset selection regex (so you can specify your own) you should use the "all" job. (not all-plugins) -Matt Treinish > > > > > > > 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? > > > > K. This: > > > > > http://git.openstack.org/cgit/openstack/neutron-tempest-plugin/tree/.zuul.yaml#n184 > > Yeah, You can install that via TEMPEST_PLUGINS var. All plugins specified in > TEMPEST_PLUGINS var, will be installed into the tempest venv[1]. You can > mention the gabbi-tempest same way. > > [1] > https://github.com/openstack-dev/devstack/blob/6f4b7fc99c4029d25a924bcad968089d89e9d296/lib/tempest#L663 > > -gmann > > > > > Has an example of a job using 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 > > > > > > __________________________________________________________________________ > > 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
signature.asc
Description: PGP signature
__________________________________________________________________________ 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
