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

After the microVM is started, the rate limiters assigned to a network interface can be updated via a `PATCH /network-interfaces/{id}` API call. E.g. for a network interface created with: ```console PUT /network-interfaces/iface_1 HTTP/1.1 Host: localhost Content-Type: application/json Accept: application/json { "ifaceid": "iface1", "hostdevname": "fctap1", "guest_mac": "06:00:c0:a8:34:02", "rxratelimiter": { "bandwidth": { "size": 1024, "onetimeburst": 1048576, "refill_time": 1000 } }, "txratelimiter": { "bandwidth": { "size": 1024, "onetimeburst": 1048576, "refill_time": 1000 } } } ``` A `PATCH` request can be sent at any future time, to update the rate limiters: ```console PATCH /network-interfaces/iface_1 HTTP/1.1 Host: localhost Content-Type: application/json Accept: application/json { "ifaceid": "iface1", "rxratelimiter": { "bandwidth": { "size": 1048576, "refill_time": 1000 }, "ops": { "size": 2000, "refill_time": 1000 } } } ``` The full specification of the data structures available for this call can be found in our . Note: The data provided for the update is merged with the existing data. In the above example, the RX rate limit is updated, but the TX rate limit remains unchanged. A rate limit can be disabled by providing a 0-sized token bucket. E.g., following the above example, the TX rate limit can be disabled with: ```console PATCH /network-interfaces/iface_1 HTTP/1.1 Host: localhost Content-Type: application/json Accept: application/json { "ifaceid": "iface1", "txratelimiter": { "bandwidth": { "size": 0, "refill_time": 0 }, "ops": { "size": 0, "refill_time": 0 } } } ```
Project: SmartOS (Runtime / Container Runtime)
File: ziostat.8.md

ziostat(8) -- Report ZFS read I/O activity ============================================= ziostat [-hIMrzZ] [interval [count]] The ziostat utility reports a summary of ZFS read I/O operations. It first prints all activity since boot, then reports activity over a specified interval. When run from a non-global zone (NGZ), only activity from that NGZ can be observed. When run from a the global zone (GZ), activity from the GZ and all other NGZs can be observed. This tool is useful for determining if disk I/O is a source of application latency. Combined with vfsstat(8), ziostat(8) shows the relative contribution of disk I/O latency to overall I/O (and therefore application) latency. The ziostat utility reports the following information: r/s reads per second kr/s kilobytes read per second actv average number of ZFS read I/O operations being handled by the disk wsvc_t average wait time per I/O, in milliseconds asvc_t average disk service time per I/O, in milliseconds %b percent of time there is an I/O operation pending The following options are supported: -h Show help message and exit -I Print results per interval, rather than per second (where applicable) -M Print results in MB/s instead of KB/s -r Show results in a comma-separated format -z Hide zones with no read I/O activity -Z Print results for all zones, not just the current zone interval Specifies the length in seconds to pause between each interval report. If not specified, ziostat will print a summary since boot and exit. count Specifies the number of intervals to report. Defaults to unlimited if not specified. iostat(8), vfsstat(8), mpstat(8) This utility does not show any ZFS write I/O activity. Most write operations are asynchronous, so the latency of those operations committing to disk is much less important that read latency. The output format from ziostat may change over time; use the comma-separated output for a stable output format.
Project: Velero (Runtime / Cloud Native Storage)
File: restore.md

title: "Restore API Type" layout: docs The `Restore` API type is used as a request for the Velero server to perform a Restore. Once created, the Velero Server immediately starts the Restore process. Restore belongs to the API group version `velero.io/v1`. Here is a sample `Restore` object with each of the fields documented: ```yaml apiVersion: velero.io/v1 kind: Restore metadata: name: a-very-special-backup-0000111122223333 namespace: velero spec: backupName: a-very-special-backup includedNamespaces: '*' excludedNamespaces: some-namespace includedResources: '*' excludedResources: storageclasses.storage.k8s.io restoreStatus: includedResources: workflows excludedResources: [] includeClusterResources: null labelSelector: matchLabels: app: velero component: server orLabelSelectors: matchLabels: app: velero matchLabels: app: data-protection namespaceMapping: namespace-backup-from: namespace-to-restore-to restorePVs: true scheduleName: my-scheduled-backup-name existingResourcePolicy: none hooks: resources: name: restore-hook-1 includedNamespaces: ns1 excludedNamespaces: ns3 includedResources: pods excludedResources: [] labelSelector: matchLabels: app: velero component: server postHooks: init: initContainers: name: restore-hook-init1 image: alpine:latest volumeMounts: mountPath: /restores/pvc1-vm name: pvc1-vm command: /bin/ash -c echo -n "FOOBARBAZ" >> /restores/pvc1-vm/foobarbaz name: restore-hook-init2 image: alpine:latest volumeMounts: mountPath: /restores/pvc2-vm name: pvc2-vm command: /bin/ash -c echo -n "DEADFEED" >> /restores/pvc2-vm/deadfeed exec: container: foo command: /bin/bash -c "psql < /backup/backup.sql" waitTimeout: 5m execTimeout: 1m onError: Continue status: phase: "" validationErrors: null warnings: 2 errors: 0 failureReason: ```
Project: lxd (Runtime / Container Runtime)
File: projects_confine.md

(projects-confine)= You can use projects to confine the activities of different users or clients. See {ref}`projects-confined` for more information. How to confine a project to a specific user depends on the authentication method you choose. You can confine access to specific projects by restricting the TLS client certificate that is used to connect to the Incus server. See {ref}`authentication-tls-certs` for detailed information. To confine the access from the time the client certificate is added, you must either use token authentication or add the client certificate to the server directly. Use the following command to add a restricted client certificate: ````{tabs} ```{group-tab} Token authentication incus config trust add --projects <project_name> --restricted ``` ```{group-tab} Add client certificate incus config trust add-certificate <certificatefile> --projects <projectname> --restricted ``` ```` The client can then add the server as a remote in the usual way ( or ) and can only access the project or projects that have been specified. To confine access for an existing certificate, use the following command: incus config trust edit <fingerprint> Make sure that `restricted` is set to `true` and specify the projects that the certificate should give access to under `projects`. ```{note} You can specify the `--project` flag when adding a remote. This configuration pre-selects the specified project. However, it does not confine the client to this project. ``` Incus can be configured to dynamically create projects for all users in a specific user group. This is usually achieved by having some users be a member of the `incus` group but not the `incus-admin` group. Make sure that all user accounts that you want to be able to use Incus are a member of this group. Once a member of the group issues an Incus command, Incus creates a confined project for this user and switches to this project. If Incus has not been {ref}`initialized <initialize>` at this point, it is automatically initialized (with the default settings). If you want to customize the project settings, for example, to impose limits or restrictions, you can do so after the project has been created. To modify the project configuration, you must have full access to Incus, which means you must be part of the `incus-admin` group and not only the group that you configured as the Incus user group.
Project: HwameiStor (Runtime / Cloud Native Storage)
File: expand.md

sidebar_position: 2 sidebar_label: "Expand Volumes" HwameiStor supports `CSI Volume Expansion`, by which altering the size of `PVC` can dynamically expand the volume online. The below example will expand PVC `data-sts-mysql-local-0` from 1GiB to 2GiB. Check the current size of the `PVC/PV`. ```console $ kubectl get pvc data-sts-mysql-local-0 NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE data-sts-mysql-local-0 Bound pvc-b9fc8651-97b8-414c-8bcf-c8d2708c4ee8 1Gi RWO hwameistor-storage-lvm-hdd 85m $ kubectl get pv pvc-b9fc8651-97b8-414c-8bcf-c8d2708c4ee8 NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-b9fc8651-97b8-414c-8bcf-c8d2708c4ee8 1Gi RWO Delete Bound default/data-sts-mysql-local-0 hwameistor-storage-lvm-hdd 85m ``` Verify if the `StorageClass` has the parameter `allowVolumeExpansion: true`. ```console $ kubectl get pvc data-sts-mysql-local-0 -o jsonpath='{.spec.storageClassName}' hwameistor-storage-lvm-hdd $ kubectl get sc hwameistor-storage-lvm-hdd -o jsonpath='{.allowVolumeExpansion}' true ``` ```console $ kubectl edit pvc data-sts-mysql-local-0 ... spec: resources: requests: storage: 2Gi ... ``` The larger the volume, the longer it takes to expand the volume. You may observe the process from `PVC` events. ```console $ kubectl describe pvc data-sts-mysql-local-0 Events: Type Reason Age From Message - - - Warning ExternalExpanding 34s volume_expand Ignoring the PVC: didn't find a plugin capable of expanding the volume; waiting for an external controller to process this PVC. Warning VolumeResizeFailed 33s external-resizer lvm.hwameistor.io resize volume "pvc-b9fc8651-97b8-414c-8bcf-c8d2708c4ee8" by resizer "lvm.hwameistor.io" failed: rpc error: code = Unknown desc = volume expansion not completed yet Normal Resizing 32s (x2 over 33s) external-resizer lvm.hwameistor.io External resizer is resizing volume pvc-b9fc8651-97b8-414c-8bcf-c8d2708c4ee8 Normal FileSystemResizeRequired 32s external-resizer lvm.hwameistor.io Require file system resize of volume on node Normal FileSystemResizeSuccessful 11s kubelet MountVolume.NodeExpandVolume succeeded for volume "pvc-b9fc8651-97b8-414c-8bcf-c8d2708c4ee8" k8s-worker-3 ``` ```console $ kubectl get pvc data-sts-mysql-local-0 NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE data-sts-mysql-local-0 Bound pvc-b9fc8651-97b8-414c-8bcf-c8d2708c4ee8 2Gi RWO hwameistor-storage-lvm-hdd 96m $ kubectl get pv pvc-b9fc8651-97b8-414c-8bcf-c8d2708c4ee8 NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-b9fc8651-97b8-414c-8bcf-c8d2708c4ee8 2Gi RWO Delete Bound default/data-sts-mysql-local-0 hwameistor-storage-lvm-hdd 96m ```
Project: gVisor (Runtime / Container Runtime)
File: quick_start.md

This document describes how to use `containerd-shim-runsc-v1` with the containerd runtime handler support on `containerd`. This is a similar setup as [GKE Sandbox], other than the . Note: If you are using Kubernetes and set up your cluster using `kubeadm` you may run into issues. See the for details. runsc and containerd-shim-runsc-v1: See the . containerd: See the for information on how to install containerd. Minimal version supported: 1.3.9 or 1.4.3. Update `/etc/containerd/config.toml`. Make sure `containerd-shim-runsc-v1` is in `${PATH}` or in the same directory as `containerd` binary. ```shell cat <<EOF | sudo tee /etc/containerd/config.toml version = 2 [plugins."io.containerd.runtime.v1.linux"] shim_debug = true [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc] runtime_type = "io.containerd.runc.v2" [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc] runtime_type = "io.containerd.runsc.v1" EOF ``` Restart `containerd`: ```shell sudo systemctl restart containerd ``` You can run containers in gVisor via containerd's CRI. Download and install the `crictl` binary: ```shell { wget https://github.com/kubernetes-sigs/cri-tools/releases/download/v1.13.0/crictl-v1.13.0-linux-amd64.tar.gz tar xf crictl-v1.13.0-linux-amd64.tar.gz sudo mv crictl /usr/local/bin } ``` Write the `crictl` configuration file: ```shell cat <<EOF | sudo tee /etc/crictl.yaml runtime-endpoint: unix:///run/containerd/containerd.sock EOF ``` Pull the nginx image: ```shell sudo crictl pull nginx ``` Create the sandbox creation request: ```shell cat <<EOF | tee sandbox.json { "metadata": { "name": "nginx-sandbox", "namespace": "default", "attempt": 1, "uid": "hdishd83djaidwnduwk28bcsb" }, "linux": { }, "log_directory": "/tmp" } EOF ``` Create the pod in gVisor: ```shell SANDBOX_ID=$(sudo crictl runp --runtime runsc sandbox.json) ``` Create the nginx container creation request: ```shell cat <<EOF | tee container.json { "metadata": { "name": "nginx" }, "image":{ "image": "nginx" }, "log_path":"nginx.0.log", "linux": { } } EOF ``` Create the nginx container: ```shell CONTAINERID=$(sudo crictl create ${SANDBOXID} container.json sandbox.json) ``` Start the nginx container: ```shell sudo crictl start ${CONTAINER_ID} ``` Inspect the created pod: ```shell sudo crictl inspectp ${SANDBOX_ID} ``` Inspect the nginx container: ```shell sudo crictl inspect ${CONTAINER_ID} ``` Verify that nginx is running in gVisor: ```shell sudo crictl exec ${CONTAINER_ID} dmesg | grep -i gvisor ``` Install the RuntimeClass for gVisor: ```shell cat <<EOF | kubectl apply -f - apiVersion: node.k8s.io/v1 kind: RuntimeClass metadata: name: gvisor handler: runsc EOF ``` Create a Pod with the gVisor RuntimeClass: ```shell cat <<EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: nginx-gvisor spec: runtimeClassName: gvisor containers: name: nginx image: nginx EOF ``` Verify that the Pod is running: ```shell kubectl get pod nginx-gvisor -o wide ``` This setup is already done for you on [GKE Sandbox]. It is an easy way to get started with gVisor. Before taking this deployment to production, review the .
Project: CubeFS (Runtime / Cloud Native Storage)
File: fish_completions.md

Cobra supports native Fish completions generated from the root `cobra.Command`. You can use the `command.GenFishCompletion()` or `command.GenFishCompletionFile()` functions. You must provide these functions with a parameter indicating if the completions should be annotated with a description; Cobra will provide the description automatically based on usage information. You can choose to make this option configurable by your users. Custom completions implemented using the `ValidArgsFunction` and `RegisterFlagCompletionFunc()` are supported automatically but the ones implemented in Bash scripting are not.
Project: Velero (Runtime / Cloud Native Storage)
File: support-matrix.md

title: "Supported Kubernetes Versions" layout: docs In general, Velero works on Kubernetes version 1.7 or later (when Custom Resource Definitions were introduced). Restic support requires Kubernetes version 1.10 or later, or an earlier version with the mount propagation feature enabled. See . Velero supports a variety of storage providers for different backup and snapshot operations. Velero has a plugin system which allows anyone to add compatibility for additional backup and volume storage platforms without modifying the Velero codebase. | Provider | Owner | Contact | ||-|| | | Velero Team | , | | | Velero Team | , | | | Velero Team | , | Velero uses to connect to the S3 API. Some third-party storage providers also support the S3 API, and users have reported the following providers work with Velero: Note that these providers are not regularly tested by the Velero team. * Ceph RADOS v12.2.7 * Quobyte * Some storage providers, like Quobyte, may need a different . | Provider | Owner | Contact | |-|--|| | | Velero Team | , | | | Velero Team | , | | | Velero Team | , | | | Velero Team | , | | | Portworx | , | | | StackPointCloud | | | | OpenEBS | , | | | AlibabaCloud | | | | HPE | , | To write a plugin for a new backup or volume storage system, take a look at the . After you publish your plugin, open a PR that adds your plugin to the appropriate list.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_fs.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> BPF filesystem mount ``` -h, --help help for fs ``` ``` --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 - Show bpf filesystem mount details
Project: Project Calico (Runtime / Cloud Native Network)
File: configuration-guide.md

The confd configuration file is written in and loaded from `/etc/confd/confd.toml` by default. You can specify the config file via the `-config-file` command line flag. Note: You can use confd without a configuration file. See . Optional: `backend` (string) - The backend to use. ("etcd") `client_cakeys` (string) - The client CA key file. `client_cert` (string) - The client cert file. `client_key` (string) - The client key file. `confdir` (string) - The path to confd configs. ("/etc/confd") `interval` (int) - The backend polling interval in seconds. (600) `log-level` (string) - level which confd should log messages ("info") `nodes` (array of strings) - List of backend nodes. (["http://127.0.0.1:4001"]) `noop` (bool) - Enable noop mode. Process all template resources; skip target update. `prefix` (string) - The string to prefix to keys. ("/") `scheme` (string) - The backend URI scheme. ("http" or "https") `srv_domain` (string) - The name of the resource record. `srv_record` (string) - The SRV record to search for backends nodes. `sync-only` (bool) - sync without checkcmd and reloadcmd. `watch` (bool) - Enable watch support. Example: ```TOML backend = "etcd" client_cert = "/etc/confd/ssl/client.crt" client_key = "/etc/confd/ssl/client.key" confdir = "/etc/confd" log-level = "debug" interval = 600 nodes = [ "http://127.0.0.1:4001", ] noop = false prefix = "/production" scheme = "https" srv_domain = "etcd.example.com" ```
Project: OpenEBS (Runtime / Cloud Native Storage)
File: CONTRIBUTING-TO-DEVELOPER-DOC.md

This document describes the process for improving developer documentation by creating PRs at OpenEBS. Developer documentation is available under the folder: The developer documentation includes anything that will help the community like: Architecture and Design documentation Technical or Research Notes FAQ Process Documentation Generic / Miscellaneous Notes We are also looking for an explainer video or presentation from the community that helps new developers in understanding the OpenEBS Architecture, it's use cases, and installation procedure locally. At a very high level, the process to contributing and improving the code is pretty simple: Submit an issue describing your proposed change Create your development branch Commit your changes Submit your Pull Request The following sections describe some guidelines that can come in handy with the above process. Followed by the guidelines, is a with frequently used git commands. Some general guidelines when submitting issues for developer documentation: If the proposed change requires an update to the existing page, please provide a link to the page in the issue. If you want to add a new page, then go ahead and open an issue describing the requirement for the new page. You can also help with some existing issues under this category available at Fork the repository and if you have forked it already, rebase with master branch to fetch latest changes to your local system. Create a new development branch in your forked repository with the following naming convention: "task description-#issue" Example: This change is being developed with the branch named: OpenEBS-DevDoc-PR-Workflow-#213 Reference the issue number along with a brief description in your commits Set your commit.template to the `COMMIT_TEMPLATE` given in the `.github` directory. `git config --local commit.template $GOPATH/src/github.com/openebs/openebs/.github` Rebase your development branch Submit the PR from the development branch to the openebs/openebs:master Incorporate review comments, if any, in the development branch. Once the PR is accepted, close the branch. After the PR is merged the development branch in the forked repository can be deleted. If you need any help with git, refer to this and go back to the guide to proceed.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_identity_get.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Retrieve information about an identity ``` cilium-dbg identity get [flags] ``` ``` -h, --help help for get --label strings Label to lookup -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 security identities
Project: runc (Runtime / Container Runtime)
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, education, socio-economic status, 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 Dan Buch at dan@meatballhat.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and 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 https://www.contributor-covenant.org/version/1/4/code-of-conduct.html