[openstack-dev] [all][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04)

Slawek Kaplonski skaplons at redhat.com
Tue Nov 6 21:05:49 UTC 2018


Hi,

Thanks for bringing this up.

On Tue, Nov 06, 2018 at 01:12:55PM +0100, Dr. Jens Harbott (frickler) wrote:
> Dear OpenStackers,
> 
> earlier this year Ubuntu released their current LTS version 18.04
> codenamed "Bionic Beaver" and we are now facing the task to migrate
> our devstack-based jobs to run on Bionic instead of the previous LTS
> version 16.04 "Xenial Xerus".
> 
> The last time this has happened two years ago (migration from 14.04 to
> 16.04) and at that time it seems the migration was mostly driven by
> the Infra team (see [1]), mostly because all of the job configuration
> was still centrally hosted in a single repository
> (openstack-infra/project-config). In the meantime, however, our CI
> setup has been updated to use Zuul v3 and one of the new features that
> come with this development is the introduction of per-project job
> definitions.
> 
> So this new flexibility requires us to make a choice between the two
> possible options we have for migrating jobs now:
> 
>     1) Change the "devstack" base job to run on Bionic instances
> instead of Xenial instances
>     2) Create new "devstack-bionic" and "tempest-full-bionic" base
> jobs and migrate projects piecewise
> 
> Choosing option 1) would cause all projects that base their own jobs
> on this job (possibly indirectly by e.g. being based on the
> "tempest-full" job) switch automatically. So there would be the
> possibility that some jobs would break and require to be fixed before
> patches could be merged again in the affected project(s). To
> accomodate those risks, QA team can give some time to projects to test
> their jobs on Bionic with WIP patches (QA can provide Bionic base job
> as WIP patch). This option does not require any pre/post migration
> changes on project's jobs.
> 
> Choosing option 2) would avoid this by letting projects switch at
> their own pace, but create the risk that some projects would never
> migrate. It would also make further migrations, like the one expected
> to happen when 20.04 is released, either having to follow the same
> scheme or re-introduce the unversioned base job. Other point to note
> down with this option is,
>    - project job definitions need to change their parent job from
> "devstack" -> "devstack-bionic" or "tempest-full" ->
> "tempest-full-bionic"
>  - QA needs to maintain existing jobs ("devstack", "tempest-full") and
> bionic version jobs ("devstack-bionic", "tempest-full-bionic")

How about option 1) and also add jobs like "devstack-xenial" and
"tempest-full-xenial" which projects can use still for some time if their job on
Bionic would be broken now?

> 
> In order to prepare the decision, we have created a set of patches
> that test the Bionic
> jobs, you can find them under the common topic "devstack-bionic" [2].
> There is also an
> etherpad to give a summarized view of the results of these tests [3].
> 
> Please respond to this mail if you want to promote either of the above
> options or
> maybe want to propose an even better solution. You can also find us
> for discussion
> in the #openstack-qa IRC channel on freenode.
> 
> Infra team has tried both approaches during precise->trusty &
> trusty->xenial migration[4].
> 
> Note that this mailing-list itself will soon be migrated, too, so if
> you haven't subscribed
> to the new list yet, this is a good time to act and avoid missing the
> best parts [5].
> 
> Yours,
> Jens (frickler at IRC)
> 
> 
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-November/106906.html
> [2] https://review.openstack.org/#/q/topic:devstack-bionic
> [3] https://etherpad.openstack.org/p/devstack-bionic
> [4] http://eavesdrop.openstack.org/irclogs/%23openstack-qa/%23openstack-qa.2018-11-01.log.html#t2018-11-01T12:40:22
> [5] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html
> 
> __________________________________________________________________________
> 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

-- 
Slawek Kaplonski
Senior software engineer
Red Hat



More information about the OpenStack-dev mailing list