cwielenb/CNCF-Dataset huggingface dataset:
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_ct_flush.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Flush all connection tracking entries ``` cilium-dbg bpf ct flush ( <endpoint identifier> | global ) [flags] ``` ``` -h, --help help for flush ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Connection tracking tables
Project: CubeFS (Runtime / Cloud Native Storage)
File: CHANGELOG.md

Fix cgroups v2 mountpoint detection. Add support for cgroups v2. Thanks to @emadolsky for their contribution to this release. Support colons in cgroup names. Remove linters from runtime dependencies. Migrate to Go modules. Fixed quota clamping to always round down rather than up; Rather than guaranteeing constant throttling at saturation, instead assume that the fractional CPU was added as a hedge for factors outside of Go's scheduler. Log the new value of `GOMAXPROCS` rather than the current value. Make logs more explicit about whether `GOMAXPROCS` was modified or not. Allow customization of the minimum `GOMAXPROCS`, and modify default from 2 to 1. Initial release.
Project: Rook (Runtime / Cloud Native Storage)
File: ci-configuration.md

title: CI Configuration This page contains information regarding the CI configuration used for the Rook project to test, build and release the project. Snyk (Security Scan): `SNYK_TOKEN` - API Token for the (workflow file: `snyk.yaml`). Testing: `IBMINSTANCEID`: Used for KMS (Key Management System) IBM Key Protect access (see ). `IBMSERVICEAPI_KEY`: Used for KMS (Key Management System) IBM Key Protect access (see ). Publishing: `DOCKERUSERNAME` + `DOCKERPASSWORD`: Username and password of registry. `DOCKER_REGISTRY`: Target registry namespace (e.g., `rook`) `AWSUSR` + `AWSPSW`: AWS credentials with access to S3 for Helm chart publishing. `GITAPITOKEN`: GitHub access token, used to push docs changes to the docs repositories `gh-pages` branch.
Project: Kanister (Runtime / Cloud Native Storage)
File: GOVERNANCE.md

This document defines the governance policies of Kanister. Anyone can contribute to Kanister, whether through code, design discussions, documentation, blog posts, talks, or other means. All contributors are expected to follow the Kanister . Contributions to the code base, documentation, or other components in the Kanister GitHub organization must follow the guidelines described in the document. Whether these contributions get merged into the project is the prerogative of the maintainers. Maintainers are responsible for the overall security, quality and integrity of the project. They propose, manage, review, approve/reject major change and enhancement requests. They also have the ability to merge code into the project. See the document for the full list of maintainer responsibilities. Ideally, all project decisions are resolved by maintainer consensus. If this is not possible, maintainers may call for a vote. The voting process is a simple majority in which each maintainer receives one vote. If a maintainer is no longer interested in or cannot perform the duties listed above, they should move themselves to emeritus status. This can also occur by a vote of the maintainers. Anyone can become a Kanister maintainer. Maintainers should be extremely proficient in Go; have relevant domain expertise; have the time and ability to meet the maintainer expectations outlined above, and demonstrate the ability to work with the existing maintainers and project process. To become a maintainer, start by expressing interest to existing maintainers. Existing maintainers will then ask you to demonstrate the qualifications above by contributing PRs, doing code reviews, and other such tasks under their guidance. After several months of working together, maintainers will decide whether to grant maintainer status. This governance is a living document and its policies will need to be updated over time to meet the community's needs. Until the steering committee is set up, the maintainers will have full ownership of this governance. Changes can be proposed at any time, but a super majority is required to approve any updates.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_ipcache_get.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Retrieve identity for an ip ``` cilium-dbg bpf ipcache get [flags] ``` ``` -h, --help help for get ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage the IPCache mappings for IP/CIDR <-> Identity
Project: HwameiStor (Runtime / Cloud Native Storage)
File: license.md

MIT License Copyright (c) 2019 Josh Bleecher Snyder 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: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_kvstore_set.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Set a key and value ``` cilium-dbg kvstore set [options] <key> [flags] ``` ``` cilium kvstore set foo=bar ``` ``` -h, --help help for set --key string Key --value string Value ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API --kvstore string Key-Value Store type --kvstore-opt map Key-Value Store options ``` - Direct access to the kvstore
Project: Kata Containers (Runtime / Container Runtime)
File: inotify.md

A common pattern in Kubernetes is to watch for changes to files/directories passed in as `ConfigMaps` or `Secrets`. Sidecar's normally use `inotify` to watch for changes and then signal the primary container to reload the updated configuration. Kata Containers typically will pass these host files into the guest using `virtiofs`, which does not support `inotify` today. While we work to enable this use case in `virtiofs`, we introduced a workaround in Kata Containers. This document describes how Kata Containers implements this workaround. Kubernetes creates `secrets` and `ConfigMap` mounts at very specific locations on the host filesystem. For container mounts, the `Kata Containers` runtime will check the source of the mount to identify these special cases. For these use cases, only a single file or very few would typically need to be watched. To avoid excessive overheads in making a mount watchable, we enforce a limit of eight files per mount. If a `secret` or `ConfigMap` mount contains more than 8 files, it will not be considered watchable. We similarly enforce a limit of 1 MB per mount to be considered watchable. Non-watchable mounts will continue to propagate changes from the mount on the host to the container workload, but these updates will not trigger an `inotify` event. If at any point a mount grows beyond the eight file or 1MB limit, it will no longer be `watchable.` For mounts that are considered `watchable`, inside the guest, the `kata-agent` will poll the mount presented from the host through `virtiofs` and copy any changed files to a `tmpfs` mount that is presented to the container. In this way, for `watchable` mounts, Kata will do the polling on behalf of the workload and existing workloads needn't change their usage of `inotify`.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_multicast_subscriber_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List the multicast subscribers for the given group. List the multicast subscribers for the given group. To get the subscribers for all the groups, use 'cilium-dbg bpf multicast subscriber list all'. ``` cilium-dbg bpf multicast subscriber list < group | all > [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 ``` - Manage the multicast subscribers.
Project: Firecracker (Runtime / Container Runtime)
File: initrd.md

You can use the script found to generate an initrd either based on alpine or suse linux. The script extracts the init system from each distribution and creates a initrd. Use this option for creating an initrd if you're building your own init or if you need any specific files / logic in your initrd. ```bash mkdir initrd cp /path/to/your/init initrd/init cd initrd find . -print0 | cpio --null --create --verbose --format=newc > initrd.cpio ``` When setting your boot source, add a `initrd_path` property like so: ```shell curl --unix-socket /tmp/firecracker.socket -i \ -X PUT 'http://localhost/boot-source' \ -H 'Accept: application/json' \ -H 'Content-Type: application/json' \ -d "{ \"kernelimagepath\": \"/path/to/kernel\", \"boot_args\": \"console=ttyS0 reboot=k panic=1 pci=off\", \"initrd_path\": \"/path/to/initrd.cpio\" }" ``` You should not use a drive with `isrootdevice: true` when using an initrd Make sure your kernel configuration has `CONFIGBLKDEV_INITRD=y` If you don't want to place your init at the root of your initrd, you can add `rdinit=/path/to/init` to your `boot_args` property If you intend to `pivot_root` in your init, it won't be possible because the initrd is mounted as a rootfs and cannot be unmounted. You will need to use `switch_root` instead.
Project: Velero (Runtime / Cloud Native Storage)
File: expose-minio.md

title: "Expose Minio outside your cluster" layout: docs When you run commands to get logs or describe a backup, the Velero server generates a pre-signed URL to download the requested items. To access these URLs from outside the cluster -- that is, from your Velero client -- you need to make Minio available outside the cluster. You can: Change the Minio Service type from `ClusterIP` to `NodePort`. Set up Ingress for your cluster, keeping Minio Service type `ClusterIP`. In Velero 0.10, you can also specify the value of a new `publicUrl` field for the pre-signed URL in your backup storage config. For basic instructions on how to install the Velero server and client, see . The Minio deployment by default specifies a Service of type `ClusterIP`. You can change this to `NodePort` to easily expose a cluster service externally if you can reach the node from your Velero client. You must also get the Minio URL, which you can then specify as the value of the new `publicUrl` field in your backup storage config. In `examples/minio/00-minio-deployment.yaml`, change the value of Service `spec.type` from `ClusterIP` to `NodePort`. Get the Minio URL: if you're running Minikube: ```shell minikube service minio --namespace=velero --url ``` in any other environment: Get the value of an external IP address or DNS name of any node in your cluster. You must be able to reach this address from the Velero client. Append the value of the NodePort to get a complete URL. You can get this value by running: ```shell kubectl -n velero get svc/minio -o jsonpath='{.spec.ports[0].nodePort}' ``` In `examples/minio/05-backupstoragelocation.yaml`, uncomment the `publicUrl` line and provide this Minio URL as the value of the `publicUrl` field. You must include the `http://` or `https://` prefix. Configuring Ingress for your cluster is out of scope for the Velero documentation. If you have already set up Ingress, however, it makes sense to continue with it while you run the example Velero configuration with Minio. In this case: Keep the Service type as `ClusterIP`. In `examples/minio/05-backupstoragelocation.yaml`, uncomment the `publicUrl` line and provide the URL and port of your Ingress as the value of the `publicUrl` field.
Project: Weave Net (Runtime / Cloud Native Network)
File: installing-weave.md

title: Installing Weave Net menu_order: 10 search_type: Documentation Ensure you are running Linux (kernel 3.8 or later) and have Docker (version 1.10.0 or later) installed. Install Weave Net by running the following: sudo curl -L git.io/weave -o /usr/local/bin/weave sudo chmod a+x /usr/local/bin/weave If you are on OSX and you are using Docker Machine ensure that a VM is running and configured before downloading Weave Net. To set up a VM see [the Docker Machine documentation](https://docs.docker.com/installation/mac/#from-your-shell) or refer to . After your VM is setup with Docker Machine, Weave Net can be launched directly from the OSX host. Weave Net respects the environment variable `DOCKER_HOST`, so that you can run and control a Weave Network locally on a remote host. See . With Weave Net downloaded onto your VMs or hosts, you are ready to launch a Weave network and deploy apps onto it. See . <a href="https://youtu.be/kihQCCT1ykE" target="_blank"> <img src="hello-screencast.png" alt="Click to watch the screencast" /> </a> Weave Net [periodically contacts Weaveworks servers for available versions](https://github.com/weaveworks/go-checkpoint). New versions are announced in the log and in [the status summary](/site/troubleshooting.md/#weave-status). The information sent in this check is: Host UUID hash Kernel version Docker version Weave Net version Network mode, e.g. 'awsvpc' To disable this check, run the following before launching Weave Net: export CHECKPOINT_DISABLE=1 Amazon ECS users see for the latest Weave AMIs. If you're on Amazon EC2, the standard installation instructions at the top of this page, provide the simplest setup and the most flexibility. A can optionally be enabled, which allows containers to communicate at the full speed of the underlying network. To make encryption in fast datapath work on Google Cloud Platform, see . See Also * * *
Project: kube-vip (Runtime / Cloud Native Network)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: '' assignees: '' Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: Go to '...' Click on '....' Scroll down to '....' See error Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Environment (please complete the following information): OS/Distro: [e.g. Ubuntu 1804] Kubernetes Version: [e.g. v.1.18] Kube-vip Version: [e.g. 0.2.3] `Kube-vip.yaml`: If Possible add in your kube-vip manifest (please remove anything that is confidential) Additional context Add any other context about the problem here.
Project: Cilium (Runtime / Cloud Native Network)
File: feature_template.md

name: Feature Proposal about: Suggest a feature to Cilium title: 'CFP: ' labels: 'kind/feature' assignees: '' Thanks for taking time to make a feature proposal for Cilium! If you have usage questions, please try the and see the first. Is your proposed feature related to a problem? If so, please describe the problem Describe the feature you'd like Include any specific requirements you need (Optional) Describe your proposed solution Please complete this section if you have ideas / suggestions on how to implement the feature. We strongly recommend discussing your approach with Cilium committers before spending lots of time implementing a change. For longer proposals, you are welcome to link to an external doc (e.g. a Google doc). We have a to help you structure your proposal - if you would like to use it, please make a copy and ensure it's publicly visible, and then add the link here. Once the CFP is close to being finalized, please add it as a PR to the repo for final approval.
Project: Kata Containers (Runtime / Container Runtime)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting Dan Buch at dan@meatballhat.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
Project: Spiderpool (Runtime / Cloud Native Network)
File: coordinator.md

| Case ID | Title | Priority | Smoke | Status | Other | |||-|-|--|-| | C00001 | coordinator in tuneMode: underlay works well | p1 | smoke | done | | | C00002 | coordinator in tuneMode: overlay works well | p1 | smoke | done | | | C00003 | coordinator in tuneMode: underlay with two NIC | p1 | smoke | done | | | C00004 | coordinator in tuneMode: overlay with two NIC | p1 | smoke | done | | | C00005 | In overlay mode: specify the NIC (net1) where the default route is located, use 'ip r get 8.8.8.8' to see if default route nic is the specify NIC | p2 | | done | | | C00006 | In underlay mode: specify the NIC (net1) where the default route is located, use 'ip r get 8.8.8.8' to see if default route nic is the specify NIC | p2 | | done | | | C00007 | ip conflict detection (ipv4, ipv6) | p2 | | done | | | C00008 | override pod mac prefix | p2 | | done | | | C00009 | gateway connection detection | p2 | | done | | | C00010 | auto clean up the dirty rules(routing\neighborhood) while pod starting | p2 | | done | | | C00011 | In the default scenario (Do not specify the NIC where the default route is located in any way) , use 'ip r get 8.8.8.8' to see if default route NIC is `eth0` | p2 | | done | | | C00012 | In multi-nic case , use 'ip r get <service_subnet> and <hostIP>' to see if src is from pod's eth0, note: only for ipv4. | p2 | | done | | | C00013 | Support `spec.externalTrafficPolicy` for service in Local mode, it works well | p2 | | done | | | C00014 | Specify the NIC of the default route, but the NIC does not exist | p3 | | done | | | C00015 | In multi-NIC mode, whether the NIC name is random and pods are created normally | p3 | | done | | | C00016 | The table name can be customized by hostRuleTable | p3 | | done | | | C00017 | TunePodRoutes If false, no routing will be coordinated | p3 | | done | | | C00018 | The conflict IPs for stateless Pod should be released | p3 | | done | | | C00019 | The conflict IPs for stateful Pod should not be released | p3 | | done | |