badba8058c
Today I learned, I must say.
When running a basic script, such as:
```bash
#/usr/bin/env bash
set -o errexit
set -o pipefail
set -o errtrace
cat junk && echo "hello"
echo "didn't fail"
cat junk
echo "hello"
echo "didn't fail"
```
One will get as a result:
```bash
cat: junk: No such file or directory
didn't fail
cat: junk: No such file or directory
```
Meaning that although there was an error on `cat junk && echo "hello"`,
and the `echo "hello"` part was not executed, an error was not reported
for that failure.
On the second part, though, it just breaks and returns an error as
expected.
Small scripts aside, this is exactly what was happening with the
attestation-agent, where a `make ... && make install ...` was being
called, make was failing but not actually breaking the script.
Let's change the logic and avoid such situations in the future, as it
caused our CI to be broken for quite some time without a simple way to
detect that line in the huge amount of logs left behind.
Here goes a reference to the documentation:
```
-e Exit immediately if a pipeline (which may consist
of a single simple command), a list, or a compound
command (see SHELL GRAMMAR above), exits with a
non-zero status. The shell does not exit if the
command that fails is part of the command list
immediately following a while or until keyword,
part of the test following the if or elif reserved
words, part of any command executed in a && or ||
list except the command following the final && or
||, any command in a pipeline but the last, or if
the command's return value is being inverted with
!. If a compound command other than a subshell
returns a non-zero status because a command failed
while -e was being ignored, the shell does not
exit. A trap on ERR, if set, is executed before
the shell exits. This option applies to the shell
environment and each subshell environment
separately (see COMMAND EXECUTION ENVIRONMENT
above), and may cause subshells to exit before
executing all the commands in the subshell.
If a compound command or shell function executes
in a context where -e is being ignored, none of
the commands executed within the compound command
or function body will be affected by the -e
setting, even if -e is set and a command returns a
failure status. If a compound command or shell
function sets -e while executing in a context
where -e is ignored, that setting will not have
any effect until the compound command or the
command containing the function call completes.
```
This comes from https://www.man7.org/linux/man-pages/man1/bash.1.html
Fixes: #7793
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
|
||
|---|---|---|
| .github | ||
| ci | ||
| docs | ||
| src | ||
| tests | ||
| tools | ||
| utils | ||
| .gitignore | ||
| CODE_OF_CONDUCT.md | ||
| CODEOWNERS | ||
| CONTRIBUTING.md | ||
| deny.toml | ||
| Glossary.md | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| utils.mk | ||
| VERSION | ||
| versions.yaml | ||
Kata Containers
Welcome to Kata Containers!
This repository is the home of the Kata Containers code for the 2.0 and newer releases.
If you want to learn about Kata Containers, visit the main Kata Containers website.
Introduction
Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs.
License
The code is licensed under the Apache 2.0 license. See the license file for further details.
Platform support
Kata Containers currently runs on 64-bit systems supporting the following technologies:
| Architecture | Virtualization technology |
|---|---|
x86_64, amd64 |
Intel VT-x, AMD SVM |
aarch64 ("arm64") |
ARM Hyp |
ppc64le |
IBM Power |
s390x |
IBM Z & LinuxONE SIE |
Hardware requirements
The Kata Containers runtime provides a command to determine if your host system is capable of running and creating a Kata Container:
$ kata-runtime check
Notes:
This command runs a number of checks including connecting to the network to determine if a newer release of Kata Containers is available on GitHub. If you do not wish this to check to run, add the
--no-network-checksoption.By default, only a brief success / failure message is printed. If more details are needed, the
--verboseflag can be used to display the list of all the checks performed.If the command is run as the
rootuser additional checks are run (including checking if another incompatible hypervisor is running). When running asroot, network checks are automatically disabled.
Getting started
See the installation documentation.
Documentation
See the official documentation including:
Configuration
Kata Containers uses a single configuration file which contains a number of sections for various parts of the Kata Containers system including the runtime, the agent and the hypervisor.
Hypervisors
See the hypervisors document and the Hypervisor specific configuration details.
Community
To learn more about the project, its community and governance, see the community repository. This is the first place to go if you wish to contribute to the project.
Getting help
See the community section for ways to contact us.
Raising issues
Please raise an issue in this repository.
Note: If you are reporting a security issue, please follow the vulnerability reporting process
Developers
See the developer guide.
Components
Main components
The table below lists the core parts of the project:
| Component | Type | Description |
|---|---|---|
| runtime | core | Main component run by a container manager and providing a containerd shimv2 runtime implementation. |
| runtime-rs | core | The Rust version runtime. |
| agent | core | Management process running inside the virtual machine / POD that sets up the container environment. |
dragonball |
core | An optional built-in VMM brings out-of-the-box Kata Containers experience with optimizations on container workloads |
| documentation | documentation | Documentation common to all components (such as design and install documentation). |
| tests | tests | Excludes unit tests which live with the main code. |
Additional components
The table below lists the remaining parts of the project:
| Component | Type | Description |
|---|---|---|
| packaging | infrastructure | Scripts and metadata for producing packaged binaries (components, hypervisors, kernel and rootfs). |
| kernel | kernel | Linux kernel used by the hypervisor to boot the guest image. Patches are stored here. |
| osbuilder | infrastructure | Tool to create "mini O/S" rootfs and initrd images and kernel for the hypervisor. |
| kata-debug | infrastructure | Utility tool to gather Kata Containers debug information from Kubernetes clusters. |
agent-ctl |
utility | Tool that provides low-level access for testing the agent. |
kata-ctl |
utility | Tool that provides advanced commands and debug facilities. |
log-parser-rs |
utility | Tool that aid in analyzing logs from the kata runtime. |
trace-forwarder |
utility | Agent tracing helper. |
runk |
utility | Standard OCI container runtime based on the agent. |
ci |
CI | Continuous Integration configuration files and scripts. |
katacontainers.io |
Source for the katacontainers.io site. |
Packaging and releases
Kata Containers is now available natively for most distributions.
Metrics tests
See the metrics documentation.
Glossary of Terms
See the glossary of terms related to Kata Containers.