cwielenb/CNCF-Dataset huggingface dataset:
Project: Apache Thrift (Orchestration & Management / Remote Procedure Call)
File: thrift-protocol-spec.md

Thrift Protocol Structure ==================================================================== Last Modified: 2007-Jun-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 http://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. -- --> This document describes the structure of the Thrift protocol without specifying the encoding. Thus, the order of elements could in some cases be rearranged depending upon the TProtocol implementation, but this document specifies the minimum required structure. There are some "dumb" terminals like STRING and INT that take the place of an actual encoding specification. The key point to notice is that ALL messages are just one wrapped `<struct>`. Depending upon the message type, the `<struct>` can be interpreted as the argument list to a function, the return value of a function, or an exception. -- ``` <message> ::= <message-begin> <struct> <message-end> <message-begin> ::= <method-name> <message-type> <message-seqid> <method-name> ::= STRING <message-type> ::= TCALL | TREPLY | TEXCEPTION | TONEWAY <message-seqid> ::= I32 <struct> ::= <struct-begin> <field>* <field-stop> <struct-end> <struct-begin> ::= <struct-name> <struct-name> ::= STRING <field-stop> ::= T_STOP <field> ::= <field-begin> <field-data> <field-end> <field-begin> ::= <field-name> <field-type> <field-id> <field-name> ::= STRING <field-type> ::= TBOOL | TBYTE | TI8 | TI16 | TI32 | TI64 | T_DOUBLE | TSTRING | TBINARY | TSTRUCT | TMAP | TSET | TLIST | T_UUID <field-id> ::= I16 <field-data> ::= I8 | I16 | I32 | I64 | DOUBLE | STRING | BINARY <struct> | <map> | <list> | <set> <map> ::= <map-begin> <field-datum>* <map-end> <map-begin> ::= <map-key-type> <map-value-type> <map-size> <map-key-type> ::= <field-type> <map-value-type> ::= <field-type> <map-size> ::= I32 <list> ::= <list-begin> <field-data>* <list-end> <list-begin> ::= <list-elem-type> <list-size> <list-elem-type> ::= <field-type> <list-size> ::= I32 <set> ::= <set-begin> <field-data>* <set-end> <set-begin> ::= <set-elem-type> <set-size> <set-elem-type> ::= <field-type> <set-size> ::= I32 ```
Project: Knative (Orchestration & Management / Scheduling & Orchestration)
File: personas.md

When discussing user actions, it is often helpful to who might want to do the action. The developer personas are software engineers looking to build and run a stateless application without concern about the underlying infrastructure. Developers expect to have tools which integrate with their native language tooling or business processes. Hobbyist Backend SWE Full stack SWE SRE User stories: Deploy some code Update environment Roll back the last change Debug an error in code Monitor my application The operator personas are focused on deploying and managing both Knative Serving and the underlying Kubernetes cluster, as well as applying organization policy and security patches. Hobbyist / Contributor Cluster administrator Security Engineer / Auditor Capacity Planner User stories: Create an Knative Serving cluster Apply policy / RBAC Control or charge back for resource usage Choose logging or monitoring plugins Audit or patch running Revisions Contributors are an important part of the Knative Serving project. As such, we will also consider how various infrastructure encourages and enables contributors to the project, as well as the impact on end-users. Hobbyist or newcomer Motivated user Corporate (employed) maintainer Consultant User stories: Check out the code Build and run the code Run tests View test status Run performance tests
Project: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: scaling.md

id: scaling title: Scaling sidebar_label: Scaling To run RIG in a more robust way you should use more nodes. To be able to form cluster from these nodes, check our . Mentioned deployment guide also provides configuration for `kubectl` and `helm` (v2 and v3). RIG guarantees distribution of API requests, event stream events and SSE/WS events. Even though it's possible to run RIG anywhere, we recommend to use Kubernetes. ```bash kubectl scale deployment/reactive-interaction-gateway --replicas 3 helm repo add accenture https://accenture.github.io/reactive-interaction-gateway helm install --set replicaCount=3 rig accenture/reactive-interaction-gateway helm install --set replicaCount=3 --name=rig accenture/reactive-interaction-gateway ```
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: connecting-an-application.md

In the previous section, you've mocked the API to provide fake results so developers can start working on it. In this section, you will deploy an application to your Kubernetes cluster and learn how to access it using Kusk Gateway. Deploy the following sample web server that has a `/hello` route: ```sh kubectl create deployment hello-world --image=kubeshop/kusk-hello-world:v1.0.0 kubectl expose deployment hello-world --name hello-world-svc --port=8080 ``` ```sh title="Expected output:" deployment.apps/hello-world created service/hello-world-svc exposed ``` First, disable Kusk's mocking of the API by delete the `mocking` section from the `api.yaml` file: ```diff ... mocking: enabled: true ... ``` Now use the `upstream` policy with the details of the service we just created, this tells Kusk that about our deployed application: ```yaml x-kusk: upstream: service: name: hello-world-svc namespace: default port: 8080 ``` The resulting file should look like this: ```yaml title="api.yaml" openapi: 3.0.0 info: title: simple-api version: 0.1.0 x-kusk: upstream: service: name: hello-world-svc namespace: default port: 8080 paths: /hello: get: responses: '200': description: A simple hello world! content: text/plain: schema: type: string example: Hello from a mocked response! ``` ```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 updated ``` :::note You can watch the changed to the OpenAPI definition and automatically deploy it by using the watch feature: ```sh kusk deploy -i api.yaml -w ``` ::: Again, let's get the IP address of the gateway by running: ```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 an implemented service!"} ``` This response is served from the deployed application. You have successfully deployed an application to Kusk Gateway!
Project: Gloo (Orchestration & Management / API Gateway)
File: documentation.md

The docs for Gloo Edge are built from the contents that can be found in the directory of this repository. Improving the documentation, including by adding examples or use cases, is the easiest way to contribute to Gloo Edge. If you see a piece of content that can be better, open a PR with an improvement, it doesn't matter how small! For more information on how to contribute to the documentation, check out the contribution guidelines in the . Please note that some of our documentation is auto-generated from source code. This includes:
Project: Tengine (Orchestration & Management / Service Proxy)
File: ngx_backtrace_module.md

Name ==== backtrace module Description =========== It can be used to dump backtrace of nginx in case a worker process exits abnormally, e.g. when some signal is received (SIGABR, SIGBUS, SIGFPE, SIGILL, SIGIOT, SIGSEGV). It's quite handy for debugging purpose. This module requires the backtrace(3) function in glibc. You can't enable it on systems lack of this function (FreeBSD, Darwin). Directives ========== backtrace_log Syntax: backtrace_log log_path Default: backtrace_log error.log Context: main Specify the log file name of backtrace. backtrace_log /path/to/backtrace.log backtracemaxstack_size Syntax: backtrace_max_stack_size size Default: backtrace_max_stack_size 30 Context: main Specify the maximum stack depth for backtrace
Project: Eraser (Orchestration & Management / Scheduling & Orchestration)
File: metrics.md

title: Metrics To view Eraser metrics, you will need to deploy an Open Telemetry collector in the 'eraser-system' namespace, and an exporter. An example collector with a Prometheus exporter is , and the endpoint can be specified using the . In this example, we are logging the collected data to the otel-collector pod, and exporting metrics through Prometheus at 'http://localhost:8889/metrics', but a separate exporter can also be configured. Below is the list of metrics provided by Eraser per run: ```yaml count name: imagesremovedrun_total description: Total images removed by eraser ``` ```yaml count name: vulnerableimagesrun_total description: Total vulnerable images detected ``` ```yaml count name: imagejobruntotal description: Total ImageJobs scheduled name: podscompletedrun_total description: Total pods completed name: podsfailedrun_total description: Total pods failed summary name: imagejobdurationrun_seconds description: Total time for ImageJobs scheduled to complete ```
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-api-policy-studio-properties.md

As an API publisher, you can define properties for your API. These properties are automatically injected into the expression language context to be used later. For example, to get the value of the property `my-property` defined in API properties: `{#properties['my-property']}` The (+) button let you create a new property. To get access to dynamic properties click on the settings button. Dynamic properties let you fetch API properties from a remote resource, such as web service. You can set a polling frequency property and apply response transformation thanks to the . Do not forget to switch on dynamic properties and re-deploy the API to unable dynamic properties. Like classical properties, dynamic properties will be injected into the expression language context.
Project: STUNner (Orchestration & Management / Service Proxy)
File: RELEASE.md

Let the new version be vX.Y.Z. remove the doc disclaimers ("this doc is for the dev version, see RTD for stable docs") from the README.md and docs/README.md write release notes for vX.Y.Z `git pull` `go mod tidy` make sure `go test ./...` passes make sure `golangci-lint run` passes `git push` if there are local changes release vX.Y.Z on github (so that we can publish the release notes) wait until the CI/CD pipeline goes green (may take a while) `git pull` bump `github.com/l7mp/stunner` version to vX.Y.Z in the `go.mod` `go mod tidy` make sure `go test ./... -count 1` passes make sure `golangci-lint run` passes `git push` if there are local changes release vX.Y.Z (try to have the same version as the main stunner repo, if possible) on github (so that we can publish the release notes) wait until both stunner and the auth-service releases finished building and the CI status goes green on both repos (the gateway-operator helm chart CI build step needs the new artifact from both, so it will fail until the other two finish the image push phase) `git pull` bump `github.com/l7mp/stunner` version to vX.Y.Z in the `go.mod` `go mod tidy` make sure `make test` passes make sure `golangci-lint run` passes `git push` if there are local changes release vX.Y.Z (try to have the same version as the main stunner repo, if possible) on github (so that we can publish the release notes) ask @Tamas to run the CI/CD for the intergation test
Project: BFE (Orchestration & Management / Service Proxy)
File: README.md

<table> <tr> <th colspan="7"></th> </tr> <tr> <th></th> <th colspan="3">PNG</th> <th colspan="3">SVG</th> </tr> <tr> <th></th> <th>horizontal</th> <th>stacked</th> <th>icon</th> <th>horizontal</th> <th>stacked</th> <th>icon</th> </tr> <tr> <th>color</th> <td><img src="./horizontal/color/bfe-horizontal-color.png" width="200"></td> <td><img src="./stacked/color/bfe-stacked-color.png" width="95"></td> <td><img src="./icon/color/bfe-icon-color.png" width="75"></td> <td><img src="./horizontal/color/bfe-horizontal-color.svg" width="200"></td> <td><img src="./stacked/color/bfe-stacked-color.svg" width="95"></td> <td><img src="./icon/color/bfe-icon-color.svg" width="75"></td> </tr> <tr> <th>black</th> <td><img src="./horizontal/black/bfe-horizontal-black.png" width="200"></td> <td><img src="./stacked/black/bfe-stacked-black.png" width="95"></td> <td><img src="./icon/black/bfe-icon-black.png" width="75"></td> <td><img src="./horizontal/black/bfe-horizontal-black.svg" width="200"></td> <td><img src="./stacked/black/bfe-stacked-black.svg" width="95"></td> <td><img src="./icon/black/bfe-icon-black.svg" width="75"></td> </tr> <tr> <th>white</th> <td><img src="./horizontal/white/bfe-horizontal-white.png" width="200"></td> <td><img src="./stacked/white/bfe-stacked-white.png" width="95"></td> <td><img src="./icon/white/bfe-icon-white.png" width="75"></td> <td><img src="./horizontal/white/bfe-horizontal-white.svg" width="200"></td> <td><img src="./stacked/white/bfe-stacked-white.svg" width="95"></td> <td><img src="./icon/white/bfe-icon-white.svg" width="75"></td> </tr> </table>
Project: wasmCloud (Orchestration & Management / Scheduling & Orchestration)
File: 0018-otel-metrics.md

| Status | Deciders | Date | |-|-|-| | Accepted | Commenters on | 17 Feb 2024 | After much development and refinement, has become the standard for in the Cloud Native ecosystem, and the three primary "pillars of observability" are key: Logs Tracing Metrics While wasmCloud has supported logs and tracing for a long time with the integration of the , metrics has not been suported natively by the wasmCloud host, and thus not supported by wasmCloud as a whole. Logs and tracing are sufficient to solve most problems that actually occur with a running host, but metrics are important to ease the burden of operators of any given service, so implementing them is important. Tools like and have become industry standards, and are used by DevOps practitioners and operations people at large extensively across the industry. wasmCloud should support OTEL-compliant metrics, along with logs and tracing. Ease of monitoring for operators Insight into the key metrics to monitor for wasmCloud hosts Support and integrate with the OTEL-compliant observability metrics collection ecosystem Support OTEL-compliant metrics Not implementing OTEL based metrics support Supporting a different stnadard for metrics Chosen option: "Support OTEL-compliant metrics", because integrating properly with the rest of the cloud native ecosystem around metrics and making operations easier encourages usage of wasmCloud and improves the product. Easier maintenance of wasmCloud hosts Build a base on which to add more important metrics Interoperation with other cloud native ecosystem projects More complexity (annotations, etc) in the `wasmCloud/wasmCloud` codebase Likely more requests for metrics to be exposed and some related friction
Project: Koordinator (Orchestration & Management / Scheduling & Orchestration)
File: question.md

name: Question about: Support request or question relating to Koordinator title: "[question]" labels: kind/question <!-- Please only use this template for submitting question --> What happened: What you expected to happen: Environment: <!-- Please add environment information, if you know what is necessary, just provide some --> Koordinator version: - v0.6.2 Kubernetes version (use kubectl version): v1.22.5 docker/containerd version: containerd 1.5.0 OS (e.g: cat /etc/os-release): Ubuntu 20.04.4 LTS Kernel (e.g. uname -a): Linux 5.10.112-11.al8.x8664 #1 SMP Tue May 24 16:05:50 CST 2022 x8664 x8664 x8664 GNU/Linux Anything else we need to know:
Project: Apache Zookeeper (Orchestration & Management / Coordination & Service Discovery)
File: zookeeperHierarchicalQuorums.md

<!-- Copyright 2002-2004 The Apache Software Foundation Licensed 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 http://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. //--> This document gives an example of how to use hierarchical quorums. The basic idea is very simple. First, we split servers into groups, and add a line for each group listing the servers that form this group. Next we have to assign a weight to each server. The following example shows how to configure a system with three groups of three servers each, and we assign a weight of 1 to each server: group.1=1:2:3 group.2=4:5:6 group.3=7:8:9 weight.1=1 weight.2=1 weight.3=1 weight.4=1 weight.5=1 weight.6=1 weight.7=1 weight.8=1 weight.9=1 When running the system, we are able to form a quorum once we have a majority of votes from a majority of non-zero-weight groups. Groups that have zero weight are discarded and not considered when forming quorums. Looking at the example, we are able to form a quorum once we have votes from at least two servers from each of two different groups.
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.27.1.md

We are delighted to present version v1.27.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. Updates Envoy to v1.28.1. See the release notes for v1.28.1 . For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.27.1 is tested against Kubernetes 1.26 through 1.28. If you're using Contour and want to add your organization to our adopters list, please visit this . If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this .
Project: BFE (Orchestration & Management / Service Proxy)
File: SUMMARY.md

Introduction * Design overview * * * Getting Started * * * * * * Configuration * Protocol * * Routing * * Load Balancing * Name Service * * * * * * * * * * * Operations * * * * How to Contribute Contribute codes * * Development guides * * FAQ * * Appendix A: Monitor Protocol * * * Routing * Load Balancing * Proxy * * Lentency Appendix B: Condition * * Request related Condition Primitives * * * * Response related Condition Primitives * Session related Condition Primitives * System related Condition Primitives Note: This documentation is working in process. Please help improve it by or .
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.28.2.md

We are delighted to present version v1.28.2 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. See the release notes . Note that this Envoy version reverts the HTTP/2 codec back to `nghttp2` from `oghttp2`. As of version v1.29.0, Envoy removes the hop-by-hop TE header. However, this causes issues with HTTP/2, particularly gRPC, with implementations expecting the header to be present (and set to `trailers`). Contour disables this via Envoy runtime setting and reverts to the v1.28.x and prior behavior of allowing the header to be proxied. Once is backported to a release or a new minor is cut, Contour will no longer set the aforementioned runtime key. For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.28.2 is tested against Kubernetes 1.27 through 1.29. If you're using Contour and want to add your organization to our adopters list, please visit this . If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this .
Project: Emissary-Ingress (Orchestration & Management / API Gateway)
File: README.md

`py-mkopensource` is a program for generating reports of the libraries used by a Python application, in order to be in compliance with the attribution requirements of various opensource licenses. `py-mkopensource` takes as input the dependencies generated by `pip show`, and produces a report in either JSON or markdown output. `py-mkopensource` requires `pip` and `pip-tools`. To generate the list of dependencies from `requirements.txt`, run the following commands: ```shell pip3 --disable-pip-version-check install -r requirements.txt pip3 --disable-pip-version-check freeze --exclude-editable | cut -d= -f1 | xargs pip show | sed 's/^$//' >dependenncies.txt echo '' >>dependenncies.txt cat dependenncies.txt | ./py-mkopensource ``` Parameter `--output-type` controls the output format. Program outputs dependency information in Markdown format. This is the default value. Program outputs dependency information in JSON format
Project: Capsule (Orchestration & Management / Scheduling & Orchestration)
File: feature_request.md

name: Feature request about: Suggest a new feature for Capsule title: '' labels: blocked-needs-validation, feature assignees: '' <!-- Yay, it look you're enjoying Capsule and, first, thanks for that! We're trying to build a community drive Open Source project, so don't hesitate proposing your enhancement ideas: keep in mind, since we would like to keep it as agnostic as possible, to motivate all your assumptions. --> A clear and concise description of the feature. How would the new interaction with Capsule look like? E.g. What are the prerequisites for this? Tenant owner creates a new Namespace This is going to be attached to the Tenant All the magic happens in the background Feel free to add a diagram if that helps explain things. A clear and concise description of what you expect to happen.