[tc] [ptl] [qa] [infra] [nova] [cinder] [designate] [trove] [zaqar] [freezer] [networking-midonet] Migrating legacy jobs to Bionic (Ubuntu LTS 18.04)
melwittt at gmail.com
Mon Mar 25 06:03:09 UTC 2019
On Wed, 13 Mar 2019 12:28:23 -0700, Melanie Witt <melwittt at gmail.com> wrote:
> On Wed, 13 Mar 2019 13:32:01 -0500, Matt Riedemann <mriedemos at gmail.com>
>> On 3/13/2019 12:21 AM, Ghanshyam Mann wrote:
>>> *FAILING PROJECTS: NEED ACTION*
>>> nova - testing with tls-proxy disable -https://review.openstack.org/#/c/639017/
>> This is being worked around for two separate issues:
>> 1. ceph setup in the nova-live-migration and nova-grenade-live-migration
>> job isn't working with bionic: https://review.openstack.org/#/c/643122/
>> 2. tls-proxy is being disabled in the nova-next job as a workaround:
>> I'm not sure what's going on with #1 since it's using the
>> devstack-plugin-ceph repo functions to install ceph but it's not very
>> easy to tell what's going wrong from the logs, we probably need a debug
>> patch which turns on xtrace.
> From what it says in the commit message on the skip patch, the plugin
> wants to install Ceph Hammer (fairly old version) and that version is
> not available on bionic. I'll look into whether we can move up to a
> newer version (or something) to fix this issue.
FYI to thread readers, this got fixed by:
>> As for the tls-proxy one, it looks like Mel is investigating it a bit
>> and could probably also use some of Stephen's help.
> Yeah, I'm digging into it. I first tried an attempt to use 2048 bit
> certs instead of 1024 bit, based on this bugzilla I found:
> https://bugzilla.redhat.com/show_bug.cgi?id=1651882#c6 - "The
> certificates which are generated by the script are too weak for openssl
> default's configuration, and thus they get rejected."
> but that didn't work. Next, I'm going to see if it's a permission issue
> with the ownership of the certs directory. I remember when I originally
> tweaked Dan Berrange's patch to run console proxies with TLS in CI, I
> had to change the user:group from qemu:qemu to libvirt-qemu:libvirt-qemu
>  before it worked. So, I'm wondering if there's possibly new change
> in the qemu user, or something like that. I'll keep investigating.
I finally got the console testing with TLS issue worked out, patches are
More information about the openstack-discuss