# Kata Containers 3.0.2

[amshinde]

• stable-3.0: Stable 3.0 backports
• stable-3.0 | docs: Fix missing critical steps in how-to-hotplug-memory-arm64.md
• Stable-3.0 | Upgrade to Cloud Hypervisor v28.2
• Qemu logs for stable 3.0
• Backport CI fixes for s390x and ppc64le to stable-3.0
• docs: Fix missing critical steps in how-to-hotplug-memory-arm64.md
• Stable-3.0 | Upgrade to Cloud Hypervisor v28.1

4ebeb51 release: Adapt kata-deploy for 3.0.2
178ee3d agent: check command before do test_ip_tables
7461bcd runtime-rs: change cache mode
123c867 SEV: Update ReducedPhysBits
98f60c1 clh: Enforce API timeout only for vm.boot request
960f089 virtiofsd: fix the build on ppc64le
92f3b11 runtime:all APIs are hang in the service.mu
92619c8 runtime: Drop QEMU log file support
4f3db76 runtime: Collect QEMU's stderr
918c11e runtime: Start QEMU undaemonized
8c4507b runtime: Launch QEMU with cmd.Start()
a61fba6 runtime: Pre-establish the QMP connection
ad9cb0b govmm: Optionally pass QMP listener to QEMU
d6dd99e govmm: Optionally start QMP with a pre-configured connection
0623f1f virtiofsd: Not use "link-self-contained=yes" on s390x
5883dc1 CI: Set docker version to v20.10 in ubuntu:20.04 for s390x|ppc64le
4a5877f docs: Fix missing critical steps in how-to-hotplug-memory-arm64.md
d3b5732 versions: Upgrade to Cloud Hypervisor v28.2
0d7bd06 docs: Fix missing critical steps in how-to-hotplug-memory-arm64.md
ac1ce2d docs: Fix missing critical steps in how-to-hotplug-memory-arm64.md
f4d71af docs: Fix missing critical steps in how-to-hotplug-memory-arm64.md
fcc120d versions: Upgrade to Cloud Hypervisor v28.1

[amshinde]

/test

[amshinde]

/test_kata_deploy

[fidencio]

/test_kata_deploy

[fidencio]

/test_kata_deploy

This is not working as it seems the action will always be read from the main repo, which contains targets that are not part of this branch. :-/

This, most likely, will also affect the release.

[amshinde]

@fidencio Yeah not sure why that is happening, I referred to the workflow of previous release(3.0.1) that you had done, and I see that it uses the workflow file from stable branch to run:
https://github.com/kata-containers/kata-containers/actions/runs/3733032319/workflow
Wonder what has changed. Will have to debug this.

[jodh-intel]

Thanks @amshinde.

lgtm

[fidencio]

@fidencio Yeah not sure why that is happening, I referred to the workflow of previous release(3.0.1) that you had done, and I see that it uses the workflow file from stable branch to run: https://github.com/kata-containers/kata-containers/actions/runs/3733032319/workflow Wonder what has changed. Will have to debug this.

Another simpler approach could be to backport #6141

[amshinde]

/test_kata_deploy

[amshinde]

/test

[fidencio]

Ouch, it seems way more patches would need to be backported. :-/

[fidencio]

@amshinde, so, this seems to be the correct behaviour when we're using an action based on issue_comment, at least according to https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#issue_comment.

[fidencio]

Please, drop the extra patches, let's have this one merged without the kata-deploy test (and, pretty please, open an issue for this), and it won't affect the release itself.

[amshinde]

/test

[amshinde]

/test_kata_deploy

[fidencio]

lgtm, thanks @amshinde!

The /test_kata_deploy won't pass, but it won't affect the release workflow.

[amshinde]

@fidencio The github docs do mentionLast commit on default branch, but I was looking at previous release : #5922

The SHA that the workflow points to is the version bump sha on the stable 3.0 branch rather than main branch. Which really doesnt add up, unless github changed the behaviour+docs recently.

[fidencio]

The SHA that the workflow points to is the version bump sha on the stable 3.0 branch rather than main branch. Which really doesnt add up, unless github changed the behaviour+docs recently.

The SHA on the workflow points to 2e54c8e, which was the last commit on main.

We do some tricks in order to get the correct SHA as part of each task of the action, but then if a new task's been added, we end up failing, which is the case right now. :-/

[amshinde]

/test-vfio