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

ARM machine: | Configuration | Information | | - | -- | | OS | openEuler 22.03-LTS | | Kernel | linux 5.10.0-136.12.0.86.oe2203.aarch64 | | CPU | 96 cores | | Memory | 128 GB | | Name | Version | | | | | iSulad | Version: 2.1.5 , Git commit: 5ebca976dd591a5676527be1bde950e5ce93eac0 | | containerd | Version: v2.0.0-beta.2, Git commit: 290194fe77d48521d3ea78ec02e2e406c4bf91b6 | | crio | version: 1.30.0, Git commit: b43e0d63a8af3277dbfc555f62d07bb2305a72c7 | tools/benchmark/criperftest.sh run 1 pod and 1 container | measure | iSulad | containerd | crio | vs containerd | vs crio | | -- | | | | | | | time(ms) | 580 | 812 | 567 | -28.5% | 2.3% | | engine mem(kb) | 38704 | 66806 | 58760 | -42.0% | -34.2% | | shim mem(kb) | 1700 | 13876 | 4648 | -87.7% | -63.4% | run 10 pods and 10 containers | measure | iSulad | containerd | crio | vs containerd | vs crio | | -- | | | | | | | time(ms) | 1141 | 4000 | 1749 | -71.5% | -34.8% | | engine mem(kb) | 47688 | 82580 | 86128 | -42.2% | -44.6% | | shim mem(kb) | 16764 | 154872 | 46836 | -89.2% | -64.2% | run 50 pods and 50 containers | measure | iSulad | containerd | crio | vs containerd | vs crio | | -- | | | | | | | time(ms) | 4544 | 19963 | 8503 | -77.2% | -46.9% | | engine mem(kb) | 88700 | 134384 | 115560 | -34.0% | -23.2% | | shim mem(kb) | 83892 | 750924 | 233480 | -88.8% | -64.0% | run 100 pods and 100 containers | measure | iSulad | containerd | crio | vs containerd | vs crio | | -- | | | | | | | time(ms) | 10012 | 39629 | 18278 | -74.7% | -45.5% | | engine mem(kb) | 148464 | 185700 | 147836 | -20.0% | 0.4% | | shim mem(kb) | 168420 | 1506268| 462000 | -88.8% | -63.3% |
Project: iSulad (Runtime / Container Runtime)
File: podsandbox_cri_interface_design.md

| Author | | | | | | Date | 2023-06-30 | | Email | zhangxiaoyu58@huawei.com | EnsureSandboxImageExists: add runtime check, only pull image if runtime is not kuasar CreateSandboxContainer: create Sandbox by SandboxManager.CreateSandbox(), and execute Sandbox.Create(). Setup sandboxkey in Sandbox.Create() SetNetworkReady: is replaced by Sandbox.SetNetworkReady InspectContainer: use member functions of Sandbox to get network_mode, sandbox_key and resolv_conf_path m_cb->container.start: is replaced by Sandbox.Start() mcb->container.updatenetworksettings: update sandbox network settings by *Sandbox.UpdateNetworkSettings(networksettings)*. Add update network settings in controller to save network settings in container data? GetRealSandboxIDToStop: SandboxManager.GetSandbox(), and use member functions of Sandbox to get network_mode and annotations StopAllContainersInSandbox: call Sandbox.GetContainers() to get all containers of sandbox, and then stop containers ClearCniNetwork: call Sandbox.GetSandboxKey(), network teardown and use Sandbox.SetNetworkReady() to set network_ready false StopContainerHelper: is replaced by Sandbox.Stop() cb->container.get_id: is replaced by SandboxManager.GetSandbox() RemoveAllContainersInSandbox: call Sandbox.GetContainers() to get all containers of sandbox, and then remove containers DoRemovePodSandbox: call Sandbox.Remove() and SandboxManager.DeleteSandbox() cb->container.get_id: is replaced by SandboxManager.GetSandbox() inspectcontainer: use member functions of Sandbox to get *id*, *created*, *startedat, finishedat*, *running*, *labels*, *annotations*, *networkmode, pidmode*, *ipcmode and networks*. m_cb->container.list: SandboxManager.ListAllSandboxes(filter), and use member functions of Sandbox to get id, status, created, labels and annotations cb->container.get_id: is replaced by SandboxManager.GetSandbox() inspectcontainer: use member functions of Sandbox to get *cgroupparent and sandbox_key* PodSandboxStatus: is replaced by Sandbox.GetAnnotations() PodSandboxStatsToGRPC: Sandbox.UpdateCPUMetrics(timestamp, cpuUsageNanos)? It's unnecessary to save metrics data. m_cb->container.list: is replaced by SandboxManager.ListAllSandboxes(filter)
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator_completion_zsh.md

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> Generate the autocompletion script for zsh Generate the autocompletion script for the zsh shell. If shell completion is not already enabled in your environment you will need to enable it. You can execute the following once: echo "autoload -U compinit; compinit" >> ~/.zshrc To load completions in your current shell session: source <(cilium-operator completion zsh) To load completions for every new session, execute once: cilium-operator completion zsh > "${fpath[1]}/_cilium-operator" cilium-operator completion zsh > $(brew --prefix)/share/zsh/site-functions/_cilium-operator You will need to start a new shell for this setup to take effect. ``` cilium-operator completion zsh [flags] ``` ``` -h, --help help for zsh --no-descriptions disable completion descriptions ``` - Generate the autocompletion script for the specified shell
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_auth_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List all authenticated connections between identities List all authenticated connections between identities ``` cilium-dbg bpf auth list [flags] ``` ``` -h, --help help for list -o, --output string json| yaml| jsonpath='{}' ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage authenticated connections between identities
Project: Kata Containers (Runtime / Container Runtime)
File: MAINTAINERS.md

This page lists all active maintainers of this repository. If you were a maintainer and would like to add your name to the Emeritus list, please send us a PR. See for governance guidelines and how to become a maintainer. See for general contribution guidelines. , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC
Project: Sysbox (Runtime / Container Runtime)
File: arch-compat.md

The following table summarizes the platform architectures where Sysbox is currently supported. It is important to highlight that Sysbox implementation is expected to be fully platform agnostic. Thus, it should be relatively easy to extend the number of supported architectures -- it's expected to be mostly a testing/validation exercise. | Architecture | Supported Sysbox release | | - | :-: | | amd64 | v0.1.0+ | | arm64 | v0.5.0+ | Please file a new issue if you have a use-case that requires a non-supported architecture.
Project: Alluxio (Runtime / Cloud Native Storage)
File: FUSE-SDK-Dora-Quick-Start.md

layout: global title: FUSE SDK with Distributed Cache Quick Start If FUSE SDK can optional provide L1 cache (local node metadata/data cache) capability, Alluxio cluster can provide L2 cache (local/nearby cluster metadata/data cache). This suits the use cases that Need data sharing between nodes or tasks The total data accessed by a single node is bigger than the local node cache capability Limitations: Only support one under storage dataset and is not modifiable Only support read-only workloads Launch FUSE SDK with the same configuration (same `<ALLUXIO_HOME>/conf/`) as launching the Alluxio cluster. Other configuration is the same as launching a standalone FUSE SDK. ```shell $ alluxio-fuse mount <understoragedataset> <mount_point> -o option ``` `<understoragedataset>` should be exactly the same as the configured `alluxio.dora.client.ufs.root`. All the metadata and data will be cached by Alluxio workers. Optional disable default FUSE SDK local metadata cache with `-o localmetadatacache_size=0`.
Project: Piraeus Datastore (Runtime / Cloud Native Storage)
File: flatcar.md

This guide shows you how to set up the DRBD Module Loader when using . To complete this guide, you should be familiar with: editing `LinstorSatelliteConfiguration` resources. Flatcar Container Linux uses a read-only `/usr` file system. For building DRBD from source on Flatcar Container Linux, the default bind mount for the not existing `/usr/src` directory needs to be disabled for the `drbd-module-loader` init container. To change the configuration for the `drbd-module-loader` container, apply the following `LinstorSatelliteConfiguration`: ```yaml apiVersion: piraeus.io/v1 kind: LinstorSatelliteConfiguration metadata: name: no-usr-src-mount spec: podTemplate: spec: volumes: name: usr-src $patch: delete initContainers: name: drbd-module-loader volumeMounts: mountPath: /usr/src name: usr-src $patch: delete ```
Project: CubeFS (Runtime / Cloud Native Storage)
File: usage.md

```example bash ./fsck check inode -master "127.0.0.1:17010" --vol "<volName>" --mport "17220" ./fsck check dentry --master "127.0.0.1:17010" --vol "<volName>" --mport "17220" ./fsck check both --master "127.0.0.1:17010" --vol "<volName>" --mport "17220" ./fsck check both --vol "<volName>" --inode-list "inodes.txt" --dentry-list "dens.txt" ./fsck clean evict --master "127.0.0.1:17010" --vol "<volName>" --mport "17220" ./fsck clean inode --master "127.0.0.1:17010" --vol "<volName>" --mport "17220" ./fsck clean inode --vol "<volName>" --inode-list "inodes.txt" --dentry-list "dens.txt" ./fsck clean dentry --master "127.0.0.1:17010" --vol "<volName>" --mport "17220" ./fsck clean dentry --vol "<volName>" --inode-list "inodes.txt" --dentry-list "dens.txt" ./fsck get locations --inode <inodeID> --master "127.0.0.1:17010" --vol "<volName>" --mport "17220" ./fsck get path --inode <inodeID> --master "127.0.0.1:17010" --vol "<volName>" --mport "17220" ./fsck get path --master "127.0.0.1:17010" --vol "<volName>" --mport "17220" ./fsck get summary --inode <inodeID> --master "127.0.0.1:17010" --vol "<volName>" --mport "17220" ```
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_auth_flush.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Deletes all entries for authenticated connections between identities Deletes all entries for authenticated connections between identities ``` cilium-dbg bpf auth flush [flags] ``` ``` -h, --help help for flush -o, --output string json| yaml| jsonpath='{}' ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage authenticated connections between identities
Project: lxd (Runtime / Container Runtime)
File: images_create.md

(images-create)= If you want to create and share your own images, you can do this either based on an existing instance or snapshot or by building your own image from scratch. (images-create-publish)= If you want to be able to use an instance or an instance snapshot as the base for new instances, you should create and publish an image from it. To publish an image from an instance, make sure that the instance is stopped. Then enter the following command: incus publish <instance_name> [<remote>:] To publish an image from a snapshot, enter the following command: incus publish <instancename>/<snapshotname> [<remote>:] In both cases, you can specify an alias for the new image with the `--alias` flag, set an expiration date with `--expire` and make the image publicly available with `--public`. If an image with the same name already exists, add the `--reuse` flag to overwrite it. See for a full list of available flags. The publishing process can take quite a while because it generates a tarball from the instance or snapshot and then compresses it. As this can be particularly I/O and CPU intensive, publish operations are serialized by Incus. Before you publish an image from an instance, clean up all data that should not be included in the image. Usually, this includes the following data: Instance metadata (use to edit) File templates (use to edit) Instance-specific data inside the instance itself (for example, host SSH keys and `dbus/systemd machine-id`) (images-create-build)= For building your own images, you can use . See the for instructions for installing and using the tool.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bgp.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Access to BGP control plane ``` -h, --help help for bgp ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI - List current state of all peers - List configured route policies - List routes in the BGP Control Plane's RIBs
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_nat.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> NAT mapping tables ``` -h, --help help for nat ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Direct access to local BPF maps - Flush all NAT mapping entries - List all NAT mapping entries
Project: Kata Containers (Runtime / Container Runtime)
File: azure-installation-guide.md

Kata Containers on Azure use nested virtualization to provide an identical installation experience to Kata on your preferred Linux distribution. This guide assumes you have an Azure account set up and tools to remotely login to your virtual machine (SSH). Instructions will use the Azure Portal to avoid local dependencies and setup. Create a new virtual machine with: Nesting support (v3 series) your distro of choice Follow distribution specific .
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_auth.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage authenticated connections between identities ``` -h, --help help for auth ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Direct access to local BPF maps - Deletes all entries for authenticated connections between identities - List all authenticated connections between identities
Project: Kata Containers (Runtime / Container Runtime)
File: device.md

Currently we have following device manager: | Name | Description | | | | | | abstracts virtual machine's physical management and provide mapping for guest virtual memory and MMIO ranges of emulated virtual devices, pass-through devices and vCPU | | | provides abstractions for configuration information | | | provides management for all console devices | | |provides resource management for `legacyirqpool`, `msiirqpool`, `piopool`, `mmiopool`, `mempool`, `kvmmemslotpool` with builder `ResourceManagerBuilder` | | | provides configuration info for `VIRTIO-VSOCK` and management for all VSOCK devices | `VIRTIO-VSOCK` `i8042` `COM1` `COM2`
Project: CNI-Genie (Runtime / Cloud Native Network)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at i@dario.im. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at
Project: HwameiStor (Runtime / Cloud Native Storage)
File: disk_volumes.md

sidebar_position: 2 sidebar_label: "Disk Volume" HwameiStor provides another type of data volume known as raw disk data volume. This volume is based on the raw disk present on the node and can be directly mounted for container use. As a result, this type of data volume offers more efficient data read and write performance, thereby fully unleashing the performance of the disk. The following steps demonstrate how to create a disk voluem. Prepare Disk Storage Node Ensure that the storage node has sufficient available capacity. If there is not enough capacity, please refer to . Check for available capacity using the following command: ```shell $ kubectl get localdisknodes NAME FREECAPACITY TOTALCAPACITY TOTALDISK STATUS AGE k8s-worker-2 1073741824 1073741824 1 Ready 19d ``` Prepare StorageClass Create a StorageClass named `hwameistor-storage-disk-ssd` using the following command: ```console $ cat << EOF | kubectl apply -f - apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: hwameistor-storage-disk-ssd parameters: diskType: SSD provisioner: disk.hwameistor.io allowVolumeExpansion: false reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer EOF ``` Create Volume Create a PVC named `hwameistor-disk-volume` using the following command: ```console $ cat << EOF | kubectl apply -f - apiVersion: v1 kind: PersistentVolumeClaim metadata: name: hwameistor-disk-volume spec: accessModes: ReadWriteOnce resources: requests: storage: 1Gi storageClassName: hwameistor-storage-disk-ssd EOF ```
Project: Velero (Runtime / Cloud Native Storage)
File: ark_restic.md

title: "ark restic" layout: docs Work with restic Work with restic ``` -h, --help help for restic ``` ``` --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 ``` - Back up and restore Kubernetes cluster resources. - Work with restic repositories - Run the ark restic server
Project: Zenko (Runtime / Cloud Native Storage)
File: ISSUE_TEMPLATE.md

GitHub issues are reserved for actionable bug reports (including documentation issues), and feature requests. All questions regarding configuration, use cases, performance, community, events, setup and usage recommendations, among other things should be asked on the . _Questions opened as GitHub issues will be summarily closed and moved to the ._ Before reporting a new issue or requesting a feature, please search the issue list for this repository to ensure the issue has not already been opened (Use the search bar and select "Issues" on the left pane after searching). If the issue has already been raised, do not open a new issue. Add a comment to the existing issue instead. -- If you are reporting a bug, provide the information described here. If you are requesting a new feature, delete this section (to the next line). Briefly describe the problem you are having. Provide steps to reproduce the issue, including the full log output. Describe the results you received. Describe the results you expected. Let us know how your deployed example is configured. Tell us your: Node.js version Docker version npm version Distribution/OS Include anything else you think will help us resolve the issue. -- If you are requesting a new feature, delete the previous section (Bug Report Information) and provide the information described here. Describe the feature you want. Tell us what the program s doing now that you want to change. Tell us what you want the program to do. Please provide use cases for changing the program's current behavior. Tell us the starting state for the desired new feature (i.e., what screen or process step you want to start from), the steps you'd like to follow (or avoid!), and the results you want. To serve you better, we'd like to know a little more about you (if you don't mind our asking...) Is this request for your company? If it is, for which company? Is your company using any Scality Enterprise Edition products (RING, Zenko EE)? Are you willing to contribute this feature yourself? What is your position or title? How did you hear about us?