cwielenb/CNCF-Dataset huggingface dataset:
Project: Knative (Orchestration & Management / Scheduling & Orchestration)
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: Gloo (Orchestration & Management / API Gateway)
File: cors.proto.sk.md

title: "cors.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> CorsPolicy defines Cross-Origin Resource Sharing for a virtual service. ```yaml "allowOrigin": []string "allowOriginRegex": []string "allowMethods": []string "allowHeaders": []string "exposeHeaders": []string "maxAge": string "allowCredentials": bool "disableForRoute": bool ``` | Field | Type | Description | | -- | - | -- | | `allowOrigin` | `[]string` | Specifies the origins that will be allowed to make CORS requests. An origin is allowed if either alloworigin or alloworigin_regex match. | | `allowOriginRegex` | `[]string` | Specifies regex patterns that match origins that will be allowed to make CORS requests. An origin is allowed if either alloworigin or alloworigin_regex match. | | `allowMethods` | `[]string` | Specifies the content for the access-control-allow-methods header. | | `allowHeaders` | `[]string` | Specifies the content for the access-control-allow-headers header. | | `exposeHeaders` | `[]string` | Specifies the content for the access-control-expose-headers header. | | `maxAge` | `string` | Specifies the content for the access-control-max-age header. | | `allowCredentials` | `bool` | Specifies whether the resource allows credentials. | | `disableForRoute` | `bool` | Optional, only applies to route-specific CORS Policies, defaults to false. If set, the CORS Policy (specified on the virtual host) will be disabled for this route. | <!-- Start of HubSpot Embed Code --> <script type="text/javascript" id="hs-script-loader" async defer src="//js.hs-scripts.com/5130874.js"></script> <!-- End of HubSpot Embed Code -->
Project: Inlets (Orchestration & Management / Service Proxy)
File: cassandra-tutorial.md

TCP tunnel for Apache Cassandra running on your local machine, out to another network Scenario: You're running Apache Cassandra, which uses TCP and which cannot be forwarded easily by Ngrok or Inlets OSS. Inlets Pro provides a solution for you. Provision a VM on DigitalOcean or another IaaS provider. Log in with ssh and obtain the binary: ```sh curl -SLsf https://github.com/inlets/inlets-pro/releases/download/0.6.0/inlets-pro > inlets-pro chmod +x ./inlets-pro mv ./inlets-pro /usr/bin/inlets-pro ``` Find your public IP: ``` export IP=$(curl -s ifconfig.co) ``` Confirm the IP with `echo $IP` and save it, you need it for the client Get an auth token and save it for later to use with the client ```sh export TOKEN="$(head -c 16 /dev/urandom |shasum|cut -d'-' -f1)" echo $TOKEN ``` Start the server: ```sh sudo inlets-pro server \ --auto-tls \ --auto-tls-name $IP \ --remote-tcp 127.0.0.1 \ --token $TOKEN ``` Using Docker you can run Cassandra. ```sh docker run --name cassandra -p 9042:9042 -ti cassandra:latest ``` The client port is `9042` which will become available on the public IP Now run the inlets client on the other side: For a Linux client ```sh curl -SLsf https://github.com/inlets/inlets-pro/releases/download/0.6.0/inlets-pro > inlets-pro chmod +x ./inlets-pro mv ./inlets-pro /usr/bin/inlets-pro ``` For a MacOS client ```sh curl -SLsf https://github.com/inlets/inlets-pro/releases/download/0.6.0/inlets-pro-darwin > inlets-pro chmod +x ./inlets-pro sudo mv ./inlets-pro /usr/bin/inlets-pro ``` Run the inlets-pro client: ```sh export IP="" # take this from the exit node export TOKEN="" # take this from the server earlier export LICENSE="" # your license sudo -E inlets-pro client \ --connect wss://$IP:8123/connect \ --tcp-ports 9042 \ --token $TOKEN \ --license $LICENSE ``` On your laptop or another computer use the Cassandra client `cqlsh` to connect and verify the tunnel is operational. ```sh export IP="" # Exit-node IP docker run \ -e CQLSH_HOST=$IP \ -e CQLSH_PORT=9042 \ -it --rm cassandra cqlsh ``` Now you're connected. ```sh Connected to Test Cluster at 185.136.232.127:9042. [cqlsh 5.0.1 | Cassandra 3.11.4 | CQL spec 3.4.4 | Native protocol v4] Use HELP for help. cqlsh> ``` Try a query: ```sh cqlsh> SELECT clustername, listenaddress FROM system.local; clustername | listenaddress --+- Test Cluster | 172.17.0.2 (1 rows) cqlsh> ```
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.2.0-released.md

title: "Avro 1.2.0" linkTitle: "Avro 1.2.0" date: 2009-10-15 <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> Apache Avro 1.2.0 is now available!
Project: Tengine (Orchestration & Management / Service Proxy)
File: ngx_procs_module.md

provides a mechanism to support standalone processes a daytime server module, run in a standalone process. http://tengine.taobao.org/examples/ngxprocdaytime_module processes { process echo { eho_str "hello, world"; echo on; listen 8888; count 1; priority 1; delay_start 10s; respawn off; } process example { count 1; priority 0; delay_start 0s; respawn on; } } Syntax: process `name { }` Default: `none` Context: `processes` Syntax: count `num` Default: `1` Context: `process` Specify the number of processes which will be forked. Syntax: priority `num` Default: `0` Context: `process` Priority is a value in the range -20 to 20. Lower priorities cause more favorable scheduling. Syntax: delay\_start `time` Default: `300ms` Context: `process` The directive specifies the time to wait before process starts. Syntax: respawn `on | off` Default: `on` Context: `process` The directive specifies whether the process will be restarted by nginx when it encounters some errors and exits.
Project: Nasp (Orchestration & Management / Service Mesh)
File: README.md

is a set of projects, which in tandem are capable of enhancing plain old TCP sockets in a frictionless way, so that application developers can focus on their business logic instead of dealing with the complexity of TLS, mTLS, and other security-related concerns. It is doing this seamlessly, no code changes or re-compilations or re-deployments are required. You only have to configure Camblet itself, and it will do the rest. The features are the following: providing zero-trust identity for UNIX TCP sockets through mTLS access control, authorization and authentication (through ) providing frictionless TLS termination for those TCP sockets supporting every Linux-based machine (bare-metal, vanilla VM, Kubernetes, etc... you name it) This repository contains the source code of the `camblet` multi-purpose binary for controlling the , which is a kernel module that does the processing of the user traffic. Camblet's architecture consists of currently 2 different components: the kernel module and the agent. This will change in the future, we plan to add a control plane, but the current architecture is the following: The Camblet kernel module comes with a user space written in Go. The kernel module exposes a character device: `/dev/camblet`, which is opened by the agent, and the CLI talks with the agent. One usually runs this CLI on the Linux host itself. The agent is the server side of the CLI. It is responsible for the following: communicates with the kernel module directly parses policy files and loads them to the kernel module generates certificates to act as a CA signs CSR requests generated by the kernel module adds metadata from the host environment to enrich process data. (e.g. Kubernetes, AWS, etc...) traces the logs of the kernel module per process Usage: ```bash sudo camblet agent --policies-path $(pwd)/camblet.d/policies --services-path $(pwd)/camblet.d/services ``` Our primary development environment is since it supports x86_64 and ARM as well. Follow the instructions for for setting up the development environment. The CLI is written in Go, so you need to have a Go development environment set up. The CLI is built with the help of , so you need to have `make` installed as well. ```bash GOOS=linux make build ``` ```bash sudo ./build/camblet agent --policies-path $(pwd)/camblet.d/policies --services-path $(pwd)/camblet.d/services ``` Join our community on , and then find us on the channel for more fun!
Project: Apache bRPC (Orchestration & Management / Remote Procedure Call)
File: status.md

shows primary statistics of services inside the server. The data sources are same with , but stats are grouped differently. Meanings of the fields above: non_service_error: number of errors raised outside processing code of the service. When a valid service is obtained, the subsequent error is regarded as service_error, otherwise it is regarded as non_service_error (such as request parsing failed, service name does not exist, request concurrency exceeding limit, etc.). As a contrast, failing to access back-end servers during the processing is an error of the service, not a non_service_error. Even if the response written out successfully stands for failure, the error is counted into the service rather than non_service_error. connection_count: number of connections to the server from clients, not including number of outward connections which are displayed at /vars/rpcchannelconnection_count. example.EchoService: Full name of the service, including the package name defined in proto. Echo (EchoRequest) returns (EchoResponse): Signature of the method. A service can have multiple methods. Click links on request/response to see schemes of the protobuf messages. count: Number of requests that are successfully processed. error: Number of requests that are failed to process. latency: average latency in recent 60s/60m/24h/30d from right to left on html, average latency in recent 10s(by default, specified by ) on plain texts. latency_percentiles: 80%, 90%, 99%, 99.9% percentiles of latency in 10 seconds(specified by). Curves with historical values are shown on html. latency_cdf: shows percentiles as , only available on html. max_latency: max latency in recent 60s/60m/24h/30d from right to left on html, max latency in recent 10s(by default, specified by ) on plain texts. qps: QPS(Queries Per Second) in recent 60s/60m/24h/30d from right to left on html. QPS in recent 10s(by default, specified by ) on plain texts. processing: (renamed to concurrency in master) Number of requests being processed by the method. If this counter can't hit zero when the traffic to the service becomes zero, the server probably has bugs, such as forgetting to call done->Run() or stuck on some processing steps. Users may customize descriptions on /status by letting the service implement . ```c++ class MyService : public XXXService, public brpc::Describable { public: ... void Describe(std::ostream& os, const brpc::DescribeOptions& options) const { os << "my_status: blahblah"; } }; ``` For example:
Project: Gloo (Orchestration & Management / API Gateway)
File: apple_dns_resolver.proto.sk.md

title: "applednsresolver.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Configuration for apple DNS resolver. ```yaml ``` | Field | Type | Description | | -- | - | -- | <!-- Start of HubSpot Embed Code --> <script type="text/javascript" id="hs-script-loader" async defer src="//js.hs-scripts.com/5130874.js"></script> <!-- End of HubSpot Embed Code -->
Project: APISIX (Orchestration & Management / API Gateway)
File: support-fips-in-apisix.md

id: support-fips-in-apisix title: Support FIPS in APISIX keywords: API Gateway Apache APISIX Code Contribution Building APISIX OpenSSL 3.0 FIPS description: Compile apisix-runtime with OpenSSL 3.0 (FIPS enabled) <!-- --> OpenSSL 3.0 mode. To support FIPS in APISIX, you can compile apisix-runtime with OpenSSL 3.0. To compile apisix-runtime with OpenSSL 3.0, run the commands below as root user: ```bash cd $(mktemp -d) OPENSSL3PREFIX=${OPENSSL3PREFIX-/usr/local} apt install -y build-essential git clone https://github.com/openssl/openssl cd openssl ./Configure --prefix=$OPENSSL3_PREFIX/openssl-3.0 enable-fips make install echo $OPENSSL3_PREFIX/openssl-3.0/lib64 > /etc/ld.so.conf.d/openssl3.conf ldconfig $OPENSSL3PREFIX/openssl-3.0/bin/openssl fipsinstall -out $OPENSSL3PREFIX/openssl-3.0/ssl/fipsmodule.cnf -module $OPENSSL3_PREFIX/openssl-3.0/lib64/ossl-modules/fips.so sed -i 's@# .include fipsmodule.cnf@.include '"$OPENSSL3PREFIX"'/openssl-3.0/ssl/fipsmodule.cnf@g; s/# \(fips = fipssect\)/\1\nbase = basesect\n\n[basesect]\nactivate=1\n/g' $OPENSSL3_PREFIX/openssl-3.0/ssl/openssl.cnf cd .. export ccopt="-I$OPENSSL3PREFIX/openssl-3.0/include" export ldopt="-L$OPENSSL3PREFIX/openssl-3.0/lib64 -Wl,-rpath,$OPENSSL3_PREFIX/openssl-3.0/lib64" wget --no-check-certificate https://raw.githubusercontent.com/api7/apisix-build-tools/master/build-apisix-runtime.sh chmod +x build-apisix-runtime.sh ./build-apisix-runtime.sh ``` This will install apisix-runtime to `/usr/local/openresty`.
Project: KubeGateway (Orchestration & Management / API Gateway)
File: bug-report.md

name: Bug Report about: Report a bug encountered while operating Kubernetes labels: kind/bug <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via https://kubernetes.io/security/ --> What happened: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use `kubectl version`): Cloud provider or hardware configuration: OS (e.g: `cat /etc/os-release`): Kernel (e.g. `uname -a`): Install tools: Network plugin and version (if this is a network-related bug): Others:
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: minsuccess.md

Sometimes we want to deploy our job with some service tasks (nginx, redis and so on) which will always be in `Running` state. So how to determine such kind job is completed? Only with `minAvailable` is not enough, because `minAvailable` only work at Job pending and all tasks Completed/Failed. It lacks the ability to change the Job state during the Job is Running state, and reclaim these service tasks. In order to solve this problem, we provide `minSuccess` field which will help the job to determine how many succeed tasks does it need to change its state to `Completed`, and reclaim the other Running pods. ```yaml apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: name: test-job spec: minAvailable: 6 minSuccess: 5 schedulerName: volcano queue: default plugins: svc: [] tasks: replicas: 5 name: "task" template: metadata: name: task spec: containers: image: ubuntu imagePullPolicy: IfNotPresent name: task resources: requests: cpu: "1" restartPolicy: OnFailure replicas: 1 name: "redis" template: metadata: name: redis spec: containers: image: redis imagePullPolicy: IfNotPresent name: redis restartPolicy: OnFailure ``` From the above picture, we can find that when there are 5 tasks completed, the controller will know it's the time to mark the job `Completed`, and reclaim the redis pod.
Project: BFE (Orchestration & Management / Service Proxy)
File: cluster_table.data.md

cluster_table.data records the load balancing config among instances. | Config Item | Description | | | - | | Version | String<br>Verson of config file | | Config | Object<br>config of all clusters | | Config{k} | String<br>name of cluster | | Config{v} | Object<br>config of cluster | | Config{v}{k} | String<br>name of subcluster | | Config{v}{v} | Object<br>config of subcluster(a list of instance) | | Config Item | Description | | | - | | Addr | String<br>ip address of instance | | Name | String<br>name of instance | | Port | String<br>port of instance | | Weight | String<br>weight of instance | ```json { "Config": { "cluster_example": { "example.bfe.bj": [ { "Addr": "10.199.189.26", "Name": "example_hostname", "Port": 10257, "Weight": 10 } ] } }, "Version": "20190101000000" } ```
Project: BFE (Orchestration & Management / Service Proxy)
File: mod_static.md

mod_static serves static files. conf/modstatic/modstatic.conf | Config Item | Description | | -- | | | Basic.DataPath | String<br>Path of rule configuration | ```ini [Basic] DataPath = modstatic/staticrule.data ``` conf/modstatic/staticrule.data | Config Item | Description | | -- | | | Version | String<br>Version of config file | | Config | Struct<br>Static rules for each product | | Config{k} | String<br>Product name | | Config{v} | Object<br>A ordered list of static rules | | Config{v}[] | Object<br>A static rule | | Config{v} | | Config{v}[].Action | Object<br>A static action | | Config{v}[].Action.Cmd | String<br>Name of static action | | Config{v}[].Action.Params | Object<br>Parameters of static action | | Action | Description | | - | - | | BROWSE | Serve static files. <br>The first parameter is the location of root directory.<br> The second parameter is the name of default file.| ```json { "Config": { "example_product": [ { "Cond": "reqhostin(\"www.example.org\")", "Action": { "Cmd": "BROWSE", "Params": [ "./", "index.html" ] } } ] }, "Version": "20190101000000" } ``` | Metric | Description | | -- |-| | FILEBROWSECOUNT | Counter for BROWSE requests | | FILECURRENTOPENED | Counter for current opend files | | FILEBROWSENOT_EXIST | Counter for "file not exists" requests | | FILEBROWSESIZE | Total served file size |
Project: etcd (Orchestration & Management / Coordination & Service Discovery)
File: triage_prs.md

Speed up PR management. The `etcd` PRs are listed at https://github.com/etcd-io/etcd/pulls A PR can have various labels, milestones, reviewers, etc. The detailed list of labels can be found at https://github.com/kubernetes/kubernetes/labels Following are a few example searches on PR for convenience: These guidelines serve as a primary document for managing PRs in `etcd`. Everyone is welcome to help manage PRs but the work and responsibilities discussed in this document are created with `etcd` maintainers and active contributors in mind. Poke PR owner if review comments are not addressed in 15 days. If the PR owner does not reply in 90 days, update the PR with a new commit if possible. If not, inactive PR should be closed after 180 days. Reviewers are responsive in a timely fashion, but considering everyone is busy, give them some time after requesting a review if a quick response is not provided. If the response is not provided in 10 days, feel free to contact them via adding a comment in the PR or sending an email or message on Slack. Make sure that appropriate reviewers are added to the PR. Also, make sure that a milestone is identified. If any of these or other important labels are missing, add them. If a correct label cannot be decided, leave a comment for the maintainers to do so as needed.
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_edit_settings.md

title: "glooctl edit settings" weight: 5 root command for settings ``` -h, --help help for settings --name string name of the resource to read or write -n, --namespace string namespace for reading or writing resources (default "gloo-system") -o, --output OutputType output format: (yaml, json, table, kube-yaml, wide) (default table) ``` ``` -c, --config string set the path to the glooctl config file (default "<home_directory>/.gloo/glooctl-config.yaml") --consul-address string address of the Consul server. Use with --use-consul (default "127.0.0.1:8500") --consul-allow-stale-reads Allows reading using Consul's stale consistency mode. --consul-datacenter string Datacenter to use. If not provided, the default agent datacenter is used. Use with --use-consul --consul-root-key string key prefix for for Consul key-value storage. (default "gloo") --consul-scheme string URI scheme for the Consul server. Use with --use-consul (default "http") --consul-token string Token is used to provide a per-request ACL token which overrides the agent's default token. Use with --use-consul -i, --interactive use interactive mode --kube-context string kube context to use when interacting with kubernetes --kubeconfig string kubeconfig to use, if not standard one --resource-version string the resource version of the resource we are editing. if not empty, resource will only be changed if the resource version matches --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - Edit a Gloo resource - Configure external auth settings (Enterprise) - Configure rate limit settings (Enterprise)
Project: KubeAdmiral (Orchestration & Management / Scheduling & Orchestration)
File: GOVERNANCE.md

The governance model adopted in KubeAdmiral is influenced by many CNCF projects. Open: KubeAdmiral is open source community. See (TODO: add Contributor License Agreement). Welcoming and respectful: See . Transparent and accessible: Work and collaboration should be done in public. Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, scope and design principles. The KubeAdmiral is aligned with the CNCF Code of Conduct. See community membership (TODO: add community membership). Decisions are made based on consensus between maintainers. Proposals and ideas can either be submitted for agreement via a github issue or PR, or by sending an email to (TODO: register an email for the org). In general, we prefer that technical issues and maintainer membership are amicably worked out between the persons involved. If a dispute cannot be decided independently, get a third-party maintainer (e.g. a mutual contact with some background on the issue, but not involved in the conflict) to intercede and the final decision will be made. Decision making process should be transparent to adhere to the principles of KubeAdmiral project. Some contents in this documents have been borrowed from , , and projects.