[openstack-dev] [qa][python3] advice needed with updating lib-forward-testing jobs

Doug Hellmann doug at doughellmann.com
Thu Jun 14 17:02:31 UTC 2018


Excerpts from Ghanshyam's message of 2018-06-14 16:54:33 +0900:
> 
> 
> 
>  ---- On Thu, 14 Jun 2018 05:55:55 +0900 Doug Hellmann <doug at doughellmann.com> wrote ---- 
>  > Excerpts from Doug Hellmann's message of 2018-06-13 12:19:18 -0400:
>  > > Excerpts from Doug Hellmann's message of 2018-06-13 10:31:00 -0400:
>  > > > Excerpts from Ghanshyam's message of 2018-06-13 16:52:33 +0900:
>  > > > >  ---- On Wed, 13 Jun 2018 05:09:03 +0900 Doug Hellmann <doug at doughellmann.com> wrote ---- 
>  > > > >  > I would like to create a version of the jobs that run as part of
>  > > > >  > lib-forward-testing (legacy-tempest-dsvm-neutron-src) that works under
>  > > > >  > python 3. I'm not sure the best way to proceed, since that's a legacy
>  > > > >  > job.
>  > > > >  > 
>  > > > >  > I'm not sure I'm familiar enough with the job to port it to be
>  > > > >  > zuulv3 native and allow us to drop the "legacy". Should I just
>  > > > >  > duplicate that job and modify it and keep the new one as "legacy"
>  > > > >  > too?
>  > > > >  > 
>  > > > >  > Is there a different job I should base the work on? I don't see anything
>  > > > >  > obvious in the tempest repo's .zuul.yaml file.
>  > > > > 
>  > > > > I had a quick glance of this job (legacy-tempest-dsvm-neutron-src) and it is similar to tempest-full-py3 job except it override the LIBS_FROM_GIT with corresponding lib. tempest-full-py3 job is py3 based with tempest-full tests running and disable the swift services 
>  > > > > 
>  > > > > You can create a new job (something tempest-full-py3-src) derived from 'tempest-full-py3' if all set var is ok for you like disable swift OR derived  'devstack-tempest' and then build other var similar to 'tempest-full-py3'.  Extra things you need to do is to add libs you want to override in 'required_project' list (FYI- 
>  > > > > Now LIBS_FROM_GIT is automatically set based on required projects [2]) .
>  > > > > 
>  > > > > Later, old job (legacy-tempest-dsvm-neutron-src) can be migrated separately if needed to run or removed. 
>  > > > > 
>  > > > > But I am not sure which repo  should own this new job.
>  > > > 
>  > > > Could it be as simple as adding tempest-full-py3 with the
>  > > > required-projects list updated to include the current repository? So
>  > > > there isn't a special separate job, and we would just reuse
>  > > > tempest-full-py3 for this?
> 
> This can work if lib-forward-testing is going to run against current lib repo only not cross lib or cross project. For example, if neutron want to tests neutron change against neutron-lib src  then this will not work. But from history [1] this does not seems to be scope of lib-forward-testing.
> 
> Even  we do not need to add current repo to required-projects list or in LIBS_FROM_GIT .  That will always from master + current patch changes. So this makes no change in tempest-full-py3 job and we can directly use  tempest-full-py3 job in lib-forward-testing. Testing in [2].

Does it? So if I add tempest-full-py3 to a *library* that library is
installed from source in the job? I know the source for the library
will be checked out, but I'm surprised that devstack would be configured
to use it. How does that work?

> 
> And if anyone needed cross lib/project testing (like i mentioned above) then, it will be very easy by defining a new job derived from tempest-full-py3 and add required lib in required_projects list. 

Sure. Someone could do that, but it's not the problem I'm trying
to solve right now.

> 
>  > > > 
>  > > > It would be less "automatic" than the current project-template and job,
>  > > > but still relatively simple to set up. Am I missing something? This
>  > > > feels too easy...
>  > > 
>  > > I think I could define a job with a name like tempest-full-py3-src based
>  > > on tempest-full-py3 and set LIBS_FROM_GIT to include
>  > > {{zuul.project.name}} in the devstack_localrc vars section. If I
>  > > understand correctly, that would automatically set LIBS_FROM_GIT to
>  > > refer to the project that the job is attached to, which would make it
>  > > easier to use from a project-template (I would also create a
>  > > lib-forward-testing-py3 project template to supplement
>  > > lib-forward-testing).
>  > > 
>  > > Does that sound right?
>  > > 
>  > > Doug
>  > 
>  > This appears to be working.
>  > 
>  > https://review.openstack.org/575164 adds a job to oslo.config and the
>  > log shows LIBS_FROM_GIT set to oslo.config's repository:
>  > 
>  > http://logs.openstack.org/64/575164/1/check/tempest-full-py3-src/7a193fa/job-output.txt.gz#_2018-06-13_19_01_22_742338
>  > 
>  > How does the QA team feel about hosting the job definition in the
>  > tempest repository with the tempest-full-py3 job? If you think that will
>  > work, I can propose the patch tomorrow.
>  > 
> 
> [1] https://review.openstack.org/#/c/125433
> [2] https://review.openstack.org/#/c/575324
> 
> -gmann
> 
>  > Doug
>  > 
>  > __________________________________________________________________________
>  > 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
>  > 
> 



More information about the OpenStack-dev mailing list