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

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> View endpoint health ``` cilium-dbg endpoint health <endpoint id> [flags] ``` ``` cilium endpoint health 5421 ``` ``` -h, --help help for health -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 endpoints
Project: Longhorn (Runtime / Cloud Native Storage)
File: CONTRIBUTING.md

Welcome contributing to Longhorn! This guideline applies to all the repositories under Longhorn. Contributing to Longhorn is not limited to writing the code or submitting the PR. We will also appreciate if you can file issues, provide feedback and suggest new features. In fact, many of Longhorn's features are driven by the community's need. The community plays a big role in the development of Longhorn. Of course, contributing the code is more than welcome. To make things simpler, if you're fixing a small issue (e.g. typo), go ahead submitting a PR and we will pick it up; but if you're planning to submit a bigger PR to implement a new feature, it's easier to submit a new issue to discuss the design with the maintainers first before implementing it. When you're ready to get involved in contributing the code, should help you to get up to the speed. And remember to ! Feel free to join the discussion on Longhorn development at slack channel. Happy contributing! All authors to the project retain copyright to their work. However, to ensure that they are only submitting work that they have rights to, we are requiring everyone to acknowledge this by signing their work. Any copyright notices in this repo should specify the authors as "the Longhorn contributors". To sign your work, just add a line like this at the end of your commit message: ``` Signed-off-by: Sheng Yang <sheng.yang@rancher.com> ``` This can easily be done with the `--signoff/-s` option to `git commit`. By doing this you state that you can certify the following (from https://developercertificate.org/): ``` Developer Certificate of Origin Version 1.1 Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 1 Letterman Drive Suite D4700 San Francisco, CA, 94129 Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. ```
Project: Velero (Runtime / Cloud Native Storage)
File: ark_restic_repo.md

title: "ark restic repo" layout: docs Work with restic repositories Work with restic repositories ``` -h, --help help for repo ``` ``` --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 restic - Get restic repositories
Project: Soda Foundation (Runtime / Cloud Native Storage)
File: Local-Cluster-Installation.md

Here is a tutorial guiding users and new contributors to get familiar with by installing a simple local cluster. If you are an end-user who are interested in this project, some links for installation and testing are as follows: (Recommended) If you are a code developer and wish to contribute in this project, here are some links for quickly installing OpenSDS Hotpot project: (Recommended) If you want to deploy and test opensds integrated with Kubernetes scenario, please refer to: (Recommended) (Deprecated) (Alpha)
Project: Kube-router (Runtime / Cloud Native Network)
File: bug_report.md

name: Report a bug about: Create a bug report to help us improve kube-router title: '' labels: bug assignees: '' What happened? A clear and concise description of what the bug is. What did you expect to happen? A clear and concise description of what you expected to happen. How can we reproduce the behavior you experienced? Steps to reproduce the behavior: Step 1 Step 2 Step 3 Step 4 Screenshots / Architecture Diagrams / Network Topologies If applicable, add those here to help explain your problem. System Information (please complete the following information): Kube-Router Version (`kube-router --version`): [e.g. 1.0.1] Kube-Router Parameters: [e.g. --run-router --run-service-proxy --enable-overlay --overlay-type=full etc.] Kubernetes Version (`kubectl version`) : [e.g. 1.18.3] Cloud Type: [e.g. AWS, GCP, Azure, on premise] Kubernetes Deployment Type: [e.g. EKS, GKE, Kops, Kubeadm, etc.] Kube-Router Deployment Type: [e.g. DaemonSet, System Service] Cluster Size: [e.g. 200 Nodes] Logs, other output, metrics Please provide logs, other kind of output or observed metrics here. Additional context Add any other context about the problem here.
Project: lxd (Runtime / Container Runtime)
File: environment.md

The Incus client and daemon respect some environment variables to adapt to the user's environment and to turn some advanced features on and off. Name | Description : | :- `INCUS_DIR` | The Incus data directory `INCUSINSECURETLS` | If set to true, allows all default Go ciphers both for client <-> server communication and server <-> image servers (server <-> server and clustering are not affected) `PATH` | List of paths to look into when resolving binaries `http_proxy` | Proxy server URL for HTTP `https_proxy` | Proxy server URL for HTTPS `no_proxy` | List of domains, IP addresses or CIDR ranges that don't require the use of a proxy Name | Description : | :- `EDITOR` | What text editor to use `VISUAL` | What text editor to use (if `EDITOR` isn't set) `INCUS_CONF` | Path to the client configuration directory `INCUSGLOBALCONF` | Path to the global client configuration directory `INCUS_REMOTE` | Name of the remote to use (overrides configured default remote) `INCUS_PROJECT` | Name of the project to use (overrides configured default project) Name | Description : | :- `INCUSAGENTPATH` | Path to the directory including the `incus-agent` builds `INCUSCLUSTERUPDATE` | Script to call on a cluster update `INCUSDEVMONITORDIR` | Path to be monitored by the device monitor. This is primarily for testing `INCUS_DOCUMENTATION` | Path to the documentation to serve through the web server `INCUSEXECPATH` | Full path to the Incus binary (used when forking subcommands) `INCUSIDMAPPEDMOUNTS_DISABLE` | Disable idmapped mounts support (useful when testing traditional UID shifting) `INCUSLXCTEMPLATE_CONFIG` | Path to the LXC template configuration directory `INCUSOVMFPATH` | Path to an OVMF build including `OVMFCODE.fd` and `OVMFVARS.ms.fd` `INCUSSECURITYAPPARMOR` | If set to `false`, forces AppArmor off `INCUS_UI` | Path to the web UI to serve through the web server `INCUSUSBIDSPATH` | Path to the hwdata `usb.ids` file
Project: Vineyard (Runtime / Cloud Native Storage)
File: SECURITY.md

The Vineyard community takes all security bugs seriously. Thank you for improving the security quality of vineyard. We adopt a private disclosure process for security issues. If you find a bug, a security vulnerability or any security related issues, please DO NOT file a public issue. Do not create a Github issue. Instead, send your report privately to . Security reports are greatly appreciated and we will publicly thank you for it. Please provide as much information as possible, so we can react quickly. For instance, that could include: Description of the location and potential impact of the vulnerability; A detailed description of the steps required to reproduce the vulnerability (POC scripts, screenshots, and compressed packet captures are all helpful to us) Whatever else you think we might need to identify the source of this vulnerability One of our maintainers will acknowledge your email within 48 hours, and will send a more detailed response within 48 hours indicating the next steps in handling your report. After the initial reply to your report, the maintainers will endeavor to keep you informed of the progress towards a fix and full announcement, and may ask for additional information or guidance.
Project: Kata Containers (Runtime / Container Runtime)
File: LICENSE.md

Copyright (C) 2014 by Oleku Konko 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: Ceph (Runtime / Cloud Native Storage)
File: elasticsearch_adapter.md

This directory contains an example `elasticsearch_adapter.lua` on how to use to push fields of the RGW requests to . Install and run Elasticsearch using docker: ```bash docker network create elastic docker pull elasticsearch:2.4.6 docker run --net elastic -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" elasticsearch:2.4.6 ``` Upload the script: ```bash radosgw-admin script put --infile=elasticsearch_adapter.lua --context=postRequest ``` Add the packages used in the script: ```bash radosgw-admin script-package add --package='elasticsearch 1.0.0-1' --allow-compilation radosgw-admin script-package add --package='lunajson' --allow-compilation radosgw-admin script-package add --package='lua-cjson 2.1.0-1' --allow-compilation ``` Restart radosgw. Send a request: ```bash s3cmd --host=localhost:8000 --host-bucket="localhost:8000/%(bucket)" --accesskey=0555b35654ad1656d804 --secretkey=h7GhxuBLTrlhVUyxSPUKUV8r/2EI4ngqJxD7iBdBYLhwluN30JaT3Q== mb s3://mybucket s3cmd --host=localhost:8000 --host-bucket="localhost:8000/%(bucket)" --accesskey=0555b35654ad1656d804 --secretkey=h7GhxuBLTrlhVUyxSPUKUV8r/2EI4ngqJxD7iBdBYLhwluN30JaT3Q== put -P /etc/hosts s3://mybucket curl http://localhost:8000/mybucket/hosts ``` Search by bucket id from Elasticsearch: ```bash curl -X GET "localhost:9200/rgw/_search?pretty" -H 'Content-Type: application/json' -d' { "query": { "match": { "Bucket.Id": "05382336-b2db-409f-82dc-f28ab5fef978.4471.4471" } } } ' ``` Lua 5.3
Project: Longhorn (Runtime / Cloud Native Storage)
File: CHANGELOG-1.4.3.md

Longhorn v1.4.3 is the latest stable version of Longhorn 1.4. It introduces improvements and bug fixes in the areas of stability, resilience, and so on. Please try it out and provide feedback. Thanks for all the contributions! For the definition of stable or latest release, please check . Please ensure your Kubernetes cluster is at least v1.21 before installing v1.4.3. Longhorn supports 3 installation ways including Rancher App Marketplace, Kubectl, and Helm. Follow the installation instructions . Please read the first and ensure your Kubernetes cluster is at least v1.21 before upgrading to Longhorn v1.4.3 from v1.3.x/v1.4.x, which are only supported source versions. Follow the upgrade instructions . N/A Please follow up on about any outstanding issues found after this release. ) - @c3y1huang @chriscchien ) - @yangchiu @ChanYiLin @mantissahz ) - @weizhe0422 @PhanLe1010 @smallteeths ) - @yangchiu @mantissahz ) - @ChanYiLin @mantissahz ) - @c3y1huang @roger-ryao ) - @yangchiu @derekbit ) - @c3y1huang @roger-ryao ) - @weizhe0422 @ejweber ) - @yangchiu @mantissahz ) - @c3y1huang @chriscchien ) - @WebberHuang1118 @chriscchien ) - @ejweber @chriscchien ) - @mantissahz @roger-ryao ) - @c3y1huang @khushboo-rancher ) - @yangchiu @ChanYiLin @mantissahz ) - @yangchiu @ejweber ) - @c3y1huang @chriscchien ) - @yangchiu @PhanLe1010 @khushboo-rancher ) - @derekbit @roger-ryao @ChanYiLin @PhanLe1010 @WebberHuang1118 @c3y1huang @chriscchien @derekbit @ejweber @innobead @khushboo-rancher @mantissahz @roger-ryao @smallteeths @weizhe0422 @yangchiu
Project: Container Network Interface (CNI) (Runtime / Cloud Native Network)
File: RELEASING.md

Releases are performed by maintainers and should usually be discussed and planned at a maintainer meeting. Choose the version number. It should be prefixed with `v`, e.g. `v1.2.3` Take a quick scan through the PRs and issues to make sure there isn't anything crucial that must be in the next release. Create a draft of the release note Discuss the level of testing that's needed and create a test plan if sensible Check what version of `go` is used in the build container, updating it if there's a new stable release. Make sure you are on the master branch and don't have any local uncommitted changes. Create a signed tag for the release `git tag -s $VERSION` (Ensure that GPG keys are created and added to GitHub) Push the tag to git `git push origin <TAG>` Create a release on Github, using the tag which was just pushed. Add the release note to the release. Announce the release on at least the CNI mailing, IRC and Slack.
Project: Velero (Runtime / Cloud Native Storage)
File: start-contributing.md

title: "Start contributing" layout: docs Please familiarize yourself with the before contributing. Also, see for instructions on the developer certificate of origin that we require. Having a high level design document with the proposed change and the impacts helps the maintainers evaluate if a major change should be incorporated. To make a design pull request, you can copy the template found in the `design/_template.md` file into a new Markdown file. You may join the Velero community and contribute in many different ways, including helping us design or test new features. For any significant feature we consider adding, we start with a design document. You may find a list of in progress new designs here: https://github.com/vmware-tanzu/velero/pulls?q=is%3Aopen+is%3Apr+label%3ADesign. Feel free to review and help us with your input. You can also vote on issues using :+1: and :-1:, as explained in our and templates. This will help us quantify importance and prioritize issues. For information on how to connect with our maintainers and community, join our online meetings, or find good first issues, start on our page. Please browse our list of resources, including a playlist of past online community meetings, blog posts, and other resources to help you get familiar with our project: . If you are ready to jump in and test, add code, or help with documentation, please use the navigation on the left under `Contribute`.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-generic_metrics_list.md

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> List all metrics for the operator ``` cilium-operator-generic metrics list [flags] ``` ``` -h, --help help for list -p, --match-pattern string Show only metrics whose names match matchpattern -o, --output string json| yaml| jsonpath='{}' -s, --server-address string Address of the operator API server (default "localhost:9234") ``` - Access metric status of the operator
Project: OpenEBS (Runtime / Cloud Native Storage)
File: openebs-provisioner-high-availibility.md

`openebs-provisioner` runs within the Kubernetes Cluster and should always be available. If any node, currently running a openebs-provisioner goes down, the pod should be assigned to another available node in the cluster. One node should be running only single `openebs-provsioner` to avoid single-point-of-failure of a node. For making `openebs-provisioner` highly available, set the `replicas` to at least 2 in `openebs-operator.yaml` for `openebs-provisioner` deployment. Pod anti-affinity can prevent the scheduler from placing a new `openebs-provsioner` pod on the node that is already running one instance of `openebs-provisioner`. You can change affinity selector in the Deployment spec. | AFFINITY SELECTOR | REQUIREMENTS MET | REQUIREMENTS NOT MET | REQUIREMENTS LOST | ||| | | |`requiredDuringSchedulingIgnoredDuringExecution` | Runs | Fails | Keeps Running | |`preferredDuringSchedulingIgnoredDuringExecution` | Runs | Runs | Keeps Running| |`requiredDuringSchedulingRequiredDuringExecution` (Not recommended) | Runs | Fails | Fails| ``` apiVersion: apps/v1beta1 kind: Deployment metadata: name: openebs-provisioner namespace: default spec: replicas: 2 template: spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: # <-- Affinity Selector weight: 100 podAffinityTerm: labelSelector: matchExpressions: key: name operator: In values: openebs-provisioner topologyKey: "kubernetes.io/hostname" template: metadata: labels: name: openebs-provisioner # <-- Default label spec: serviceAccountName: openebs-maya-operator containers: name: openebs-provisioner imagePullPolicy: Always image: openebs/openebs-k8s-provisioner:0.4.0 env: name: NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName ```
Project: containerd (Runtime / Container Runtime)
File: CONTRIBUTING.md

Welcome to Kubernetes. We are excited about the prospect of you joining our ! The Kubernetes community abides by the CNCF . Here is an excerpt: As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. We have full documentation on how to get started contributing here: <! If your repo has certain guidelines for contribution, put them here ahead of the general k8s resources --> Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests - Main contributor documentation, or you can just jump directly to the - Common resources for existing developers - We have a diverse set of mentorship programs available that are always looking for volunteers! <! Custom Information - if you're copying this template for the first time you can add custom content here, for example: - Replace `kubernetes-users` with your slack channel string, this will send users directly to your channel. -->
Project: Weave Net (Runtime / Cloud Native Network)
File: troubleshooting-ipam.md

title: Troubleshooting the IP Allocator menu_order: 50 search_type: Documentation The command weave status reports on the current status of the weave router and IP allocator: ``` ... Service: ipam Status: awaiting consensus (quorum: 2, known: 0) Range: 10.32.0.0-10.47.255.255 DefaultSubnet: 10.32.0.0/12 ... ``` The first section covers the router; see the [troubleshooting guide](/site/troubleshooting.md#weave-status) for full details. The 'Service: ipam' section displays the consensus state as well as the total allocation range and default subnet. Columns are as follows: 'Status' - allocator state 'idle' - no allocation requests or claims have been made yet; consensus is deferred until then 'awaiting consensus' - an attempt to achieve consensus is ongoing, triggered by an allocation or claim request; allocations will block. This state persists until a quorum of peers are able to communicate amongst themselves successfully. 'priming' - peer is an observer and is waiting to receive IPAM data from seeding or consensus elsewhere in the network 'ready' - consensus achieved; allocations proceed normally 'waiting for IP range grant from peers' - peer has exhausted its agreed portion of the range and is waiting to be granted some more 'all IP ranges owned by unreachable peers' - peer has exhausted its agreed portion of the range but cannot reach anyone to ask for more 'Range' - total allocation range set by `--ipalloc-range` 'DefaultSubnet' - default subnet set by `--ipalloc-default-subnet` Information regarding the division of the IP allocation range amongst peers and their reachability can be obtained with ``` $ weave status ipam 00:00:00:00:00:01(one) 349526 IPs (33.3% of total) (2 active) 00:00:00:00:00:02(two) 349525 IPs (33.3% of total) 00:00:00:00:00:03(three) 349525 IPs (33.3% of total) - unreachable! ``` Columns are as follows: Peer Name and Nickname Absolute quantity/percentage of allocation range managed by peer Active - number of IP addresses in use on that peer - this is only available for the peer where you run the status command. Indication of unreachability. This means that the peer is not visible (directly or indirectly) to the peer on which `weave status ipam` was run; whilst this could be a transient condition due to a partition, it may be because the peer has failed and needs to be removed administratively - see [Starting, Stopping and Removing Peers](/site/tasks/ipam/stop-remove-peers-ipam.md) for more details. If you see the message: `IP allocation was seeded by different peers`, this means that some Weave Net peers were initialized into one cluster and some into another cluster; Weave Net cannot operate in this state. To recover, you need to eliminate the IPAM data from the affected nodes and restart. If you installed via the Kubernetes Addon, this data will be in a file under `/var/lib/weave` on the node - delete this file and restart the node. For other installations, run `weave reset` and restart. Any existing connections to containers will be lost.