cwielenb/CNCF-Dataset huggingface dataset:
Project: CubeFS (Runtime / Cloud Native Storage)
File: capacity.md

```bash $ cfs-cli volume expand {volume name} {capacity / GB} ``` This interface is used to increase the volume capacity space. ::: tip Note DpReadOnlyWhenVolFull can strictly limit volume capacity. How to configure the configuration to stop writing when the volume is full: (1)master When creating the volume, set the DpReadOnlyWhenVolFull parameter to true; If the value of the created volume is false, use the update interface to change it to true. After this value is set to true, when the volume is full, the master will change the status of all DPs of the volume to readonly. (2)client Upgrade the client and set the "minWriteAbleDataPartitionCnt" parameter in the client's configuration to 0. ::: The more readable and writable data partitions (DPs), the more dispersed the data, and the better the read and write performance of the volume. CubeFS adopts a dynamic space allocation mechanism. After creating a volume, a certain number of data partition DPs will be pre-allocated for the volume. When the number of readable and writable DPs is less than 10, the number of DPs will be automatically increased. If you want to manually increase the number of readable and writable DPs, you can use the following command: ```bash $ cfs-cli volume create-dp {volume name} {number} ``` ::: tip Note The default size of a DP is 120GB. Please create DPs based on the actual usage of the volume to avoid overdraw of all DPs. ::: ```bash $ cfs-cli volume shrink {volume name} {capacity in GB} ``` This interface is used to reduce the volume capacity space. It will be calculated based on the actual usage. If the set value is less than 120% of the used capacity, the operation will fail. Prepare new data nodes (DNs) and metadata nodes (MNs), and configure the existing master address in the configuration file to automatically add the new nodes to the cluster.
Project: Curve (Runtime / Cloud Native Storage)
File: CHANGELOG-2.3.md

Previous change logs can be found at Hardware: 3 nodes (3mds, 9metaserver), each with: Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz 256G RAM disk cache: INTEL SSDSC2BB80 800G(iops is about 30000+,bw is about 300MB) performance is as follows: s3 backend is minio and the cto is disable(). and as you know, the performance of read may associated with read cache hit. | minio + diskcache(free)| iops/bandwidth | avg-latency(ms) | clat 99.00th (ms) | clat 99.99th (ms) | | :-: | :-: | :-: | :-: | :-: | | (numjobs 1) (50G filesize) 4k randwrite | 3539 | 0.281 | 1.5 | 16 | | (numjobs 1) (50G filesize) 4k randread | 2785 | 0.357 | 0.9 | 5.8| | (numjobs 1) (50G filesize) 512k write | 290 MB/s | 1 | 600 ms | 248| | (numjobs 1) (50G filesize) 512k read | 216 MB/s | 4.3 | 275 ms | 7.6 | | minio + diskcache(near full)| iops/bandwidth | avg-latency(ms) | clat 99.00th (ms) | clat 99.99th (ms) | | :-: | :-: | :-: | :-: | :-: | | (numjobs 1) (50G filesize) 4k randwrite | 2988 | 0.3 | 1.2 | 18 | | (numjobs 1) (50G filesize) 4k randread | 1559 | 0.6 | 1.9 | 346| | (numjobs 1) (50G filesize) 512k write | 266 MB/s | 0.9| 600 ms | 396| | (numjobs 1) (50G filesize) 512k read | 82 MB/s | 86 | 275 ms | 901| | minio + diskcache(full)| iops/bandwidth | avg-latency(ms) | clat 99.00th (ms) | clat 99.99th (ms) | | :-: | :-: | :-: | :-: | :-: | | (numjobs 1) (20G filesize * 5) 4k randwrite | 2860 |

14 | 41 | | (numjobs 1) (20G filesize * 5) 4k randread | 76 | 65 | 278 | 725| | (numjobs 1) (20G filesize * 5) 512k write | 240 MB/s | 10| 278 | 513| | (numjobs 1) (20G filesize * 5) 512k read | 192 MB/s | 12 | 40 | 1955 | Cluster Topology: 3 nodes (3mds, 6metaserver), each metaserver is deployed on a separate SATA SSD Configuration: use default configuration Test tool: mdtest v3.4.0 Test cases: case 1: the directory structure is relatively flat and total 130,000 dirs and files. mdtest -z 2 -b 3 -I 10000 -d /mountpoint case 2: the directory structure is relatively deep and total 204,700 dirs and files. mdtest -z 10 -b 2 -I 100 -d /mountpoint | Case | Dir creation | Dir stat | Dir rename | Dir removal | File creation | File stat | File read | File removal | Tree creation | Tree removal | | | | | | | | | | | | | | case 1 | 1320 | 5853 | 149 | 670 | 1103 | 5858 | 1669 | 1419 | 851 | 64 | | case 2 | 1283 | 5205 | 147 | 924 | 1081 | 5316 | 1634 | 1260 | 1302 | 887 | You can set configuration item fuseClient.enableMultiMountPointRename to false in client.conf if you don't need concurrent renames on multiple mountpoints on the same filesystem. It will improve the performance of metadata. fuseClient.enableMultiMountPointRename=false | Case | Dir creation | Dir stat | Dir rename | Dir removal | File creation | File stat | File read | File removal | Tree creation | Tree removal | | | | | | | | | | | | | | case 1 | 1537 | 7885 | 530 | 611 | 1256 | 7998 | 1861 | 1614 | 1050 | 72 | | case 2 | 1471 | 6328 | 509 | 1055 | 1237 | 6874 | 1818 | 1454 | 1489 | 1034 |
Project: HwameiStor (Runtime / Cloud Native Storage)
File: what.md

id: "intro" sidebar_position: 1 sidebar_label: "What is HwameiStor" HwameiStor is an HA local storage system for cloud-native stateful workloads. HwameiStor creates a local storage resource pool for centrally managing all disks such as HDD, SSD, and NVMe. It uses the CSI architecture to provide distributed services with local volumes, and provides data persistence capabilities for stateful cloud-native workloads or components. HwameiStor is an open source, lightweight, and cost-efficient local storage system that can replace expensive traditional SAN storage. The system architecture of HwameiStor is as follows. By using the CAS pattern, users can achieve the benefits of higher performance, better cost-efficiency, and easier management of their container storage. It can be deployed by helm charts or directly use the independent installation. You can easily enable high-performance local storage across the entire cluster with one click and automatically identify disks. HwameiStor is easy to deploy and ready to go. Automated Maintenance Disks can be automatically discovered, identified, managed, and allocated. Smart scheduling of applications and data based on affinity. Automatically monitor disk status and give early warning. High Availability Use cross-node replicas to synchronize data for high availability. When a problem occurs, the application will be automatically scheduled to the high-availability data node to ensure the continuity of the application. Full-Range support of Storage Medium Aggregate HDD, SSD, and NVMe disks to provide low-latency, high-throughput data services. Agile Linear Scalability Dynamically expand the cluster according to flexibly meet the data persistence requirements of the application.
Project: rkt (Runtime / Container Runtime)
File: run-prepared.md

Once a pod is prepared with rkt , it can be run by executing `rkt run-prepared UUID`. ``` UUID APP ACI STATE NETWORKS c9fad0e6 etcd coreos.com/etcd prepared 2015/10/01 16:44:08 Setting up stage1 2015/10/01 16:44:08 Wrote filesystem to /var/lib/rkt/pods/run/c9fad0e6-8236-4fc2-ad17-55d0a4c7d742 2015/10/01 16:44:08 Pivoting to filesystem /var/lib/rkt/pods/run/c9fad0e6-8236-4fc2-ad17-55d0a4c7d742 2015/10/01 16:44:08 Execing /init ``` | Flag | Default | Options | Description | | | | | | | `--dns` | `` | IP Address | Name server to write in `/etc/resolv.conf`. It can be specified several times | | `--dns-opt` | `` | Option as described in the options section in resolv.conf(5) | DNS option to write in `/etc/resolv.conf`. It can be specified several times | | `--dns-search` | `` | Domain name | DNS search domain to write in `/etc/resolv.conf`. It can be specified several times | | `--hostname` | "rkt-$PODUUID" | A host name | Set pod's host name. | | `--interactive` | `false` | `true` or `false` | Run pod interactively. If true, only one image may be supplied | | `--ipc` | `auto` | `auto`, `private` or `parent` | Whether to stay in the host IPC namespace. | | `--mds-register` | `false` | `true` or `false` | Register pod with metadata service. It needs network connectivity to the host (`--net=(default|default-restricted|host)` | | `--net` | `default` | A comma-separated list of networks. Syntax: `--net[=n[:args], ...]` | Configure the pod's networking. Optionally, pass a list of user-configured networks to load and set arguments to pass to each network, respectively | See the table with .
Project: HwameiStor (Runtime / Cloud Native Storage)
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: Cilium (Runtime / Cloud Native Network)
File: cilium-health_completion.md

<!-- This file was autogenerated via cilium-agent --cmdref, do not edit manually--> Generate the autocompletion script for the specified shell Generate the autocompletion script for cilium-health for the specified shell. See each sub-command's help for details on how to use the generated script. ``` -h, --help help for completion ``` ``` -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 ``` - Cilium Health Client - Generate the autocompletion script for bash - Generate the autocompletion script for fish - Generate the autocompletion script for powershell - Generate the autocompletion script for zsh
Project: Velero (Runtime / Cloud Native Storage)
File: examples.md

title: "Examples" layout: docs After you set up the Velero server, you can clone the examples used in the following sections by running the following: ``` git clone https://github.com/vmware-tanzu/velero.git cd velero ``` Start the sample nginx app: ```bash kubectl apply -f examples/nginx-app/base.yaml ``` Create a backup: ```bash velero backup create nginx-backup --include-namespaces nginx-example ``` Simulate a disaster: ```bash kubectl delete namespaces nginx-example ``` Wait for the namespace to be deleted. Restore your lost resources: ```bash velero restore create --from-backup nginx-backup ``` NOTE: For Azure, you must run Kubernetes version 1.7.2 or later to support PV snapshotting of managed disks. Start the sample nginx app: ```bash kubectl apply -f examples/nginx-app/with-pv.yaml ``` Create a backup with PV snapshotting: ```bash velero backup create nginx-backup --include-namespaces nginx-example ``` Simulate a disaster: ```bash kubectl delete namespaces nginx-example ``` Because the default for dynamically-provisioned PVs is "Delete", these commands should trigger your cloud provider to delete the disk that backs the PV. Deletion is asynchronous, so this may take some time. Before continuing to the next step, check your cloud provider to confirm that the disk no longer exists. Restore your lost resources: ```bash velero restore create --from-backup nginx-backup ```
Project: HwameiStor (Runtime / Cloud Native Storage)
File: community.md

sidebar_position: 15 sidebar_label: "Community" If you have any questions about the HwameiStor cloud-native local storage system, welcome to join the community to explore this metaverse world dedicated to developers and grow together! Submit your feedback and issue via . Join a user group #user Join a developer group #developer The blog posts updates on a regular basis. Join regular discussions with community developers. Tel.: (+86) 400 002 6898 Email: info@ Join our Wechat group by scanning the QR code:
Project: containerd (Runtime / Container Runtime)
File: RELEASES.md

Pass the ttRPC receiving context from the Stub to each NRI request handler of the plugin. Fix Stub/Plugin UpdateContainer interface to pass the resource update to the UpdateContainer NRI request handler of the plugin as the last argument. All plugins need to be updated to reflect the above changes in any NRI request handler they implement. NRI plugins can now add rlimits Eliminate the global NRI configuration file, replacing any remaining configuration options with corresponding programmatic options for runtimes. Change default socket path from /var/run/nri.sock to /var/run/nri/nri.sock. Make plugin timeouts configurable on the runtime side. Plugins should be API-compatible between 0.2.0 and 0.3.0, but either the runtime needs to be configured to use the old NRI socket path, or 0.2.0 plugins need to be configured to use the new default NRI socket path. Replace the v0.1.0 CNI like plugin interface with JSON message exchange on stdin and stdout with external daemon-like plugins and a protobuf-defined protocol with ttRPC bindings for communicating with the runtime. Allow plugins to track the state of (CRI) pods and containers. Allow plugins to make changes to a selected subset of container parameters during container creation, update, and stopping of (other) containers. All 0.1.0 plugins are incompatible with 0.2.0, although is provided to bridge between any existing 0.1.0 plugins and the current NRI APIs.
Project: gVisor (Runtime / Container Runtime)
File: roadmap.md

gVisor serve as the source-of-truth for most work in flight. Specific performance and compatibility issues are generally tracked there. may be used to track larger features that span many issues. However, labels are also used to aggregate cross-cutting feature work. Most gVisor work is focused on four areas. : overall sandbox performance, including platform performance, is a critical area for investment. This includes: network performance (throughput and latency), file system performance (metadata and data I/O), application switch and fault costs, etc. The goal of gVisor is to provide sandboxing without a material performance or efficiency impact on all but the most performance-sensitive applications. : supporting a wide range of applications requires supporting a large system API, including special system files (e.g. proc, sys, dev, etc.). The goal of gVisor is to support the broad set of applications that depend on a generic Linux API, rather than a specific kernel version. : the above goals require aggressive testing and coverage, and well-established processes. This includes adding appropriate system call coverage, end-to-end suites and runtime tests. : Container infrastructure is evolving rapidly and becoming more complex, and gVisor must continuously implement relevant and popular features to ensure that integration points remain robust and feature-complete while preserving security guarantees. Releases are available on . As a convenience, binary packages are also published. Instructions for their use are available via the .
Project: Velero (Runtime / Cloud Native Storage)
File: CHANGELOG-0.11.md

https://github.com/heptio/velero/releases/tag/v0.11.1 Added the `velero migrate-backups` command to migrate legacy Ark backup metadata to the current Velero format in object storage. This command needs to be run in preparation for upgrading to v1.0, if* you have backups that were originally created prior to v0.11 (i.e. when the project was named Ark). https://github.com/heptio/velero/releases/tag/v0.11.0 Heptio Ark is now Velero! This release is the first one to use the new name. For details on the changes and how to migrate to v0.11, see the . Please follow the instructions to ensure a successful upgrade to v0.11.* Restic has been upgraded to v0.9.4, which brings significantly faster restores thanks to a new multi-threaded restorer. Velero now waits for terminating namespaces and persistent volumes to delete before attempting to restore them, rather than trying and failing to restore them while they're being deleted. Fix concurrency bug in code ensuring restic repository exists (#1235, @skriss) Wait for PVs and namespaces to delete before attempting to restore them. (#826, @nrb) Set the zones for GCP regional disks on restore. This requires the `compute.zones.get` permission on the GCP serviceaccount in order to work correctly. (#1200, @nrb) Renamed Heptio Ark to Velero. Changed internal imports, environment variables, and binary name. (#1184, @nrb) use 'restic stats' instead of 'restic check' to determine if repo exists (#1171, @skriss) upgrade restic to v0.9.4 & replace --hostname flag with --host (#1156, @skriss) Clarify restore log when object unchanged (#1153, @daved) Add backup-version file in backup tarball. (#1117, @wwitzel3) add ServerStatusRequest CRD and show server version in `ark version` output (#1116, @skriss)
Project: Velero (Runtime / Cloud Native Storage)
File: vendoring-dependencies.md

title: "Vendoring dependencies" layout: docs We are using to manage dependencies. You can install it by following [these instructions][1]. Run `dep ensure`. If you want to see verbose output, you can append `-v` as in `dep ensure -v`. Run `dep ensure -update <pkg> [<pkg> ...]` to update one or more dependencies.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_policy_delete.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Delete a policy entry ``` cilium-dbg bpf policy delete <endpoint id> <identity> [port/proto] [flags] ``` ``` --deny Sets deny mode -h, --help help for delete ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage policy related BPF maps
Project: CubeFS (Runtime / Cloud Native Storage)
File: trash.md

The default setting for CubeFS volumes does not enable the trash feature. However, you can enable the trash feature for a volume through the master service interface. namevolume name. authKeycalculate the 32-bit MD5 value of the owner field of vol as authentication information. trashIntervaltrash cleanup period for deleted files is specified in minutes. The default value of 0 means that the trash feature is not enabled. ``` bash curl -v "http://127.0.0.1:17010/vol/setTrashInterval?name=test&authKey=&trashInterval=7200" | jq . ``` After enabling the trash feature, the client will create a hidden folder named ".Trash" in the root directory of the mount point. The "Current" folder within ".Trash" retains the currently mistakenly deleted files or folders along with their complete file paths. ::: tip Note In order to improve the efficiency of the trash, deleted files are displayed with their parent directories flattened in the file names. The background coroutine constructs the parent directory paths for the files. Therefore, when there are a large number of files in the deleted, it is possible to briefly encounter situations where deleted files do not have their parent directories. This is considered a normal occurrence. ::: The "Current" directory is periodically renamed to Expired_ExpirationTimestamp. When the expiration timestamp of the "Expired" folder is reached, all contents within that folder are deleted. As mentioned earlier, to recover a mistakenly deleted file, you simply need to locate the file in either the "Current" or "Expired" directory within the ".Trash" folder. Using the complete parent directory path, you can restore the deleted file/folder to its original location using the "mv" operation. It is important to note that the contents of the trash rely on the client's background coroutine for periodic deletion. Therefore, if there is no online client for the respective volume, the contents of the trash will be retained until a client for the respective volume. To free up space in the trash as quickly as possible, you can also directly perform the "rm" operation on the ".Trash" folder through the client.
Project: Rook (Runtime / Cloud Native Storage)
File: rook-test-framework.md

title: Rook Test Framework The integration tests run end-to-end tests on Rook in a running instance of Kubernetes. The framework includes scripts for starting Kubernetes so users can quickly spin up a Kubernetes cluster. The tests are generally designed to install Rook, run tests, and uninstall Rook. The CI runs the integration tests with each PR and each master or release branch build. If the tests fail in a PR, the tmate for debugging. This document will outline the steps to run the integration tests locally in a minikube environment, should the CI not be sufficient to troubleshoot. !!! hint The CI is generally much simpler to troubleshoot than running these tests locally. Running the tests locally is rarely necessary. !!! warning A risk of running the tests locally is that a local disk is required during the tests. If not running in a VM, your laptop or other test machine could be destroyed. Follow Rook's to install Minikube. Now that the Kubernetes cluster is running we need to populate the Docker registry to allow local image builds to be easily used inside Minikube. ```console eval $(minikube docker-env -p minikube) ``` `make build` will now build and push the images to the Docker registry inside the Minikube virtual machine. ```console make build ``` Tag the newly built images to `rook/ceph:local-build` for running tests, or `rook/ceph:master` if creating example manifests:: ```console docker tag $(docker images|awk '/build-/ {print $1}') rook/ceph:local-build docker tag rook/ceph:local-build rook/ceph:master ``` Some settings are available to run the tests under different environments. The settings are all configured with environment variables. See for the available environment variables. Set the following variables: ```console export TESTHELMPATH=/tmp/rook-tests-scripts-helm/linux-amd64/helm export TESTBASEDIR=WORKING_DIR export TESTSCRATCHDEVICE=/dev/vdb ``` Set `TESTSCRATCHDEVICE` to the correct block device name based on the driver that's being used. !!! hint If using the `virtualbox` minikube driver, the device should be `/dev/sdb` !!! warning The integration tests erase the contents of `TESTSCRATCHDEVICE` when the test is completed To run a specific suite, specify the suite name: ```console go test -v -timeout 1800s -run CephSmokeSuite github.com/rook/rook/tests/integration ``` After running tests, see test logs under `tests/integration/_output`. To run specific tests inside a suite: ```console go test -v -timeout 1800s -run CephSmokeSuite github.com/rook/rook/tests/integration -testify.m TestARookClusterInstallation_SmokeTest ``` !!! info Only the golang test suites are documented to run locally. Canary and other tests have only ever been supported in the CI. Setup OpenShift environment and export KUBECONFIG Make sure `oc` executable file is in the PATH. Only the `CephSmokeSuite` is currently supported on OpenShift. Set the following environment variables depending on the environment: ```console export TESTENVNAME=openshift export TESTSTORAGECLASS=gp2 export TESTBASEDIR=/tmp ``` Run the integration tests
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_statedb_health.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Show contents of table "health" ``` cilium-dbg statedb health [flags] ``` ``` -h, --help help for health -w, --watch duration Watch for new changes with the given interval (e.g. --watch=100ms) ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Inspect StateDB