cwielenb/CNCF-Dataset huggingface dataset:
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.8.0-released.md

title: "Avro 1.8.0" linkTitle: "Avro 1.8.0" date: 2016-01-29 <!-- 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.8.0 has been released!
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: pull-request.md

Pull Request is a way of software cooperation, which is a process of bringing code involving different functions into the trunk. During this process, the code can be discussed, reviewed, and modified. In Pull Request, we try not to discuss the implementation of the code. The general implementation of the code and its logic should be determined in Issue. In the Pull Request, we only focus on the code format and code specification, so as to avoid wasting time caused by different opinions on implementation. Title Format: `Pull Request Description` The corresponding relationship between `Pull Request Type` and `Issue Type` is as follows: <table> <thead> <tr> <th style="width: 10%; text-align: center;">Issue Type</th> <th style="width: 20%; text-align: center;">Pull Request Type</th> <th style="width: 20%; text-align: center;">Example(Suppose Issue No is 3333)</th> </tr> </thead> <tbody> <tr> <td style="text-align: center;">Feature</td> <td style="text-align: center;">Feature</td> <td style="text-align: center;"> Implement xxx</td> </tr> <tr> <td style="text-align: center;">Bug</td> <td style="text-align: center;">Fix</td> <td style="text-align: center;"> Fix xxx</td> </tr> <tr> <td style="text-align: center;">Improvement</td> <td style="text-align: center;">Improvement</td> <td style="text-align: center;"> Improve the performance of xxx</td> </tr> <tr> <td style="text-align: center;">Test</td> <td style="text-align: center;">Test</td> <td style="text-align: center;"> Add the e2e test of xxx</td> </tr> <tr> <td style="text-align: center;">Sub-Task</td> <td style="text-align: center;">(Parent type corresponding to Sub-Task)</td> <td style="text-align: center;"> Implement xxx</td> </tr> </tbody> </table> `Issue No` refers to the Issue number corresponding to the current Pull Request to be resolved, `Module Name` is the same as the `Module Name` of Issue. Branch name format: `Pull Request type`-`Issue number`. e.g. Feature-3333 Please refer to the commit message section. DolphinScheduler uses `Spotless` to automatically fix code style and formatting errors, see `Code Style` section for details. How to deal with one Pull Request to many Issues scenario. First of all, there are fewer scenarios for one Pull Request to many Issues. The root cause is that multiple issues need to do the same thing. Usually, there are two solutions to this scenario: the first is to merge multiple issues with into the same issue, and then close the other issues; the second is multiple issues have subtle differences. In this scenario, the responsibilities of each issue can be clearly divided. The type of each issue is marked as Sub-Task, and then these sub task type issues are associated with one issue. And each Pull Request is submitted should be associated with only one issue of a sub task.
Project: Contour (Orchestration & Management / Service Proxy)
File: contour-xds-resources.md

Sometimes it's helpful to be able to interrogate Contour to find out exactly what resource data it is sending to Envoy. Contour ships with a `contour cli` subcommand which can be used for this purpose. Because Contour secures its communications with Envoy using Secrets in the cluster, the easiest way is to run `contour cli` commands inside the pod. Do this is via `kubectl exec`: ```bash $ CONTOUR_POD=$(kubectl -n projectcontour get pod -l app=contour -o jsonpath='{.items[0].metadata.name}') $ kubectl -n projectcontour exec $CONTOUR_POD -c contour -- contour cli lds --cafile=/certs/ca.crt --cert-file=/certs/tls.crt --key-file=/certs/tls.key ``` Which will stream changes to the LDS api endpoint to your terminal. Replace `contour cli lds` with `contour cli rds` for route resources, `contour cli cds` for cluster resources, and `contour cli eds` for endpoints.
Project: Gloo (Orchestration & Management / API Gateway)
File: solo_jwt_authn.proto.sk.md

title: "solojwtauthn.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> ```yaml "jwtAuthn": .solo.io.envoy.extensions.filters.http.jwt_authn.v3.JwtAuthentication "stage": int ``` | Field | Type | Description | | -- | - | -- | | `jwtAuthn` | | The JwtAuthentication config for this filter. | | `stage` | `int` | Only SoloJwtAuthnPerRoute.JwtAuthnPerRoute with matching stage will be used with this filter. | ```yaml "requirement": string "claimsToHeaders": map<string, .envoy.config.filter.http.solojwtauthn.v2.SoloJwtAuthnPerRoute.ClaimToHeaders> "clearRouteCache": bool "payloadInMetadata": string ``` | Field | Type | Description | | -- | - | -- | | `requirement` | `string` | | | `claimsToHeaders` | `map<string, .envoy.config.filter.http.solojwtauthn.v2.SoloJwtAuthnPerRoute.ClaimToHeaders>` | Copy the claims from the payload field is the key. non-existant fields are ignored. | | `clearRouteCache` | `bool` | clear the route cache if claims were added to the header. | | `payloadInMetadata` | `string` | To easly integrate with other filters, this will copy the payload to this name in the dynamic metadata. The payload will only be copied if one payload is present (i.e. or match). | If this is specified, one of the claims will be copied to a header and the route cache will be cleared. ```yaml "claim": string "header": string "append": bool ``` | Field | Type | Description | | -- | - | -- | | `claim` | `string` | | | `header` | `string` | | | `append` | `bool` | | ```yaml "claims": []envoy.config.filter.http.solojwtauthn.v2.SoloJwtAuthnPerRoute.ClaimToHeader ``` | Field | Type | Description | | -- | - | -- | | `claims` | | | ```yaml "jwtConfigs": map<int, .envoy.config.filter.http.solojwtauthn.v2.SoloJwtAuthnPerRoute> ``` | Field | Type | Description | | -- | - | -- | | `jwtConfigs` | `map<int, .envoy.config.filter.http.solojwtauthn.v2.SoloJwtAuthnPerRoute>` | Map from stage number to jwt config This jwt config will only be processed by filters with the same stage number. | <!-- 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: Kusk Gateway (Orchestration & Management / API Gateway)
File: mock-an-api.md

In this section you will deploy a mocked API. A mocked API is an API that returns fake API responses. Kusk reads the OpenAPI schema and can provide those mocked results, without the need of having an implementation of the API. A mock API is helpful when, for example, a frontend team does not want to get blocked by the backend team's API implementation, so the frontend team can start working on using the API when scaffolding their work. To configure Kusk Gateway, you will need to create an OpenAPI definition of your API. Once created, you can add the gateway configurations as OpenAPI extensions (similar to code annotations). The Kusk OpenAPI extension starts with `x-kusk`. For mocking to work, you will need to have an `example` field under `Content-Type` section, in this case under `application/json`. ```yaml title="api.yaml" openapi: 3.0.0 info: title: simple-api version: 0.1.0 x-kusk: mocking: enabled: true paths: /hello: get: responses: "200": description: A simple hello world! content: application/json: example: message: Hello from a mocked response! schema: type: object properties: message: type: string ``` ```sh kusk deploy -i api.yaml ``` ```sh title="Expected output:" successfully parsed api.yaml initiallizing deployment to fleet kusk-gateway-envoy-fleet api.gateway.kusk.io/simple-api created ``` First, you'll need to get the IP address of the API by running the following command: ```sh kusk ip ``` ```sh title="Expected output:" 123.45.67.89 ``` And now test the API using `curl`: ```sh curl 123.45.67.89/hello ``` ```sh title="Expected output:" {"message":"Hello from a mocked response!"} ``` :::info If you're running a local cluster with Minikube you might not have an IP address when running `kusk ip` and you might find the following message: ```sh EnvoyFleet doesn't have an External IP address assigned yet. Try port-forwarding by running: kubectl port-forward svc/kusk-gateway-envoy-fleet -n kusk-system 8080:80 ``` You should run the suggested command and when using `curl` you would need to run it as follows: ```sh curl localhost:8080/hello ``` :::
Project: Kubernetes (Orchestration & Management / Scheduling & Orchestration)
File: minikube-walkthrough.md

This document will take you through setting up and trying the sample apiserver on a local minikube from a fresh clone of this repo. Go 1.7.x or later installed and setup. More information can be found at Dockerhub account to push the image to Minikube is a single node Kubernetes cluster that runs on your local machine. The Minikube docs have installation instructions for your OS. In order to build the sample apiserver image we will need to build the apiserver binary. ``` cd $GOPATH/src mkdir -p k8s.io cd k8s.io git clone https://github.com/kubernetes/sample-apiserver.git ``` Next we will want to create a new binary to both test we can build the server and to use for the container image. From the root of this repo, where ```main.go``` is located, run the following command: ``` export GOOS=linux; go build . ``` if everything went well, you should have a binary called ```sample-apiserver``` present in your current directory. Using the binary we just built, we will now create a Docker image and push it to our Dockerhub registry so that we deploy it to our cluster. There is a sample ```Dockerfile``` located in ```artifacts/simple-image``` we will use this to build our own image. Again from the root of this repo run the following commands: ``` cp ./sample-apiserver ./artifacts/simple-image/kube-sample-apiserver docker build -t <YOURDOCKERHUBUSER>/kube-sample-apiserver:latest ./artifacts/simple-image docker push <YOURDOCKERHUBUSER>/kube-sample-apiserver ``` You need to modify the file to change the ```imagePullPolicy``` to ```Always``` or ```IfNotPresent```. You also need to change the image from ```kube-sample-apiserver:latest``` to ```<YOURDOCKERHUBUSER>/kube-sample-apiserver:latest```. For example: ```yaml ... containers: name: wardle-server image: <YOURDOCKERHUBUSER>/kube-sample-apiserver:latest imagePullPolicy: Always ... ``` Save this file and we are then ready to deploy and try out the sample apiserver. We will need to create several objects in order to setup the sample apiserver so you will need to ensure you have the ```kubectl``` tool installed. . ``` kubectl create ns wardle kubectl create -f artifacts/example/sa.yaml -n wardle kubectl create -f artifacts/example/auth-delegator.yaml -n kube-system kubectl create -f artifacts/example/auth-reader.yaml -n kube-system kubectl create -f artifacts/example/rbac.yaml kubectl create -f artifacts/example/rbac-bind.yaml kubectl create -f artifacts/example/deployment.yaml -n wardle kubectl create -f artifacts/example/service.yaml -n wardle kubectl create -f artifacts/example/apiservice.yaml ``` You should now be able to create the resource type ```Flunder``` which is the resource type registered by the sample apiserver. ``` kubectl create -f artifacts/flunders/01-flunder.yaml ``` You can then get this resource by running: ``` kubectl get flunder my-first-flunder ```
Project: Gloo (Orchestration & Management / API Gateway)
File: kube-e2e-tests.md

These end-to-end tests install each of the 3 Gloo Edge flavors (`gateway`, `ingress`, and `knative`) in a Kubernetes cluster, and run end-to-end tests against them. - Kubernetes may be relied on for scheduling, persistence or security. These tests validate that Gloo Edge can successfully operate within a Kubernetes cluster. Kubernetes end-to-end tests: Install Gloo Edge in Kubernetes cluster Apply Gloo resources using Kubernetes resource clients Execute requests against the Envoy proxy and confirm the expected response. This validates that the Gloo resources have been picked up by the controllers, were been translated correctly into Envoy configuration, the configuration was sent to the Envoy proxy, and the proxy behaves appropriately. These tests are run by a as part of our CI pipeline. If a test fails, you can retry it from a . If you do this, please make sure to comment on the Pull Request with a link to the failed logs for debugging purposes. See the for more details about running these tests.
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.0.1.md

+++ title = "CoreDNS-1.0.1 Release" description = "CoreDNS-1.0.1 Release Notes." tags = ["Release", "1.0.1", "Notes"] draft = false release = "1.0.1" date = "2017-12-11T14:43:43-00:00" author = "coredns" +++ We are pleased to announce the of CoreDNS-1.0.1! This release fixes a crash in the file plugin and has some minor bug fixes for other plugins. One new plugin was added: nsid, that implements . file fixes a crash when an request with a DO bit (pretty much the default) hits an unsigned zone. The default configuration should recover the go-routine, but this is nonetheless serious. file* received some other fixes when returning (secure) delegations. dnstap* plugin is now 50% faster. metrics* fixed the start time bucket for the duration. The following people helped with getting this release done: Brad Beam, James Hartig, Miek Gieben, Rene Treffer, Ruslan Drozhdzh, Seansean2, Yong Tang. If you want to help, please check out one of the and start coding! For documentation and help, see our .
Project: KubeGateway (Orchestration & Management / API Gateway)
File: manually-setup.md

For demo purpose, this tutorial introduces how to setup KubeGateway on local Kubernetes by `kind`, and we will use the kind cluster as upstream cluster. Please install the following tools: Build the environment locally by running the script ``` bash hack/local-up.sh ``` The script performs the following tasks: create a local kubernetes cluster named `kubegateway` by `kind` generating generate tls key and cert for kube-gateway control plane server, and create a associated secret generate tls key and cert for kube-gateway to connect to upstream kube-apiserver generate tls key and cert for client to connect to kube-gateway control plane configure contexts of kubectl create a new context named `gateway-control-plane` create a new context named `gateway-proxy` compile and build image run kube-gateway on local kubernetes cluster and create a new UpstreamCluster on it After script running completed, then you can comunicate with kube-gateway control plane by using `kubectl --context gateway-control-plane` you can comunicate with kube-apiserver through kube-gateway proxy by using `kubectl --context gateway-proxy` you can comunicate with kube-apiserver directly by using `kubectl --context kind-kubegateway` make sure local port 8443 is not occupied please specify the domain name to `localhost` when connecting to kube-apiserver through kube-gateway proxy for demo purpose, default user has super privilege. you can generate new user tls key and cert by using `ca.key` and `ca.crt` under `output/upstream`
Project: MetalLB (Orchestration & Management / Service Proxy)
File: _index.en.md

+++ title = "Showcase" [_build] render = "always" list = "never" publishResources = true +++ A collection of poems with requirements for improved taxonomy support, adjusted menu width and additional JavaScript dependencies. ](http://poesieland.free.fr/) A Linux distribution wiki with customized CSS and the inspiration for the theme's Neon variant. ](https://wiki.gobolinux.org/) Governmental IT security training with additional requirements for accessibility and title customization. ](https://bits-training.de/training/) A classical documentation site in the domain of automation technology with a custom branding variant. ](https://pamasol.github.io/de/)
Project: Traefik (Orchestration & Management / API Gateway)
File: redirectregex.md

title: "Traefik RedirectRegex Documentation" description: "In Traefik Proxy's HTTP middleware, RedirectRegex redirecting clients to different locations. Read the technical documentation." Redirecting the Client to a Different Location {: .subtitle } <!-- TODO: add schema --> The RedirectRegex redirects a request using regex matching and replacement. ```yaml tab="Docker & Swarm" labels: "traefik.http.middlewares.test-redirectregex.redirectregex.regex=^http://localhost/(.*)" "traefik.http.middlewares.test-redirectregex.redirectregex.replacement=http://mydomain/$${1}" ``` ```yaml tab="Kubernetes" apiVersion: traefik.io/v1alpha1 kind: Middleware metadata: name: test-redirectregex spec: redirectRegex: regex: ^http://localhost/(.*) replacement: http://mydomain/${1} ``` ```yaml tab="Consul Catalog" "traefik.http.middlewares.test-redirectregex.redirectregex.regex=^http://localhost/(.*)" "traefik.http.middlewares.test-redirectregex.redirectregex.replacement=http://mydomain/$${1}" ``` ```yaml tab="File (YAML)" http: middlewares: test-redirectregex: redirectRegex: regex: "^http://localhost/(.*)" replacement: "http://mydomain/${1}" ``` ```toml tab="File (TOML)" [http.middlewares] [http.middlewares.test-redirectregex.redirectRegex] regex = "^http://localhost/(.*)" replacement = "http://mydomain/${1}" ``` Set the `permanent` option to `true` to apply a permanent redirection. The `regex` option is the regular expression to match and capture elements from the request URL. !!! tip Regular expressions and replacements can be tested using online tools such as or the . When defining a regular expression within YAML, any escaped character needs to be escaped twice: `example\.com` needs to be written as `example\\.com`. The `replacement` option defines how to modify the URL to have the new target URL. !!! warning Care should be taken when defining replacement expand variables: `$1x` is equivalent to `${1x}`, not `${1}x` (see ), so use `${1}` syntax.
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns.1.md

coredns - pluggable DNS nameserver optimized for service discovery and flexibility. coredns [-conf FILE] [-dns.port PORT} [OPTION]... CoreDNS is a DNS server that chains plugins. Each plugin handles a DNS feature, like rewriting queries, kubernetes service discovery or just exporting metrics. There are many other plugins, each described on <https://coredns.io/plugins> and their respective manual pages. Plugins not bundled by default in CoreDNS are listed on <https://coredns.io/explugins>. When started without options CoreDNS will look for a file named `Corefile` in the current directory, if found, it will parse its contents and start up accordingly. If no `Corefile` is found it will start with the whoami plugin (coredns-whoami(7)) and start listening on port 53 (unless overridden with `-dns.port`). Available options: -conf FILE : specify Corefile to load, if not given CoreDNS will look for a `Corefile` in the current directory. -dns.port PORT or -p PORT : override default port (53) to listen on. -pidfile FILE : write PID to FILE. -plugins : list all plugins and quit. -quiet : don't print any version and port information on startup. -version : show version and quit. CoreDNS Authors. Apache License 2.0 Corefile(5) @@PLUGINS@@.
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: committer-candidate-guidelines.md

title: Apache Mesos - Committer Candidate Guidelines layout: documentation This document contains categories of contributions and behaviors relevant to becoming an Apache Mesos committer. As a committer candidate you can use these guidelines to gauge what you have achieved so far. Neither is this an exhaustive list nor do all categories need to be addressed, since there can be reasonably diverse committer profiles. But some categories are always crucial to have covered, e.g., writing high quality source code and performing meaningful code reviews. For your reference, this is committers usually use when they nominate cadidates. Understanding of the Apache philosophy (). Understanding of the Mesos project's goals. Commitment to the Mesos project. Knowledge and activity breadth and depth in the Mesos project. Can the candidate be trusted to act the right way outside of known areas where they have already demonstrated committer-level expertise and behavior? High quality source code. Community participation. IRC dev mailing list user mailing list JIRA comments Stack Overflow Quora Developer Community Sync Meetings Working groups Helping new contributors Release votes Documentation added Other Presentations at meetups, conferences, etc. Catching functionality and style issues in reviews. Major source code contribution and initiated design documents. Dependability: issues quickly / immediately solved that arose out of own contributions.
Project: Contour (Orchestration & Management / Service Proxy)
File: architecture.md

The Contour Ingress controller is a collaboration between: Envoy, which provides the high performance reverse proxy. Contour, which acts as a management server for Envoy and provides it with configuration. These containers are deployed separately, Contour as a Deployment and Envoy as a Daemonset, although other configurations are possible. In the Envoy Pods, Contour runs as an initcontainer in `bootstrap` mode and writes a bootstrap configuration to a temporary volume. This volume is passed to the Envoy container and directs Envoy to treat Contour as its . After initialisation is complete, the Envoy container starts, retrieves the bootstrap configuration written by Contour's `bootstrap` mode, and establishes a GRPC session with Contour to receive configuration. Envoy will gracefully retry if the management server is unavailable, which removes any container startup ordering issues. Contour is a client of the Kubernetes API. Contour watches Ingress, HTTPProxy, Secret, Service, and Endpoint objects, and acts as the management server for its Envoy sibling by translating its cache of objects into the relevant JSON stanzas: Service objects for CDS, Ingress for RDS, Endpoint objects for SDS, and so on). The transfer of information from Kubernetes to Contour is by watching the API with the SharedInformer framework. Kubernetes readiness probes are configured to check whether Envoy is ready to accept connections. The Envoy readiness probe sends GET requests to `/ready` in Envoy's administration endpoint. For Contour, a liveness probe checks the `/healthz` running on the Pod's metrics port. Readiness probe is a TCP check that the gRPC port is open. Below are a couple of high level architectural diagrams of how Contour works inside a Kubernetes cluster as well as showing the data path of a request to a backend pod. A request to `projectcontour.io/blog` gets routed via a load balancer to an instance of an Envoy proxy which then sends the request to a pod. ! !