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

Doug Hellmann doug at doughellmann.com
Tue Nov 6 23:45:45 UTC 2018


Ghanshyam Mann <gmann at ghanshyammann.com> writes:

>  ---- On Wed, 07 Nov 2018 06:51:32 +0900 Slawomir Kaplonski <skaplons at redhat.com> wrote ---- 
>  > Hi,
>  > 
>  > > Wiadomość napisana przez Jeremy Stanley <fungi at yuggoth.org> w dniu 06.11.2018, o godz. 22:25:
>  > > 
>  > > On 2018-11-06 22:05:49 +0100 (+0100), Slawek Kaplonski wrote:
>  > > [...]
>  > >> 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?
>  > > [...]
>  > > 
>  > > That opens the door to piecemeal migration, which (as we similarly
>  > > saw during the Trusty to Xenial switch) will inevitably lead to
>  > > projects who no longer gate on Xenial being unable to integration
>  > > test against projects who don't yet support Bionic. At the same
>  > > time, projects which have switched to Bionic will start merging
>  > > changes which only work on Bionic without realizing it, so that
>  > > projects which test on Xenial can't use them. In short, you'll be
>  > > broken either way. On top of that, you can end up with projects that
>  > > don't get around to switching completely before release comes, and
>  > > then they're stuck having to manage a test platform transition on a
>  > > stable branch.
>  > 
>  > I understand Your point here but will option 2) from first email lead to the same issues then?
>
> seems so. approach 1 is less risky for such integrated testing issues and requires less work. In approach 1, we can coordinate the base job migration with project side testing with bionic.
>
> -gmann

I like the approach of updating the devstack jobs to move everything to
Bionic at one time because it sounds like it presents less risk of us
ending up with something that looks like it works together but doesn't
actually because it's tested on a different platform, as well as being
less likely to cause us to have to do major porting work in stable
branches after the release.

We'll need to take the same approach when updating the version of Python
3 used inside of devstack.

Doug



More information about the OpenStack-dev mailing list