cwielenb/CNCF-Dataset huggingface dataset:
Project: APISIX (Orchestration & Management / API Gateway)
File: grpc-proxy.md

title: gRPC Proxy <!-- --> proxying gRPC traffic: gRPC client -> APISIX -> gRPC/gRPCS server `scheme`: the `scheme` of the route's upstream must be `grpc` or `grpcs`. `uri`: format likes /service/method, Example/helloworld.Greeter/SayHello Here's an example, to proxying gRPC service by specified route: attention: the `scheme` of the route's upstream must be `grpc` or `grpcs`. attention: APISIX use TLSencrypted HTTP/2 to expose gRPC service, so need to attention: APISIX also support to expose gRPC service with plaintext HTTP/2, which does not rely on TLS, usually used to proxy gRPC service in intranet environment the grpc server example :::note You can fetch the `admin_key` from `config.yaml` and save to an environment variable with the following command: ```bash adminkey=$(yq '.deployment.admin.adminkey[0].key' conf/config.yaml | sed 's/"//g') ``` ::: ```shell curl http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "methods": ["POST", "GET"], "uri": "/helloworld.Greeter/SayHello", "upstream": { "scheme": "grpc", "type": "roundrobin", "nodes": { "127.0.0.1:50051": 1 } } }' ``` Invoking the route created before ```shell $ grpcurl -insecure -import-path /pathtoprotos -proto helloworld.proto -d '{"name":"apisix"}' 127.0.0.1:9443 helloworld.Greeter.SayHello { "message": "Hello apisix" } ``` grpcurl is a CLI tool, similar to curl, that acts as a gRPC client and lets you interact with a gRPC server. For installation, please check out the official . This means that the proxying is working. By default, the APISIX only listens to `9443` for TLSencrypted HTTP/2. You can support HTTP/2 with plaintext via the `node_listen` section under `apisix` in `conf/config.yaml`: ```yaml apisix: node_listen: port: 9080 port: 9081 enable_http2: true ``` Invoking the route created before ```shell $ grpcurl -plaintext -import-path /pathtoprotos -proto helloworld.proto -d '{"name":"apisix"}' 127.0.0.1:9081 helloworld.Greeter.SayHello { "message": "Hello apisix" } ``` This means that the proxying is working. If your gRPC service encrypts with TLS by itself (so called `gPRCS`, gPRC + TLS), you need to change the `scheme` to `grpcs`. The example above runs gRPCS service on port 50052, to proxy gRPC request, we need to use the configuration below: ```shell curl http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "methods": ["POST", "GET"], "uri": "/helloworld.Greeter/SayHello", "upstream": { "scheme": "grpcs", "type": "roundrobin", "nodes": { "127.0.0.1:50052": 1 } } }' ```
Project: wasmCloud (Orchestration & Management / Scheduling & Orchestration)
File: 0009-jetstream.md

Status: Accepted During the course of normal operation, wasmCloud hosts need to share certain information; metadata about the contents and operation of the lattice. This includes information such as a lookup table of JWT claims, a lookup table that maps OCI URLs to public keys, and a list of link definitions. This information needs to be shared with all hosts in a lattice at all times, and it needs to withstand things like partition events and temporary connectivity loss, as well as expected events like the termination and starting of individual host processes. The current solution to this problem is not reliable, doesn't scale beyond simple installations and, worse, can quite easily result in "split-brain" problems where different hosts have different views of the same set of information, potentially causing runtime failures in production. Reliability Developer Experience Predictability Scalability Resiliency Enterprise suitability Leave As-Is Use Redis Use memcached/etcd/consul or their ilk Use NATS JetStream Chosen option: **Use NATS JetStream**, because this is the only option that actually satisfies all of our runtime production requirements while still enabling a simple developer experience and not burdening the developer by requiring the installation of additional software. Gain a "free" external source of truth for the lattice cache without requiring developers to install additional products Gain access to all of the JetStream features, including defining replication, clusters, persistence, and more Ability to provide a reasonable default while allowing organizations and enterprises to define their own stream configuration Requires developers to enable the JetStream feature when starting NATS servers for development (goes to developer experience) Continue using naive state replication by simply emitting at most once messages in fire-and-forget fashion into the lattice. Bad, because message loss will result in cache drift/split brain Bad, because at least one host must remain up at all times to maintain state Bad, because it is intolerant of partition events Communicate with a Redis server (or cluster) and store lattice cache metadata in Redis keys Good, because the information in the cache would be durable Good, because if properly clustered, it could tolerate certain kinds of partition events Bad, because developers and operators now have an entirely new product to maintain even to get a simple "hello world" sample running Use one of these other servers that are often optimized for high-efficiency, in-memory operation. Basically the same Good/Bad arguments as Redis Rely on the features of streams in NATS JetStream to manage the lattice shared metadata Good, because developers are already using NATS, they simply have to enable JetStream (requires no additional download) Good, because we can default to a quick, easy, in-memory store while optionally supporting more complex configurations Documentation -
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.22.1.md

We are delighted to present version v1.22.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. Updates Go to 1.19.0, see . (#4660, @sunjayBhatia) The global connect-timeout configuration value was not taking effect for routes that did not have timeoutPolicy set. (#4690, @tsaarni) Update Envoy to v1.23.1. This fixes an issue where the arm64 variant of the Envoy image was not built properly. See the for additional information. (#4691, @skriss) For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.22.1 is tested against Kubernetes 1.22 through 1.24. 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: APISIX (Orchestration & Management / API Gateway)
File: benchmark.md

title: Benchmark <!-- --> n1-highcpu-8 (8 vCPUs, 7.2 GB memory) on Google Cloud But we only used 4 cores to run APISIX, and left 4 cores for system and , which is the HTTP benchmarking tool. Only used APISIX as the reverse proxy server, with no logging, limit rate, or other plugins enabled, and the response size was 1KB. The x-axis means the size of CPU core, and the y-axis is QPS. Note the y-axis latency in microsecond(s) not millisecond. The result of Flame Graph: And if you want to run the benchmark test in your machine, you should run another Nginx to listen 80 port. :::note You can fetch the `admin_key` from `config.yaml` and save to an environment variable with the following command: ```bash adminkey=$(yq '.deployment.admin.adminkey[0].key' conf/config.yaml | sed 's/"//g') ``` ::: ```shell curl http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "methods": ["GET"], "uri": "/hello", "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:80": 1, "127.0.0.2:80": 1 } } }' ``` then run wrk: ```shell wrk -d 60 --latency http://127.0.0.1:9080/hello ``` Only used APISIX as the reverse proxy server, enabled the limit rate and prometheus plugins, and the response size was 1KB. The x-axis means the size of CPU core, and the y-axis is QPS. Note the y-axis latency in microsecond(s) not millisecond. The result of Flame Graph: And if you want to run the benchmark test in your machine, you should run another Nginx to listen 80 port. ```shell curl http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "methods": ["GET"], "uri": "/hello", "plugins": { "limit-count": { "count": 999999999, "time_window": 60, "rejected_code": 503, "key": "remote_addr" }, "prometheus":{} }, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:80": 1, "127.0.0.2:80": 1 } } }' ``` then run wrk: ```shell wrk -d 60 --latency http://127.0.0.1:9080/hello ``` For more reference on how to run the benchmark test, you can see this and this . :::tip If you want to run the benchmark with a large number of connections, You may have to update the keepalive config in the . Connections exceeding this number will become short connections. You can run the following command to test the benchmark with a large number of connections: ```bash wrk -t200 -c5000 -d30s http://127.0.0.1:9080/hello ``` For more details, you can refer to . :::
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-api-health-check-configure.md

Health check configuration let you enable or disable health check service, set a frequency rate, choose an `health` relative path and provide some assertions to control endpoint API's health. How to write assertion: Example 1: Check the status of the HTTP response `#response.status == 200` Example 2: Check the JSON content of the response `#jsonPath(#response.content, '$.status') == 'green'`
Project: Crossplane (Orchestration & Management / Scheduling & Orchestration)
File: PULL_REQUEST_TEMPLATE.md

<!-- Thank you for helping to improve Crossplane! Please read the contribution docs (linked below) if this is your first Crossplane pull request. --> <!-- Briefly describe what this pull request does, and how it is covered by tests. Be proactive - direct your reviewers' attention to anything that needs special consideration. We love pull requests that fix an open issue. If yours does, use the below line to indicate which issue it fixes, for example "Fixes #500". --> Fixes # I have: <!--You MUST either [x] check or [ ] ~strike through~ every item.--> [ ] Read and followed Crossplane's [contribution process]. [ ] Run `make reviewable` to ensure this PR is ready for review. [ ] Added or updated unit tests. [ ] Added or updated e2e tests. [ ] Linked a PR or a [docs tracking issue] to [document this change]. [ ] Added `backport release-x.y` labels to auto-backport this PR. Need help with this checklist? See the [cheat sheet].
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: bug_report_cpp.md

name: Report a gRPC C++ bug about: Create a report to help us improve labels: kind/bug, priority/P2, lang/c++, untriaged <!-- PLEASE DO NOT POST A QUESTION HERE. This form is for bug reports and feature requests ONLY! For general questions and troubleshooting, please ask/look for answers at StackOverflow, with "grpc" tag: https://stackoverflow.com/questions/tagged/grpc For questions that specifically need to be answered by gRPC team members, please ask/look for answers at grpc.io mailing list: https://groups.google.com/forum/#!forum/grpc-io Issues specific to grpc-java, grpc-go, grpc-node, grpc-dart, grpc-web should be created in the repository they belong to (e.g. https://github.com/grpc/grpc-LANGUAGE/issues/new) --> Please provide either 1) A unit test for reproducing the bug or 2) Specific steps for us to follow to reproduce the bug. If theres not enough information to debug the problem, gRPC team may close the issue at their discretion. Youre welcome to re-open the issue once you have a reproduction. Make sure you include information that can help us debug (full error message, exception listing, stack trace, logs). See for how to diagnose problems better.
Project: Capsule (Orchestration & Management / Scheduling & Orchestration)
File: DEPENDENCY.md

This policy describes how Capsule maintainers consume third-party packages. This policy applies to all Capsule maintainers and all third-party packages used in the Capsule project. Capsule maintainers must follow these guidelines when consuming third-party packages: Only use third-party packages that are necessary for the functionality of Capsule. Use the latest version of all third-party packages whenever possible. Avoid using third-party packages that are known to have security vulnerabilities. Pin all third-party packages to specific versions in the Capsule codebase. Use a dependency management tool, such as Go modules, to manage third-party dependencies. Dependencies must pass all automated tests before being merged into the Capsule codebase. When adding a new third-party package to Capsule, maintainers must follow these steps: Evaluate the need for the package. Is it necessary for the functionality of Capsule? Research the package. Is it well-maintained? Does it have a good reputation? Choose a version of the package. Use the latest version whenever possible. Pin the package to the specific version in the Capsule codebase. Update the Capsule documentation to reflect the new dependency. When a third-party package is discontinued, the Capsule maintainers must fensure to replace the package with a suitable alternative. This policy is enforced by the Capsule maintainers. Maintainers are expected to review each other's code changes to ensure that they comply with this policy. Exceptions to this policy may be granted by the Capsule project lead on a case-by-case basis. This policy was adapted from the
Project: MetalLB (Orchestration & Management / Service Proxy)
File: pull_request_template.md

<!-- Thanks for sending a pull request! If this is your first time, please read the For non-trivial pull requests, please [file an issue](https://github.com/metallb/metallb/issues/new) first, and get agreement that the change is a good idea, and a general guideline for how it should be implemented, before sending code. Large PRs that weren't first discussed and agreed upon in an issue won't be accepted. If the PR fixes a particular bug, please include the words "Fixed the PR is merged. --> Is this a BUG FIX or a FEATURE ?: Uncomment only one, leave it on its own line: /kind bug /kind cleanup /kind feature /kind design /kind flake /kind failing /kind documentation /kind regression What this PR does / why we need it: Special notes for your reviewer: Release note: <!-- Write your release note: Enter your extended release note in the below block. If the PR requires additional action from users switching to the new release, include the string "action required". Follow the instructions for writing a release note from k8s: https://git.k8s.io/community/contributors/guide/release-notes.md If no release note is required, just write "NONE". --> ```release-note ```
Project: MetalLB (Orchestration & Management / Service Proxy)
File: index.pir.md

+++ descrption = "List Rrresources shorrrtcode contained in a plank bundle" title = "Resources" [[resources]] name = 'MaybeTreasure.txt' src = 'MaybeTreasure.pir.txt' +++ {{% resources /%}} {{< piratify >}}
Project: Apache Thrift (Orchestration & Management / Remote Procedure Call)
File: README-MSYS2.md

<! 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. --> Thrift uses cmake to make it easier to build the project on multiple platforms, however to build a fully functional and production ready thrift on Windows requires a number of third party libraries to be obtained. Once third party libraries are ready, the right combination of options must be passed to cmake in order to generate the correct environment. Note: libevent and libevent-devel do not work with this toolchain as they do not properly detect mingw64 and expect some headers to exist that do not, so the non-blocking server is not currently built into this solution. Download and fully upgrade msys2 following the instructions at: https://msys2.github.io/ Install the necessary toolchain items for C++: $ pacman --needed -S bison flex make mingw-w64-x86_64-openssl \ mingw-w64-x8664-boost mingw-w64-x8664-cmake \ mingw-w64-x8664-toolchain mingw-w64-x8664-zlib Update your msys2 bash path to include /mingw64/bin by adding a line to your ~/.bash_profiles using this command: echo "export PATH=/mingw64/bin:\$PATH" >> ~/.bash_profile After that, close your shell and open a new one. Use cmake to create a MinGW makefile, out of tree (assumes you are in the top level of the thrift source tree): mkdir ../thrift-build cd ../thrift-build cmake -G"MinGW Makefiles" -DCMAKEMAKEPROGRAM=/mingw64/bin/mingw32-make \ -DCMAKECCOMPILER=x86_64-w64-mingw32-gcc.exe \ -DCMAKECXXCOMPILER=x86_64-w64-mingw32-g++.exe \ -DWITH_LIBEVENT=OFF \ -DWITHSHAREDLIB=OFF -DWITHSTATICLIB=ON \ -DWITHJAVA=OFF -DWITHPYTHON=OFF -DWITH_PERL=OFF \ ../thrift Build thrift (inside thrift-build): cmake --build . Run the tests (inside thrift-build): ctest If you run into issues, check Apache Jira THRIFT-4046 for patches relating to MinGW64/MSYS2 builds. msys2 64-bit 2016-10-26 distribution
Project: Hango (Orchestration & Management / API Gateway)
File: ISSUE_TEMPLATE.md

DO NOT OPEN NEW ISSUES ON THIS REPOSITORY This repository has not been marked archived/read-only, as we do periodically update the list of packages and/or their constraints. However, this repository is a metapackage, and is only used to release the product. If you find an issue, you should determine which package is responsible, and report against the correct package repository. As an example, if you see an exception reported that mentions `data plane`, this indicates an issue with the `Envoy` package, and should be reported against the `Envoy` repository. In the majority of cases, we will close any new issues without comment.
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: good-first.md

name: Good First Issue about: Publish a good first issue labels: good first issue <!-- Please use this template while publishing a good first issue. Thanks! --> Task description: Solution: Who can join or take the task: The good first issue is intended for `first-time contributors` to get started on his/her contributor journey. After a contributor has successfully completed 1-2 good first issue's, they should be ready to move on to `help wanted` items, saving the remaining `good first issue` for other new contributors. How to join or take the task: Just reply on the issue with the message `/assign` in a separate line. Then, the issue will be assigned to you. How to ask for help: If you need help or have questions, please feel free to ask on this issue. The issue author or other members of the community will guide you through the contribution process.
Project: Contour (Orchestration & Management / Service Proxy)
File: tagging.md

title: Contour Tagging Policy layout: page This document describes Contour's image tagging policy. `ghcr.io/projectcontour/contour:<SemVer>` Contour follows the standard for releases. Each tag in the github.com/projectcontour/contour repository has a matching image. eg. `ghcr.io/projectcontour/contour:{{< param latest_version >}}` `ghcr.io/projectcontour/contour:v<major>.<minor>` This tag will point to the latest available patch of the release train mentioned. That is, it's `:latest` where you're guaranteed to not have a minor version bump. `ghcr.io/projectcontour/contour:latest` The `latest` tag follows the most recent stable version of Contour. `ghcr.io/projectcontour/contour:main` The `main` tag follows the latest commit to land on the `main` branch.
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: launch-a-kubernetes-cluster.md

Kusk needs to be installed in a Kubernetes cluster to serve its traffic. You can start a local Kubernetes cluster or connect to a remote cluster. In this tutorial, you'll find instructions to start a local cluster using , which will help you get started with Kusk. For more information on the different options for running a Kubernetes cluster locally or remotely, which contains a vast comparison list. Install Minikube Use the installation guide from Minikube . Start your Minikube cluster ```sh minikube start ``` ```sh title="Expected output:" minikube v1.28.0 on Darwin 13.0 (arm64) Automatically selected the docker driver Using Docker Desktop driver with root privileges Starting control plane node minikube in cluster minikube Pulling base image ... > gcr.io/k8s-minikube/kicbase: 0 B [_] ?% ? p/s 1m5s Creating docker container (CPUs=2, Memory=7802MB) ... Preparing Kubernetes v1.25.3 on Docker 20.10.20 ... Generating certificates and keys ... Booting up control plane ... Configuring RBAC rules ... Verifying Kubernetes components... Using image gcr.io/k8s-minikube/storage-provisioner:v5 Enabled addons: storage-provisioner, default-storageclass Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default ```
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.11.0-released.md

title: "Avro 1.11.0" linkTitle: "Avro 1.11.0" date: 2021-10-31 <!-- 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. --> The Apache Avro community is pleased to announce the release of Avro 1.11.0! All signed release artifacts, signatures and verification instructions can be found <a href="{{< relref "/project/download" >}}">here</a> This release includes 120 Jira issues, including some interesting features: Specification: AVRO-3212 Support documentation tags for FIXED types C#: AVRO-2961 Support dotnet framework 5.0 C#: AVRO-3225 Prevent memory errors when deserializing untrusted data C++: AVRO-2923 Logical type corrections Java: AVRO-2863 Support Avro core on android Javascript: AVRO-3131 Drop support for node.js 10 Perl: AVRO-3190 Fix error when reading from EOF Python: AVRO-2906 Improved performance validating deep record data Python: AVRO-2914 Drop Python 2 support Python: AVRO-3004 Drop Python 3.5 support Ruby: AVRO-3108 Drop Ruby 2.5 support For the first time, the 1.11.0 release includes experimental support for Rust. Work is continuing on this donated SDK, but we have not versioned and published official artifacts for this release. Python: The avro package fully supports Python 3. We will no longer publish a separate avro-python3 package And of course upgraded dependencies to latest versions, CVE fixes and more: https://issues.apache.org/jira/issues/?jql=project%3DAVRO%20AND%20fixVersion%3D1.11.0 The link to all fixed JIRA issues and a brief summary can be found at: https://github.com/apache/avro/releases/tag/release-1.11.0 In addition, language-specific release artifacts are available: C#: https://www.nuget.org/packages/Apache.Avro/1.11.0 Java: from Maven Central, Javascript: https://www.npmjs.com/package/avro-js/v/1.11.0 Perl: https://metacpan.org/release/Avro Python 3: https://pypi.org/project/avro/1.11.0 Ruby: https://rubygems.org/gems/avro/versions/1.11.0 Thanks to everyone for contributing!