This is a proposal that was sent to the ML and can be accessed via
http://lists.katacontainers.io/pipermail/kata-dev/2021-May/001894.html
Shortly, the proposal is to maintain only one stable branch per major
active release.
This will help the developers and the CI maintainers, to spend more time
on what's coming, rather on backporting and debugging issues with old
releases; while still providing one stable branch that downstream
companies can rely on.
Hopefully, with this we'll be able to lower the maintainance burden and
spend more time on getting things rock solid / move forward in a faster
pace with the project.
Fixes: #1876
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
The current wording is good, but we could emphasize better that changes
on behaviour from a previous release by simply making the text bold
rather than italic.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
As there's no active `master` branch as part of kata-containers 2.x,
let's avoid referring to it, and let's referr to the `main` branch
instead.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
This config is not selected for ppc64le. It is
only supported on PPC32 for now. Moved it to
respective arch base.conf.
Signed-off-by: Amulyam24 <amulmek1@in.ibm.com>
we can have the following case,
1. start kata container with factory feature, this need kata-runtime
config to enable factory and use initrd as base image.
2. start a kata container.
3. cd /root; cd /run/vc/vm/template dir, this will make
/run/vc/vm/template to be in used.
4. destroy vm template with kata-runtime factory destroy , and check
the template mountpoint.
we can see the template mountpoints will add everytime we repeat the above steps .
[root@centos1 template]# mount |grep template
[root@centos1 template]# docker run -ti --rm --runtime untrusted-runtime --net none busybox echo
[root@centos1 template]# cd /root; cd /run/vc/vm/template/
[root@centos1 template]# /kata/bin/kata-runtime factory destroy
vm factory destroyed
[root@centos1 template]# mount |grep template
tmpfs on /run/vc/vm/template type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=2105344k)
[root@centos1 template]# docker run -ti --rm --runtime untrusted-runtime --net none busybox echo
[root@centos1 template]# cd /root; cd /run/vc/vm/template/
[root@centos1 template]# /kata/bin/kata-runtime factory destroy
vm factory destroyed
[root@centos1 template]# mount |grep template
tmpfs on /run/vc/vm/template type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=2105344k)
tmpfs on /run/vc/vm/template type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=2105344k)
Fixes: #938
Signed-off-by: Shukui Yang <keloyangsk@gmail.com>
While evaluating the possibility of having kata-agent statically linked
to the GNU libc, we've ended up facing some issues with prctl.
When debugging the issues, we figured out that the crate hasn't been
maintained since 2015 and that the capctl one is a good 1:1 replacement
for what we need.
Fixes: #1844
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
When hotplug memory on arm64 in kata, kernel will shout:
[ 0.396551] Block size [0x40000000] unaligned hotplug range: start 0xc8000000, size 0x40000000
[ 0.396556] acpi PNP0C80:01: add_memory failed
[ 0.396834] acpi PNP0C80:01: acpi_memory_enable_device() error
[ 0.396948] acpi PNP0C80:01: Enumeration failure
It means that kernel will check if the memory range to be hotplugged
align with 1G before plug the memory. So we should twist the qemu to
make sure the memory range align with 1G to pass the kernel check.
Fixes: #1841
Signed-off-by: Yuanzhe Liu <yuanzheliu09@gmail.com>
After some enablement work, memory hotplug can be used on arm64.
Here we offer a document to instruct user to enable it.
Fixes: #1854
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
covertool has no active since 2018 and is not compatible with go1.16
../vendor/github.com/dlespiau/covertool/pkg/cover/cover.go:76:29: cannot use f (type dummyTestDeps) as type testing.testDeps in argument to testing.MainStart:
dummyTestDeps does not implement testing.testDeps (missing SetPanicOnExit0 method)
Fixes: #1862
Signed-off-by: Shengjing Zhu <zhsj@debian.org>
The reason for doing such is to (try to) avoid random crashes we've been
facing as part of our CI, such as the one reported as part of
https://github.com/kata-containers/tests/issues/3473Fixes: #1850
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Otherwise we might block delete and create orphan containers.
Fixes: #1039
Signed-off-by: Peng Tao <bergwolf@hyper.sh>
Signed-off-by: Eric Ernst <eric_ernst@apple.com>
Since the propagation flags couldn't be combinted with the
standard mount flags, and they should be used with the remount,
thus it's better to split them from the standard mount flags.
Fixes: #1699
Signed-off-by: fupan.lfp <fupan.lfp@antgroup.com>
Following the fix for #1713, adding a unit test for ioCopy() that
verifies that data is properly copied from source to destination
whatever the order in which the pipes are closed.
Fixes#1831
Signed-off-by: Julien Ropé <jrope@redhat.com>
Occasionally patches are necessary to build QEMU with the kata containers
configuration. This changed the developer guide to make it clear it is
recommended to apply the patches; and tell how.
Fixes#1807
Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
When we create a new stable branch, it is good practice to ensure that the test
repository points to that stable branch, to make sure that it is not impacted by
later changes to the CI made on the stable branch.
Fixes: #1823
Signed-off-by: Christophe de Dinechin <christophe@dinechin.org>
For easier debug, let's add subcommand to kata-runtime for gathering
metrics associated with a given sandbox.
kata-runtime metrics --sandbox-id foobar
Fixes: #1815
Signed-off-by: Eric Ernst <eric_ernst@apple.com>
Gathering stats for a given sandbox is pretty useful; let's export a
function from katamonitor pkg to do this.
Signed-off-by: Eric Ernst <eric_ernst@apple.com>