The `kata-agent` binaries inside the Kata Containers images provided
with release are statically linked with the GNU LGPL-2.1 licensed
libseccomp library by default.
Therefore, we attach the complete source code of the libseccomp
to the release page in order to comply with the LGPL-2.1 (6(a)).
In addition, we add the description about the libseccomp license
to the release page.
Fixes: #2922
Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>
This commit will add containerd to versions.yaml.
Please at now there are both containerd and cri-containerd
in the versions.yaml.
After updating of kata-containers/tests repo, the cri-containerd
should be removed.
Fixes: #2791
Signed-off-by: bin <bin@hyper.sh>
Let's teach our `update-repository-version.sh` script to properly update
the kata-deploy tags on both kata-deploy and kata-cleanup yaml files.
The 3 scenarios that we're dealing with, based on which branch we're
targetting, are:
```
1) [main] ------> [main] NO-OP
"alpha0" "alpha1"
+----------------+----------------+
| from | to |
-----------------+----------------+----------------+
kata-deploy | "latest" | "latest" |
-----------------+----------------+----------------+
kata-deploy-base | "stable | "stable" |
-----------------+----------------+----------------+
2) [main] ------> [stable] Update kata-deploy and
"alpha2" "rc0" get rid of kata-deploy-base
+----------------+----------------+
| from | to |
-----------------+----------------+----------------+
kata-deploy | "latest" | "rc0" |
-----------------+----------------+----------------+
kata-deploy-base | "stable" | REMOVED |
-----------------+----------------+----------------+
3) [stable] ------> [stable] Update kata-deploy
"x.y.z" "x.y.(z+1)"
+----------------+----------------+
| from | to |
-----------------+----------------+----------------+
kata-deploy | "x.y.z" | "x.y.(z+1)" |
-----------------+----------------+----------------+
kata-deploy-base | NON-EXISTENT | NON-EXISTENT |
-----------------+----------------+----------------+
```
And we can easily cover those 3 cases only with the information about
the "${target_branch}" and the "${new_version}", where:
* case 1) if "${target_branch}" is "main" *and* "${new_version}"
contains "alpha", do nothing
* case 2) if "${target_branch}" is "main" *and* "${new_version}"
contains "rc":
* change the kata-deploy & kata-cleanup tags from "latest" to
"${new_version}".
* delete the kata-deploy-stable & kata-cleanup-stable files.
* case 3) if the "${target_branch}" contains "stable":
* change the kata-deploy & kata-cleanup tags from "${current_version}"
to "${new_version}".
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Removed all TOCs now that GitHub auto-generates them.
Also updated the documentation requirements doc removing the requirement
to add a TOC.
Fixes: #2022.
Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
Update kata-deploy-binaries.sh cli options.
Add options to allow ask build a tarball for a specific asset.
It will help developers build a specific component and update
a kata-deploy installation. Also build each asset independetly
can help to create cache tarballs per asset in the future.
e.g. Build a tarball with shimv2.
```
./kata-deploy-binaries.sh --build=shim-v2
```
Additionally, the script path is moved to a new directory
as not only will work for releases.
Signed-off-by: Carlos Venegas <jos.c.venegas.munoz@intel.com>
Let's teach `update-repository-version.sh` to automatically bump the
version of the kata-deploy images to be used within that release, when
running against the `kata-containers` repo.
Fixes: #1665
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
This doesn't make much difference for the automated process we have in
place, but makes a whole lot of difference for those trying to have the
binaries deployed locally.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
There's no runtime repo anymore, let's avoid making a reference to it,
which may end up confusing people reading the Release-Process file.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
There's no reason to ship qemu & qemu-virtiofs when the former already
includes vitiofs support (and that's the default for 2.x deployments).
In case we will enable experimental qemu DAX support, we should add a
new target, a "qemu-experimental" target, as Carlos has been working on.
Fixes: #1424
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
The docker script has been removed as part of
62cbaf4de4, but references to it were left
behind in the artifact-list.sh, release/kata-deploy-binaries.sh, and
kata-deploy/Dockerfile.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Update all tools/packaging scripts to prefer the new options over the
old ones (e.g. `--config` instead of `--kata-config`).
Signed-off-by: Daniel Knittl-Frank <knittl89+git@googlemail.com>
2.0 Packaging runtime-release-notes.sh script is using 1.x Packaging
kernel urls. Fix these urls to 2.0 branch Packaging urls.
Fixes: #829
Signed-off-by: Ychau Wang <wangyongchao.bj@inspur.com>
We should just download the official static build binary instead of
trying to build on our own.
Fixes: #760
Signed-off-by: Peng Tao <bergwolf@hyper.sh>
Since we always build musl kata-agent, there is no need to build
it inside a musl container. We can just build on the host and then
copy the binary to the target rootfs.
There are still a lot to clean up and it should be made so for ALL
target distros instead of just alpine. But this is at least working
for alpine first.
Signed-off-by: Peng Tao <bergwolf@hyper.sh>
