cwielenb/CNCF-Dataset huggingface dataset:
Project: Spiderpool (Runtime / Cloud Native Network)
File: subnet.md

| Case ID | Title | Priority | Smoke | Status | Other | ||-|-|-||-| | I00001 | Add, delete, modify, and query CIDR subnet | p1 | | done | | | I00002 | Add and remove IP for CIDR subnet | p1 | | done | | | I00003 | Automatically create, scale, restart, and delete of ippools for different types of controllers | p1 | | done | | | I00004 | The excludeIPs in the subnet will not be used by pools created automatically or manually. | p2 | | done | | | I00005 | If routes and gateway are modified for CIDR, how the manually created ippools are affected? | p3 | | done | | | I00006 | Multiple automatic creation and recycling of ippools, eventually the free IPs in the subnet should be restored to its initial state | p1 | true | done | | | I00007 | Multiple manual creation and recycling of ippools, eventually the free IPs in the subnet should be restored to its initial state | p1 | true | done | | | I00008 | Scale up and down the number of deployment several times to see if the state of the ippools is eventually stable | p1 | | done | | | I00009 | Create 100 Subnets with the same `Subnet.spec` and see if only one succeeds in the end | p1 | | done | | | I00010 | Create 100 IPPools with the same `IPPool.spec` and see if only one succeeds in the end | p1 | | done | | | I00011 | The subnet automatically creates an ippool and allocates IP, and should consider reservedIP | p1 | | done | | | I00012 | SpiderSubnet supports multiple interfaces | p1 | | done | | | I00013 | SpiderSubnet supports automatic IP assignment for Pods | p2 | | done | | | I00014 | The default subnet should support different controller types | p2 | | done | | | I00015 | Applications with the same name and type can use the reserved IPPool. | p2 | | done | | | I00016 | Applications with the same name and different types cannot use the reserved IPPool. | p3 | | done | | | I00017 | Ability to create fixed IPPools for applications with very long names | p3 | | done | | | I00018 | automatic IPPool IPs are not modifiable | p3 | | done | | | I00019 | Change the annotation ipam.spidernet.io/ippool-reclaim to true and the reserved IPPool will be reclaimed. | p3 | | done | | | I00020 | Redundant IPs for automatic IPPool, which cannot be used by other applications | p3 | | done | | | I00021 | Pod works correctly when multiple NICs are specified by annotations for applications of the same name | p3 | | done | | | I00022 | Dirty data in the subnet should be recycled. | p3 | | done | | | I00023 | SpiderSubnet feature doesn't support orphan pod | p2 | | done | | | I00024 | The Pod would not be setup and no auto Pools created when the SpiderSubnet AutoPool feature is disabled | p2 | | done | |
Project: Flannel (Runtime / Cloud Native Network)
File: reporting_bugs.md

If any part of the flannel project has bugs or documentation mistakes, please let us know by . Before creating a bug report, please check that an issue reporting the same problem does not already exist. To make the bug report accurate and easy to understand, please try to create bug reports that are: Specific. Include as much details as possible: which version, what environment, what configuration, etc. Reproducible. Include the steps to reproduce the problem. We understand some issues might be hard to reproduce, please includes the steps that might lead to the problem. Isolated. Please try to isolate and reproduce the bug with minimum dependencies. It would significantly slow down the speed to fix a bug if too many dependencies are involved in a bug report. Debugging external systems that rely on flannel is out of scope, but we are happy to provide guidance in the right direction or help with using flannel itself. Unique. Do not duplicate an existing bug report. Scoped. One bug per report. Do not follow up with another bug inside one report. It may be worthwhile to read before creating a bug report. We might ask for further information to locate a bug. A duplicated bug report will be closed. ``` bash $ kill -QUIT $PID ``` ``` bash $ flannel --version ```
Project: Piraeus Datastore (Runtime / Cloud Native Storage)
File: http-proxy.md

This guide shows you how to configure the DRBD Module Loader when using a HTTP Proxy. To complete this guide, you should be familiar with: editing `LinstorSatelliteConfiguration` resources. using the `kubectl` command line tool to access the Kubernetes cluster. We will use environment variables to configure the proxy, this tells the drbd-module-loader component to use the proxy for outgoing communication. Configure the sample below according to your environment and apply the configuration using `kubectl apply -f filename.yml`. This sample configuration assumes that a HTTP proxy is reacheable at `http://10.0.0.1:3128`. ```yaml apiVersion: piraeus.io/v1 kind: LinstorSatelliteConfiguration metadata: name: http-proxy spec: podTemplate: spec: initContainers: name: drbd-module-loader env: name: HTTP_PROXY value: http://10.0.0.1:3128 # Add your proxy connection here name: HTTPS_PROXY value: http://10.0.0.1:3128 # Add your proxy connection here name: NO_PROXY value: localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12 # Add internal IP ranges and domains here ```
Project: OpenIO (Runtime / Cloud Native Storage)
File: ISSUE_TEMPLATE.md

<! Verify first that your issue/request is not already reported on GitHub. Also test if the latest release, and devel branch are affected too. Always add information AFTER of these html comments. --> <! Pick one below and delete the rest --> Bug Report Feature Idea Documentation Report <! Insert below this comment the name of the servicetype. --> <! Paste verbatim output from "openio --version" between quotes below --> ``` ``` <! Paste verbatim output from "cat /etc/oio/sds.conf.d/NAMESPACE" between quotes below --> ``` ``` <! Paste verbatim output from "cat /etc/os-release" between quotes below --> ``` ``` <! Explain the problem briefly --> <! For bugs, show exactly how to reproduce the problem, using a minimal test-case. For new features, show how the feature would be used. --> ```bash ``` <! You can also paste gist.github.com links for larger files --> <! What did you expect to happen when running the steps above? --> <! What actually happened? --> <! Paste verbatim command output between quotes below --> ``` ```
Project: Rook (Runtime / Cloud Native Storage)
File: direct-tools.md

title: Direct Tools Rook is designed with Kubernetes design principles from the ground up. This topic is going to escape the bounds of Kubernetes storage and show you how to use block and file storage directly from a pod without any of the Kubernetes magic. The purpose of this topic is to help you quickly test a new configuration, although it is not meant to be used in production. All of the benefits of Kubernetes storage including failover, detach, and attach will not be available. If your pod dies, your mount will die with it. To test mounting your Ceph volumes, start a pod with the necessary mounts. An example is provided in the examples test directory: ```console kubectl create -f deploy/examples/direct-mount.yaml ``` After the pod is started, connect to it like this: ```console kubectl -n rook-ceph get pod -l app=rook-direct-mount $ kubectl -n rook-ceph exec -it <pod> bash ``` After you have created a pool as described in the topic, you can create a block image and mount it directly in a pod. This example will show how the Ceph rbd volume can be mounted in the direct mount pod. Create the . Create a volume image (10MB): ```console rbd create replicapool/test --size 10 rbd info replicapool/test rbd feature disable replicapool/test fast-diff deep-flatten object-map ``` Map the block volume and format it and mount it: ```console rbd map replicapool/test lsblk | grep rbd mkfs.ext4 -m0 /dev/rbd0 mkdir /tmp/rook-volume mount /dev/rbd0 /tmp/rook-volume ``` Write and read a file: ```console echo "Hello Rook" > /tmp/rook-volume/hello cat /tmp/rook-volume/hello ``` Unmount the volume and unmap the kernel device: ```console umount /tmp/rook-volume rbd unmap /dev/rbd0 ``` After you have created a filesystem as described in the topic, you can mount the filesystem from multiple pods. The the other topic you may have mounted the filesystem already in the registry pod. Now we will mount the same filesystem in the Direct Mount pod. This is just a simple way to validate the Ceph filesystem and is not recommended for production Kubernetes pods. Follow to start a pod with the necessary mounts and then proceed with the following commands after connecting to the pod. ```console mkdir /tmp/registry monendpoints=$(grep monhost /etc/ceph/ceph.conf | awk '{print $3}') my_secret=$(grep key /etc/ceph/keyring | awk '{print $3}') mount -t ceph -o mdsnamespace=myfs,name=admin,secret=$mysecret $mon_endpoints:/ /tmp/registry df -h ``` Now you should have a mounted filesystem. If you have pushed images to the registry you will see a directory called `docker`. ```console ls /tmp/registry ``` Try writing and reading a file to the shared filesystem. ```console echo "Hello Rook" > /tmp/registry/hello cat /tmp/registry/hello rm -f /tmp/registry/hello ``` To unmount the shared filesystem from the Direct Mount Pod: ```console umount /tmp/registry rmdir /tmp/registry ``` No data will be deleted by unmounting the filesystem.
Project: Weave Net (Runtime / Cloud Native Network)
File: interactive.md

title: Interactive Deployment menu_order: 20 search_type: Documentation Weave Net can be launched interactively on the command line, and as long as Docker is configured to start on boot, the network will survive host reboots without the use of a systemd. However, since launching Weave Net commands in interactive mode is not amenable to automation and configuration management, it is recommended that deploying Weave Net in this mode be reserved for exploration and evaluation only. On the initial peer: weave launch On the new peer: weave launch <extant peers> Where, `<extant peers>` indicates all peers in the network, initial and subsequently added, which have not been explicitly removed. It should include peers that are temporarily offline or stopped. To ensure that the new peer has joined the existing network, execute the following: weave prime Before adding any new peers, you must wait for this to complete. If this command waits and does not exit, it means that there is some issue (such as a network partition or failed peers) that is preventing a quorum from being reached - you will need to [address that](/site/troubleshooting.md) before moving on. A peer can be stopped temporarily with the following command: weave stop A temporarily stopped peer will remember IP address allocation information on the next `weave launch` but will forget any discovered peers or modifications to the initial peer list that were made with `weave connect` or `weave forget`. Note that if the host reboots, Docker automatically restarts the peer. On the peer to be removed: weave reset Then optionally on each remaining peer: weave forget <removed peer> This step is not mandatory, but it will eliminate log noise and spurious network traffic by stopping reconnection attempts and preventing further connection attempts after a restart.
Project: rkt (Runtime / Container Runtime)
File: user-namespaces.md

User namespaces is a feature of Linux that can be used to separate the user IDs and group IDs between the host and containers. It can provide a better isolation and security: the privileged user `root` in the container can be mapped to a non-privileged user on the host. rkt's implementation is based on systemd-nspawn. A pod can transparently use user IDs in the range 0-65535 and this range is mapped on the host to a high range chosen randomly. Before the pod is started, the ACIs are rendered to the filesystem and the owners of the files are set with `chown` in that high range. When starting several pods with user namespaces, they will each get a random UID range. Although very unlikely, it is possible that two distincts containers get the same UID range. If this happens, user namespaces will not provide any additional isolation between the two containers, exactly like when user namespaces are not used. The two containers will however still not use the same UID range as the host, so using user namespaces is better than not using them. In order to avoid collisions, it is planned to implement a locking mechanism so that two pods will always have a different UID range. The initial implementation works only with `--no-overlay`. Ideally, preparing a pod should not have to iterate over all files to call `chown`. It is planned to add kernel support for a mount option to shift the user IDs in the correct range (see ). It would make it work with overlayfs. When mounting a volume from the host into the pod, the ownership of the files is not shifted, so it makes volumes difficult if not impossible to use with user namespaces. The same kernel support should help here too ().
Project: Velero (Runtime / Cloud Native Storage)
File: backup-resources-order.md

This document proposes a solution that allows user to specify a backup order for resources of specific resource type. During backup process, user may need to back up resources of specific type in some specific order to ensure the resources were backup properly because these resources are related and ordering might be required to preserve the consistency for the apps to recover itself from the backup image (Ex: primary-secondary database pods in a cluster). Enable user to specify an order of backup resources belong to specific resource type Use a plugin to backup an resources and all the sub resources. For example use a plugin for StatefulSet and backup pods belong to the StatefulSet in specific order. This plugin solution is not generic and requires plugin for each resource type. User will specify a map of resource type to list resource names (separate by semicolons). Each name will be in the format "namespaceName/resourceName" to enable ordering across namespaces. Based on this map, the resources of each resource type will be sorted by the order specified in the list of resources. If a resource instance belong to that specific type but its name is not in the order list, then it will be put behind other resources that are in the list. Add new field to BackupSpec type BackupSpec struct { ... // OrderedResources contains a list of key-value pairs that represent the order // of backup of resources that belong to specific resource type // +optional // +nullable OrderedResources map[string]string } Function getResourceItems collects all items belong to a specific resource type. This function will be enhanced to check with the map to see whether the OrderedResources has specified the order for this resource type. If such order exists, then sort the items by such order being process before return. Add new flag "--ordered-resources" to Velero backup create command which takes a string of key-values pairs which represents the map between resource type and the order of the items of such resource type. Key-value pairs are separated by semicolon, items in the value are separated by commas. Example: velero backup create mybackup --ordered-resources "pod=ns1/pod1,ns1/pod2;persistentvolumeclaim=n2/slavepod,ns2/primarypod" In the CLI, the design proposes to use commas to separate items of a resource type and semicolon to separate key-value pairs. This follows the convention of using commas to separate items in a list (For example: --include-namespaces ns1,ns2). However, the syntax for map in labels and annotations use commas to separate key-value pairs. So it introduces some inconsistency. For pods that managed by Deployment or DaemonSet, this design may not work because the pods' name is randomly generated and if pods are restarted, they would have different names so the Backup operation may not consider the restarted pods in the sorting algorithm. This problem will be addressed when we enhance the design to use regular expression to specify the OrderResources instead of exact match.
Project: MinIO (Runtime / Cloud Native Storage)
File: CONTRIBUTING.md

``MinIO`` community welcomes your contribution. To make the process as seamless as possible, we recommend you read this contribution guide. Start by forking the MinIO GitHub repository, make changes in a branch and then send a pull request. We encourage pull requests to discuss code changes. Here are the steps in details: Fork source repository to your own personal repository. Copy the URL of your MinIO fork (you will need it for the `git clone` command below). ```sh git clone https://github.com/minio/minio go install -v ls /go/bin/minio ``` ```sh $ cd minio $ git remote add upstream https://github.com/minio/minio $ git fetch upstream $ git merge upstream/master ... ``` Before making code changes, make sure you create a separate branch for these changes ``` git checkout -b my-new-feature ``` After your code changes, make sure To add test cases for the new code. If you have questions about how to do it, please ask on our channel. To run `make verifiers` To squash your commits into a single commit. `git rebase -i`. It's okay to force update your pull request. To run `make test` and `make build` completes. After verification, commit your changes. This is a on how to write useful commit messages ``` git commit -am 'Add some feature' ``` Push your locally committed changes to the remote origin (your fork) ``` git push origin my-new-feature ``` Pull requests can be created via GitHub. Refer to for detailed steps on how to create a pull request. After a Pull Request gets peer reviewed and approved, it will be merged. ``MinIO`` uses `go mod` to manage its dependencies. Run `go get foo/bar` in the source folder to add the dependency to `go.mod` file. To remove a dependency Edit your code and remove the import reference. Run `go mod tidy` in the source folder to remove dependency from `go.mod` file. ``MinIO`` is fully conformant with Golang style. Refer: article from Golang project. If you observe offending code, please feel free to send a pull request or ping us on .
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_tunnel_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List tunnel endpoint entries ``` cilium-dbg bpf tunnel 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 ``` - Tunnel endpoint map
Project: rkt (Runtime / Container Runtime)
File: LICENSE.md

The MIT License (MIT) Copyright (c) 2014 Brian Goff Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Project: CRI-O (Runtime / Container Runtime)
File: LICENSE.md

Copyright (c) 2018-2023, Sylabs Inc. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Project: Rook (Runtime / Cloud Native Storage)
File: nfs-advanced.md

title: Advanced configuration All CephNFS daemons are configured using shared RADOS objects stored in a Ceph pool named `.nfs`. Users can modify the configuration object for each CephNFS cluster if they wish to customize the configuration. By default, Rook creates the `.nfs` pool with Ceph's default configuration. If you wish to change the configuration of this pool (for example to change its failure domain or replication factor), you can create a CephBlockPool with the `spec.name` field set to `.nfs`. This pool must be replicated and cannot be erasure coded. contains a sample for reference. Ceph uses servers. The config file format for these objects is documented in the . Use Ceph's `rados` tool from the toolbox to interact with the configuration object. The below command will get you started by dumping the contents of the config object to stdout. The output will look something like the example shown if you have already created two exports as documented above. It is best not to modify any of the export objects created by Ceph so as not to cause errors with Ceph's export management. ```console $ rados --pool <pool> --namespace <namespace> get conf-nfs.<cephnfs-name> - %url "rados://<pool>/<namespace>/export-1" %url "rados://<pool>/<namespace>/export-2" ``` `rados ls` and `rados put` are other commands you will want to work with the other shared configuration objects. Of note, it is possible to pre-populate the NFS configuration and export objects prior to creating CephNFS server clusters. !!! warning RGW NFS export is experimental for the moment. It is not recommended for scenario of modifying existing content. For creating an NFS export over RGW(CephObjectStore) storage backend, the below command can be used. This creates an export for the `/testrgw` pseudo path on an existing bucket bkt4exp as an example. You could use `/testrgw` pseudo for nfs mount operation afterwards. ```console ceph nfs export create rgw my-nfs /testrgw bkt4exp ```