Issues with SLES CI

[GabyCT]

I am trying to re-enable the SLES CI for kata containers. Currently the image that is available on Azure is SLES 12 SP4, however, trying to modify the https://github.com/kata-containers/tests/blob/master/.ci/setup_env_sles.sh, I faced with the following issues.

1. If I want to install redis package, I need to do

   $ redis_repo="https://download.opensuse.org/repositories/server:database/SLE_15_SP1/server:database.repo"
   $ sudo -E zypper addrepo --no-gpgcheck ${redis_repo}

   As we can see I am enabling a further version of SLES in order to get this package.

2. I have issues in trying to install package dependencies for CRI-O Some of the CRI-O dependencies are

   [crio_dependencies]="libglib-2_0-0 libseccomp-devel libapparmor-devel libgpg-error-devel glibc-devel-static libgpgme-devel libassuan-devel glib2-devel glibc-devel util-linux"

   However, a lot of those packages can't be found or they got conflicts with other packages, for example

   
   $ sudo zypper -n install  libapparmor-devel
   Refreshing service 'Advanced_Systems_Management_Module_x86_64'.
   Refreshing service 'Containers_Module_x86_64'.
   Refreshing service 'HPC_Module_x86_64'.
   Refreshing service 'Legacy_Module_x86_64'.
   Refreshing service 'Public_Cloud_Module_x86_64'.
   Refreshing service 'SUSE_Linux_Enterprise_Server_x86_64'.
   Refreshing service 'SUSE_Linux_Enterprise_Software_Development_Kit_x86_64'.
   Refreshing service 'SUSE_Package_Hub_x86_64'.
   Refreshing service 'Toolchain_Module_x86_64'.
   Refreshing service 'Web_and_Scripting_Module_x86_64'.
   Loading repository data...
   Warning: Repository 'leap-oss' appears to be outdated. Consider using a different mirror or server.
   Reading installed packages...
   Resolving package dependencies...

Problem: libapparmor-devel-2.12.3-lp150.6.17.1.x86_64 requires libapparmor1 = 2.12.3, but this requirement cannot be provided uninstallable providers: libapparmor1-2.12.3-lp150.6.17.1.x86_64[leap-oss] Solution 1: install libapparmor1-2.12.3-lp150.6.17.1.x86_64 (with vendor change) SUSE LLC https://www.suse.com/ --> openSUSE Solution 2: do not install libapparmor-devel-2.12.3-lp150.6.17.1.x86_64 Solution 3: break libapparmor-devel-2.12.3-lp150.6.17.1.x86_64 by ignoring some of its dependencies

This another example of package conflicts

$ sudo zypper -n install glibc-devel-static Refreshing service 'Advanced_Systems_Management_Module_x86_64'. Refreshing service 'Containers_Module_x86_64'. Refreshing service 'HPC_Module_x86_64'. Refreshing service 'Legacy_Module_x86_64'. Refreshing service 'Public_Cloud_Module_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Server_x86_64'. Refreshing service 'SUSE_Linux_Enterprise_Software_Development_Kit_x86_64'. Refreshing service 'SUSE_Package_Hub_x86_64'. Refreshing service 'Toolchain_Module_x86_64'. Refreshing service 'Web_and_Scripting_Module_x86_64'. Loading repository data... Warning: Repository 'leap-oss' appears to be outdated. Consider using a different mirror or server. Reading installed packages... Resolving package dependencies...

Problem: glibc-devel-static-2.26-lp150.11.20.1.x86_64 requires glibc-devel = 2.26, but this requirement cannot be provided uninstallable providers: glibc-devel-2.26-lp150.11.14.2.x86_64[leap-oss] glibc-devel-2.26-lp150.11.17.1.x86_64[leap-oss] glibc-devel-2.26-lp150.11.20.1.x86_64[leap-oss] glibc-devel-2.26-lp150.11.3.2.x86_64[leap-oss] glibc-devel-2.26-lp150.11.6.120.x86_64[leap-oss] glibc-devel-2.26-lp150.11.9.1.x86_64[leap-oss] Solution 1: Following actions will be done: install glibc-2.26-lp150.11.20.1.x86_64 (with vendor change) SUSE LLC https://www.suse.com/ --> openSUSE install glibc-devel-2.26-lp150.11.20.1.x86_64 (with vendor change) SUSE LLC https://www.suse.com/ --> openSUSE install glibc-locale-2.26-lp150.11.20.1.x86_64 (with vendor change) SUSE LLC https://www.suse.com/ --> openSUSE install nscd-2.26-lp150.11.20.1.x86_64 (with vendor change) SUSE LLC https://www.suse.com/ --> openSUSE Solution 2: do not install glibc-devel-static-2.26-lp150.11.20.1.x86_64 Solution 3: break glibc-devel-static-2.26-lp150.11.20.1.x86_64 by ignoring some of its dependencies

Now the issue of packages is not only related with CRI-O dependencies, but also with cri-containerd, kernel and qemu dependencies.

The Azure image that I am using is

NAME="SLES" VERSION="12-SP4" VERSION_ID="12.4" PRETTY_NAME="SUSE Linux Enterprise Server 12 SP4" ID="sles" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:suse:sles:12:sp4"

I do not know if there is a better approach to fix this
/cc @rhafer

[rhafer]

Currently the image that is available on Azure is SLES 12 SP4

Azure also has SLES 15 SP1 images, which is the lastest release of SLES. Have you tried them? They would be a much better choice I think.

[GabyCT]

@rhafer , I switched to SLES 15 SP1, however, when I try to run a container with kata, I am getting the following error

S docker run -ti --runtime kata-runtime busybox sh
docker: Error response from daemon: OCI runtime create failed: Could not setup vhost fds eth0 : open /dev/vhost-net: no such file or directory: unknown.

[rhafer]

I assume that's caused by the azure specific kernel the instances are having installed by default. It doesn't include the vhost_net module. Please try zypper in kernel-default and reboot the instance. That should fix it.

[GabyCT]

@rhafer yes, that worked, for the CI we need to create a custom opensuse image that has the vhost_net module and then triggered that image in jenkins

[rhafer]

for the CI we need to create a custom opensuse image that has the vhost_net module

I guess you mean custom SLES image?

[GabyCT]

@rhafer yes SLES, sorry

[GabyCT]

@rhafer , the custom image for SLES has been generated, and now I will enable the SLES CI for kata repositories https://github.com/kata-containers/tests/pull/2402 I will close this issue