CI fixes/workarounds

[Danilo Šegan]

Ok, looking at the CI docs Andres pointed me at, we do usually
workaround this by setting the suid bit on the qemu-bridge-helper
executable, and dpkg stat-overriding it so it persists across package
upgrades.

The docs point at /usr/lib/qemu-bridge-helper which is now a symlink to
/usr/lib/qemu/qemu-bridge-helper, so perhaps that's why the problems
started (and there was indeed a qemu upload on Apr 20: https://launchpa
d.net/ubuntu/+source/qemu/1:2.5+dfsg-5ubuntu10.11).

It seems as if autopkgtest could be improved to start up libvirt
instances in a way that tells libvirtd to kick off the apparmor profile
creation for the domain, but I am dropping this (for now).

Cheers,
Danilo


У чет, 27. 04 2017. у 12:09 +0200, Danilo Šegan пише:
> It seems libvirt is expected to run virt-aa-helper to create an
> AppArmor profile for each domain and put a file into
> /etc/apparmor.d/libvirt/DOMAIN-UUID based on TEMPLATE.qemu in the
> same
> directory.
> 
> For some reason, this does not seem to happen (or it does not apply)
> when autopkgtest is used, so it would be useful to investigate
> further
> with a proper shell (I've did my digging with "script console" from
> within the Jenkins UI).
> 
> Since I am just joining the MAAS team, I'll wait for someone more
> experienced with our CI infrastructure to come up so I don't mess
> something up (eg. slave rebuild process needs to be fixed too, if
> it's
> not manual).
> 
> Cheers,
> Danilo
> 
> У чет, 27. 04 2017. у 11:19 +0200, Danilo Šegan пише:
> > 
> > Hi all,
> > 
> > It seems MAAS CI has started failing recently with the following:
> > 
> > failed to create tun device: Operation not permitted
> > qemu-system-x86_64:/home/ubuntu/workspace/maas-xenial-trunk/maas-
> > ci-
> > config/etc/region.cfg:3: bridge helper failed
> > autopkgtest-virt-qemu: DBG: cleanup...
> > <VirtSubproc>: failure: Timed out waiting for /tmp/autopkgtest-
> > virt-
> > qemu.hekftn7o/ttyS0 socket
> > 
> > See eg.
> > 
> > http://162.213.35.104:8080/job/maas-xenial-trunk/1216/console
> > http://162.213.35.104:8080/job/maas-xenial-trunk-manual-juju/262/co
> > ns
> > ole
> > http://162.213.35.104:8080/job/arm64_firmware_update/32/console
> > 
> > 
> > region.cfg referenced above on our HP-DL360-Gen9 slave 
> > (http://162.213.35.104:8080/computer/HP-DL360-Gen9/) is the
> > following:
> > 
> > ----- 8< ----------- 8< -----
> > # qemu config file
> > 
> > [net]
> >   type = "bridge"
> >   vlan = "3"
> >   br = "br2"
> >   helper = "/usr/lib/qemu-bridge-helper"
> > 
> > [net]
> >   type = "nic"
> >   model = "virtio"
> >   macaddr = "DE:AD:BE:EF:6B:B3"
> >   vlan = "3"
> > ----- 8< ----------- 8< -----
> > 
> > (pulled from maas-ci-config branch, where it has not changed since
> > January 2017).
> > 
> > 
> > I've so far worked-around it by setting suid bit on
> > /usr/lib/qemu/qemu-
> > bridge-helper (the above is just a symlink to this), and the
> > following
> > job went past that on to running tests:
> > 
> >   http://162.213.35.104:8080/job/maas-xenial-trunk/1217/console
> > 
> > I am looking into why apparmor configuration from libvirt-bin
> > package
> > is not working in this case so I can drop the workaround and fix it
> > properly.
> > 
> > Cheers,
> > Danilo
> >