vdsm check-patch networking tests need privileged containers in CI

Description

Hi,
is there any documentation on how to use the new container backend with the
CI container that spawns VM for privileged operations?

Thank you.
Regards,
Ales

Ales Musil

Software Engineer - RHV Network

Red Hat EMEA <https://www.redhat.com>

amusil@redhat.com IM: amusil
<https://red.ht/sig>

Activity

Show:
Ales Musil
April 29, 2020, 8:40 AM

No, vagrant is not going to be used. The original question was if we can use CI container that runs vagrant VM. Because this option is not good idea as we were told, we would like to have privileged container running directly on CI.

 

As requested here is list of services that we run in container:

UNIT LOAD ACTIVE SUB DESCRIPTION
dbus.service loaded active running D-Bus System Message Bus
NetworkManager.service loaded active running Network Manager
selinux-autorelabel-mark.service loaded active exited Mark the need to relabel after reboot
systemd-journald.service loaded active running Journal Service
systemd-resolved.service loaded active running Network Name Resolution
systemd-tmpfiles-setup.service loaded active exited Create Volatile Files and Directories
systemd-udevd.service loaded active running udev Kernel Device Manager

LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.

7 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

 

Evgheni Dereveanchin
April 29, 2020, 12:24 PM

We already have a set of working containers that spawn VMs using lago/OST - can we leverage that to use for VDSM testing?

From the infra point of view we want to limit the potential effect on the host and network tests may try to reconfigure NICs etc. Can’t we use existing VMs running mocks for these kinds of tests? What’s the quay.io/ovirt/vdsm-test-func-network-centos-8 container and where is it currently used?

Ales Musil
April 29, 2020, 12:38 PM

We already have a set of working containers that spawn VMs using lago/OST - can we leverage that to use for VDSM testing?

If it helps I am in. Is there any documentation how to do that?

From the infra point of view we want to limit the potential effect on the host and network tests may try to reconfigure NICs etc. Can’t we use existing VMs running mocks for these kinds of tests? What’s the quay.io/ovirt/vdsm-test-func-network-centos-8 container and where is it currently used?

Mock is slowing down the tests which makes it unstable and we cant relay on results. That’s why we want to switch in first place. The container is used to run network functional tests on check patch is something has changed in networking code. Everything I have shared about services and modules is from this container.

 

Anton Marchukov
April 29, 2020, 2:41 PM

For the spawning VMs case there is nothing that CI currently supports AFAIK. You either implement it yourself as part of your check-patch scripts (you can use libvirt, vagrant or lago or whatever else to run a VM in your check-patch). I do not think it is good solution to force each project to implement that functionality separately, but there is nothing yet that helps with it in CI. So till we have a better solution this could be an option.

The OST runs post merge and thus is not part of STDCI steps running per patch. Also OST is custom job and we do not want each projects to have customs jenkins jobs too since it will also require custom slaves.

We also can schedule check-patch to a baremetal (it is possible to configure in stdci yaml). The only problem is that this baremetal is not reprovisioned each time, so if it gets broken or polluted it will eventually affect other jobs using it.

We announced support for running containers in STDCI, but due to missing kernel isolation and lack of reprovisioning of “used” kernels, we cannot really support privileged containers yet unless CI users explicitly fence themselves from the outside by explicitly running a VM on top of their container. But then they cannot really use STDCI functionality for that.

I am reassigning to to figure out what could be possible with STDCI right now as I might have missed something.

Martin Perina
May 4, 2020, 11:24 AM

Any news?

Assignee

Ehud Yonasi

Reporter

Ales Musil

Blocked By

None

Priority

Medium
Configure