Open Stack

On Thu, Sep 20, 2018 at 11:11:12AM +0900, Ghanshyam Mann wrote:
>  ---- On Wed, 19 Sep 2018 23:29:46 +0900 Monty Taylor <mordred at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180919/655f9d36/attachment.sig>