On Mon, Oct 11, 2021 at 07:59:47AM +0200, Christian Ehrhardt wrote:
On Thu, Oct 7, 2021 at 7:25 PM Ioanna Alifieraki
> +# For the next test to run apparmor needs to be installed and enabled.
> +# In some environments (e.g. containers) even though apparmor is
> +# installed, it is not enabled because securityfs is not mounted.
> +# In those environments this test cannot run so skip it.
> +# This test also needs to be run as root.
> +if [ `eval id -u` = 0 ] && [ -x "$(command -v aa-enabled)" ]
&& [ `eval aa-enabled` = "Yes" ]; then
This is great to be checked before causing a failure, but a question
to the libvirt-CI experts,
how doable (or not) would it be to get apparmor installed on those
distro testbeds that support it?
Assuming the necessary packages are included in the container image,
what else is needed to have apparmor running? Does apparmor need to
be running in the host OS as well for it to work in containers? Does
the "securityfs" thing mentioned in the comment above need to be
passed through from the host OS?
Our CI pipeline uses containers running on the GitLab infrastructure.
I'm not sure what they're using as host OS, but if it's something
like Fedora for example I would expect that running apparmor would be
a problem. If special filesystems need to be passed to the container,
that's probably going to pose a challenge too.
Are there any good pointers one would start to look at adapting those
testbeds?
The container images are generated from the Dockerfiles in
ci/containers, which in turn are generated using the lcitool utility
that's being developed as part of
https://gitlab.com/libvirt/libvirt-ci/
If you want to include more packages, you should start by defining a
mapping for it in
guests/lcitool/lcitool/ansible/vars/mappings.yml
and then adding it to
guests/lcitool/lcitool/ansible/vars/projects/libvirt.yml
That's the short version. If you're looking for more information,
just let me know and I'll be happy to help :)
--
Andrea Bolognani / Red Hat / Virtualization