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

name: Bug report about: Tell us about a problem you are experiencing What steps did you take and what happened: <!--A clear and concise description of what the bug is, and what commands you ran.--> What did you expect to happen: The following information will help us better understand what's going on: If you are using velero v1.7.0+: Please use `velero debug --backup <backupname> --restore <restorename>` to generate the support bundle, and attach to this issue, more options please refer to `velero debug --help` If you are using earlier versions: Please provide the output of the following commands (Pasting long output into a or other pastebin is fine.) `kubectl logs deployment/velero -n velero` `velero backup describe <backupname>` or `kubectl get backup/<backupname> -n velero -o yaml` `velero backup logs <backupname>` `velero restore describe <restorename>` or `kubectl get restore/<restorename> -n velero -o yaml` `velero restore logs <restorename>` Anything else you would like to add: <!--Miscellaneous information that will assist in solving the issue.--> Environment: Velero version (use `velero version`): Velero features (use `velero client config get features`): Kubernetes version (use `kubectl version`): Kubernetes installer & version: Cloud provider or hardware configuration: OS (e.g. from `/etc/os-release`): Vote on this issue! This is an invitation to the Velero community to vote on issues, you can see the project's . Use the "reaction smiley face" up to the right of this comment to vote. :+1: for "I would like to see this bug fixed as soon as possible" :-1: for "There are more important bugs to focus on right now"
Project: Spiderpool (Runtime / Cloud Native Network)
File: crd-spiderreservedip.md

A SpiderReservedIP resource represents a collection of IP addresses that Spiderpool expects not to be allocated. For details on using this CRD, please read the . ```yaml apiVersion: spiderpool.spidernet.io/v2beta1 kind: SpiderIPPool metadata: name: exclude-ips spec: subnet: 172.18.41.0/24 ips: 172.18.41.40-172.18.41.44 172.18.41.46-172.18.41.50 ``` | Field | Description | Schema | Validation | |-|--|--|| | name | the name of this SpiderReservedIP resource | string | required | This is the SpiderReservedIP spec for users to configure. | Field | Description | Schema | Validation | Values | |-|-|||| | ipVersion | IP version of this resource | int | optional | 4,6 | | ips | IP ranges for this resource that we expect not to use | list of strings | optional | array of IP ranges and single IP address |
Project: Kilo (Runtime / Cloud Native Network)
File: vpn.md

Kilo enables peers outside of a Kubernetes cluster to connect to the created WireGuard network. This enables several use cases, for example: giving cluster applications secure access to external services, e.g. services behind a corporate VPN; improving the development flow of applications by running them locally and connecting them to the cluster; allowing external services to access the cluster; and enabling developers and support to securely debug cluster resources. In order to declare a peer, start by defining a Kilo Peer resource. See the following `peer.yaml`, where the `publicKey` field holds a : ```yaml apiVersion: kilo.squat.ai/v1alpha1 kind: Peer metadata: name: squat spec: allowedIPs: 10.5.0.1/32 # Example IP address on the peer's interface. publicKey: GY5aT1N9dTR/nJnT1N2f4ClZWVj0jOAld0r8ysWLyjg= persistentKeepalive: 10 ``` Then, apply the resource to the cluster: ```shell kubectl apply -f peer.yaml ``` Now, the `kgctl` tool can be used to generate the WireGuard configuration for the newly defined peer: ```shell PEER=squat kgctl showconf peer $PEER ``` This will produce some output like: ```ini [Peer] PublicKey = 2/xU029dz/WtvMZAbnSzmhicl8U1/Y3NYmunRr8EJ0Q= AllowedIPs = 10.4.0.2/32, 10.2.3.0/24, 10.1.0.3/32 Endpoint = 108.61.142.123:51820 ``` The configuration can then be applied to a local WireGuard interface, e.g. `wg0`: ```shell IFACE=wg0 kgctl showconf peer $PEER > peer.ini sudo wg setconf $IFACE peer.ini ``` Finally, in order to access the cluster, the client will need appropriate routes for the new configuration. For example, on a Linux machine, the creation of these routes could be automated by running: ```shell for ip in $(kgctl showconf peer $PEER | grep AllowedIPs | cut -f 3- -d ' ' | tr -d ','); do sudo ip route add $ip dev $IFACE done ``` Once the routes are in place, the connection to the cluster can be tested. For example, try connecting to the API server: ```shell curl -k https://$(kubectl get endpoints kubernetes | tail -n +2 | tr , \\t | awk '{print $2}') ``` Likewise, the cluster now also has layer 3 access to the newly added peer. From any node or Pod on the cluster, one can now ping the peer: ```shell ping 10.5.0.1 ``` If the peer exposes a layer 4 service, for example an HTTP server listening on TCP port 80, then one could also make requests against that endpoint from the cluster: ```shell curl http://10.5.0.1 ``` Kubernetes Services can be created to provide better discoverability to cluster workloads for services exposed by peers, for example: ```shell cat <<'EOF' | kubectl apply -f - apiVersion: v1 kind: Service metadata: name: important-service spec: ports: port: 80 apiVersion: v1 kind: Endpoints metadata: name: important-service subsets: addresses: ip: 10.5.0.1 ports: port: 80 EOF ``` . Although it is not a primary goal of the project, the VPN created by Kilo can also be .
Project: Project Calico (Runtime / Cloud Native Network)
File: installation.md

Currently confd ships binaries for OS X and Linux 64bit systems. You can download the latest release from ``` $ wget https://github.com/bacongobbler/confd/releases/download/v0.12.1/confd-0.12.1-darwin-amd64 ``` ``` $ wget https://github.com/bacongobbler/confd/releases/download/v0.12.1/confd-0.12.1-linux-amd64 ``` ``` $ ./build $ sudo ./install ``` Since many people are using Alpine Linux as their base images for Docker there's support to build Alpine package also. Naturally by using Docker itself. :) ``` $ docker build -t confd_builder -f Dockerfile.build.alpine . $ docker run -ti --rm -v $(pwd):/app confd_builder ./build ``` The above docker commands will produce binary in the local bin directory. Get up and running with the .
Project: Longhorn (Runtime / Cloud Native Storage)
File: test.md

name: Test about: Create or update test title: "[TEST] " labels: kind/test assignees: '' <!--A clear and concise description of what test you want to develop.--> <!-- Please use a task list for items on a separate line with a clickable checkbox https://docs.github.com/en/issues/tracking-your-work-with-issues/about-task-lists [ ] `item 1` --> <!--Add any other context or screenshots about the test request here.-->
Project: Rook (Runtime / Cloud Native Storage)
File: ceph-rbd-mirror-crd.md

title: CephRBDMirror CRD Rook allows creation and updating rbd-mirror daemon(s) through the custom resource definitions (CRDs). RBD images can be asynchronously mirrored between two Ceph clusters. For more information about user management and capabilities see the . To get you started, here is a simple example of a CRD to deploy an rbd-mirror daemon. ```yaml apiVersion: ceph.rook.io/v1 kind: CephRBDMirror metadata: name: my-rbd-mirror namespace: rook-ceph spec: count: 1 ``` This guide assumes you have created a Rook cluster as explained in the main If any setting is unspecified, a suitable default will be used automatically. `name`: The name that will be used for the Ceph RBD Mirror daemon. `namespace`: The Kubernetes namespace that will be created for the Rook cluster. The services, pods, and other resources created by the operator will be added to this namespace. `count`: The number of rbd mirror instance to run. `placement`: The rbd mirror pods can be given standard Kubernetes placement restrictions with `nodeAffinity`, `tolerations`, `podAffinity`, and `podAntiAffinity` similar to placement defined for daemons configured by the .. `annotations`: Key value pair list of annotations to add. `labels`: Key value pair list of labels to add. `resources`: The resource requirements for the rbd mirror pods. `priorityClassName`: The priority class to set on the rbd mirror pods. Configure mirroring peers individually for each CephBlockPool. Refer to the for more detail.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_endpoint_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List local endpoint entries ``` cilium-dbg bpf endpoint list [flags] ``` ``` -h, --help help for list -o, --output string json| yaml| jsonpath='{}' ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Local endpoint map
Project: Firecracker (Runtime / Container Runtime)
File: block-caching.md

Firecracker offers the possiblity of choosing the block device caching strategy. Caching strategy affects the path data written from inside the microVM takes to the host persistent storage. When installing a block device through a PUT /drives API call, users can choose the caching strategy by inserting a `cache_type` field in the JSON body of the request. The available cache types are: `Unsafe` `Writeback` When configuring the block caching strategy to `Unsafe`, the device will not advertise the VirtIO `flush` feature to the guest driver. When configuring the block caching strategy to `Writeback`, the device will advertise the VirtIO `flush` feature to the guest driver. If negotiated when activating the device, the guest driver will be able to send flush requests to the device. When the device executes a flush request, it will perform an `fsync` syscall on the backing block file, committing all data in the host page cache to disk. The caching strategy should be used in order to make a trade-off: `Unsafe` enhances performance as fewer syscalls and IO operations are performed when running workloads sacrifices data integrity in situations where the host simply loses the contents of the page cache without committing them to the backing storage (such as a power outage) recommended for use cases with ephemeral storage, such as serverless environments `Writeback` ensures that once a flush request was acknowledged by the host, the data is committed to the backing storage sacrifices performance, from boot time increases to greater emulation-related latencies when running workloads recommended for use cases with low power environments, such as embedded environments Example sequence that configures a block device with a caching strategy: ```bash curl --unix-socket ${socket} -i \ -X PUT "http://localhost/drives/dummy" \ -H "accept: application/json" \ -H "Content-Type: application/json" \ -d "{ \"drive_id\": \"dummy\", \"pathonhost\": \"${drive_path}\", \"isrootdevice\": false, \"isreadonly\": false, \"cache_type\": \"Writeback\" }" ```
Project: Vineyard (Runtime / Cloud Native Storage)
File: ISSUE_TEMPLATE.md

<!-- Thanks for your contribution! please review https://github.com/v6d-io/v6d/blob/main/CONTRIBUTING.rst before opening an issue. --> Describe your problem A clear and concise description of what your problem is. It might be a bug, a feature request, or just a problem that need support from the vineyard team. If is is a bug report, to help us reproducing this bug, please provide information below: Your Operation System version (`uname -a`): The version of vineyard you use (`vineyard.version`): Versions of crucial packages, such as gcc, numpy, pandas, etc.: Full stack of the error (if there are a crash): Minimized code to reproduce the error: If it is a feature request, please provides a clear and concise description of what you want to happen: Additional context Add any other context about the problem here.
Project: Curve (Runtime / Cloud Native Storage)
File: CHANGELOG-2.6.md

Previous change logs can be found at , thanks to . , thanks to . , thanks to . , thanks to . , thanks to . , thanks to . , thanks to . , thanks to . , thanks to . , thanks to . 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+, bandwidth is about 300 MiB) ```yaml fs.cto: true fs.lookupCache.negativeTimeoutSec: 1 fs.lookupCache.minUses: 3 fuseClient.supportKVcache: true client.loglevel: 0 ``` ```bash [global] rw=randread direct=1 size=50G iodepth=128 ioengine=libaio bsrange=4k-4k ramp_time=10 runtime=300 group_reporting [disk01] filename=/path/to/mountpoint/1.txt ``` | fio | IOPS/bandwidth | avg-latency(ms) | clat 99.00th (ms) | clat 99.99th (ms) | | :-: | :-: | :-: | :-: | :-: | | numjobs=1 / size=50GB / 4k randwrite | 4243 | 0.23 | 0.176 | 2 | | numjobs=1 / size=50GB / 4k randwrite | 908 | 1.0 | 3.5 | 104 | | numjobs=1 / size=50GB / 512k write | 412 MiB/s | 2.4 | 19 | 566 | | numjobs=1 / size=50GB / 512k read | 333 MiB/s | 2.9 | 20 | 115 | ```bash for i in 1 4 8; do mpirun --allow-run-as-root -np $i mdtest -z 2 -b 3 -I 10000 -d /path/to/mountpoint; done ``` | Case | Dir creation | Dir stat | Dir removal | File creation | File stat | File read | File removal | Tree creation | Tree removal | | | | | | | | | | | | | client*1 | 341 | 395991 | 291 | 334 | 383844 | 3694 | 309 | 322 | 851 | | client*4 | 385 | 123266 | 288 | 361 | 1515592 | 15056 | 310 | 363 | 16 | | client*8 | 415 | 22138 | 314 | 400 | 2811416 | 20976 | 347 | 355 | 8 |
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_multicast_subscriber.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage the multicast subscribers. ``` -h, --help help for subscriber ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage multicast BPF programs - Add a remote subscriber to the multicast group. - Delete a subscriber from the multicast group. - List the multicast subscribers for the given group.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bgp_routes.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List routes in the BGP Control Plane's RIBs List routes in the BGP Control Plane's Routing Information Bases (RIBs) ``` cilium-dbg bgp routes <available | advertised> <afi> <safi> [vrouter <asn>] [peer|neighbor <address>] [flags] ``` ``` Get all IPv4 unicast routes available: cilium-dbg bgp routes available ipv4 unicast Get all IPv6 unicast routes available for a specific vrouter: cilium-dbg bgp routes available ipv6 unicast vrouter 65001 Get IPv4 unicast routes advertised to a specific peer: cilium-dbg bgp routes advertised ipv4 unicast peer 10.0.0.1 ``` ``` -h, --help help for routes -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 ``` - Access to BGP control plane
Project: CubeFS (Runtime / Cloud Native Storage)
File: md_docs.md

Generating Markdown pages from a cobra command is incredibly easy. An example is as follows: ```go package main import ( "log" "github.com/spf13/cobra" "github.com/spf13/cobra/doc" ) func main() { cmd := &cobra.Command{ Use: "test", Short: "my test program", } err := doc.GenMarkdownTree(cmd, "/tmp") if err != nil { log.Fatal(err) } } ``` That will get you a Markdown document `/tmp/test.md` This program can actually generate docs for the kubectl command in the kubernetes project ```go package main import ( "log" "io/ioutil" "os" "k8s.io/kubernetes/pkg/kubectl/cmd" cmdutil "k8s.io/kubernetes/pkg/kubectl/cmd/util" "github.com/spf13/cobra/doc" ) func main() { kubectl := cmd.NewKubectlCommand(cmdutil.NewFactory(nil), os.Stdin, ioutil.Discard, ioutil.Discard) err := doc.GenMarkdownTree(kubectl, "./") if err != nil { log.Fatal(err) } } ``` This will generate a whole series of files, one for each command in the tree, in the directory specified (in this case "./") You may wish to have more control over the output, or only generate for a single command, instead of the entire command tree. If this is the case you may prefer to `GenMarkdown` instead of `GenMarkdownTree` ```go out := new(bytes.Buffer) err := doc.GenMarkdown(cmd, out) if err != nil { log.Fatal(err) } ``` This will write the markdown doc for ONLY "cmd" into the out, buffer. Both `GenMarkdown` and `GenMarkdownTree` have alternate versions with callbacks to get some control of the output: ```go func GenMarkdownTreeCustom(cmd *Command, dir string, filePrepender, linkHandler func(string) string) error { //... } ``` ```go func GenMarkdownCustom(cmd Command, out bytes.Buffer, linkHandler func(string) string) error { //... } ``` The `filePrepender` will prepend the return value given the full filepath to the rendered Markdown file. A common use case is to add front matter to use the generated documentation with : ```go const fmTemplate = ` date: %s title: "%s" slug: %s url: %s ` filePrepender := func(filename string) string { now := time.Now().Format(time.RFC3339) name := filepath.Base(filename) base := strings.TrimSuffix(name, path.Ext(name)) url := "/commands/" + strings.ToLower(base) + "/" return fmt.Sprintf(fmTemplate, now, strings.Replace(base, "_", " ", -1), base, url) } ``` The `linkHandler` can be used to customize the rendered internal links to the commands, given a filename: ```go linkHandler := func(name string) string { base := strings.TrimSuffix(name, path.Ext(name)) return "/commands/" + strings.ToLower(base) + "/" } ```
Project: Curve (Runtime / Cloud Native Storage)
File: CHANGELOG-1.1.md

Previous change logs can be found at <hr> This version is mainly for performance optimization. - - Hardware: 6 nodes, each with: 20x SATA SSD Intel SSD DC S3500 Series 800G 2x Intel(R) Xeon(R) CPU E5-2660 v4 @ 2.00GHz 2x Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection, bond mode is 802.3ad with layer2+3 hash policy 251G RAM Performance test is based on curve-nbd, the size of each block device is 200GB, all configurations are default, and each Chunkserver is deployed on one SSD. 1 NBD block device: | item | iops/bandwidth | avg-latency | 99th-latency | release-1.0<br>iops/bandwidth | release-1.0<br>avg-latency | release-1.0<br>99th-latency | iops/bandwidth improvement percentage | | :-: | :-: | :-: | :-: | :-: |:-: |:-: | :-: | | 4K randwrite, 128 depth | 109,000 iops | 1,100 us | 2,040 us | 62,900 iops | 2,000 us | 3,000 us | 73% | | 4K randread, 128 depth | 128,000 iops | 1,000 us | 1,467 us | 76,600 iops | 1,600 us | 2,000us | 67% | | 512K write, 128 depth | 204 MB/s | 314 ms | 393 ms | 147 MB/s | 435 ms | 609 ms| 38% | | 512K read, 128 depth | 995 MB/s | 64 ms | 92 ms | 757 MB/s | 84 ms | 284 ms| 31% | 10 NBD block device: | item | iops/bandwidth | avg-latency | 99th-latency | release-1.0<br>iops/bandwidth | release-1.0<br>avg-latency | release-1.0<br>99th-latency | iops/bandwidth improvement percentage | | :-: | :-: | :-: | :-: | :-: |:-: |:-: | :-: | | 4K randwrite, 128 depth | 262,000 iops | 4.9 ms | 32 ms | 176,000 iops | 7.2 ms | 16 ms | 48% | | 4K randread, 128 depth | 497,000 iops | 2.69 ms | 6 ms | 255,000 iops | 5.2 ms | 22 ms | 94% | | 512K write, 128 depth | 1,122 MB/s | 569 ms | 1,101 ms | 899 MB/s | 710 ms | 1,502 ms | 24% | | 512K read, 128 depth | 3,241 MB/s | 200 ms | 361 ms | 1,657 MB/s | 386 ms | 735 ms | 95% |
Project: Container Network Interface (CNI) (Runtime / Cloud Native Network)
File: cnitool.md

The `cnitool` is a utility that can be used to test a CNI plugin without the need for a container runtime. The `cnitool` takes a `network name` and a `network namespace` and a command to `ADD` or `DEL`,.i.e, attach or detach containers from a network. The `cnitool` relies on the following environment variables to operate properly: `NETCONFPATH`: This environment variable needs to be set to a directory. It defaults to `/etc/cni/net.d`. The `cnitool` searches for CNI configuration files in this directory with the extension `.conf` or `.json`. It loads all the CNI configuration files in this directory and if it finds a CNI configuration with the `network name` given to the cnitool it returns the corresponding CNI configuration, else it returns `nil`. `CNI_PATH`: For a given CNI configuration `cnitool` will search for the corresponding CNI plugin in this path. For the full documentation of `cnitool` see the
Project: Alluxio (Runtime / Cloud Native Storage)
File: Overview.md

layout: global title: Overview Welcome to Alluxio Documentation! You will find resources regarding deploying Alluxio, integrations with various tech stacks, API references, and more! If you have any questions, join our Alluxio Community Slack &rarr; Check out our for step-by-step guidance on how to download and configure Alluxio, run Alluxio on a local machine, and perform basic tasks via Alluxio Shell. {:target="_blank"} (2:36) See on how to install Alluxio on Kubernetes via , a kubernetes package manager, and , a kubernetes extension for managing applications. Check out these 2 short videos on deployment and best practices with configurations & recommendations: {:target="_blank"} (5:12) {:target="_blank"} (5:26) Make sure you have the proper , then follow to deploy an Alluxio cluster with High Availability (HA), which is achieved by running multiple Alluxio master processes on different nodes in the system. You can run an Alluxio cluster with a couple of `docker run` commands by following our tutorial for running Dockerized Alluxio on a single node with local disk as the under storage at . Take a look at for a list of all storage systems available to integrate with Alluxio and its necessary prerequisites. Join our vibrant and fast-growing to connect with users & developers of Alluxio. If you need help running Alluxio or encounter any blockers, send your technical questions to our `#troubleshooting` channel. If you are a developer looking to contribute to Alluxio, check out the `#dev` channel. Become a contributor! Follow our to learn how to fork the Alluxio repository and take on a new contributor task.
Project: rkt (Runtime / Container Runtime)
File: on-disk-format.md

On disk format ============== The data directory is `/var/lib/rkt`, unless configured otherwise. For details, see . The `--dir` command line option can be used to change this location. The CAS database is stored in `/var/lib/rkt/cas/db`. The database schema can be migrated to newer versions (). The CAS also uses other directories in `/var/lib/rkt/cas/`. To ensure stability for the CAS, we need to make sure we don't remove any of those directories or make any destructive changes to them. Future version of rkt will retain compatibility with older CAS versions. The pods are stored in `/var/lib/rkt/pods/` as explained in The stability of prepared and exited pods is desirable, but not as critical as the CAS. The on-disk format is documented separately.
Project: lxd (Runtime / Container Runtime)
File: images_profiles.md

(images-profiles)= You can associate one or more profiles with a specific image. Instances that are created from the image will then automatically use the associated profiles in the order they were specified. To associate a list of profiles with an image, use the command and edit the `profiles:` section: ```yaml profiles: default ``` Most provided images come with a profile list that includes only the `default` profile. To prevent any profile (including the `default` profile) from being associated with an image, pass an empty list. ```{note} Passing an empty list is different than passing `nil`. If you pass `nil` as the profile list, only the `default` profile is associated with the image. ``` You can override the associated profiles for an image when creating an instance by adding the `--profile` or the `--no-profiles` flag to the launch or init command.