Open Stack

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.
> 
> 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

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