cwielenb/CNCF-Dataset huggingface dataset:
Project: Crossplane (Orchestration & Management / Scheduling & Orchestration)
File: one-pager-custom-secret-definitions.md

Owner: Bassam Tabbara (@bassam) Reviewers: Crossplane Maintainers Status: Defunct Secrets in Kubernetes are objects that hold sensitive data like passwords, tokens and keys. Secrets can be consumed directly from Pods and mounted as volumes or through environment variables, and as result present a powerful way to pass sensitive config to a pod. While secrets are objects/resources themselves they do not have a schema or spec, like other objects. The payload of a secret is an arbitrary map of values. Secrets do however have a `type` field that specifies the payload type and is typically set to `Opaque`. For example, `kubernetes.io/service-account-token` and `kubernetes.io/dockercfg`. For tools that consume and generate secrets it's desirable to define the schema for a secret, in the same way that we define a schema for resource via Customer Resource Definitions (CRDs). This would enable a consistent representation of secrets that can be validated, and consumed by the eco-system of tools building on-top of the Kubernetes API. This proposal explores the idea of a Custom Secret Definition (CSD). We borrow heavily from CRDs in this design. Here's an example, CSD: ```yaml apiVersion: core.crossplane.io/v1alpha1 kind: CustomSecretDefinition metadata: name: mysql.database.crossplane.io spec: group: database.crossplane.io names: kind: mysql version: v1alpha1 validation: openAPIV3Schema: properties: username: type: string password: type: string required: username password ``` this would serve as the schema for the following secret: ```yaml apiVersion: v1 kind: Secret metadata: name: mysecret type: mysql.v1alpha1.database.crossplane.io data: username: YWRtaW4= password: MWYyZDFlMmU2N2Rm ``` The secret could can be validated but that would require a validating webhook. For now, the CSD could merely be used as the documentation for the secret schema.
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: DEVELOPER_GUIDE.md

So you want to contribute code to the OpenSearch Go Client? Excellent! We're glad you're here. Here's what you need to do: Fork and clone locally, e.g. `git clone https://github.com/[your username]/opensearch-go.git`. OpenSearch Go Client builds using 1.11 at a minimum. is required for building some OpenSearch artifacts and executing integration tests. Go has a simple tool for running tests, and we simplified it further by creating this make command: ``` make test-unit ``` Individual unit tests can be run with the following command: ``` cd folder-path/to/test; go test -v -run TestName; ``` In order to test opensearch-go client, you need a running OpenSearch cluster. You can use Docker to accomplish this. The supports the ability to run integration tests for the project in local environments. If you have not installed docker-compose, you can install it from this . In order to differentiate unit tests from integration tests, Go has a built-in mechanism for allowing you to logically separate your tests with . The build tag needs to be placed as close to the top of the file as possible, and must have a blank line beneath it. Hence, create all integration tests with build tag 'integration'. Run below command to start containers. By default, it will launch latest OpenSearch cluster. ``` make cluster.opensearch.build cluster.opensearch.start ``` Run all integration tests. ``` make test-integ race=true ``` Stop and clean containers. ``` make cluster.opensearch.stop cluster.clean ``` You can import the OpenSearch project into GoLand as follows: Select File | Open In the subsequent dialog navigate to the ~/go/src/opensearch-go and click Open After you have opened your project, you need to specify the location of the Go SDK. You can either specify a local path to the SDK or download it. To set the Go SDK, navigate to Go | GOROOT and set accordingly.
Project: APISIX (Orchestration & Management / API Gateway)
File: route.md

title: Route keywords: API Gateway Apache APISIX Route description: This article describes the concept of Route and how to use it. <!-- --> Routes match the client's request based on defined rules, load and execute the corresponding , and forwards the request to the specified . A Route mainly consists of three parts: Matching rules (`uri`, `host`, `remote address`) Plugin configuration (current-limit, rate-limit) Upstream information The image below shows some example Route rules. Note that the values are of the same color if they are identical. All the parameters are configured directly in the Route. It is easy to set up, and each Route has a high degree of freedom. When Routes have repetitive configurations (say, enabling the same plugin configuration or Upstream information), to update it, we need to traverse all the Routes and modify them. This adds a lot of complexity, making it difficult to maintain. These shortcomings are independently abstracted in APISIX by two concepts: and . The Route example shown below proxies the request with the URL `/index.html` to the Upstream service with the address `127.0.0.1:1980`. :::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 -i -d ' { "uri": "/index.html", "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } }' ``` ```shell HTTP/1.1 201 Created Date: Sat, 31 Aug 2019 01:17:15 GMT Content-Type: text/plain Transfer-Encoding: chunked Connection: keep-alive Server: APISIX web server {"node":{"value":{"uri":"\/index.html","upstream":{"nodes":{"127.0.0.1:1980":1},"type":"roundrobin"}},"createdIndex":61925,"key":"\/apisix\/routes\/1","modifiedIndex":61925}} ``` A successful response indicates that the route was created. For specific options of Route, please refer to the .
Project: Sermant (Orchestration & Management / Service Mesh)
File: pull_request_template.md

What type of PR is this? Feature/Bug/Refactor etc. What this PR does / why we need it? Describe it. Which issue(s) this PR fixes Fixes # Does this PR introduce a user-facing change? No <!-- Follow this checklist to help us incorporate your contribution quickly and easily: --> related with this PR before you start working on it. [ ] Make sure you have squashed your change to one single commit. [ ] GitHub Actions works fine in this PR.
Project: KubeStellar (Orchestration & Management / Scheduling & Orchestration)
File: _index.md

: Discussion and help from your fellow users : Follow us on YouTube to view recordings of past KubeStellar community meetings and demo days : See what others are saying about the community : Follow us on Medium to read about community developments : Development takes place here! in the : Chat with other project developers : Discuss development issues around the project You can find out how to contribute to KubeStellar in our Join our to get your community meeting invitation. You can also directly , or view our See and community meeting agendas and notes Sign up to discuss a topic in the <br/> <iframe src="https://calendar.google.com/calendar/embed?src=b3d65c92bed7a9884ef7fe9e3f6c8fed16f6fb2f811f5750f547567a5dd58fed%40group.calendar.google.com&ctz=America%2FNew_York" style="border: 0" width="800" height="600" frameborder="0" scrolling="no"></iframe>
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: karmadactl_test.md

| Test Case | E2E Describe Text | Comments | |--|--|| | Test promoting namespace scope resource(deployment) by karmadactl | Test promoting a deployment from cluster member | | | Test promoting cluster scope resource(clusterrole, clusterrolebinding) by karmadactl | Test promoting clusterrole and clusterrolebindings | | | Test promoting namespace scope resource(service) by karmadactl | Test promoting a service from cluster member | | | Test join cluster and unjoin not ready cluster by karmadactl | Test unjoining not ready cluster | | | Test cordon cluster by karmadactl | cluster %s should have unschedulable:NoSchedule taint | | | Test uncordon cluster by karmadactl | cluster %s should not have unschedulable:NoSchedule taint | | | Test exec command by karmadactl | Test exec command | | Add the testcase for the rest commands https://karmada.io/docs/next/reference/karmadactl/karmadactl-commands/karmadactl#see-also.
Project: HAProxy (Orchestration & Management / Service Proxy)
File: README.md

This tool monitors the HAProxy stable branches and calculates a proposed release date for the next minor release based on the bug fixes that are in the queue. Python 3.x release-estimator.py [-h] [--print] [--to-email TO_EMAIL] [--from-email FROM_EMAIL] [--send-mail] optional arguments: -h, --help show this help message and exit --print Print email only --to-email TO_EMAIL Send email to <email> --from-email FROM_EMAIL Send email from <email> --send-mail Send email ./release-estimator.py --print ./release-estimator.py --send-mail --from-email from@domain.local --to-email to@domain.local For each version we check the age and apply the following logic: Skip the release if it's: older than MAXVERSIONAGE older than MAXVERSIONAGE_NONLTS days and an odd numbered release (1.9,2.1,2.3) For all other valid releases we will then collect the number of bug fixes in queue for each of the defined severity levels: BUG BUILD MINOR MEDIUM MAJOR CRITICAL We'll then begin calculating the proposed release date based on the last release date plus the first commit date of the first bug fix for the defined severity level. By default the proposed release dates use the following padding: (Can be modified in THRESHOLDS) BUG/BUILD/MINOR - 28 days MEDIUM - 30 days MAJOR - 14 days CRITICAL - 2 days After we have a proposed release date we will assign a release urgency to it. As we get closer to the proposed release date the urgency level changes. By default the urgency levels and their times are: WARNING - proposed date is 7 days or less NOTICE - proposed date is 21 days or less INFO - proposed date is longer than the above
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-configuration-apiquality.md

Add a quality rate on apis according to criteria: documentation exists and is published a health-check is set the description contains has a minimum length the default logo is not used categories and labels are set on the API The idea is to invite API publisher to configure all non-mandatory fields according to the admin rules. A percentage rate will be calculated according to these rules and their weights. This will allow for a reviewer to validate the quality of the APIs according to some rules defined manually. These rules are attached to a weight to process the final quality rate.
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: mcs_test.md

| Test Case | E2E Describe Text | Comments | |-|-|| | Test the connectivity(Export service and import service) | Export Service from source-clusters, import Service to destination-clusters | | | Test the connectivity(Update source-cluster's deployment's replicas) | Update Deployment's replicas | | | Test Case | E2E Description | Comments | |--|-|-| | Test when the ServiceProvisionClusters field is [member1], ServiceConsumptionClusters field is [member2] | Test dispatch EndpointSlice from the provision clusters to the consumption clusters | | | Test when the ServiceProvisionClusters field is [member1, member2], ServiceConsumptionClusters field is [member2] | Test dispatch EndpointSlice from the provision clusters to the consumption clusters | | | Test when the ServiceProvisionClusters field is [member1, member2], ServiceConsumptionClusters field is [member2]; then, ServiceProvisionClusters field changes to [member2], ServiceConsumptionClusters field is [member1] | Test dispatch EndpointSlice from the provision clusters to the consumption clusters | | | Test when the ServiceProvisionClusters field is empty, ServiceConsumptionClusters field is [member2] | Test dispatch EndpointSlice from the provision clusters to the consumption clusters | | | Test when the ServiceProvisionClusters field is [member1], ServiceConsumptionClusters field is empty | Test dispatch EndpointSlice from the provision clusters to the consumption clusters | | | Test when the ServiceProvisionClusters field is empty, ServiceConsumptionClusters field is empty | Test dispatch EndpointSlice from the provision clusters to the consumption clusters | |
Project: Gloo (Orchestration & Management / API Gateway)
File: router.proto.sk.md

title: "router.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Router is an envoy http filter Maps to https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/router/v3/router.proto ```yaml "suppressEnvoyHeaders": .google.protobuf.BoolValue "dynamicStats": .google.protobuf.BoolValue ``` | Field | Type | Description | | -- | - | -- | | `suppressEnvoyHeaders` | | Do not add any additional x-envoy- headers to requests or responses. This only affects the router filter generated x-envoy- headers, other Envoy filters and the HTTP connection manager may continue to set x-envoy- headers. | | `dynamicStats` | | Whether dynamic stats should be enabled or disabled. If not set, or if set to true, dynamic stats will be enabled. Otherwise, if set to false, dynamic stats will be disabled. It is strongly recommended to leave this in the default state in production - it should only be set to false in very specific benchmarking or profiling scenarios. | <!-- Start of HubSpot Embed Code --> <script type="text/javascript" id="hs-script-loader" async defer src="//js.hs-scripts.com/5130874.js"></script> <!-- End of HubSpot Embed Code -->
Project: APISIX (Orchestration & Management / API Gateway)
File: load-balancing.md

title: Load Balancing slug: /getting-started/load-balancing <head> <link rel="canonical" href="https://docs.api7.ai/apisix/getting-started/load-balancing" /> </head> The Getting Started tutorials are contributed by . Load balancing manages traffic between clients and servers. It is a mechanism used to decide which server handles a specific request, allowing for improved performance, scalability, and reliability. Load balancing is a key consideration in designing systems that need to handle a large volume of traffic. Apache APISIX supports weighted round-robin load balancing, in which incoming traffic are distributed across a set of servers in a cyclical pattern, with each server taking a turn in a predefined order. In this tutorial, you will create a route with two upstream services and enable round-robin load balancing to distribute traffic between the two services. Complete to install APISIX. Understand APISIX . Let's create a route with two upstream services. All requests sent to the `/headers` endpoint will be forwarded to and , which should echo back the requester's headers. ```shell curl -i "http://127.0.0.1:9180/apisix/admin/routes" -X PUT -d ' { "id": "getting-started-headers", "uri": "/headers", "upstream" : { "type": "roundrobin", "nodes": { "httpbin.org:443": 1, "mock.api7.ai:443": 1 }, "pass_host": "node", "scheme": "https" } }' ``` You will receive an `HTTP/1.1 201 Created` response if the route was created successfully. :::info The `pass_host` field is set to `node` to pass the host header to the upstream. The `scheme` field is set to `https` to enable TLS when sending requests to the upstream. ::: The two services respond with different data. From `httpbin.org`: ```json { "headers": { "Accept": "/", "Host": "httpbin.org", "User-Agent": "curl/7.58.0", "X-Amzn-Trace-Id": "Root=1-63e34b15-19f666602f22591b525e1e80", "X-Forwarded-Host": "localhost" } } ``` From `mock.api7.ai`: ```json { "headers": { "accept": "/", "host": "mock.api7.ai", "user-agent": "curl/7.58.0", "content-type": "application/json", "x-application-owner": "API7.ai" } } ``` Let's generate 100 requests to test the load-balancing effect: ```shell hc=$(seq 100 | xargs -I {} curl "http://127.0.0.1:9080/headers" -sL | grep "httpbin" | wc -l); echo httpbin.org: $hc, mock.api7.ai: $((100 - $hc)) ``` The result shows the requests were distributed over the two services almost equally: ```text httpbin.org: 51, mock.api7.ai: 49 ``` You have learned how to configure load balancing. In the next tutorial, you will learn how to configure key authentication.
Project: Knative (Orchestration & Management / Scheduling & Orchestration)
File: LICENSE.md

MIT License Copyright (c) 2019 Josh Bleecher Snyder Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Project: Clusterpedia (Orchestration & Management / Scheduling & Orchestration)
File: PULL_REQUEST_TEMPLATE.md

What type of PR is this? <!-- Add one of the following kinds: /kind api-change /kind bug /kind cleanup /kind deprecation /kind design /kind documentation /kind failing-test /kind feature /kind flake --> What this PR does / why we need it: Which issue(s) this PR fixes: Fixes # Special notes for your reviewer: Does this PR introduce a user-facing change?: <!-- If no, just write "NONE" in the release-note block below. If yes, a release note is required. --> ```release-note ```
Project: Crossplane (Orchestration & Management / Scheduling & Orchestration)
File: bug_report.md

name: Bug Report about: Help us diagnose and fix bugs in Crossplane labels: bug <!-- Thank you for helping to improve Crossplane! Please be sure to search for open issues before raising a new one. We use issues for bug reports and feature requests. Please find us at https://slack.crossplane.io for questions, support, and discussion. --> <!-- Please let us know what behaviour you expected and how Crossplane diverged from that behaviour. --> <!-- Help us to reproduce your bug as succinctly and precisely as possible. Artifacts such as example manifests or a script that triggers the issue are highly appreciated! --> Crossplane version: <!-- Include at least the version or commit of Crossplane you were running. Consider also including your: Cloud provider or hardware configuration Kubernetes version (use `kubectl version`) Kubernetes distribution (e.g. Tectonic, GKE, OpenShift) OS (e.g. from /etc/os-release) Kernel (e.g. `uname -a`) -->
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: api-c++.md

title: "C++ API" linkTitle: "C++ API" weight: 102 manualLink: /docs/++version++/api/cpp/html/ <!-- 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 C++ API documentation can be found <a href="/docs/++version++/api/cpp/html/">here</a>.
Project: APISIX (Orchestration & Management / API Gateway)
File: apisix.md

title: Architecture keywords: API Gateway Apache APISIX APISIX architecture description: Architecture of Apache APISIXthe Cloud Native API Gateway. <!-- --> APISIX is built on top of Nginx and leveraging the power offered by LuaJIT. See . APISIX has two main parts: APISIX core, Lua plugin, multi-language Plugin runtime, and the WASM plugin runtime. Built-in Plugins that adds features for observability, security, traffic control, etc. The APISIX core handles the important functions like matching Routes, load balancing, service discovery, configuration management, and provides a management API. It also includes APISIX Plugin runtime supporting Lua and multilingual Plugins (Go, Java , Python, JavaScript, etc) including the experimental WASM Plugin runtime. APISIX also has a set of that adds features like authentication, security, observability, etc. They are written in Lua. The diagram below shows how APISIX handles an incoming request and applies corresponding Plugins: The chart below shows the order in which different types of Plugin are applied to a request:
Project: Netflix Zuul (Orchestration & Management / Service Proxy)
File: README.md

](https://github.com/Netflix/zuul/actions/workflows/snapshot.yml) <img src="https://i.imgur.com/mRSosEp.png" width=500/> Zuul is an L7 application gateway that provides capabilities for dynamic routing, monitoring, resiliency, security, and more. Please view the wiki for usage, information, HOWTO, etc https://github.com/Netflix/zuul/wiki Here are some links to help you learn more about the Zuul Project. Feel free to PR to add any other info, presentations, etc. Articles from Netflix: Zuul 1: http://techblog.netflix.com/2013/06/announcing-zuul-edge-service-in-cloud.html Zuul 2: https://netflixtechblog.com/open-sourcing-zuul-2-82ea476cb2b3 https://netflixtechblog.com/zuul-2-the-netflix-journey-to-asynchronous-non-blocking-systems-45947377fb5c https://netflixtechblog.com/the-show-must-go-on-securing-netflix-studios-at-scale-19b801c86479 Netflix presentations about Zuul: Strange Loop 2017 - Zuul 2: https://youtu.be/2oXqbLhMS_A AWS re:Invent 2018 - Scaling push messaging for millions of Netflix devices: https://youtu.be/IdR6N9B-S1E Slides from Netflix presentations about Zuul: http://www.slideshare.net/MikeyCohen1/zuul-netflix-springone-platform http://www.slideshare.net/MikeyCohen1/rethinking-cloud-proxies-54923218 https://github.com/strangeloop/StrangeLoop2017/blob/master/slides/ArthurGonigberg-ZuulsJourneyToNonBlocking.pdf https://www.slideshare.net/SusheelAroskar/scaling-push-messaging-for-millions-of-netflix-devices Projects Using Zuul: https://cloud.spring.io/ https://jhipster.github.io/ Info and examples from various projects: https://cloud.spring.io/spring-cloud-netflix/multi/multirouterandfilter_zuul http://www.baeldung.com/spring-rest-with-zuul-proxy https://blog.heroku.com/usingnetflixzuultoproxyyourmicroservices http://blog.ippon.tech/jhipster-3-0-introducing-microservices/ Other blog posts about Zuul: https://engineering.riotgames.com/news/riot-games-api-fulfilling-zuuls-destiny https://engineering.riotgames.com/news/riot-games-api-deep-dive http://instea.sk/2015/04/netflix-zuul-vs-nginx-performance/ This project uses a GitHub Action workflow for publishing a new release. The workflow is triggered by a Git tag. ``` git checkout master git tag vX.Y.Z git push --tags ```
Project: hami (Orchestration & Management / Scheduling & Orchestration)
File: PULL_REQUEST_TEMPLATE.md

What type of PR is this? <!-- Add one of the following kinds: /kind bug /kind cleanup /kind deprecation /kind design /kind documentation /kind failing-test /kind feature /kind flake --> What this PR does / why we need it: Which issue(s) this PR fixes: Fixes # Special notes for your reviewer: Does this PR introduce a user-facing change?: