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

(devices-infiniband)= ```{note} The `infiniband` device type is supported for both containers and VMs. It supports hotplugging only for containers, not for VMs. ``` Incus supports two different kinds of network types for InfiniBand devices: `physical`: Passes a physical device from the host through to the instance. The targeted device will vanish from the host and appear in the instance. `sriov`: Passes a virtual function of an SR-IOV-enabled physical network device into the instance. ```{note} InfiniBand devices support SR-IOV, but in contrast to other SR-IOV-enabled devices, InfiniBand does not support dynamic device creation in SR-IOV mode. Therefore, you must pre-configure the number of virtual functions by configuring the corresponding kernel module. ``` To create a `physical` `infiniband` device, use the following command: incus config device add <instancename> <devicename> infiniband nictype=physical parent=<device> To create an `sriov` `infiniband` device, use the following command: incus config device add <instancename> <devicename> infiniband nictype=sriov parent=<sriovenableddevice> `infiniband` devices have the following device options: Key | Type | Default | Required | Description :-- | :-- | :-- | :-- | :-- `hwaddr` | string | randomly assigned | no | The MAC address of the new interface (can be either the full 20-byte variant or the short 8-byte variant, which will only modify the last 8 bytes of the parent device) `mtu` | integer | parent MTU | no | The MTU of the new interface `name` | string | kernel assigned | no | The name of the interface inside the instance `nictype` | string | - | yes | The device type (one of `physical` or `sriov`) `parent` | string | - | yes | The name of the host device or bridge
Project: lxd (Runtime / Container Runtime)
File: images_copy.md

(images-copy)= To add images to an image store, you can either copy them from another server or import them from files (either local files or files on a web server). To copy an image from one server to another, enter the following command: incus image copy [<sourceremote>:]<image> <targetremote>: ```{note} To copy the image to your local image store, specify `local:` as the target remote. ``` See for a list of all available flags. The most relevant ones are: `--alias` : Assign an alias to the copy of the image. `--copy-aliases` : Copy the aliases that the source image has. `--auto-update` : Keep the copy up-to-date with the original image. `--vm` : When copying from an alias, copy the image that can be used to create virtual machines. If you have image files that use the required {ref}`image-format`, you can import them into your image store. There are several ways of obtaining such image files: Exporting an existing image (see {ref}`images-manage-export`) Building your own image using `distrobuilder` (see {ref}`images-create-build`) Downloading image files from a {ref}`remote image server <image-servers>` (note that it is usually easier to {ref}`use the remote image <images-remote>` directly instead of downloading it to a file and importing it) To import an image from the local file system, use the command. This command supports both {ref}`unified images <image-format-unified>` (compressed file or directory) and {ref}`split images <image-format-split>` (two files). To import a unified image from one file or directory, enter the following command: incus image import <imagefileordirectorypath> [<target_remote>:] To import a split image, enter the following command: incus image import <metadatatarballpath> <rootfstarballpath> [<target_remote>:] In both cases, you can assign an alias with the `--alias` flag. See for all available flags. You can import image files from a remote web server by URL. This method is an alternative to running an Incus server for the sole purpose of distributing an image to users. It only requires a basic web server with support for custom headers (see {ref}`images-copy-http-headers`). The image files must be provided as unified images (see {ref}`image-format-unified`). To import an image file from a remote web server, enter the following command: incus image import <URL> You can assign an alias to the local image with the `--alias` flag. (images-copy-http-headers)= Incus requires the following custom HTTP headers to be set by the web server: `Incus-Image-Hash` : The SHA256 of the image that is being downloaded. `Incus-Image-URL` : The URL from which to download the image. Incus sets the following headers when querying the server: `Incus-Server-Architectures` : A comma-separated list of architectures that the client supports. `Incus-Server-Version` : The version of Incus in use.
Project: OpenEBS (Runtime / Cloud Native Storage)
File: feature-request.md

name: Feature Request about: Suggest an idea for this project <!-- Make sure to include as much information as possible so we can add it as quickly as possible. --> <!-- If you know how to add this feature, please open a pull request on https://github.com/openebs/openebs/compare/?template=features.md --> <!-- If you can't answer some sections, please delete them --> <!-- Provide a description of this change or addition --> <!-- Why is this change important to you? How would you use it? How can it benefit other users? --> <!-- Suggest an idea for implementing this change or addition --> <!-- Add optional screenshots of this change or addition -->
Project: Piraeus Datastore (Runtime / Cloud Native Storage)
File: install-kernel-headers.md

Piraeus Datastore uses to mirror your volume data to one or more nodes. This document aims to describe the way to install the necessary files for common Linux distributions. To check if your nodes already have the necessary files installed, try running: ``` $ test -d /lib/modules/$(uname -r)/build/ && echo found headers ``` If the command prints `found headers`, your nodes are good to go. Installation of Linux Kernel headers on Ubuntu can be done through the `apt` package manager: ``` $ sudo apt-get update $ sudo apt-get install -y linux-headers-$(uname -r) ``` In addition, you can install the `linux-headers-virtual` package. This causes `apt upgrade` to install the headers matching any newly installed kernel versions. ``` $ sudo apt-get update $ sudo apt-get install -y linux-headers-virtual ``` Installation of Linux Kernel headers on Debian can be done through the `apt` package manager: ``` $ sudo apt-get update $ sudo apt-get install -y linux-headers-$(uname -r) ``` In addition, you can install an additional package, that causes `apt` to also install Kernel headers on upgrade: ``` $ sudo apt-get update $ sudo apt-get install -y linux-headers-$(dpkg --print-architecture) ``` Installing on RedHat Enterprise Linux or compatible distributions, such as AlmaLinux or Rocky Linux can be done through the `dnf` package manager: ``` $ sudo dnf install -y kernel-devel-$(uname -r) ``` In addition, you can install an additional package, that causes `yum` to also install Kernel headers on upgrade: ``` $ sudo dnf install -y kernel-devel ```
Project: Velero (Runtime / Cloud Native Storage)
File: ark_restore_logs.md

title: "ark restore logs" layout: docs Get restore logs Get restore logs ``` ark restore logs RESTORE [flags] ``` ``` -h, --help help for logs --timeout duration how long to wait to receive logs (default 1m0s) ``` ``` --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 ``` - Work with restores
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_vtep_delete.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Delete vtep entries Delete vtep entries using vtep CIDR. ``` cilium-dbg bpf vtep delete [flags] ``` ``` -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 the VTEP mappings for IP/CIDR <-> VTEP MAC/IP
Project: lxd (Runtime / Container Runtime)
File: storage.md

(storage)= ```{toctree} :maxdepth: 1 About storage </explanation/storage> Manage pools <howto/storage_pools> Create an instance in a pool <howto/storagecreateinstance> Manage volumes <howto/storage_volumes> Move or copy a volume <howto/storagemovevolume> Back up a volume <howto/storagebackupvolume> Manage buckets <howto/storage_buckets> reference/storage_drivers ```
Project: Submariner (Runtime / Cloud Native Network)
File: committership.md

name: Submariner Committer Request about: Request Submariner Committer rights on some files title: 'REQUEST: New Committer rights request for <your-GH-handle>' labels: committer-request assignees: '' e.g. (at)example_user e.g. submariner-operator/\ or submariner-operator/scripts/\ [ ] I have reviewed the contributor roles guidelines (https://submariner.io/community/contributor-roles/) [ ] I have enabled 2FA on my GitHub account (https://github.com/settings/security) [ ] I have subscribed to the submariner-dev e-mail list (https://groups.google.com/forum/#!forum/submariner-dev) [ ] I have been actively contributing to Submariner for at least 3 months [ ] I have two sponsors that meet the sponsor requirements listed in the community membership guidelines [ ] I have spoken to my sponsors ahead of this application, and they have agreed to sponsor my application (at)sponsor-1 (at)sponsor-2 At least 20 PRs to the relevant codebase that you reviewed, and at least 5 for which you were the primary reviewer `https://github.com/submariner-io/<repo>/pulls?q=is%3Apr+reviewed-by%3A<your-GH-handle>+-author%3A<your-GH-handle>`
Project: Velero (Runtime / Cloud Native Storage)
File: ark_backup_create.md

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

English Spiderpool supports the configuration of routing information for Pods. When setting the gateway address (`spec.gateway`) for a SpiderIPPool resource, a default route will be generated for Pods based on that gateway address: ```yaml apiVersion: spiderpool.spidernet.io/v2beta1 kind: SpiderIPPool metadata: name: ipv4-ippool-route spec: subnet: 172.18.41.0/24 ips: 172.18.41.51-172.18.41.60 gateway: 172.18.41.0 ``` SpiderIPPool resources also support configuring routes (`spec.routes`), which will be inherited by Pods during their creation process: If a gateway address is configured for the SpiderIPPool resource, avoid setting default routes in the routes field. Both `dst` and `gw` fields are required. ```yaml apiVersion: spiderpool.spidernet.io/v2beta1 kind: SpiderIPPool metadata: name: ipv4-ippool-route spec: subnet: 172.18.41.0/24 ips: 172.18.41.51-172.18.41.60 gateway: 172.18.41.0 routes: dst: 172.18.42.0/24 gw: 172.18.41.1 ``` You can customize routes for Pods by adding the annotation `ipam.spidernet.io/routes`: When a gateway address or default route is configured in the SpiderIPPool resource, avoid configuring default routes for Pods. Both `dst` and `gw` fields are required. ```yaml ipam.spidernet.io/routes: |- [{ "dst": "10.0.0.0/16", "gw": "192.168.1.1" },{ "dst": "172.10.40.0/24", "gw": "172.18.40.1" }] ```
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-azure_completion.md

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> Generate the autocompletion script for the specified shell Generate the autocompletion script for cilium-operator-azure 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 cilium-operator-azure - 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: Cilium (Runtime / Cloud Native Network)
File: pull_request_template.md

Please ensure your pull request adheres to the following guidelines: [ ] All code is covered by unit and/or runtime tests where feasible. [ ] All commits contain a well written commit description including a title, description and a `Fixes: #XXX` line if the commit addresses a particular GitHub issue. [ ] If your commit description contains a `Fixes: <commit-id>` tag, then please add the commit author[s] as reviewer[s] to this issue. [ ] Provide a title or release-note blurb suitable for the release notes. [ ] Thanks for contributing! <!-- Description of change --> Fixes: #issue-number ```release-note <!-- Enter the release note text here if needed or remove this section! --> ```
Project: lxd (Runtime / Container Runtime)
File: server_config.md

(server)= The Incus server can be configured through a set of key/value configuration options. The key/value configuration is namespaced. The following options are available: {ref}`server-options-core` {ref}`server-options-acme` {ref}`server-options-cluster` {ref}`server-options-images` {ref}`server-options-loki` {ref}`server-options-misc` {ref}`server-options-oidc` {ref}`server-options-openfga` See {ref}`server-configure` for instructions on how to set the configuration options. ```{note} Options marked with a `global` scope are immediately applied to all cluster members. Options with a `local` scope must be set on a per-member basis. ``` (server-options-core)= The following server options control the core daemon configuration: % Include content from ```{include} config_options.txt :start-after: <!-- config group server-core start --> :end-before: <!-- config group server-core end --> ``` (server-options-acme)= The following server options control the {ref}`ACME <authentication-server-certificate>` configuration: % Include content from ```{include} config_options.txt :start-after: <!-- config group server-acme start --> :end-before: <!-- config group server-acme end --> ``` (server-options-oidc)= The following server options configure external user authentication through {ref}`authentication-openid`: % Include content from ```{include} config_options.txt :start-after: <!-- config group server-oidc start --> :end-before: <!-- config group server-oidc end --> ``` (server-options-openfga)= The following server options configure external user authorization through {ref}`authorization-openfga`: % Include content from ```{include} config_options.txt :start-after: <!-- config group server-openfga start --> :end-before: <!-- config group server-openfga end --> ``` (server-options-cluster)= The following server options control {ref}`clustering`: % Include content from ```{include} config_options.txt :start-after: <!-- config group server-cluster start --> :end-before: <!-- config group server-cluster end --> ``` (server-options-images)= The following server options configure how to handle {ref}`images`: % Include content from ```{include} config_options.txt :start-after: <!-- config group server-images start --> :end-before: <!-- config group server-images end --> ``` (server-options-loki)= The following server options configure the external log aggregation system: % Include content from ```{include} config_options.txt :start-after: <!-- config group server-loki start --> :end-before: <!-- config group server-loki end --> ``` (server-options-misc)= The following server options configure server-specific settings for {ref}`instances`, {ref}`OVN <network-ovn>` integration, {ref}`Backups <backups>` and {ref}`storage`: % Include content from ```{include} config_options.txt :start-after: <!-- config group server-miscellaneous start --> :end-before: <!-- config group server-miscellaneous end --> ```
Project: CubeFS (Runtime / Cloud Native Storage)
File: CONTRIBUTING.md

We definitely welcome your patches and contributions to gRPC! Please read the gRPC organization's and before proceeding. If you are new to github, please start by reading In order to protect both you and ourselves, you will need to sign the . How to get your contributions merged smoothly and quickly. Create small PRs that are narrowly focused on addressing a single concern. We often times receive PRs that are trying to fix several things at a time, but only one fix is considered acceptable, nothing gets merged and both author's & review's time is wasted. Create more PRs to address different concerns and everyone will be happy. The grpc package should only depend on standard Go packages and a small number of exceptions. If your contribution introduces new dependencies which are NOT in the , you need a discussion with gRPC-Go authors and consultants. For speculative changes, consider opening an issue and discussing it first. If you are suggesting a behavioral or API change, consider starting with a [gRFC proposal](https://github.com/grpc/proposal). Provide a good PR description as a record of what change is being made and why it was made. Link to a github issue if it exists. Don't fix code style and formatting unless you are already changing that line to address an issue. PRs with irrelevant changes won't be merged. If you do want to fix formatting or style, do that in a separate PR. Unless your PR is trivial, you should expect there will be reviewer comments that you'll need to address before merging. We expect you to be reasonably responsive to those comments, otherwise the PR will be closed after 2-3 weeks of inactivity. Maintain clean commit history and use meaningful commit messages. PRs with messy commit history are difficult to review and won't be merged. Use `rebase -i upstream/master` to curate your commit history and/or to bring in latest changes from master (but avoid rebasing in the middle of a code review). Keep your PR up to date with upstream/master (if there are merge conflicts, we can't really merge your change). All tests need to be passing before your change can be merged. We recommend you run tests locally before creating your PR to catch breakages early on. `make all` to test everything, OR `make vet` to catch vet errors `make test` to run the tests `make testrace` to run tests in race mode Exceptions to the rules can be made if there's a compelling reason for doing so.
Project: Rook (Runtime / Cloud Native Storage)
File: ceph-csi-volume-clone.md

title: Volume clone The CSI Volume Cloning feature adds support for specifying existing PVCs in the `dataSource` field to indicate a user would like to clone a Volume. A Clone is defined as a duplicate of an existing Kubernetes Volume that can be consumed as any standard Volume would be. The only difference is that upon provisioning, rather than creating a "new" empty Volume, the back end device creates an exact duplicate of the specified Volume. Refer to for more info. In , `dataSource` should be the name of the `PVC` which is already created by RBD CSI driver. The `dataSource` kind should be the `PersistentVolumeClaim`. The `storageClassName` can be any RBD storageclass (not necessarily same as Parent PVC) Please note: `provisioner` must be the same for both the Parent PVC and the Clone PVC. The non-encrypted PVC cannot be cloned to an encrypted one and vice-versa. encrypted -> encrypted (possible) non-encrypted -> non-encrypted (possible) encrypted -> non-encrypted (not possible) non-encrypted -> encrypted (not possible) Create a new PVC Clone from the PVC ```console kubectl create -f deploy/examples/csi/rbd/pvc-clone.yaml ``` ```console kubectl get pvc ``` ```console NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE rbd-pvc Bound pvc-74734901-577a-11e9-b34f-525400581048 1Gi RWO rook-ceph-block 34m rbd-pvc-clone Bound pvc-70473135-577f-11e9-b34f-525400581048 1Gi RWO rook-ceph-block 8s ``` To clean your cluster of the resources created by this example, run the following: ```console kubectl delete -f deploy/examples/csi/rbd/pvc-clone.yaml ``` Requires Kubernetes v1.16+ which supports volume clone. Ceph-csi diver v3.1.0+ which supports volume clone. In , `dataSource` should be the name of the `PVC` which is already created by CephFS CSI driver. The `dataSource` kind should be the `PersistentVolumeClaim` and also storageclass should be same as the source `PVC`. Create a new PVC Clone from the PVC ```console kubectl create -f deploy/examples/csi/cephfs/pvc-clone.yaml ``` ```console kubectl get pvc ``` ```console NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE cephfs-pvc Bound pvc-1ea51547-a88b-4ab0-8b4a-812caeaf025d 1Gi RWX rook-cephfs 39m cephfs-pvc-clone Bound pvc-b575bc35-d521-4c41-b4f9-1d733cd28fdf 1Gi RWX rook-cephfs 8s ``` To clean your cluster of the resources created by this example, run the following: ```console kubectl delete -f deploy/examples/csi/cephfs/pvc-clone.yaml ```