Copyright 2016 OpenStack Foundation
This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode
Newton testing on Xenial¶
Include the URL of your StoryBoard story:
https://storyboard.openstack.org/#!/story/2000668
A new Ubuntu LTS release has happened and in order to keep up with the TC’s assertion that we support latest Ubuntu LTS and RHEL release we need to shift our testing onto this new release. General plan is move the default test image type from Ubuntu Trusty to Ubuntu Xenial for all testing on branches >= Newton (currently Newton is called master).
Problem Description¶
This poses a couple of issues. First we need a way to have Zuul instruct Zuul launchers on using the appropriate image type for jobs based on the branch. Second we need to do this in a way that avoids exploding the total number of Gearman function registrations as there are scaling limits there.
Proposed Change¶
Using JJB create jobs that are image type unique. This means instead of having:
gate-tempest-dsvm-full
we will have:
gate-tempest-dsvm-full-ubuntu-trusty
gate-tempest-dsvm-full-ubuntu-xenial
We can build these jobs from the same JJB job template ensuring the actual content of the jobs is shared.
Going this route and using a default Zuul Launcher or Jenkins with Gearman plugin will result in the following job registrations:
gate-tempest-dsvm-full-ubuntu-trusty
gate-tempest-dsvm-full-ubuntu-trusty:ubuntu-trusty
gate-tempest-dsvm-full-ubuntu-xenial
gate-tempest-dsvm-full-ubuntu-xenial:ubuntu-xenial
which is problematic because it will double our total number of Gearman function registrations on an already stressed system. We can address that by updating Zuul Launcher to optionally drop the label specific function registrations. This has been implemented in https://review.openstack.org/#/c/336311/
Alternatives¶
An alternative solution would be to do what we did during the Precise to Trusty transition. During that transition we used Zuul parameter functions to introspect the branch under test then set the ZUUL_NODE parameter to choose the correct test node type. The problem with this method was that it hid away a lot of the node selection logic in the parameter function where people did not expect to find it. On top of that any test not wanting to use this default split (eg anything wanting to use centos) needed an explicit override in that parameter function.
General consensus seems to be that we should try something different even if we know there are other deficiencies with the other options as this particular option was painful.
Implementation¶
Assignee(s)¶
- Primary assignee:
clarkb
Gerrit Topic¶
Use Gerrit topic “newton-xenial” for all patches related to this spec.
git-review -t newton-xenial
Work Items¶
Update Zuul Launcher code to optionally prevent label registrations.
Update Zuul Launcher installs and config to prevent label registrations.
Notify dev mailing list of switch.
Convert groups of jobs over to being run in a split setup. Likely we will want to do this with a common set at a time. pep8, docs, unittests, functional tests, tempest/integration tests. We can perform tests of these jobs ahead of time as well to ensure that things work well.
Repositories¶
No new repos required.
Servers¶
This will make use of the existing ubuntu-xenial test images and instances. We will also be taking advantage of the Xenial Ubuntu apt mirror and the Xenial wheel mirror.
DNS Entries¶
No new DNS entries.
Documentation¶
The biggest impact here should just be in notifying the developers of the switch. If we do this switchover like we have done it in the past it will happen in a controlled manner after we have tested that things generally work. It is possible that we will run into another major bug like the Trusty python34 garbage collection bug so we should notify people that this change is happening.
Security¶
No new security issues as this only affects single use test instances that already hand out root.
Testing¶
For previous distro release transitions we have held test instances and run unittests and integration tests on them to ensure that the new platform works as expected.
Dependencies¶
Just the new Zuul Launcher config being merged and deployed.
