cwielenb/CNCF-Dataset huggingface dataset:
Project: Traefik Mesh (Orchestration & Management / Service Mesh)
File: index.md

title: "Traefik Mesh: Simpler Service Mesh" description: "Traefik Mesh is a lightweight and simpler service mesh designed from the ground up to be straightforward, easy to install and use. Read the docs to learn more." <p align="center"> <img src="assets/img/traefik-mesh.png" alt="Traefik Mesh" title="Traefik Mesh" /> </p> Traefik Mesh is a lightweight and simpler service mesh designed from the ground up to be straightforward, easy to install and easy to use. Built on top of Traefik, Traefik Mesh fits as your de-facto service mesh in your Kubernetes cluster supporting the latest Service Mesh Interface specification (SMI). Moreover, Traefik Mesh is opt-in by default, which means that your existing services are unaffected until you decide to add them to the mesh. <p align="center"> <a href="https://smi-spec.io" target="_blank"><img width="150" src="assets/img/smi.png" alt="SMI" title="SMI" /></a> </p> Traefik Mesh does not use any sidecar container but handles routing through proxy endpoints running on each node. The mesh controller runs in a dedicated pod and handles all the configuration parsing and deployment to the proxy nodes. Traefik Mesh supports multiple configuration options: annotations on user service objects, and SMI objects. Not using sidecars means that Traefik Mesh does not modify your Kubernetes objects and does not modify your traffic without your knowledge. Using the Traefik Mesh endpoints is all that is required. <p align="center"> <img width="360" src="assets/img/before-traefik-mesh-graphic.png" alt="Traefik Mesh" title="Traefik Mesh" /> <img width="360" src="assets/img/after-traefik-mesh-graphic.png" alt="Traefik Mesh" title="Traefik Mesh" /> </p> To run this app, you require the following: Kubernetes 1.11+ CoreDNS/KubeDNS installed as (versions 1.3+ supported) Helm v3
Project: Open Cluster Management (Orchestration & Management / Scheduling & Orchestration)
File: README.md

](https://travis-ci.org/kubernetes-sigs/yaml) kubernetes-sigs/yaml is a permanent fork of . A wrapper around designed to enable a better way of handling YAML when marshaling to and from structs. In short, this library first converts YAML to JSON using go-yaml and then uses `json.Marshal` and `json.Unmarshal` to convert to or from the struct. This means that it effectively reuses the JSON struct tags as well as the custom JSON methods `MarshalJSON` and `UnmarshalJSON` unlike go-yaml. For a detailed overview of the rationale behind this method, . This package uses and therefore supports . Caveat #1: When using `yaml.Marshal` and `yaml.Unmarshal`, binary data should NOT be preceded with the `!!binary` YAML tag. If you do, go-yaml will convert the binary data from base64 to native binary data, which is not compatible with JSON. You can still use binary in your YAML files though - just store them without the `!!binary` tag and decode the base64 in your code (e.g. in the custom JSON methods `MarshalJSON` and `UnmarshalJSON`). This also has the benefit that your YAML and your JSON binary data will be decoded exactly the same way. As an example: ``` BAD: exampleKey: !!binary gIGC GOOD: exampleKey: gIGC ... and decode the base64 data in your code. ``` Caveat #2: When using `YAMLToJSON` directly, maps with keys that are maps will result in an error since this is not supported by JSON. This error will occur in `Unmarshal` as well since you can't unmarshal map keys anyways since struct fields can't be keys. To install, run: ``` $ go get sigs.k8s.io/yaml ``` And import using: ``` import "sigs.k8s.io/yaml" ``` Usage is very similar to the JSON library: ```go package main import ( "fmt" "sigs.k8s.io/yaml" ) type Person struct { Name string `json:"name"` // Affects YAML field names too. Age int `json:"age"` } func main() { // Marshal a Person struct to YAML. p := Person{"John", 30} y, err := yaml.Marshal(p) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(y)) /* Output: age: 30 name: John */ // Unmarshal the YAML back into a Person struct. var p2 Person err = yaml.Unmarshal(y, &p2) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(p2) /* Output: {John 30} */ } ``` `yaml.YAMLToJSON` and `yaml.JSONToYAML` methods are also available: ```go package main import ( "fmt" "sigs.k8s.io/yaml" ) func main() { j := []byte(`{"name": "John", "age": 30}`) y, err := yaml.JSONToYAML(j) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(y)) /* Output: age: 30 name: John */ j2, err := yaml.YAMLToJSON(y) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(j2)) /* Output: {"age":30,"name":"John"} */ } ```
Project: Knative (Orchestration & Management / Scheduling & Orchestration)
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, 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 the project team at oss-conduct@uber.com. The project team will review and investigate all complaints, and will respond in a way that it deems 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 .
Project: k8gb (Orchestration & Management / Coordination & Service Discovery)
File: service_upgrade.md

Since Kubernetes API doesn't allow to change service type. Helm chart provides default label `k8gb-migrated-svc`, when set during helm upgrade, old service deleted by helm upgrade hook in automatic manner. Here is the label pattern for service deletion `app.kubernetes.io/name=coredns,k8gb-migrated-svc!=true`
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: kusk_mock.md

Spin up a local mocking server serving your API Spin up a local mocking server that generates responses from your content schema or returns your defined examples. Schema example: content: application/json: schema: type: object properties: title: type: string description: Description of what to do completed: type: boolean order: type: integer format: int32 url: type: string format: uri required: title completed order url The mock server will return a response like the following that matches the schema above: { "completed": false, "order": 1957493166, "title": "Inventore ut.", "url": "http://langosh.name/andreanne.parker" } Example with example responses: application/xml: example: title: "Mocked XML title" completed: true order: 13 url: "http://mockedURL.com" The mock server will return this exact response as its specified in an example: <doc> <completed>true</completed> <order>13</order> <title>Mocked XML title</title> <url>http://mockedURL.com</url> </doc> ``` kusk mock [flags] ``` ``` To mock an api on the local file system $ kusk mock -i path-to-openapi-file.yaml To mock an api from a url $ kusk mock -i https://url.to.api.com ``` ``` -h, --help help for mock -i, --in string path to openapi spec you wish to mock -p, --port uint32 port to expose mock server on. If none specified, will search for next available port starting from 8080 ``` ``` --config string config file (default is $HOME/.kusk.yaml) ``` -
Project: Gloo (Orchestration & Management / API Gateway)
File: processing_mode.proto.sk.md

title: "processing_mode.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> copied from https://github.com/envoyproxy/envoy/blob/ad89a587aa0177bfdad6b5c968a6aead5d9be7a4/api/envoy/extensions/filters/http/extproc/v3/processingmode.proto [#next-free-field: 7] ```yaml "requestHeaderMode": .solo.io.envoy.extensions.filters.http.ext_proc.v3.ProcessingMode.HeaderSendMode "responseHeaderMode": .solo.io.envoy.extensions.filters.http.ext_proc.v3.ProcessingMode.HeaderSendMode "requestBodyMode": .solo.io.envoy.extensions.filters.http.ext_proc.v3.ProcessingMode.BodySendMode "responseBodyMode": .solo.io.envoy.extensions.filters.http.ext_proc.v3.ProcessingMode.BodySendMode "requestTrailerMode": .solo.io.envoy.extensions.filters.http.ext_proc.v3.ProcessingMode.HeaderSendMode "responseTrailerMode": .solo.io.envoy.extensions.filters.http.ext_proc.v3.ProcessingMode.HeaderSendMode ``` | Field | Type | Description | | -- | - | -- | | `requestHeaderMode` | | How to handle the request header. Default is "SEND". | | `responseHeaderMode` | | How to handle the response header. Default is "SEND". | | `requestBodyMode` | | How to handle the request body. Default is "NONE". | | `responseBodyMode` | | How do handle the response body. Default is "NONE". | | `requestTrailerMode` | | How to handle the request trailers. Default is "SKIP". | | `responseTrailerMode` | | How to handle the response trailers. Default is "SKIP". | Control how headers and trailers are handled | Name | Description | | -- | -- | | `DEFAULT` | The default HeaderSendMode depends on which part of the message is being processed. By default, request and response headers are sent, while trailers are skipped. | | `SEND` | Send the header or trailer. | | `SKIP` | Do not send the header or trailer. | Control how the request and response bodies are handled | Name | Description | | -- | -- | | `NONE` | Do not send the body at all. This is the default. | | `STREAMED` | Stream the body to the server in pieces as they arrive at the proxy. | | `BUFFERED` | Buffer the message body in memory and send the entire body at once. If the body exceeds the configured buffer limit, then the downstream system will receive an error. | | `BUFFERED_PARTIAL` | Buffer the message body in memory and send the entire body in one chunk. If the body exceeds the configured buffer limit, then the body contents up to the buffer limit will be sent. | <!-- 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: Pipy (Orchestration & Management / Service Proxy)
File: NOTES-VALGRIND.md

Notes on Valgrind ================= Valgrind is a test harness that includes many tools such as memcheck, which is commonly used to check for memory leaks, etc. The default tool run by Valgrind is memcheck. There are other tools available, but this will focus on memcheck. Valgrind runs programs in a virtual machine, this means OpenSSL unit tests run under Valgrind will take longer than normal. Requirements Platform supported by Valgrind See <http://valgrind.org/info/platforms.html> Valgrind installed on the platform See <http://valgrind.org/downloads/current.html> OpenSSL compiled See Running Tests Test behavior can be modified by adjusting environment variables. `EXE_SHELL` This variable is used to specify the shell used to execute OpenSSL test programs. The default wrapper (`util/wrap.pl`) initializes the environment to allow programs to find shared libraries. The variable can be modified to specify a different executable environment. EXE_SHELL=\ "`/bin/pwd`/util/wrap.pl valgrind --error-exitcode=1 --leak-check=full -q" This will start up Valgrind with the default checker (`memcheck`). The `--error-exitcode=1` option specifies that Valgrind should exit with an error code of 1 when memory leaks occur. The `--leak-check=full` option specifies extensive memory checking. The `-q` option prints only error messages. Additional Valgrind options may be added to the `EXE_SHELL` variable. `OPENSSL_ia32cap` This variable controls the processor-specific code on Intel processors. By default, OpenSSL will attempt to figure out the capabilities of a processor, and use it to its fullest capability. This variable can be used to control what capabilities OpenSSL uses. As of valgrind-3.15.0 on Linux/x86_64, instructions up to AVX2 are supported. Setting the following disables instructions beyond AVX2: `OPENSSL_ia32cap=":0"` This variable may need to be set to something different based on the processor and Valgrind version you are running tests on. More information may be found in . Additional variables (such as `VERBOSE` and `TESTS`) are described in the file . Example command line: $ make test EXE_SHELL="`/bin/pwd`/util/wrap.pl valgrind --error-exitcode=1 \ --leak-check=full -q" OPENSSL_ia32cap=":0" If an error occurs, you can then run the specific test via the `TESTS` variable with the `VERBOSE` or `VF` or `VFP` options to gather additional information. $ make test VERBOSE=1 TESTS=testtest EXESHELL="`/bin/pwd`/util/wrap.pl \ valgrind --error-exitcode=1 --leak-check=full -q" OPENSSL_ia32cap=":0"
Project: Kestra (Orchestration & Management / Scheduling & Orchestration)
File: getting-started.md

Welcome to the Code Editor! The embedded Visual Studio Code IDE lets you easily add custom scripts, queries, and configuration files along with your flow YAML configuration files. Get started by selecting a namespace. If you type a name of a namespace that doesn't exist yet, Kestra will create it for you at runtime. Then, add a new file, e.g., a Python script. Try adding a folder named `scripts` and a file called `hello.py` with the following content: ```python print("Hello from the Editor!") ``` Once you added a file, you can use it in your flow. Try adding a new flow named `hello.yml` with the following content: ```yaml id: hello namespace: ${namespace} tasks: id: hello type: io.kestra.plugin.scripts.python.Script script: "{{ read('scripts/hello.py') }}" ``` Finally, click on the Execute button to run your flow. You should see the friendly message ``Hello from the Editor!`` in the logs. For more information about the Code Editor, check out the .
Project: Gloo (Orchestration & Management / API Gateway)
File: rest.proto.sk.md

title: "rest.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> ```yaml "transformations": map<string, .envoy.api.v2.filter.http.TransformationTemplate> "swaggerInfo": .rest.options.gloo.solo.io.ServiceSpec.SwaggerInfo ``` | Field | Type | Description | | -- | - | -- | | `transformations` | `map<string, .envoy.api.v2.filter.http.TransformationTemplate>` | | | `swaggerInfo` | | | ```yaml "url": string "inline": string ``` | Field | Type | Description | | -- | - | -- | | `url` | `string` | Only one of `url` or `inline` can be set. | | `inline` | `string` | Only one of `inline` or `url` can be set. | This is only for upstream with REST service spec ```yaml "functionName": string "parameters": .transformation.options.gloo.solo.io.Parameters "responseTransformation": .envoy.api.v2.filter.http.TransformationTemplate ``` | Field | Type | Description | | -- | - | -- | | `functionName` | `string` | | | `parameters` | | | | `responseTransformation` | | | <!-- 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: overlays.md

Kusk supports code-first approaches, i.e. OpenAPI generated from code annotations, by use of OpenAPI Overlays. is a new specification that allows you to have an OpenAPI file without any Kusk extensions, and an overlay file containing the extenions you would want to add to your OpenAPI definition. After merging the overlay with the OpenAPI file, the resulting file is an OpenAPI definition with all the metadata added to it, ready to be deployed by Kusk. This way, teams can generate their OpenAPI from code, and then add the gateway deployment metadata later. Let's start with an OpenAPI definition that does not have any Kusk extensions added to it. ```yaml file="openapi.yaml" openapi: 3.0.0 servers: url: http://api.mydomain.com info: title: simple-api version: 0.1.0 paths: /hello: get: summary: Returns a Hello world to the user responses: '200': description: A simple hello world! content: application/json; charset=utf-8: schema: type: object properties: message: type: string required: message ``` Now let's create an overlay that adds Kusk mocking policy to our OpenAPI definition. ```yaml file="overlay.yaml" overlays: 1.0.0 extends: ./openapi.yaml actions: target: "$" update: mocking: enabled: true ``` To apply the overlay to the OpenAPI definition, run: ```sh kusk deploy --overlay overlay.yaml ``` ```sh title="Expected output" successfully parsed initiallizing deployment to fleet kusk-gateway-envoy-fleet api.gateway.kusk.io/simple-api created ``` If you want to look at the generated OpenAPI file before deploying it to Kusk, you can run: ```sh kusk generate --overlay overlay.yaml ``` ```yaml title="Expected output" apiVersion: gateway.kusk.io/v1alpha1 kind: API metadata: name: simple-api namespace: default spec: fleet: name: kusk-gateway-envoy-fleet namespace: kusk-system spec: | openapi: 3.0.0 servers: url: http://api.mydomain.com components: {} info: title: simple-api version: 0.1.0 x-kusk: mocking: enabled: true paths: /hello: get: responses: "200": content: application/json; charset=utf-8: schema: properties: message: type: string required: message type: object description: A simple hello world! summary: Returns a Hello world to the user ``` Overlay reference: target* - property is a JSONPath selector (currently proposed by OpenAPI initiative is JMESPath). extends* - defines which API spec to extend or which API spec should be overlayed. The value must be in form of full path either as relative or absolute path. For example `extends: overlay.yaml` won't work but `extends: ./overlay.yaml` will update* - property should be a valid YAML that will be placed in the target object remove* - property is a boolean - indicates that the selected target should be removed
Project: KubeGateway (Orchestration & Management / API Gateway)
File: GOVERNANCE.md

The governance model adopted in KubeGateway is influenced by many CNCF projects. Open: KubeGateway 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 KubeGateway is aligned with the CNCF Code of Conduct. See 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 kubewharf.conduct@bytedance.com. 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 KubeGateway project. Some contents in this documents have been borrowed from , , and projects.
Project: Traefik (Orchestration & Management / API Gateway)
File: include-acme-single-domain-example.md

```yaml tab="Docker & Swarm" labels: traefik.http.routers.blog.rule=Host(`example.com`) && Path(`/blog`) traefik.http.routers.blog.tls=true traefik.http.routers.blog.tls.certresolver=myresolver ``` ```yaml tab="Docker (Swarm)" deploy: labels: traefik.http.routers.blog.rule=Host(`example.com`) && Path(`/blog`) traefik.http.routers.blog.tls=true traefik.http.routers.blog.tls.certresolver=myresolver traefik.http.services.blog-svc.loadbalancer.server.port=8080" ``` ```yaml tab="Kubernetes" apiVersion: traefik.io/v1alpha1 kind: IngressRoute metadata: name: blogtls spec: entryPoints: websecure routes: match: Host(`example.com`) && Path(`/blog`) kind: Rule services: name: blog port: 8080 tls: certResolver: myresolver ``` ```yaml tab="File (YAML)" http: routers: blog: rule: "Host(`example.com`) && Path(`/blog`)" tls: certResolver: myresolver ``` ```toml tab="File (TOML)" [http.routers] [http.routers.blog] rule = "Host(`example.com`) && Path(`/blog`)" [http.routers.blog.tls] certResolver = "myresolver" ```
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.10.1-released.md

title: "Avro 1.10.1" linkTitle: "Avro 1.10.1" date: 2020-12-03 <!-- 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.10.1 has been released!
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.1.0-released.md

title: "Avro 1.1.0" linkTitle: "Avro 1.1.0" date: 2009-09-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.1.0 is now available!