cwielenb/CNCF-Dataset huggingface dataset:
Project: rkt (Runtime / Container Runtime)
File: app-environment.md

Apps launched by rkt have access to some basic devices and file systems as defined by the App Container spec in the section. In addition to the basic devices and file systems mandated by the App Container spec, rkt gives access to the following files. Support for /etc/hosts is optional in the App Container spec. rkt creates it. `/etc/resolv.conf` is automatically . Since rkt v1.2.0, rkt gives access to systemd-journald's sockets in the /run/systemd/journal directory: /run/systemd/journal/dev-log /run/systemd/journal/socket /run/systemd/journal/stdout Since rkt v1.2.0, if /dev/log does not exist in the image, it will be created as a symlink to /run/systemd/journal/dev-log.
Project: Spiderpool (Runtime / Cloud Native Network)
File: kubevirt.md

| Case ID | Title | Priority | Smoke | Status | Other | ||-|-|-|--|-| | F00001 | Succeed to keep static IP for kubevirt VM/VMI after restarting the VM/VMI pod | P1 | | done | | | F00002 | Succeed to keep static IP for the kubevirt VM live migration | P1 | | done | | | F00003 | Succeed to allocate multiple NICs | P1 | | done | |
Project: JuiceFS (Runtime / Cloud Native Storage)
File: benchmark.md

title: Performance Benchmark sidebar_position: 1 slug: . description: This article describes benchmarking the file system using FIO, mdtest, and the bench command that comes with JuiceFS. Redis is used as Metadata Engine in this benchmark. Under this test condition, JuiceFS performs 10x better than and . JuiceFS provides a subcommand `bench` to run a few basic benchmarks to evaluate how it works in your environment: Performed sequential read/write benchmarks on JuiceFS, and by . Here is the result: ](../images/sequential-read-write-benchmark.svg) It shows JuiceFS can provide 10X more throughput than the other two. Read . Performed a simple benchmark on JuiceFS, and by . Here is the result: ](../images/metadata-benchmark.svg) It shows JuiceFS can provide significantly more metadata IOPS than the other two. Read . See if you encounter performance issues.
Project: Longhorn (Runtime / Cloud Native Storage)
File: 20230116-smb-cifs-backup-store-support.md

Longhorn supports SMB/CIFS share as a backup storage. https://github.com/longhorn/longhorn/issues/3599 Support SMB/CIFS share as a backup storage. Introduce SMB/CIFS client for supporting SMB/CIFS as a backup storage. Longhorn already supports NFSv4 and S3 servers as backup storage. However, certain users may encounter compatibility issues with their backup servers, particularly those running on Windows, as the protocols for NFSv4 and S3 are not always supported. To address this issue, the enhancement will enhance support for backup storage options with a focus on the commonly used SMB/CIFS protocol, which is compatible with both Linux and Windows-based servers. Check each Longhorn node's kernel supports the CIFS filesystem by ``` cat /boot/config-`uname -r` | grep CONFIG_CIFS ``` Install the CIFS filesystem user-space tools `cifs-utils` on each Longhorn node Users can configure a SMB/CIFS share as a backup storage Set Backup Target. The path to a SMB/CIFS share is like ```bash cifs://${IP address}/${share name} ``` Set Backup Target Credential Secret Create a secret and deploy it ```yaml apiVersion: v1 kind: Secret metadata: name: cifs-secret namespace: longhorn-system type: Opaque data: CIFSUSERNAME: ${CIFSUSERNAME} CIFSPASSWORD: ${CIFSPASSWORD} ``` Set the setting Backup Target Credential Secret to `cifs-secret` longhorn-manager Introduce the fields `CIFSUSERNAME` and `CIFSPASSWORD` in credentials. The two fields are passed to engine and replica processes for volume backup and restore operations. backupstore Implement SMB/CIFS register/unregister and mount/unmount functions Set a SMB/CIFS share as backup storage. Back up volumes to the backup storage and the operation should succeed. Restore backups and the operation should succeed.
Project: Carina (Runtime / Cloud Native Storage)
File: FAQ.md

What are the main conponents of Carina and their resposibility? Carina has three main components: carina-schedulercarina-controllercarina-node. User can get detailed runtime information by checking each components' logs. carina-schedulerall pods using PVC backed by Carina will be scheduled by carina-scheduler. carina-controllerWatching the events of PVC and creates LogicVolume internally. carina-nodeManaging local disks and watching events of LogicVolume and create local LVM or raw volumes. Known issue, PV creation may fail if the local disks' performance is really poor. Carina will try to create LVM volume every ten seconds. The creation will be failed if retries 10 times. User can learn more details by using `kubectl get lv`. Once the PV has been created successfully, can the Pod migrate to other nodes. For typical local volume solutions, if node failes, the pod using local disks can't migrate to other nodes. But Carina can detect the node status and let pod migrate. The newly-borned Pod will have an empty carina volume however. How to run a pod using an specified PV on one of the nodes? using `spec.nodeName` to bypass the scheduler. For StorageClass with `WaitForFirstConsumer`, user can add one annotation `volume.kubernetes.io/selected-node: ${nodeName}` to PVC and then the pod will be scheduled to specified node. This is not recommanded unless knowning the machanisums very clearly. How to deal with the PVs if it's node been deleted from K8S cluster? Just delete the PVC and rebuild. How to create local disks for testing usage? user can create loop device if there are not enough physical disks. ```shell for i in $(seq 1 5); do truncate --size=200G /tmp/disk$i.device && \ losetup -f /tmp/disk$i.device done ``` How to simulate local SSD disks? ```shell $ echo 0 > /sys/block/loop0/queue/rotational $ lsblk -d -o name,rota NAME ROTA loop1 1 loop0 0 ``` About bcache of each node. bcache is an kernel module. Some the Linux distributions may not enable bcache, you can disable carina's bcache suppport by below methods. ```shell $ modprobe bcache $ lsmod | grep bcache bcache 233472 0 crc64 16384 1 bcache name: host-bcache mountPath: /sys/fs/bcache name: host-bcache hostPath: path: /sys/fs/bcache ``` Enjoy Carina!
Project: Velero (Runtime / Cloud Native Storage)
File: ark_completion.md

title: "ark completion" layout: docs Output shell completion code for the specified shell (bash or zsh) Generate shell completion code. Auto completion supports both bash and zsh. Output is to STDOUT. Load the ark completion code for bash into the current shell - source <(ark completion bash) Load the ark completion code for zsh into the current shell - source <(ark completion zsh) ``` ark completion SHELL [flags] ``` ``` -h, --help help for completion ``` ``` --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.
Project: Velero (Runtime / Cloud Native Storage)
File: velero-install.md

title: "Velero Install CLI" layout: docs This document serves as a guide to using the `velero install` CLI command to install `velero` server components into your kubernetes cluster. NOTE: `velero install` will, by default, use the CLI's version information to determine the version of the server components to deploy. This behavior may be overridden by using the `--image` flag. Refer to . This section explains some of the basic flags supported by the `velero install` CLI command. For a complete explanation of the flags, please run `velero install --help` ```bash velero install \ --plugins <PLUGINCONTAINERIMAGE [PLUGINCONTAINERIMAGE]> --provider <YOUR_PROVIDER> \ --bucket <YOUR_BUCKET> \ --secret-file <PATHTOFILE> \ --velero-pod-cpu-request <CPU_REQUEST> \ --velero-pod-mem-request <MEMORY_REQUEST> \ --velero-pod-cpu-limit <CPU_LIMIT> \ --velero-pod-mem-limit <MEMORY_LIMIT> \ [--use-restic] \ [--default-volumes-to-restic] \ [--restic-pod-cpu-request <CPU_REQUEST>] \ [--restic-pod-mem-request <MEMORY_REQUEST>] \ [--restic-pod-cpu-limit <CPU_LIMIT>] \ [--restic-pod-mem-limit <MEMORY_LIMIT>] ``` The values for the resource requests and limits flags follow the same format as For plugin container images, please refer to our page. This section provides examples that serve as a starting point for more customized installations. ```bash velero install --provider gcp --plugins velero/velero-plugin-for-gcp:v1.0.0 --bucket mybucket --secret-file ./gcp-service-account.json velero install --provider aws --plugins velero/velero-plugin-for-aws:v1.0.0 --bucket backups --secret-file ./aws-iam-creds --backup-location-config region=us-east-2 --snapshot-location-config region=us-east-2 --use-restic velero install --provider azure --plugins velero/velero-plugin-for-microsoft-azure:v1.0.0 --bucket $BLOBCONTAINER --secret-file ./credentials-velero --backup-location-config resourceGroup=$AZUREBACKUPRESOURCEGROUP,storageAccount=$AZURESTORAGEACCOUNTID[,subscriptionId=$AZUREBACKUPSUBSCRIPTIONID] --snapshot-location-config apiTimeout=<YOURTIMEOUT>[,resourceGroup=$AZUREBACKUPRESOURCEGROUP,subscriptionId=$AZUREBACKUPSUBSCRIPTION_ID] ```
Project: Velero (Runtime / Cloud Native Storage)
File: website-guidelines.md

title: "Website Guidelines" layout: docs When making changes to the website, please run the site locally before submitting a PR and manually verify your changes. At the root of the project, run: ```bash make serve-docs ``` This runs all the Hugo dependencies in a container. Alternatively, for quickly loading the website, under the `velero/site/` directory run: ```bash hugo serve ``` For more information on how to run the website locally, please see our . To add a blog post, create a new markdown (.MD) file in the `/site/content/posts/` folder. A blog post requires the following front matter. ```yaml title: "Title of the blog" excerpt: Brief summary of thee blog post that appears as a preview on velero.io/blogs author_name: Jane Smith slug: URL-For-Blog categories: ['velero','release'] image: /img/posts/example-image.jpg tags: ['Velero Team', 'Nolan Brubaker'] ``` Include the `author_name` value in tags field so the page that lists the author's posts will work properly, for example https://velero.io/tags/carlisia-thompson/. Ideally each blog will have a unique image to use on the blog home page, but if you do not include an image, the default Velero logo will be used instead. Use an image that is less than 70KB and add it to the `/site/static/img/posts` folder.
Project: Velero (Runtime / Cloud Native Storage)
File: upgrade-to-1.6.md

title: "Upgrading to Velero 1.6" layout: docs Velero installed. If you're not yet running at least Velero v1.5, see the following: Before upgrading, check the to make sure your version of Kubernetes is supported by the new version of Velero. Install the Velero v1.6 command-line interface (CLI) by following the . Verify that you've properly installed it by running: ```bash velero version --client-only ``` You should see the following output: ```bash Client: Version: v1.6.2 Git commit: <git SHA> ``` Update the Velero custom resource definitions (CRDs) to include schema changes across all CRDs that are at the core of the new features in this release: ```bash velero install --crds-only --dry-run -o yaml | kubectl apply -f - ``` NOTE: If you are upgrading Velero in Kubernetes 1.14.x or earlier, you will need to use `kubectl apply`'s `--validate=false` option when applying the CRD configuration above. See and for more context. Update the container image used by the Velero deployment and, optionally, the restic daemon set: ```bash kubectl set image deployment/velero \ velero=velero/velero:v1.6.2 \ --namespace velero kubectl set image daemonset/restic \ restic=velero/velero:v1.6.2 \ --namespace velero ``` Confirm that the deployment is up and running with the correct version by running: ```bash velero version ``` You should see the following output: ```bash Client: Version: v1.6.2 Git commit: <git SHA> Server: Version: v1.6.2 ``` We have deprecated the way to indicate the default backup storage location. Previously, that was indicated according to the backup storage location name set on the velero server-side via the flag `velero server --default-backup-storage-location`. Now we configure the default backup storage location on the velero client-side. Please refer to the on how to indicate which backup storage location is the default one. After upgrading, if there is a previously created backup storage location with the name that matches what was defined on the server side as the default, it will be automatically set as the `default`.
Project: runc (Runtime / Container Runtime)
File: runc-delete.8.md

% runc-delete "8" runc-delete - delete any resources held by the container runc delete [--force|-f] container-id --force|-f : Forcibly delete the running container, using SIGKILL signal(7) to stop it first. If the container id is ubuntu01 and runc list currently shows its status as stopped, the following will delete resources held for ubuntu01, removing it from the runc list: runc-kill(8), runc(8).
Project: Weave Net (Runtime / Cloud Native Network)
File: ISSUE_TEMPLATE.md

What version of Go are you running? (Paste the output of `go version`) What version of gorilla/mux are you at? (Paste the output of `git rev-parse HEAD` inside `$GOPATH/src/github.com/gorilla/mux`) Describe your problem (and what you have tried so far) Paste a minimal, runnable, reproduction of your issue below (use backticks to format it)
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-agent_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-agent for the specified shell. See each sub-command's help for details on how to use the generated script. ``` -h, --help help for completion ``` - Run the cilium agent - 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: Rook (Runtime / Cloud Native Storage)
File: design_template.md

title: feature-name target-version: release-X.X List the specific goals of the proposal. How will we know that this has succeeded? What is out of scope for this proposal? Listing non-goals helps to focus discussion and make progress. This is where we get down to the nitty gritty of what the proposal actually is. API changed in any, Golang snippets. What are the risks of this proposal and how do we mitigate. Think broadly. For example, consider both security and how this will impact the larger OKD ecosystem. The idea is to find the best form of an argument why this feature should not be implemented. Similar to the `Drawbacks` section the `Alternatives` section is used to highlight and record other possible approaches to delivering the value proposed by a feature. This is where to call out areas of the design that require closure before deciding to implement the design.
Project: Antrea (Runtime / Cloud Native Network)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: kind/bug assignees: '' Describe the bug <!-- A clear and concise description of what the bug is. If you believe this bug is a security issue, please don't use this template and follow our --> To Reproduce <!-- Steps to reproduce the behavior. --> Expected <!-- A clear and concise description of what you expected to happen. --> Actual behavior <!-- A clear and concise description of what's the actual behavior. If applicable, add screenshots, log messages, etc. to help explain the problem. --> Versions: <!-- Please provide the following information: Antrea version (Docker image tag). Kubernetes version (use `kubectl version`). If your Kubernetes components have , please provide the version for all of them. Container runtime: which runtime are you using (e.g. containerd, cri-o, docker) and which version are you using? Linux kernel version on the Kubernetes Nodes (`uname -r`). If you chose to compile the Open vSwitch kernel module manually instead of using the kernel module built into the Linux kernel, which version of the OVS kernel module are you using? Include the output of `modinfo openvswitch` for the Kubernetes Nodes. --> Additional context <!-- Add any other context about the problem here, such as Antrea logs, kubelet logs, etc. --> <!-- (Please consider pasting long output into a or any other pastebin.) -->
Project: Firecracker (Runtime / Container Runtime)
File: DISCLAIMER.md

Please keep this document in mind when using these guest kernel configuration files. Firecracker as a virtual machine monitor is designed and built for use with specific goals, so these kernel configurations are tuned to be secure and to use the host's resources as optimally as possible, specifically allowing for as many guests to be running concurrently as possible (high density). For example, one of the mechanisms to improve density is to reduce virtual memory areas of the guest. This decreases the page table size and improves available memory on the host for other guests to occupy. As Firecracker is intended for ephemeral compute (short-lived environments, not intended to run indefinitely), a Firecracker guest is not expected to require large memory sizes. One interesting use-case where this can be seen to cause odd side affects is one where golang's race detector for aarch64 expected a 48-bit space, but the guest's kernel config enforced 39-bit. See .
Project: Longhorn (Runtime / Cloud Native Storage)
File: app-readme.md

Longhorn is a lightweight, reliable and easy to use distributed block storage system for Kubernetes. Once deployed, users can leverage persistent volumes provided by Longhorn. Longhorn creates a dedicated storage controller for each volume and synchronously replicates the volume across multiple replicas stored on multiple nodes. The storage controller and replicas are themselves orchestrated using Kubernetes. Longhorn supports snapshots, backups and even allows you to schedule recurring snapshots and backups! Important: Please install Longhorn chart in `longhorn-system` namespace only. Warning: Longhorn doesn't support downgrading from a higher version to a lower version.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_nodeid.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List node IDs and associated information ``` -h, --help help for nodeid ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI - List node IDs and the associated IP addresses
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-generic_completion_bash.md

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> Generate the autocompletion script for bash Generate the autocompletion script for the bash shell. This script depends on the 'bash-completion' package. If it is not installed already, you can install it via your OS's package manager. To load completions in your current shell session: source <(cilium-operator-generic completion bash) To load completions for every new session, execute once: cilium-operator-generic completion bash > /etc/bash_completion.d/cilium-operator-generic cilium-operator-generic completion bash > $(brew --prefix)/etc/bash_completion.d/cilium-operator-generic You will need to start a new shell for this setup to take effect. ``` cilium-operator-generic completion bash ``` ``` -h, --help help for bash --no-descriptions disable completion descriptions ``` - Generate the autocompletion script for the specified shell
Project: Container Network Interface (CNI) (Runtime / Cloud Native Network)
File: README.md

This plugin aims to help debugging or troubleshooting in CNI plugin development. ``` { "cniVersion": "0.3.1", "name": "mynet", "plugins": [ { "type": "ptp", "ipMasq": true, "ipam": { "type": "host-local", "subnet": "172.16.30.0/24", "routes": [ { "dst": "0.0.0.0/0" } ] } }, { "type": "debug", "cniOutput": "/tmp/cni_output.txt", "addHooks": [ [ "sh", "-c", "ip link set $CNI_IFNAME promisc on" ] ] }, { "type": "portmap", "capabilities": {"portMappings": true}, "externalSetMarkChain": "KUBE-MARK-MASQ" } ] } ``` `cniOutput` (string, optional): output CNI request into file. `addHooks` (string array, optional): commands executed in container network namespace at interface add. (note: but just execute it and does not catch command failure) `delHooks` (string array, optional): commands executed in container network namespace at interface delete. (note: but just execute it and does not catch command failure) `checkHooks` (string array, optional): commands executed in container network namespace at interface check. (note: but just execute it and does not catch command failure) ``` CmdAdd ContainerID: cnitool-20c433bb2b1d6ede56d6 Netns: /var/run/netns/cnitest IfName: eth0 Args: Path: /opt/cni/bin StdinData: {"cniOutput":"/tmp/cni_output.txt","cniVersion":"0.3.1","name":"test","prevResult":{"cniVersion":"0.3.1","interfaces":[{"name":"veth92e295cc","mac":"56:22:7f:b7:5b:75"},{"name":"eth0","mac":"46:b3:f3:77:bf:21","sandbox":"/var/run/netns/cnitest"}],"ips":[{"version":"4","interface":1,"address":"10.1.1.2/24","gateway":"10.1.1.1"}],"dns":{"nameservers":["10.64.255.25","8.8.8.8"]}},"type":"none"} CmdDel ContainerID: cnitool-20c433bb2b1d6ede56d6 Netns: /var/run/netns/cnitest IfName: eth0 Args: Path: /opt/cni/bin StdinData: {"cniOutput":"/tmp/cni_output.txt","cniVersion":"0.3.1","name":"test","type":"none"} ```