The commit message of a revert commit usually generated by
`git revert`, we should consider this as legal.
Consider the commit as the merge commit if the subject
starts with 'Reject "'
Follow the pr kata-containers/tests/#3938, the suttle diffrence
is we skip all commit checks for revert commit including fixes checking
and subsystem checking. Because the commit was reverted must have passed
the check so the revert-commit should have the Fixes and Subsystem.
Fixes: #3568Fixes: kata-containers/tests#3934
Signed-off-by: Tim Zhang <tim@hyper.sh>
Move the netns specific bits into a Linux specific file.
Fixes: #3607
Signed-off-by: Samuel Ortiz <s.ortiz@apple.com>
Signed-off-by: Eric Ernst <eric_ernst@apple.com>
When building a non-stable release, the tag is **always** "latest¨,
instead of the version. The same magic done for setting the correct
tags up should be done for replacing the tag on the kata-deploy and
kata-cleanup yaml files, as part of the kata-deploy test.
Fixes: #3559
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
There are software and hardware architectures which do not support
dynamically adjusting the CPU and memory resources associated with a
sandbox. For these, today, they rely on "default CPU" and "default
memory" configuration options for the runtime, either set by annotation
or by the configuration toml on disk.
In the case of a single container (launched by ctr, or something like
"docker run"), we could allow for sizing the VM correctly, since all of
the information is already available to us at creation time.
In the sandbox / pod container case, it is possible for the upper layer
container runtime (ie, containerd or crio) could send a specific
annotation indicating the total workload resource requirements
associated with the sandbox creation request.
In the case of sizing information not being provided, we will follow
same behavior as today: start the VM with (just) the default CPU/memory.
If this information is provided, we'll track this as Workload specific
resources, and track default sizing information as Base resources. We
will update the hypervisor configuration to utilize Base+Workload
resources, thus starting the VM with the appropriate amount of CPU and
memory.
In this scenario (we start the VM with the "right" amount of
CPU/Memory), we do not want to update the VM resources when containers
are added, or adjusted in size.
This functionality is introduced behind a configuration flag,
`static_sandbox_resource_mgmt`. This is defaulted to false for all
configurations except Firecracker, which is set to true.
This'll greatly improve UX for folks who are utilizing
Kata with a VMM or hardware architecture that doesn't support hotplug.
Note, users will still be unable to do in place vertical pod autoscaling
or other dynamic container/pod sizing with this enabled.
Fixes: #3264
Signed-off-by: Eric Ernst <eric_ernst@apple.com>
Describe the static_sandbox_resource_mgmt flag, and how this applies to
configurations that do not utilize hotplug.
Signed-off-by: Eric Ernst <eric_ernst@apple.com>
Add the POD metadata we get from the container manager to the metrics by
adding more labels.
Fixes: #3551
Signed-off-by: Francesco Giudici <fgiudici@redhat.com>
Kata-monitor detects started and terminated kata pods by monitoring the
vc/sbs fs (this makes sense since we will have to access that path to
access the sockets there to get the metrics from the shim).
While kata-monitor updates its sandbox cache based on the sbs fs events,
it will schedule also a sync with the container manager via the CRI in
order to sync the list of sandboxes there.
The container manager will be the ultimate source of truth, so we will
stick with the response from the container manager, removing the
sandboxes not reported from the container manager.
May happen anyway that when we check the container manager, the new kata
pod is not reported yet, and we will remove it from the kata-monitor pod
cache. If we don't get any new kata pod added or removed, we will not
check with the container manager again, missing reporting metrics about
that kata pod.
Let's stick with the sbs fs as the source of truth: we will update the
cache just following what happens on the sbs fs.
At this point we may have also decided to drop the container manager
connection... better instead to keep it in order to get the kube pod
metadata from it, i.e., the kube UID, Name and Namespace associated with
the sandbox.
Every time we get a new sandbox from the sbs fs we will try to retrieve the
pod metadata associated with it.
Right now we just attach the container manager sandbox id as a label to
the exposed metrics, making hard to link the metrics to the running pod
in the kubernetes cluster.
With kubernetes pod metadata we will be able to add them as labels to map
explicitly the metrics to the kubernetes workloads.
Fixes: #3550
Signed-off-by: Francesco Giudici <fgiudici@redhat.com>
We currently WARN about unexpected fs events, which includes CHMOD
operations (which should be actually expected...).
Just ignore all the fs events we don't care about without any warn.
We dump all the events with debug log in any case.
Signed-off-by: Francesco Giudici <fgiudici@redhat.com>
Improve debug log formatting of the sandbox cache update process.
Move raw and tracing logs from the DEBUG to the TRACE log level.
Signed-off-by: Francesco Giudici <fgiudici@redhat.com>
Updated the doc to clarify certain networking details and
external links to some of the networking terms used.
Fixes#3308
Signed-off-by: Archana Shinde <archana.m.shinde@intel.com>
The OCI container spec specifies a limit of -1 signifies
unlimited memory. Update the sandbox memory calculator
to reflect this part of the spec.
Fixes: #3512
Signed-off-by: Braden Rayhorn <bradenrayhorn@fastmail.com>
This PR removes the docker run and sysctl limitation reference
for kata 2.0 as well as docker daemon limitation as currently
for kata we are not supporting docker and this reference belonged
to kata 1.0
Fixes#3545
Signed-off-by: Gabriela Cervantes <gabriela.cervantes.tellez@intel.com>
1. The hook.args[0] is the hook binary name which shouldn't be included
in the Command.args.
2. Add new unit tests
Fixes: #2610
Signed-off-by: Binbin Zhang <binbin36520@gmail.com>
no explicit PCI test, just switch path depending on architecture
(CCW for s390x, PCI for others). Also fixes an unknown variable error.
Signed-off-by: Jakob Naucke <jakob.naucke@ibm.com>
When no options are passed to -ldflags, it passes
incorrect values(in this case, $BUILDFLAGS) to it.
Fix passing empty values by passing $KATA_LDFLAGS
in quotes.
Fixes: #3521
Signed-off-by: Amulya Meka <amulmek1@in.ibm.com>
Highlights from the Cloud Hypervisor release v21.0: 1) Efficient Local
Live Migration (for Live Upgrade); 2) Recommended Kernel is Now 5.15; 3)
Bug fixes on OpenAPI yaml spec file, avoid deadlock for live-migration,
etc.
Details can be found: https://github.com/cloud-hypervisor/cloud-hypervisor/releases/tag/v21.0Fixes: #3519
Signed-off-by: Bo Chen <chen.bo@intel.com>
Now that kata-pkgsync has been removed, this PR removes the reference
in the documentation.
Fixes#3513
Signed-off-by: Gabriela Cervantes <gabriela.cervantes.tellez@intel.com>
Remove the libseccomp package from Dockerfile of `alpine` and `clearlinux`
because the libseccomp library is installed by the `ci/install_libseccomp.sh`
script when building the kata-agent.
Fixes: #3508
Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>
Whilst we work to update the
[copy of the glossary currently hosted in the wiki](https://github.com/kata-containers/kata-containers/wiki/Glossary),
update the in-tree glossary doc to refer to that wiki version.
Fixes: #3505.
Signed-off-by: James O. D. Hunt <james.o.hunt@intel.com>
Although I've done tests on my own fork using `head_ref` and those
worked, it seems those only worked as the PR was coming from exactly the
same repository as the target one.
Let's switch to base_ref, instead, which we for sure have as part of our
repo.
The downside of this is that we run the test with the last merged PR,
rather than with the "to-be-approved" PR, but that's a limitation we've
always had.
Fixes: #3482
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
