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

The specifications below quantify Firecracker's promise to enable minimal-overhead execution of container and serverless workloads. These specifications are enforced by integration tests (that run for each PR and main branch merge). On an (with hyperthreading disabled) and an and given host system resources are available (e.g., there are enough free CPU cycles, there is enough RAM, etc.), customers can rely on the following: Stability: The Firecracker virtual machine manager starts (up to API socket availability) within `8 CPU ms`[^1] and never crashes/halts/terminates for internal reasons once started. Note: The wall-clock time has a large standard deviation, spanning `6 ms to 60 ms`, with typical durations around `12 ms`. Failure Information: When failures occur due to external circumstances, they are logged[^2] by the Firecracker process. API Stability: The API socket is always available and the API conforms to the in-tree . API failures are logged in the Firecracker log. Overhead: For a Firecracker virtual machine manager running a microVM with `1 CPUs and 128 MiB of RAM`, and a guest OS with the Firecracker-tuned kernel: Firecracker's virtual machine manager threads have a memory overhead `<= 5 MiB`. The memory overhead is dependent on the workload (e.g. a workload with multiple connections might generate a memory overhead > 5MiB) and on the VMM configuration (the overhead does not include the memory used by the data store. The overhead is tested as part of the Firecracker CI using a . It takes `<= 125 ms` to go from receiving the Firecracker InstanceStart API call to the start of the Linux guest user-space `/sbin/init` process. The boot time is measured using a VM with the serial console disabled and a minimal kernel and root file system. For more details check the integration tests. The compute-only guest CPU performance is `> 95%` of the equivalent bare-metal performance. `[integration test pending]` IO Performance: With a host CPU core dedicated to the Firecracker device emulation thread, the guest achieves up to `14.5 Gbps` network throughput by using `<= 80%` of the host CPU core for emulation. `[integration test pending]` the guest achieves up to `25 Gbps` network throughput by using `100%` of the host CPU core for emulation. `[integration test pending]` the virtualization layer adds on average `0.06ms` of latency. `[integration test pending]` the guest achieves up to `1 GiB/s` storage throughput by using `<= 70%` of the host CPU core for emulation. `[integration test pending]` Telemetry: Firecracker emits logs and metrics to the named pipes passed to the logging API. Any logs and metrics emitted while their respective pipes are full will be lost. Any such events will be signaled through the `lost-logs` and `lost-metrics` counters. getting consistent measurements for some performance metrics. process start-up and the logging system initialization in the `firecracker` process.
Project: Inclavare Containers (Runtime / Container Runtime)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: Rook (Runtime / Cloud Native Storage)
File: ceph-object-zonegroup-crd.md

title: CephObjectZoneGroup CRD Rook allows creation of zone groups in a configuration through a CRD. The following settings are available for Ceph object store zone groups. ```yaml apiVersion: ceph.rook.io/v1 kind: CephObjectZoneGroup metadata: name: zonegroup-a namespace: rook-ceph spec: realm: realm-a ``` `name`: The name of the object zone group to create `namespace`: The namespace of the Rook cluster where the object zone group is created. `realm`: The object realm in which the zone group will be created. This matches the name of the object realm CRD.
Project: Rook (Runtime / Cloud Native Storage)
File: ceph-block-pool-rados-namespace-crd.md

title: CephBlockPoolRados Namespace CRD This guide assumes you have created a Rook cluster as explained in the main RADOS currently uses pools both for data distribution (pools are shared into PGs, which map to OSDs) and as the granularity for security (capabilities can restrict access by pool). Overloading pools for both purposes makes it hard to do multi-tenancy because it is not a good idea to have a very large number of pools. A namespace would be a division of a pool into separate logical namespaces. For more information about BlockPool and namespace refer to the [Ceph docs](https://docs.ceph.com/en/latest/man/8/rbd/) Having multiple namespaces in a pool would allow multiple Kubernetes clusters to share one unique ceph cluster without creating a pool per kubernetes cluster and it will also allow to have tenant isolation between multiple tenants in a single Kubernetes cluster without creating multiple pools for tenants. Rook allows creation of Ceph BlockPool through the custom resource definitions (CRDs). To get you started, here is a simple example of a CR to create a CephBlockPoolRadosNamespace on the CephBlockPool "replicapool". ```yaml apiVersion: ceph.rook.io/v1 kind: CephBlockPoolRadosNamespace metadata: name: namespace-a namespace: rook-ceph # namespace:cluster spec: blockPoolName: replicapool ``` If any setting is unspecified, a suitable default will be used automatically. `name`: The name that will be used for the Ceph BlockPool rados namespace. `blockPoolName`: The metadata name of the CephBlockPool CR where the rados namespace will be created.
Project: Curve (Runtime / Cloud Native Storage)
File: CHANGELOG-2.5.md

Previous change logs can be found at Memcache support @ilixiaocui @Cyber-SiKu @fansehep @ilixiaocui @Cyber-SiKu curvefs new tools @shentupenghui @Sindweller @zyb521 @tsonglew @aspirer @Wine93 @tangwz @Tangruilin @fansehep Merge block storage and file storage compilation scripts [Merge block storage and file storage compilation scripts ](https://github.com/opencurve/curve/pull/2089) @linshiyx @linshiyx @SeanHai @tsonglew @shentupenghui aws s3 sdk revert @h0hmj @wuhongsong
Project: Weave Net (Runtime / Cloud Native Network)
File: how-works-weavedns.md

title: How Weave Finds Containers menu_order: 10 search_type: Documentation The weaveDNS service running on every host acts as the nameserver for containers on that host. It learns about hostnames for local containers from the proxy and from the `weave attach` command. If a hostname is in the `.weave.local` domain, then weaveDNS records the association of that name with the container's Weave Net IP address(es) in its in-memory database, and then broadcasts the association to other Weave Net peers in the cluster. When weaveDNS is queried for a name in the `.weave.local` domain, it looks up the hostname in its memory database and responds with the IPs of all containers for that hostname across the entire cluster. When weaveDNS is queried for a name in a domain other than `.weave.local`, it queries the host's configured nameserver, which is the standard behaviour for Docker containers. So that containers can connect to a stable and always routable IP address, weaveDNS listens on port 53 to the Docker bridge device, which is assumed to be `docker0`. Some configurations may use a different Docker bridge device. To supply a different bridge device, use the environment variable `DOCKER_BRIDGE`, e.g., ``` $ sudo DOCKER_BRIDGE=someother weave launch ``` In the event that weaveDNS is launched in this way, it's important that other calls to `weave` also specify the bridge device: ``` $ sudo DOCKER_BRIDGE=someother weave attach ... ``` See Also *
Project: gVisor (Runtime / Container Runtime)
File: filesystem.md

[TOC] gVisor accesses the filesystem through a file proxy, called the Gofer. The gofer runs as a separate process, that is isolated from the sandbox. Gofer instances communicate with their respective sentry using the LISAFS protocol. Configuring the filesystem provides performance benefits, but isn't the only step to optimizing gVisor performance. See the [Production guide] for more. To isolate the host filesystem from the sandbox, you can set a writable tmpfs overlay on top of the entire filesystem. All modifications are made to the overlay, keeping the host filesystem unmodified. Note: All created and modified files are stored in memory inside the sandbox. To use the tmpfs overlay, add the following `runtimeArgs` to your Docker configuration (`/etc/docker/daemon.json`) and restart the Docker daemon: ```json { "runtimes": { "runsc": { "path": "/usr/local/bin/runsc", "runtimeArgs": [ "--overlay2=all:memory" ] } } } ``` Any modifications to the root filesystem is destroyed with the container. So it almost always makes sense to apply an overlay on top of the root filesystem. This can drastically boost performance, as runsc will handle root filesystem changes completely in memory instead of making costly round trips to the gofer and make syscalls to modify the host. However, holding so much file data in memory for the root filesystem can bloat up container memory usage. To circumvent this, you can have root mount's upper layer (tmpfs) be backed by a host file, so all file data is stored on disk. The newer `--overlay2` flag allows you to achieve these. You can specify `--overlay2=root:self` in `runtimeArgs`. The overlay backing host file will be created in the container's root filesystem. This file will be hidden from the containerized application. Placing the host file in the container's root filesystem is important because k8s scans the container's root filesystem from the host to enforce local ephemeral storage limits. You can also place the overlay host file in another directory using `--overlay2=root:/path/dir`. The root filesystem is where the image is extracted and is not generally modified from outside the sandbox. This allows for some optimizations, like skipping checks to determine if a directory has changed since the last time it was cached, thus missing updates that may have happened. If you need to `docker cp` files inside the root filesystem, you may want to enable shared mode. Just be aware that file system access will be slower due to the extra checks that are required. Note: External mounts are always shared. To use set the root filesystem shared, add the following `runtimeArgs` to your Docker configuration (`/etc/docker/daemon.json`) and restart the Docker daemon: ```json { "runtimes": { "runsc": { "path": "/usr/local/bin/runsc", "runtimeArgs": [ "--file-access=shared" ] } } } ```
Project: Spiderpool (Runtime / Cloud Native Network)
File: BENCHMARK.md

```bash go test -bench XXX -run XXX -benchtime 30s ``` ``` goos: linux goarch: amd64 pkg: github.com/go-openapi/swag cpu: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz BenchmarkToXXXName/ToGoName-4 862623 44101 ns/op 10450 B/op 732 allocs/op BenchmarkToXXXName/ToVarName-4 853656 40728 ns/op 10468 B/op 734 allocs/op BenchmarkToXXXName/ToFileName-4 1268312 27813 ns/op 9785 B/op 617 allocs/op BenchmarkToXXXName/ToCommandName-4 1276322 27903 ns/op 9785 B/op 617 allocs/op BenchmarkToXXXName/ToHumanNameLower-4 895334 40354 ns/op 10472 B/op 731 allocs/op BenchmarkToXXXName/ToHumanNameTitle-4 882441 40678 ns/op 10566 B/op 749 allocs/op ``` ~ x10 performance improvement and ~ /100 memory allocations. ``` goos: linux goarch: amd64 pkg: github.com/go-openapi/swag cpu: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz BenchmarkToXXXName/ToGoName-4 9595830 3991 ns/op 42 B/op 5 allocs/op BenchmarkToXXXName/ToVarName-4 9194276 3984 ns/op 62 B/op 7 allocs/op BenchmarkToXXXName/ToFileName-4 17002711 2123 ns/op 147 B/op 7 allocs/op BenchmarkToXXXName/ToCommandName-4 16772926 2111 ns/op 147 B/op 7 allocs/op BenchmarkToXXXName/ToHumanNameLower-4 9788331 3749 ns/op 92 B/op 6 allocs/op BenchmarkToXXXName/ToHumanNameTitle-4 9188260 3941 ns/op 104 B/op 6 allocs/op ``` ``` goos: linux goarch: amd64 pkg: github.com/go-openapi/swag cpu: AMD Ryzen 7 5800X 8-Core Processor BenchmarkToXXXName/ToGoName-16 18527378 1972 ns/op 42 B/op 5 allocs/op BenchmarkToXXXName/ToVarName-16 15552692 2093 ns/op 62 B/op 7 allocs/op BenchmarkToXXXName/ToFileName-16 32161176 1117 ns/op 147 B/op 7 allocs/op BenchmarkToXXXName/ToCommandName-16 32256634 1137 ns/op 147 B/op 7 allocs/op BenchmarkToXXXName/ToHumanNameLower-16 18599661 1946 ns/op 92 B/op 6 allocs/op BenchmarkToXXXName/ToHumanNameTitle-16 17581353 2054 ns/op 105 B/op 6 allocs/op ```
Project: Velero (Runtime / Cloud Native Storage)
File: ark_create_backup.md

title: "ark create backup" layout: docs Create a backup Create a backup ``` ark create backup NAME [flags] ``` ``` --exclude-namespaces stringArray namespaces to exclude from the backup --exclude-resources stringArray resources to exclude from the backup, formatted as resource.group, such as storageclasses.storage.k8s.io -h, --help help for backup --include-cluster-resources optionalBool[=true] include cluster-scoped resources in the backup --include-namespaces stringArray namespaces to include in the backup (use '' for all namespaces) (default ) --include-resources stringArray resources to include in the backup, formatted as resource.group, such as storageclasses.storage.k8s.io (use '*' for all resources) --label-columns stringArray a comma-separated list of labels to be displayed as columns --labels mapStringString labels to apply to the backup -o, --output string Output display format. For create commands, display the object but do not send it to the server. Valid formats are 'table', 'json', and 'yaml'. -l, --selector labelSelector only back up resources matching this label selector (default <none>) --show-labels show labels in the last column --snapshot-volumes optionalBool[=true] take snapshots of PersistentVolumes as part of the backup --ttl duration how long before the backup can be garbage collected (default 720h0m0s) ``` ``` --alsologtostderr log to standard error as well as files --kubeconfig string Path to the kubeconfig file to use to talk to the Kubernetes apiserver. If unset, try the environment variable KUBECONFIG, as well as in-cluster configuration --kubecontext string The context to use to talk to the Kubernetes apiserver. If unset defaults to whatever your current-context is (kubectl config current-context) --logbacktraceat traceLocation when logging hits line file:N, emit a stack trace (default :0) --log_dir string If non-empty, write log files in this directory --logtostderr log to standard error instead of files -n, --namespace string The namespace in which Ark should operate (default "heptio-ark") --stderrthreshold severity logs at or above this threshold go to stderr (default 2) -v, --v Level log level for V logs --vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging ``` - Create ark resources
Project: Kanister (Runtime / Cloud Native Storage)
File: logs_level.md

Kanister uses structured logging to ensure that its logs can be easily categorized, indexed and searched by downstream log aggregation software. The default logging level of Kanister is set to `info`. This logging level can be changed by modifying the value of the `LOG_LEVEL` environment variable of the Kanister container. When using Helm, this value can be configured using the `controller.logLevel` variable. For example, to set the logging level to `debug`: ``` bash helm -n kanister upgrade --install kanister \ --set controller.logLevel=debug \ --create-namespace kanister/kanister-operator ``` The supported logging levels are: `panic` `fatal` `error` `info` `debug` `trace`
Project: Soda Foundation (Runtime / Cloud Native Storage)
File: update_southbound_interface.md

.. This work is licensed under a Creative Commons Attribution 4.0 International License. .. http://creativecommons.org/licenses/by/4.0 http://creativecommons.org/licenses/by/3.0/legalcode ==================================== OpenSDS SourthBound Interface Design ==================================== Problem description =================== Currently OpenSDS SourthBound interface is as follow: type VolumeDriver interface { //Any initialization the volume driver does while starting. Setup() //Any operation the volume driver does while stoping. Unset() CreateVolume(name string, volType string, size int32) (string, error) GetVolume(volID string) (string, error) GetAllVolumes(allowDetails bool) (string, error) DeleteVolume(volID string) (string, error) AttachVolume(volID string) (string, error) DetachVolume(device string) (string, error) MountVolume(mountDir, device, fsType string) (string, error) UnmountVolume(mountDir string) (string, error) } From the interface shown above, we came to a conclusion that MountVolume and UnmountVolume methods can not be handled by drivers, thus they should be from here. The reasons are as follows: 1) From the point of semantics, mount and unmount operations belong to host rather than storage backends, so there is no need for backends to receive these two requests. 2) From the point of architecture design, OpenSDS only contains volume and share resources. So when users want to mount a resource, just tell OpenSDS which type of resource it should choose and let OpenSDS do the remaining work. 3) From the point of implementation, if we move these two operations to dock module, a lot of redundant code will be removed. Proposed Change =============== The main changes are as follows: 1) Remove mount and unmount operation in VolumeDriver and ShareDriver interface. 2) Create two packages(volume and share) in dock module, and move the two operations above to new files(such as "volume_mount.go"). 3) Remove code of these two operation in all backend drivers. Data model impact -- After changed, the interface will be like this: type VolumeDriver interface { //Any initialization the volume driver does while starting. Setup() //Any operation the volume driver does while stoping. Unset() CreateVolume(name string, volType string, size int32) (string, error) GetVolume(volID string) (string, error) GetAllVolumes(allowDetails bool) (string, error) DeleteVolume(volID string) (string, error) AttachVolume(volID string) (string, error) DetachVolume(device string) (string, error) } REST API impact None Security impact None Other end user impact None Performance impact None Other deployer impact None Dependencies ============ None Testing ======= None Documentation Impact ==================== None References ========== None
Project: iSulad (Runtime / Container Runtime)
File: fuzz_test_guide.md

You need to install the following dependencies and configure the PATH environment variable to point to the binary directory where gclang is located: ```bash $ yum makecache $ yum install -y git unzip patch golang llvm clang compiler-rt libasan-static libasan $ go env -w GO111MODULE=auto $ go env -w GOPROXY="https://goproxy.io,direct" $ go get -v github.com/SRI-CSL/gllvm/cmd/... $ export PATH=/root/go/bin:$PATH ``` ```bash $ mkdir build && cd build $ cmake -DCMAKEBUILDTYPE=Debug -DENABLEASAN=ON -DENABLEFUZZ=ON .. $ cmake -DCMAKEBUILDTYPE=Debug -DGCOV=ON -DENABLEASAN=ON -DENABLEFUZZ=ON .. $ make -j $(nproc) ``` Execute all fuzz test cases: ```bash $ cd test/fuzz/ $ ./fuzz.sh ``` Execute some fuzz test cases: ```bash $ cd test/fuzz/ $ ./fuzz.sh testgrobjparserfuzz testpwobjparserfuzz testvolumemountspecfuzz testvolumeparsevolumefuzz ``` If the test is successful, a log will be generated in the iSulad root directory: ```bash $ ls -la *.log -rw-. 1 root root 2357 Jul 4 10:23 testgrobjparserfuzz.log -rw-. 1 root root 3046 Jul 4 10:23 testpwobjparserfuzz.log -rw-. 1 root root 1167 Jul 4 10:23 testvolumemountspecfuzz.log -rw-. 1 root root 3411 Jul 4 10:23 testvolumeparsevolumefuzz.log ``` You can use third-party tools to collect coverage information and analyze it. For example, you can run the following command to let lcov collect cover.info, where ISULADSRCPATH is filled with iSulad source code path: ```bash $ lcov -gcov-tool /usr/bin/llvm-gcov.sh -c -d -m $ISULADSRCPATH -o cover.info ```
Project: HwameiStor (Runtime / Cloud Native Storage)
File: lvm_nodes.md

sidebar_position: 1 sidebar_label: "LVM Storage Node" LVM storage nodes pool the disks on the node and provide LVM-type data volumes for applications. Add the node into the Kubernetes cluster or select a Kubernetes node. The node should have all the required items described in . For example, suppose you have a new node with the following information: name: k8s-worker-4 devPath: /dev/sdb diskType: SSD disk After the new node is already added into the Kubernetes cluster, make sure the following HwameiStor pods are already running on this node. ```bash $ kubectl get node NAME STATUS ROLES AGE VERSION k8s-master-1 Ready master 96d v1.24.3-2+63243a96d1c393 k8s-worker-1 Ready worker 96h v1.24.3-2+63243a96d1c393 k8s-worker-2 Ready worker 96h v1.24.3-2+63243a96d1c393 k8s-worker-3 Ready worker 96d v1.24.3-2+63243a96d1c393 k8s-worker-4 Ready worker 1h v1.24.3-2+63243a96d1c393 $ kubectl -n hwameistor get pod -o wide | grep k8s-worker-4 hwameistor-local-disk-manager-c86g5 2/2 Running 0 19h 10.6.182.105 k8s-worker-4 <none> <none> hwameistor-local-storage-s4zbw 2/2 Running 0 19h 192.168.140.82 k8s-worker-4 <none> <none> $ kubectl get localstoragenode k8s-worker-4 NAME IP ZONE REGION STATUS AGE k8s-worker-4 10.6.182.103 default default Ready 8d ``` Construct the storage pool of the node by adding a LocalStorageClaim CR as below: ```console $ kubectl apply -f - <<EOF apiVersion: hwameistor.io/v1alpha1 kind: LocalDiskClaim metadata: name: k8s-worker-4 spec: nodeName: k8s-worker-4 owner: local-storage description: diskType: SSD EOF ``` Finally, check if the node has constructed the storage pool by checking the LocalStorageNode CR. ```bash kubectl get localstoragenode k8s-worker-4 -o yaml ``` The output may look like: ```yaml apiVersion: hwameistor.io/v1alpha1 kind: LocalStorageNode metadata: name: k8s-worker-4 spec: hostname: k8s-worker-4 storageIP: 10.6.182.103 topogoly: region: default zone: default status: pools: LocalStorage_PoolSSD: class: SSD disks: capacityBytes: 214744170496 devPath: /dev/sdb state: InUse type: SSD freeCapacityBytes: 214744170496 freeVolumeCount: 1000 name: LocalStorage_PoolSSD totalCapacityBytes: 214744170496 totalVolumeCount: 1000 type: REGULAR usedCapacityBytes: 0 usedVolumeCount: 0 volumeCapacityBytesLimit: 214744170496 volumes: state: Ready ```
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-health_completion_powershell.md

<!-- This file was autogenerated via cilium-agent --cmdref, do not edit manually--> Generate the autocompletion script for powershell Generate the autocompletion script for powershell. To load completions in your current shell session: cilium-health completion powershell | Out-String | Invoke-Expression To load completions for every new session, add the output of the above command to your powershell profile. ``` cilium-health completion powershell [flags] ``` ``` -h, --help help for powershell --no-descriptions disable completion descriptions ``` ``` -D, --debug Enable debug messages -H, --host string URI to cilium-health server API --log-driver strings Logging endpoints to use for example syslog --log-opt map Log driver options for cilium-health e.g. syslog.level=info,syslog.facility=local5,syslog.tag=cilium-agent ``` - Generate the autocompletion script for the specified shell