qemuArchBase.appendBridges is never actually used, because the bare
qemuArchBase type is itself never used (outside of unit tests). Instead
*all* the subclasses of qemuArchBase override appendBridges() to call
the very similar, but not identical genericAppendBridges. So, we can
remove the qemuArchBase.appendBridges implementation.
Furthermore, all those subclasses override appendBridges() in exactly
the same way, and so we can remove *those* definitions and replace the
base class qemuArchBase appendBridges() with that version, calling
genericAppendBridges().
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Update to commit 1b60b536f3, in particular to get extensions to
allow IO and memory window reservations to be set on PCI bridges.
https://github.com/kata-containers/govmm/pull/201
Git log:
de039da govmm/qemu: Let IO/memory reservations be specified for bridge devices
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
A related dir is needed when apply qemu patch using script. As qemu 5.1
is used for arm, a dir of "v5.1.0" is needed under tag_patches.
Fixes: #2696
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
There are `DeviceToDeviceCgroup` and `deviceToDeviceCgroup` two functions,
creating a `specs.LinuxDeviceCgroup` object. We clear the new function `deviceToDeviceCgroup`.
Fixes: #2694
Signed-off-by: wangyongchao.bj <wangyongchao.bj@inspur.com>
Let's make it as clear as possible for the user that if they go for a
tagged version of kata-deploy, eg, 2.2.1, they'll have the kata runtime
2.2.1 deployed on their cluster.
Suggested-by: Eric Adams <eric.adams@intel.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's add more instructions in the README in order to make clear to the
reader what they can do to check whether kata-deploy is ready, or
whether they have to wait till proceeding with the next instruction.
Suggested-by: Eric Adams <eric.adams@intel.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
There's only one QEMU runtime class deployed as part of kata-deploy, and
that includes virtiofs support (which is the default for quite some time
already). Knowing this, let's just remove the `qemu-virtiofs` runtime
class definition.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
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>
Similar to the instructions we have for the "latest" images, let's also
add instructions about the "stable" images.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's just point to our repo URLs rather than assume users using
kata-deploy will have our repo cloned.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
This is **not** the nicest patch of my career, and I know it adds code
duplication. However, I've decided to take this approach in order to
have easier / better instructions for users who're consuming
kata-deploy.
Having both stable & latest yaml on `main` will let us point to just one
place, without having to update the instructions.
I know, would be better to have those generated from a .in file,
wouldn't it? For sure, but then we'd lose the ability to just point to
those files from kata-deploy pages (either on dockerhub or quay.io).
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Instead of point to a specific release number, let's point to the
`latest` tag on the main branch.
There's still some work needed in order to point to the `stable` tag on
the stable-x.y branches, as this is something that should be done
automagically as part of the release process.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
When releasing a tarball, let's *also* add the "stable" & "latest" tags
to the kata-deploy image.
The "stable" tag refers to any official release, while the "latest" tag
refers to any pre-release / release candidate.
Fixes: #2302
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
This was added in the 1.x repo and is missing in the 2.x repo.
Copying over the document from 1.x.
This is a starting point and focuses on the devices / interfaces
with the virtual machine, and ultimately to the container itself.
We then discuss how these devices/interfaces vary by VMM/hypervisor.
The threat model drawing is created via gdocs, located here:
https://docs.google.com/drawings/d/1dPi9DG9bcCUXlayxrR2OUa1miEZXewtW7YCt4r_VDmA/edit?usp=sharing
For Kata 2.x, the block named as `kata-runtime` has been changed to
`kata-shim`.
Fixes: #2340
Signed-off-by: Eric Ernst <eric.ernst@intel.com>
Signed-off-by: Archana Shinde <archana.m.shinde@intel.com>
As part of the release, let's also upload a tarball with the vendored
cargo code. By doing this we allow distros, which usually don't have
access to the internet while performing the builds, to just add the
vendored code as a second source, making the life of the downstream
maintainers slightly easier*.
Fixes: #1203
*: The current workflow requires the downstream maintainer to download
the tarball, unpack it, run `cargo vendor`, create the tarball, etc.
Although this doesn't look like a ridiculous amount of work, it's better
if we can have it in an automated fashion.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
The agent shutdown test should only run on the CI JOB of CRI_CONTAINERD_K8S_MINIMAL
which is the only one where testing tracing is being enabled, however, this
test is being triggered in multiple CI jobs where it should not run. This PR
fixes that issue.
Fixes#2683
Signed-off-by: Gabriela Cervantes <gabriela.cervantes.tellez@intel.com>
A discussion on the Linux kernel mailing list [1] exposed that virtiofsd makes a
core assumption that the file systems being shared are not accessible by any
non-privileged user. We currently create the `shared` directory in the sandbox
with the default `0750` permissions, which gives read and directory traversal
access to the group. There is no real good reason for a non-root user to access
the shared directory, and this is potentially dangerous.
Fixes: #2589
[1]: https://lore.kernel.org/linux-fsdevel/YTI+k29AoeGdX13Q@redhat.com/
Signed-off-by: Christophe de Dinechin <dinechin@redhat.com>
Retrieve the absolute sandbox storage path. We will soon need this to
monitor the creation/deletion of new kata sandboxes.
Signed-off-by: Francesco Giudici <fgiudici@redhat.com>
The storage path we use to collect the sandbox files is defined in the
virtcontainers/persist/fs package.
We create the runtime socket in that storage path, by hardcoding the
full path in the SocketAddress() function in the runtime package.
This commit splits the hardcoded path by the socket address path so that
the runtime package will be able to provide the storage path to all the
components that may need it.
Signed-off-by: Francesco Giudici <fgiudici@redhat.com>
In order to retrieve the list of sandboxes, we poll the container engine
every 15 seconds via the CRI. Once we have the list we have to inspect
each pod to find out the kata ones.
This commit extend the sandbox cache to keep track of all the pods,
marking the kata ones, so that during the next polling only the new
sandboxes should be inspected to figure out which ones are using the
kata runtime.
Fixes: #2563
Signed-off-by: Francesco Giudici <fgiudici@redhat.com>
this is an unexpected event (likely a change in how containerd/cri-o
record the lower level runtime in the pod) and should be more visible:
raise the log level to "warning".
Signed-off-by: Francesco Giudici <fgiudici@redhat.com>
Change logger in Trace call in newContainer from sandbox.Logger() to
nil. Passing nil will cause an error to be logged by kataTraceLogger
instead of the sandbox logger, which will avoid having the log message
report it as part of the sandbox subsystem when it is part of the
container subsystem.
The kataTraceLogger will not log it as related to the container
subsystem, but since the container logger has not been created at this
point, and we already use the kataTraceLogger in other instances where a
subsystem's logger has not been created yet, this PR makes the call
consistent with other code.
Fixes#2665
Signed-off-by: Chelsea Mafrica <chelsea.e.mafrica@intel.com>
Call StopTracing with s.rootCtx, which is the root context for tracing,
instead of s.ctx, which is parent to a subset of trace spans.
Fixes#2661
Signed-off-by: Chelsea Mafrica <chelsea.e.mafrica@intel.com>
A random generated user/group is used to start QEMU VMM process.
The /dev/kvm group owner is also added to the QEMU process to grant it access.
Fixes#2444
Signed-off-by: Feng Wang <feng.wang@databricks.com>
Due to #2332 being merged after running tests for #2604, and the latter
being merged now, a test for the now removed `storeContainer` was added.
Remove it.
Fixes: #2652
Signed-off-by: Jakob Naucke <jakob.naucke@ibm.com>
And use a released version instead of the master branch so that it no
longer gets invalidated.
Depends-on: github.com/kata-containers/kata-containers#2645
Signed-off-by: Peng Tao <bergwolf@hyper.sh>
The only remaining callers of ensure_destination_exists() are in its own
unit tests. So, just remove it.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
mount_storage() first makes sure the mount point for the storage volume
exists. It uses fs::create_dir_all() in the case of 9p or virtiofs volumes
otherwise ensure_destination_exists(). But.. ensure_destination_exists()
boils down to an fs::create_dir_all() in most cases anyway. The only case
it doesn't is for a bind fstype, where it creates a file instead of a
directory. But, that's not correct anyway because we need to create either
a file or a directory depending on the source of the bind mount, which
ensure_destination_exists() doesn't know.
The 9p/virtiofs paths also check if the mountpoint exists before calling
fs::create_dir_all(), which is unnecessary (fs::create_dir_all already
handles that case).
mount_storage() does have the information to know what we need to create,
so have it explicitly call ensure_destination_file_exists() for the bind
mount to a non-directory case, and fs::create_dir_all() in all other cases.
fixes#2390
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
