cwielenb/CNCF-Dataset huggingface dataset:
Project: Firecracker (Runtime / Container Runtime)
File: cpuid-normalization.md

On x86_64, Firecracker makes certain modifications to the guest's CPUID regardless of whether a CPU template is used. This is referred to as `CPUID normalization`. If a CPU template is used the normalization is performed after the CPU template is applied. That means that if the CPU template configures CPUID bits used in the normalization process, they will be

See also: | Description | Leaf | Subleaf | Register | Bits | | | :--: | :--: | :--: | :: | | Pass through vendor ID from host | 0x0 | - | EBX, ECX, EDX | all | | Set CLFLUSH line size | 0x1 | - | EBX | 15:8 | | Set maximum number of addressable IDs for logical processors in the physical package | 0x1 | - | EBX | 23:16 | | Set initial APIC ID | 0x1 | - | EBX | 31:24 | | Disable PDCM (Perfmon and Debug Capability) | 0x1 | - | ECX | 15 | | Enable TSC_DEADLINE | 0x1 | - | ECX | 24 | | Enable HYPERVISOR | 0x1 | - | ECX | 31 | | Set HTT value if the microVM's CPU count is greater than 1 | 0x1 | - | EDX | 28 | | Insert leaf 0xb, subleaf 0x1 filled with `0` if it is not already present | 0xb | 0x1 | all | all | | Update extended topology enumeration | 0xb | all | EAX | 4:0 | | Update extended topology enumeration | 0xb | all | EBX | 15:0 | | Update extended topology enumeration | 0xb | all | ECX | 15:8 | | Pass through L1 cache and TLB information from host | 0x80000005 | - | all | all | | Pass through L2 cache and TLB and L3 cache information from host | 0x80000006 | - | all | all | | Description | Leaf | Subleaf | Register | Bits | | -- | :--: | :--: | :-: | :: | | Update deterministic cache parameters | 0x4 | all | EAX | 31:14 | | Disable Intel Turbo Boost technology | 0x6 | - | EAX | 1 | | Disable frequency selection | 0x6 | - | ECX | 3 | | Set FDPEXCPTNONLY bit | 0x7 | 0x0 | EBX | 6 | | Set "Deprecates FPU CS and FPU DS values" bit | 0x7 | 0x0 | EBX | 13 | | Disable performance monitoring | 0xa | - | EAX, EBX, ECX, EDX | all | | Update brand string to use a default format and real frequency | 0x80000002, 0x80000003, 0x80000004 | - | EAX, EBX, ECX, EDX | all | | Description | Leaf | Subleaf | Register | Bits | | - | :--: | :--: | :-: | :: | | Set IA32ARCHCAPABILITIES MSR as not present | 0x7 | - | EDX | 29 | | Update largest extended function entry to 0x8000001f | 0x80000000 | - | EAX | 31:0 | | Set topology extension bit | 0x80000001 | - | ECX | 22 | | Update brand string with a default AMD value | 0x80000002, 0x80000003, 0x80000004 | - | EAX, EBX, ECX, EDX | all | | Update number of physical threads | 0x80000008 | - | ECX | 7:0 | | Update APIC ID size | 0x80000008 | - | ECX | 15:12 | | Update cache topology information | 0x8000001d | all | all | all | | Update extended APIC ID | 0x8000001e | - | EAX, EBX, ECX | all |
Project: Rook (Runtime / Cloud Native Storage)
File: bug_report.md

name: Bug report about: Create a report to help us improve labels: bug <!-- Are you in the right place? For issues or feature requests, please create an issue in this repository. For general technical and non-technical questions, we are happy to help you on our . Did you already search the existing open issues for anything similar? --> Is this a bug report or feature request? Bug Report Deviation from expected behavior: Expected behavior: How to reproduce it (minimal and precise): <!-- Please let us know any circumstances for reproduction of your bug. --> File(s) to submit: Cluster CR (custom resource), typically called `cluster.yaml`, if necessary Logs to submit: Operator's logs, if necessary Crashing pod(s) logs, if necessary To get logs, use `kubectl -n <namespace> logs <pod name>` When pasting logs, always surround them with backticks or use the `insert code` button from the Github UI. Read . Cluster Status to submit: Output of kubectl commands, if necessary To get the health of the cluster, use `kubectl rook-ceph health` To get the status of the cluster, use `kubectl rook-ceph ceph status` For more details, see the Environment: OS (e.g. from /etc/os-release): Kernel (e.g. `uname -a`): Cloud provider or hardware configuration: Rook version (use `rook version` inside of a Rook Pod): Storage backend version (e.g. for ceph do `ceph -v`): Kubernetes version (use `kubectl version`): Kubernetes cluster type (e.g. Tectonic, GKE, OpenShift): Storage backend status (e.g. for Ceph use `ceph health` in the ):
Project: lxd (Runtime / Container Runtime)
File: network_configure.md

(network-configure)= To configure an existing network, use either the and commands (to configure single settings) or the `incus network edit` command (to edit the full configuration). To configure settings for specific cluster members, add the `--target` flag. For example, the following command configures a DNS server for a physical network: ```bash incus network set UPLINK dns.nameservers=8.8.8.8 ``` The available configuration options differ depending on the network type. See {ref}`network-types` for links to the configuration options for each network type. There are separate commands to configure advanced networking features. See the following documentation: {doc}`/howto/network_acls` {doc}`/howto/network_forwards` {doc}`/howto/network_integrations` {doc}`/howto/networkloadbalancers` {doc}`/howto/network_zones` {doc}`/howto/networkovnpeers` (OVN only)
Project: Kata Containers (Runtime / Container Runtime)
File: using-Intel-SGX-and-kata.md

Intel Software Guard Extensions (SGX) is a set of instructions that increases the security of applications code and data, giving them more protections from disclosure or modification. This document guides you to run containers with SGX enclaves with Kata Containers in Kubernetes. Intel SGX capable bare metal nodes Host kernel Linux 5.13 or later with SGX and SGX KVM enabled: ```sh $ grep SGX /boot/config-`uname -r` CONFIGX86SGX=y CONFIGX86SGX_KVM=y ``` Kubernetes cluster configured with: based Kata Containers installation and associated components including and dependencies Note: Kata Containers supports creating VM sandboxes with Intel SGX enabled using and VMMs only. For `containerd` check in `/etc/containerd/config.toml` that the list of `pod_annotations` passed to the `sandbox` are: `["io.katacontainers.*", "sgx.intel.com/epc"]`. With the following sample job deployed using `kubectl apply -f`: Note: Change the `runtimeClassName` option accordingly, only `kata-clh` and `kata-qemu` support Intel SGX. ```yaml apiVersion: batch/v1 kind: Job metadata: name: oesgx-demo-job labels: jobgroup: oesgx-demo spec: template: metadata: labels: jobgroup: oesgx-demo spec: runtimeClassName: kata-clh initContainers: name: init-sgx image: busybox command: ['sh', '-c', 'mkdir /dev/sgx; ln -s /dev/sgxenclave /dev/sgx/enclave; ln -s /dev/sgxprovision /dev/sgx/provision'] volumeMounts: mountPath: /dev name: dev-mount restartPolicy: Never containers: name: eosgx-demo-job-1 image: oeciteam/oe-helloworld:latest imagePullPolicy: IfNotPresent volumeMounts: mountPath: /dev name: dev-mount securityContext: readOnlyRootFilesystem: true capabilities: add: ["IPC_LOCK"] resources: limits: sgx.intel.com/epc: "512Ki" volumes: name: dev-mount hostPath: path: /dev ``` You'll see the enclave output: ```sh $ kubectl logs oesgx-demo-job-wh42g Hello world from the enclave Enclave called into host to print: Hello World! ``` The Kata VM's SGX Encrypted Page Cache (EPC) memory size is based on the sum of `sgx.intel.com/epc` resource requests within the pod. `init-sgx` can be removed from the YAML configuration file if the Kata rootfs is modified with the necessary udev rules. See the . Intel SGX DCAP attestation is known to work from Kata sandboxes but it comes with one limitation: If the Intel SGX `aesm` daemon runs on the bare metal node and DCAP `out-of-proc` attestation is used, containers within the Kata sandbox cannot get the access to the host's `/var/run/aesmd/aesm.sock` because socket passthrough is not supported. An alternative is to deploy the `aesm` daemon as a side-car container. Projects like are also known to work. For GSC specifically, the Kata guest kernel needs to have the `CONFIG_NUMA=y` enabled and at least one CPU online when running the GSC container. The Kata Containers guest kernel currently has `CONFIG_NUMA=y` enabled by default.
Project: containerd (Runtime / Container Runtime)
File: README-v0.1.0.md

This version of NRI is supported through the included v010-adapter plugin. This project is a WIP for a new, CNI like, interface for managing resources on a node for Pods and Containers. The basic interface, concepts and plugin design of the Container Network Interface (CNI) is an elegant way to handle multiple implementations of the network stack for containers. This concept can be used for additional interfaces to customize a container's runtime environment. This proposal covers a new interface for resource management on a node with a structured API and plugin design for containers. The big selling point for CNI is that it has a structured interface for modifying the network namespace for a container. This is different from generic hooks as they lack a type safe API injected into the lifecycle of a container. The lifecycle point that CNI and NRI plugins will be injected into is the point between `Create` and `Start` of the container's init process. `Create->NRI->Start` Configuration is split into two parts. One is the payload that is specific to a plugin invocation while the second is the host level configuration and options that specify what plugins to run and provide additional configuration to a plugin. Plugin binary paths can be configured via the consumer but will default to `/opt/nri/bin`. Binaries are named with their type as the binary name, same as the CNI plugin naming scheme. The config's default location will be `/etc/nri/resource.d/*.conf`. ```json { "version": "0.1", "plugins": [ { "type": "konfine", "conf": { "systemReserved": [0, 1] } }, { "type": "clearcfs" } ] } ``` Input to a plugin is provided via `STDIN` as a `json` payload. ```json { "version": "0.1", "state": "create", "id": "redis", "pid": 1234, "spec": { "resources": {}, "cgroupsPath": "default/redis", "namespaces": { "pid": "/proc/44/ns/pid", "mount": "/proc/44/ns/mnt", "net": "/proc/44/ns/net" }, "annotations": { "qos.class": "ls" } } } ``` ```json { "version": "0.1", "state": "create", "id": "redis", "pid": 1234, "cgroupsPath": "qos-ls/default/redis" } ``` Invoke - provides invocations into different lifecycle changes of a container states: `setup|pause|resume|update|delete` A Go based API and client package will be created for both producers of plugins and consumers, commonly being the container runtime (containerd). nri is a containerd sub-project, licensed under the . As a containerd sub-project, you will find the: , , and information in our repository.
Project: CubeFS (Runtime / Cloud Native Storage)
File: man_docs.md

Generating man pages from a cobra command is incredibly easy. An example is as follows: ```go package main import ( "log" "github.com/spf13/cobra" "github.com/spf13/cobra/doc" ) func main() { cmd := &cobra.Command{ Use: "test", Short: "my test program", } header := &doc.GenManHeader{ Title: "MINE", Section: "3", } err := doc.GenManTree(cmd, header, "/tmp") if err != nil { log.Fatal(err) } } ``` That will get you a man page `/tmp/test.3`
Project: containerd (Runtime / Container Runtime)
File: stream_processors.md

Processors are a binary API that works off of content streams. The incoming content stream will be provided to the binary via `STDIN` and the stream processor is expected to output the processed stream on `STDOUT`. If errors are encountered, errors MUST be returned via `STDERR` with a non-zero exit status. Additional information can be provided to stream processors via a payload. Payloads are marshaled as `protobuf.Any` types and can wrap any type of serialized data structure. On Unix systems, the payload, if available, is provided on `fd 3` for the process. On Windows systems, the payload, if available, is provided via a named pipe with the pipe's path set as the value of the environment variable `STREAMPROCESSORPIPE`. To configure stream processors for containerd, entries in the config file need to be made. The `stream_processors` field is a map so that users can chain together multiple processors to mutate content streams. Processor Fields: Key - ID of the processor, used for passing a specific payload to the processor. `accepts` - Accepted media-types for the processor that it can handle. `returns` - The media-type that the processor returns. `path` - Path to the processor binary. `args` - Arguments passed to the processor binary. ```toml version = 2 [stream_processors] [stream_processors."io.containerd.processor.v1.pigz"] accepts = ["application/vnd.docker.image.rootfs.diff.tar.gzip"] returns = "application/vnd.oci.image.layer.v1.tar" path = "unpigz" args = ["-d", "-c"] ```
Project: rkt (Runtime / Container Runtime)
File: test-on-several-distro.md

rkt aims to be supported on several Linux distributions. In order to notice distro-specific issues, Continuous Integration should ideally run the tests on several Linux distributions. rkt tests can be intrusive and require full root privileges. Each test should be run on a fresh VM. VMs should not be reused for next tests. Tests run on Jenkins and . The script `tests/aws.sh` can generate a AMI of the specified Linux distribution with all the dependencies rkt needs. First, install and configure it with your AWS credentials. Then, create a key pair and a security group for rkt tests: ``` $ tests/aws.sh setup ``` Then generate an AMI of the specified Linux distribution: ``` $ tests/aws.sh fedora-22 $ tests/aws.sh fedora-23 $ tests/aws.sh fedora-24 $ tests/aws.sh fedora-rawhide $ tests/aws.sh ubuntu-1604 $ tests/aws.sh ubuntu-1510 $ tests/aws.sh debian $ tests/aws.sh centos ``` The generated AMIs can then be used to configure Jenkins. If new packages are needed they can be added to the corresponding cloudinit files in `test/cloudinit`.
Project: gVisor (Runtime / Container Runtime)
File: docker-compose.md

This page shows you how to deploy a sample site using . to install runsc with Docker. This document assumes that Docker and Docker Compose are installed and the runtime name chosen for gVisor is `runsc`. We'll start by creating the `docker-compose.yaml` file to specify our services. We will specify two services, a `wordpress` service for the Wordpress Apache server, and a `db` service for MySQL. We will configure Wordpress to connect to MySQL via the `db` service host name. Note: This example uses gVisor to sandbox the frontend web server, but not the MySQL database backend. In a production setup, due to imposed by gVisor, it is not recommended to run your database in a sandbox. The frontend is the critical component with the largest outside attack surface, where gVisor's security/performance trade-off makes the most sense. See the [Production guide] for more details. Note: Docker Compose uses it's own network by default and allows services to communicate using their service name. Docker Compose does this by setting up a DNS server at IP address 127.0.0.11 and configuring containers to use it via . This IP is not addressable inside a gVisor sandbox so it's important that we set the DNS IP address to the alternative `8.8.8.8` and use a network that allows routing to it. See for more details. Note: The `runtime` field was removed from services in the 3.x version of the API in versions of docker-compose < 1.27.0. You will need to write your `docker-compose.yaml` file using the 2.x format or use docker-compose >= 1.27.0. See this for more details. ```yaml version: '2.3' services: db: image: mysql:5.7 volumes: db_data:/var/lib/mysql restart: always environment: MYSQLROOTPASSWORD: somewordpress MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: wordpress network_mode: "bridge" wordpress: depends_on: db links: db image: wordpress:latest ports: "8080:80" restart: always environment: WORDPRESSDBHOST: db:3306 WORDPRESSDBUSER: wordpress WORDPRESSDBPASSWORD: wordpress WORDPRESSDBNAME: wordpress dns: 8.8.8.8 network_mode: "bridge" runtime: "runsc" volumes: db_data: {} ``` Once you have a `docker-compose.yaml` in the current directory you can start the containers: ```bash docker-compose up ``` Once the containers have started you can access wordpress at http://localhost:8080. Congrats! You now how a working wordpress site up and running using Docker Compose. Learn how to deploy . Before deploying this to production, see the [Production guide] for how to take full advantage of gVisor.
Project: Gluster (Runtime / Cloud Native Storage)
File: versioning.md

Versioning ========== The number of the current interface exported by the library. A current value of '1', means that you are calling the interface exported by this library interface 1. The implementation number of the most recent interface exported by this library. In this case, a revision value of `0` means that this is the first implementation of the interface. If the next release of this library exports the same interface, but has a different implementation (perhaps some bugs have been fixed), the revision number will be higher, but current number will be the same. In that case, when given a choice, the library with the highest revision will always be used by the runtime loader. The number of previous additional interfaces supported by this library. If age were '2', then this library can be linked into executables which were built with a release of this library that exported the current interface number, current, or any of the previous two interfaces. By definition age must be less than or equal to current. At the outset, only the first ever interface is implemented, so age can only be `0'. For every release of the library `-version-info` argument needs to be set correctly depending on any interface changes you have made. This is quite straightforward when you understand what the three numbers mean: If you have changed any of the sources for this library, the revision number must be incremented. This is a new revision of the current interface. If the interface has changed, then current must be incremented, and revision reset to '0'. This is the first revision of a new interface. If the new interface is a superset of the previous interface (that is, if the previous interface has not been broken by the changes in this new release), then age must be incremented. This release is backwards compatible with the previous release.
Project: lxd (Runtime / Container Runtime)
File: cluster_member_config.md

(cluster-member-config)= Each cluster member has its own key/value configuration with the following supported namespaces: `user` (free form key/value for user metadata) `scheduler` (options related to how the member is automatically targeted by the cluster) The following keys are currently supported: % Include content from ```{include} ../config_options.txt :start-after: <!-- config group cluster-cluster start --> :end-before: <!-- config group cluster-cluster end --> ```
Project: Kata Containers (Runtime / Container Runtime)
File: VmResizeZone.md

Name | Type | Description | Notes | - | - | - Id | Pointer to string | | [optional] DesiredRam | Pointer to int64 | desired memory zone size in bytes | [optional] `func NewVmResizeZone() *VmResizeZone` NewVmResizeZone instantiates a new VmResizeZone object This constructor will assign default values to properties that have it defined, and makes sure properties required by API are set, but the set of arguments will change when the set of required properties is changed `func NewVmResizeZoneWithDefaults() *VmResizeZone` NewVmResizeZoneWithDefaults instantiates a new VmResizeZone object This constructor will only assign default values to properties that have it defined, but it doesn't guarantee that properties required by API are set `func (o *VmResizeZone) GetId() string` GetId returns the Id field if non-nil, zero value otherwise. `func (o VmResizeZone) GetIdOk() (string, bool)` GetIdOk returns a tuple with the Id field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *VmResizeZone) SetId(v string)` SetId sets Id field to given value. `func (o *VmResizeZone) HasId() bool` HasId returns a boolean if a field has been set. `func (o *VmResizeZone) GetDesiredRam() int64` GetDesiredRam returns the DesiredRam field if non-nil, zero value otherwise. `func (o VmResizeZone) GetDesiredRamOk() (int64, bool)` GetDesiredRamOk returns a tuple with the DesiredRam field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *VmResizeZone) SetDesiredRam(v int64)` SetDesiredRam sets DesiredRam field to given value. `func (o *VmResizeZone) HasDesiredRam() bool` HasDesiredRam returns a boolean if a field has been set.
Project: CubeFS (Runtime / Cloud Native Storage)
File: datapartition.md

Get information of the specified data partition. ```bash cfs-cli datapartition info [Partition ID] ``` Decommission the specified data partition on the target node and automatically transfer it to other available nodes. ```bash cfs-cli datapartition decommission [Address] [Partition ID] ``` Add a new data partition on the target node. ```bash cfs-cli datapartition add-replica [Address] [Partition ID] ``` Delete the data partition on the target node. ```bash cfs-cli datapartition del-replica [Address] [Partition ID] ``` Fault diagnosis, find data partitions that are mostly unavailable and missing. ```bash cfs-cli datapartition check ``` ```bash cfs-cli datapartition set-discard [DATA PARTITION ID] [DISCARD] ```