It seems the lack of protoc in the alpine containers is causing issues
with some of our CIs, such as the VFIO one.
Fixes: #3323
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Currently the versions.txt in rootfs-builder dir is already removed,
so avoid to copy it in list of helper files.
Fixes: #3267
Signed-off-by: zhanghj <zhanghj.lc@inspur.com>
In `utils/kata-manager.sh`, we download the first asset listed for the
release, which used to be the static x86_64 tarball. If that happened to
not match the system architecture, we would abort. Besides that logic
being invalid for !x86_64 (despite not distributing other tarballs at
the moment), the first asset listed is also not the static tarball any
more, it is the vendored source tarball. Retrieve all _static_ tarballs
and select the appropriate one depending on architecture.
Fixes: #3254
Signed-off-by: Jakob Naucke <jakob.naucke@ibm.com>
As containerd can properly run without having a existent
`/etc/containerd/config.toml` file (it'd run using the default
cobnfiguration), let's explicitly create the file in those cases.
This will avoid issues on ammending runtime classes to a non-existent
file.
Fixes: #3229
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Tested-by: Jakob Naucke <jakob.naucke@ibm.com>
Use the same runtime used for podman run also for the podman build cmd
Additionally remove "docker" from the docker_run_args variable
Fixes: #3239
Signed-off-by: Snir Sheriber <ssheribe@redhat.com>
In `utils/kata-manager.sh`, we download the first asset listed for the
release, which used to be the static x86_64 tarball. If that happened to
not match the system architecture, we would abort. Besides that logic
being invalid for !x86_64 (despite not distributing other tarballs at
the moment), the first asset listed is also not the static tarball any
more, it is the vendored source tarball. Retrieve all _static_ tarballs
and select the appropriate one depending on architecture.
Fixes: #3254
Signed-off-by: Jakob Naucke <jakob.naucke@ibm.com>
The links are either pointing to the not-used-anymore `master` branch,
or to the kubernetes-incubator page.
Let's always point to the CRI-O github page, using the `main`branch.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
#3244 moved directories that were referred to with links to `main`,
which affects stable.
Fixes: #3334
Signed-off-by: Jakob Naucke <jakob.naucke@ibm.com>
This is a bug release from Cloud Hypervisor addressing the following
issues: 1) Networking performance regression with virtio-net; 2) Limit
file descriptors sent in vfio-user support; 3) Fully advertise PCI MMIO
config regions in ACPI tables; 4) Set the TSS and KVM identity maps so
they don't overlap with firmware RAM; 5) Correctly update the DeviceTree
on restore.
Details can be found: https://github.com/cloud-hypervisor/cloud-hypervisor/releases/tag/v20.1Fixes: #3262
Signed-off-by: Bo Chen <chen.bo@intel.com>
(cherry picked from commit bbfb10e169)
- Set Alpine guest rootfs to 3.13 on all instances.
- Specify a minor version rather than patch level as the Alpine
repositories use that.
Signed-off-by: Jakob Naucke <jakob.naucke@ibm.com>
#2399 partially reverted #418, missing on returning to bootstrapping a
rootfs with `apk.static` instead of copying the entire root, which can
result in drastically larger (more than 10x) images. Revert this as well
(requires some updates to URL building).
Fixes: #3216
Signed-off-by: Jakob Naucke <jakob.naucke@ibm.com>
ppc64le & s390x have no (well supported) musl target for Rust,
therefore, the agent must use glibc and cannot use Alpine. Specify
Ubuntu as the distribution to be used for initrd.
Fixes: #3212
Signed-off-by: Jakob Naucke <jakob.naucke@ibm.com>
The latest release of openapi-generator v5.3.0 contains the fix for
`dropping err` bug [1]. This patch also re-generated the client code of
Cloud Hypervisor to have the bug fixed.
[1] https://github.com/OpenAPITools/openapi-generator/pull/10275Fixes: #3201
Signed-off-by: Bo Chen <chen.bo@intel.com>
(cherry picked from commit 995300260e)
Highlights from the Cloud Hypervisor release v20.0: 1) Multiple PCI
segments support (now support up to 496 PCI devices); 2) CPU pinning; 3)
Improved VFIO support; 4) Safer code; 5) Extended documentation; 6) Bug
fixes.
Details can be found: https://github.com/cloud-hypervisor/cloud-hypervisor/releases/tag/v20.0Fixes: #3178
Signed-off-by: Bo Chen <chen.bo@intel.com>
(cherry picked from commit 0bf4d2578a)
vhost-net is disabled in the rootless kata runtime feature, which has been abandoned since kata 2.0.
I reused the rootless flag for nonroot hypervisor and would like to enable vhost-net.
Fixes#3182
Signed-off-by: Feng Wang <feng.wang@databricks.com>
(cherry picked from commit b3bcb7b251)
In function `update_target`, if the updated source is a directory,
we should create the corresponding directory.
Fixes: #3140
Signed-off-by: bin <bin@hyper.sh>
kata-deploy files must be adapted to a new release. The cases where it
happens are when the release goes from -> to:
* main -> stable:
* kata-deploy / kata-cleanup: change from "latest" to "rc0"
* kata-deploy-stable / kata-cleanup-stable: are removed
* stable -> stable:
* kata-deploy / kata-cleanup: bump the release to the new one.
There are no changes when doing an alpha release, as the files on the
"main" branch always point to the "latest" and "stable" tags.
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
So that the debug console is more useful. In the meantime, remove
iptables as it is not used by kata-agent any more.
Fixes: #3138
Signed-off-by: Peng Tao <bergwolf@hyper.sh>
kernel compiled in fedora 35 (latest) is not working, following error
is reported:
```
qemu-system-x86_64: Error loading uncompressed kernel without PVH ELF
Note
```
Build QAT kernel in fedora 34 container to fix it
fixes#3135
Signed-off-by: Julio Montes <julio.montes@intel.com>
(cherry picked from commit 857501d8dd)
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Let's take advantage of the "is-organization-member" action and only
allow members who are part of the `kata-containers` organization to
trigger `/test_kata_deploy`.
One caveat with this approach is that for the user to be considered as
part of an organization, they **must** have their "Organization
Visibility" configured as Public (and I think the default is Private).
This was found out and suggested by @jcvenegas!
Fixes: #3130
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
(cherry picked from commit 5e7c1a290f)
Commit 3c9ae7f made /test_kata_deploy run
against HEAD, but it also mistakenly removed all the checks that ensure
/test_kata_deploy only runs when explicitly called.
Mea culpa on this, and let's add the tests back.
Fixes: #3101
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
(cherry picked from commit a7c08aa4b6)
Is the past few releases we ended up hitting issues that could be easily
avoided if `/test_kata_deploy` would use HEAD instead of a specific
tarball.
By the end of the day, we want to ensure kata-deploy works, but before
we cut a release we also want to ensure that the binaries used in that
release are in a good shape. If we don't do that we end up either
having to roll a release back, or to cut a second release in a really
short time (and that's time consuming).
Note: there's code duplication here that could and should be avoided,b
but I sincerely would prefer treating it in a different PR.
Fixes: #3001
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
(cherry picked from commit 3c9ae7fb4b)
We noticed s390x test failures on several of the watcher unit tests.
Discovered that on s390 in particular, if we update a file in quick
sucecssion, the time stampe on the file would not be unique between the
writes. Through testing, we observe that a 20 millisecond delay is very
reliable for being able to observe the timestamp update. Let's ensure we
have this delay between writes for our tests so our tests are more
reliable.
In "the real world" we'll be polling for changes every 2 seconds, and
frequency of filesystem updates will be on order of minutes and days,
rather that microseconds.
Fixes: #2946
Signed-off-by: Eric Ernst <eric_ernst@apple.com>
