cwielenb/CNCF-Dataset huggingface dataset:
Project: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: 0004-use-rig-config-for-global-configuration.md

Date: 28/11/2017 Accepted Supercedes The previous way of handling application configuration did not allow for a clean way override values using environment variables. Such overrides are necessary, because `config.exs` is evaluated at compile-time only. For instance, changing RIG's HTTP port should not require the corresponding Docker image to be recompiled. We use to make this more flexible. Consider the following example for use in `config.exs`: ```elixir config :rig, RigInboundGateway.ApiProxy.Base, recvtimeout: {:system, :integer, "PROXYRECVTIMEOUT", 5000} ``` Note that default values are given in `config.exs` and never in the implementation. The keyword list that supplied to the macro specifies the required keys; that is, their presence will be checked. Note that you can also validate the configuration values yourself by using `:custom_validation`, for example: ```elixir defmodule Rig.Kafka.MessageHandler do use Rig.Config, :custom_validation defp validateconfig!(nil), do: validateconfig!([]) defp validate_config!(config) do {targetmod, targetfun} = Keyword.fetch!(config, :userchannelname_mf) %{ messageuserfield: Keyword.fetch!(config, :messageuserfield), userchannelname: fn user -> apply(targetmod, targetfun, [user]) end } end ... end ``` To the user, configuring RIG becomes easier. To the developer, using application configuration within modules should be straightforward, with little to no boilerplate code involved.
Project: Traefik (Orchestration & Management / API Gateway)
File: logs.md

title: "Traefik Logs Documentation" description: "Logs are a key part of observability in Traefik Proxy. Read the technical documentation to learn their configurations, rotations, and time zones." Reading What's Happening {: .subtitle } By default, logs are written to stdout, in text format. Traefik logs concern everything that happens to Traefik itself (startup, configuration, events, shutdown, and so on). By default, the logs are written to the standard output. You can configure a file path instead using the `filePath` option. ```yaml tab="File (YAML)" log: filePath: "/path/to/traefik.log" ``` ```toml tab="File (TOML)" [log] filePath = "/path/to/traefik.log" ``` ```bash tab="CLI" --log.filePath=/path/to/traefik.log ``` By default, the logs use a text format (`common`), but you can also ask for the `json` format in the `format` option. ```yaml tab="File (YAML)" log: filePath: "/path/to/log-file.log" format: json ``` ```toml tab="File (TOML)" [log] filePath = "/path/to/log-file.log" format = "json" ``` ```bash tab="CLI" --log.filePath=/path/to/traefik.log --log.format=json ``` By default, the `level` is set to `ERROR`. Alternative logging levels are `TRACE`, `DEBUG`, `INFO`, `WARN`, `ERROR`, `FATAL`, and `PANIC`. ```yaml tab="File (YAML)" log: level: DEBUG ``` ```toml tab="File (TOML)" [log] level = "DEBUG" ``` ```bash tab="CLI" --log.level=DEBUG ``` When using the 'common' format, disables the colorized output. ```yaml tab="File (YAML)" log: noColor: true ``` ```toml tab="File (TOML)" [log] noColor = true ``` ```bash tab="CLI" --log.nocolor=true ``` The rotation of the log files can be configured with the following options. `maxSize` is the maximum size in megabytes of the log file before it gets rotated. It defaults to 100 megabytes. ```yaml tab="File (YAML)" log: maxSize: 1 ``` ```toml tab="File (TOML)" [log] maxSize = 1 ``` ```bash tab="CLI" --log.maxsize=1 ``` `maxBackups` is the maximum number of old log files to retain. The default is to retain all old log files (though `maxAge` may still cause them to get deleted). ```yaml tab="File (YAML)" log: maxBackups: 3 ``` ```toml tab="File (TOML)" [log] maxBackups = 3 ``` ```bash tab="CLI" --log.maxbackups=3 ``` `maxAge` is the maximum number of days to retain old log files based on the timestamp encoded in their filename. Note that a day is defined as 24 hours and may not exactly correspond to calendar days due to daylight savings, leap seconds, etc. The default is not to remove old log files based on age. ```yaml tab="File (YAML)" log: maxAge: 3 ``` ```toml tab="File (TOML)" [log] maxAge = 3 ``` ```bash tab="CLI" --log.maxage=3 ``` `compress` determines if the rotated log files should be compressed using gzip. The default is not to perform compression. ```yaml tab="File (YAML)" log: compress: 3 ``` ```toml tab="File (TOML)" [log] compress = 3 ``` ```bash tab="CLI" --log.compress=3 ```
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: connection-backoff.md

GRPC Connection Backoff Protocol ================================ When we do a connection to a backend which fails, it is typically desirable to not retry immediately (to avoid flooding the network or the server with requests) and instead do some form of exponential backoff. We have several parameters: INITIAL_BACKOFF (how long to wait after the first failure before retrying) MULTIPLIER (factor with which to multiply backoff after a failed retry) JITTER (by how much to randomize backoffs). MAX_BACKOFF (upper bound on backoff) MINCONNECTTIMEOUT (minimum time we're willing to give a connection to complete) Exponentially back off the start time of connection attempts up to a limit of MAX_BACKOFF, with jitter. ``` ConnectWithBackoff() currentbackoff = INITIALBACKOFF currentdeadline = now() + INITIALBACKOFF while (TryConnect(Max(currentdeadline, now() + MINCONNECT_TIMEOUT)) != SUCCESS) SleepUntil(current_deadline) currentbackoff = Min(currentbackoff * MULTIPLIER, MAX_BACKOFF) currentdeadline = now() + currentbackoff + UniformRandom(-JITTER current_backoff, JITTER current_backoff) ``` With specific parameters of MINCONNECTTIMEOUT = 20 seconds INITIAL_BACKOFF = 1 second MULTIPLIER = 1.6 MAX_BACKOFF = 120 seconds JITTER = 0.2 Implementations with pressing concerns (such as minimizing the number of wakeups on a mobile phone) may wish to use a different algorithm, and in particular different jitter logic. Alternate implementations must ensure that connection backoffs started at the same time disperse, and must not attempt connections substantially more often than the above algorithm. The back off should be reset to INITIAL_BACKOFF at some time point, so that the reconnecting behavior is consistent no matter the connection is a newly started one or a previously disconnected one. We choose to reset the Backoff when the SETTINGS frame is received, at that time point, we know for sure that this connection was accepted by the server.
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-audit.md

Gather all changes generated by the API Management. You're also able to filter them. Here is a description of an audit log: Date*: When the audit log was created User*: The user who has generated the audit log Type*: The parent entity type of the log (API/APPLICATION/PORTAL) Reference*: The parent entity name of the log (API name or Application name) Event*: The event type Target*: The target of the change Patch*: The Json patch of the change
Project: CloudWeGo (Orchestration & Management / Remote Procedure Call)
File: ROADMAP.md

This document shows key roadmap of Kitex development from the year of 2021 to 2022. It may help users know more about the future features. But the actual work is driven by real-world needs, we may adjust our goals sometimes. IO Communication Netpoll provides more features and do further performance optimization, references https://github.com/cloudwego/netpoll. Support ShmIPC to optimize IPC. Support data packet compression. Service Governance Support more extension for users. All developers are welcome to contribute your extension to https://github.com/kitex-contrib. Support dynamic config, expose API in Kitex. Support Proxyless mode to integrate with Istio. Codec Support no serialization which references but is compatible with Thrift. Support runtime serialization&deserialization without generating code (JIT) for Thrift. Tool Support generating Protobuf code to optimize performance. Improve the throughput of client side. Optimize Protobuf Streaming performance. Kitex-Protobuf supports codec with NoCopy API to reduce memory copies. Provide good development practices for users to develop with Kitex more easily. Improve Kitex Tool to provide more conveniences.
Project: 3Scale (Orchestration & Management / API Gateway)
File: grpc.md

APIcast 3.8 fully supports the HTTP/2 protocol. This enables APIcast to handle gRPC connections end-to-end, taking care of APIcast authentication, headers modification, and so on. HTTP/2 is only enabled in the Transport Layer Security (TLS) port. It is not enabled in the plaintext port. It is only enabled in TLS to support both HTTP 1.1 and 1.1 and HTTP2 protocols are supported. Within the TLS hello exchanges, the Application-Layer Protocol Negotiation (ALPN) uses the appropriate protocol. HTTP2 always takes precedence. Use headers authentication or OpenID, JSON Web Tokens (JWT), for transparency of the gRPC endpoints and to make it easier to add in the gRPC clients. The GRPC endpoint server should also listen in TLS, MTLS can be enabled or not, but the endpoint should finish TLS connections to be able to work as expected. In APIcast, for full gRPC traffic, enable the gRPC policy in the given service. The protocol used will then be full HTTP/2. This is because NGINX directives do not support ALPN. ``` { "services": [ { "id": 200, "backend_version": 1, "backendauthenticationtype": "service_token", "backendauthenticationvalue": "token-value", "proxy": { "credentials_location": "headers", "hosts": [ "apicast-service" ], "api_backend": "https://grpc-service:443", "proxy_rules": [ { "pattern": "/", "http_method": "GET", "metricsystemname": "hits", "delta": 1 }, { "pattern": "/", "http_method": "POST", "metricsystemname": "hits", "delta": 1 } ], "policy_chain": [ { "name": "apicast.policy.tls", "configuration": { "certificates": [ { "certificate_path": "/gateway/apicast-service.crt", "certificatekeypath": "/gateway/apicast-service.key" } ] } }, { "name": "apicast.policy.grpc" }, { "name": "apicast.policy.apicast" } ] } } ] } ``` Server TLS listener Example using golang: ``` creds, err := credentials.NewServerTLSFromFile(cert, key) if err != nil { log.Fatalf("Failed to setup TLS: %v", err) } lis, err := net.Listen("tcp", port) if err != nil { log.Fatalf("failed to listen: %v", err) } s := grpc.NewServer(grpc.Creds(creds)) ``` Client header metadata using golang: This snippet adds metadata as headers to send the credentials in the header, making it easier to read. ``` md := metadata.Pairs("userkey", *userkey) ctx := metadata.NewOutgoingContext(context.Background(), md) ctx, cancel := context.WithTimeout(ctx, time.Second) ```
Project: Gloo (Orchestration & Management / API Gateway)
File: kubernetes.proto.sk.md

title: "kubernetes.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Kubernetes Upstreams represent a set of one or more addressable pods for a Kubernetes Service the Gloo Kubernetes Upstream maps to a single service port. Because Kubernetes Services support multiple ports, Gloo requires that a different upstream be created for each port Kubernetes Upstreams are typically generated automatically by Gloo from the Kubernetes API ```yaml "serviceName": string "serviceNamespace": string "servicePort": int "selector": map<string, string> "serviceSpec": .options.gloo.solo.io.ServiceSpec "subsetSpec": .options.gloo.solo.io.SubsetSpec ``` | Field | Type | Description | | -- | - | -- | | `serviceName` | `string` | The name of the Kubernetes Service. | | `serviceNamespace` | `string` | The namespace where the Service lives. | | `servicePort` | `int` | The access port of the kubernetes service is listening. This port is used by Gloo to look up the corresponding port on the pod for routing. | | `selector` | `map<string, string>` | Allows finer-grained filtering of pods for the Upstream. Gloo will select pods based on their labels if any are provided here. (see . | | `serviceSpec` | | An optional Service Spec describing the service listening at this address. | | `subsetSpec` | | Subset configuration. For discovery sources that has labels (like kubernetes). this configuration allows you to partition the upstream to a set of subsets. for each unique set of keys and values, a subset will be created. | <!-- 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: Envoy (Orchestration & Management / Service Proxy)
File: repokitteh.md

<img src="https://repokitteh.io/logo.svg" height="100" align="right"> is a that provides an easy way to create, integrate and maintain GitHub bots. It is deployed in GCP and supplied to Envoy under a contract with the CNCF. The application is installed on specific GitHub repositories and interacts with these by receiving webhooks and making GitHub API calls. A root `repokitteh.star` script tells the application what to do based on the webhook received. The file , which resides in the root of the Envoy repository tells RepoKitteh what functionality to use. The file is written in the , which is a Python dialect with well defined threading and hermeticity guarantees. For example, the statement ``` use("github.com/repokitteh/modules/assign.star") ``` tells RepoKitteh to use the module. Similar modules can be integrated in the future into Envoy in the same way. Set assignees to issues or pull requests. Examples: ``` /assign @someone ``` Adds `@someone` as an assignee to the issue or pull request that this comment is made on. ``` /unassign @someone ``` Removes `@someone` as an assignee. ``` /assign-from @envoyproxy/some-team [@envoyproxy/another-team..] ``` Assign a random member from `@envoyproxy/some-team` to an issue or pull request. Additional teams may be specified as extra args. Example teams include: `@envoyproxy/senior-maintainers` (Senior maintainers) `@envoyproxy/maintainers` (All maintainers) `@envoyproxy/api-shepherds` (API shepherds) `@envoyproxy/dependency-shepherds` (Dependency shepherds) `@envoyproxy/first-pass-reviewers` (Contributors that provide first-pass reviews, typically non-senior maintainers and maintainer applicants) Only organization members can assign or unassign other users, who must be organization members as well. Requests a user to review a pull request. Examples: ``` /review @someone ``` Asks `@someone` to review the pull requests that this comment is made on. ``` /unreview @someone ``` Removes `@someone` from the reviewers list. Only organization members can request a review from other users or cancel it, who must be organization members as well. Wait for activity on an issue or a PR. Example: ``` /wait ``` Sets the label `waiting` on a PR. When a new commit is pushed the label will be removed. It is also possible to wait until any comment is submitted and/or a new commit is pushed. Example: ``` /wait-any ``` Sets the label `waiting:any` on a PR. When a new commit is pushed or any comment is submitted the label will be removed. Restart failed Azure pipelines. Example: ``` /retest ``` Restarts all failed Azure pipelines. Two types of approvals: Global approvals, done by approving the PR using Github's review approval feature. Partial approval, done by commenting "/lgtm [label]" where label is the label associated with the path. This does not affect GitHub's PR approve status, only this module's maintained commit status. This approval is automatically revoked if any further changes are done to the relevant files in this spec. ``` /backport ``` will labels the PR commented on with `backport/review`.
Project: Serverless Devs (Orchestration & Management / Scheduling & Orchestration)
File: set.md

title: Set Command description: 'Set Command' position: 11 category: 'Commands' The `set` command is used to configure the tool's settings. When you execute `s set -h`, you can view the corresponding help information: ```shell script $ s set -h Usage: s set [commands] [options] You can make some default settings for the tool here. Document: https://serverless.help/t/s/set Options: -h, --help Display help for command Commands: proxy [options] Set proxy information analysis Set to enable or disable analysis log Set to enable or disable log ``` This command includes three sub-commands: This command sets a global proxy for HTTP requests. Executing `s set proxy -h` displays the help documentation: ```shell script $ s set proxy -h Usage: s set proxy [options] Set proxy information. Example: $ s set proxy $ s set proxy --httpproxy xxxx:xxx --httpsproxy xxxx:xxx $ s set proxy --enable Document: https://serverless.help/t/s/set Options: --enable whether to enable proxy --no-enable whether to disable proxy --httpproxy <httpproxyvalue> Specify the httpproxy. --httpsproxy <httpsproxyvalue> Specify the httpsproxy. -h, --help Display help for command ``` There are two methods to set the proxy: Direct configuration, for example: `s set proxy --httpproxy xxxx:xxx --httpsproxy xxxx:xxx --enable` Through an interactive method: ```shell script $ s set proxy ? Please enter http_proxy: xxxx:xxx ? Please enter https_proxy: xxxx:xxx ? Do you want to enable proxy Yes ``` This command configures the data analysis capabilities of the Serverless Devs developer tool. Executing `s set analysis -h` displays the help documentation: ```shell script $ s set analysis -h Usage: s set analysis [options] Set analysis action. Example: $ s set analysis $ s set analysis disable Document: https://serverless.help/t/s/set Options: -h, --help Display help for command ``` There are two methods to set analysis: Direct configuration, for example: `s set analysis disable` Through an interactive method: ```shell script $ s set analysis Current analysis action: enable ? Choose an action? (Use arrow keys) enable disable ``` At this point, you just need to select the corresponding option to operate in a guided manner. Note: The system default for analysis is: `enable` This command configures the log writing capabilities of the Serverless Devs developer tool. Executing `s set log -h` displays the help documentation: ```shell script $ s set log -h Usage: s set log [options] Set log action. Example: $ s set log $ s set log enable $ s set log disable Document: https://serverless.help/t/s/set Options: -h, --help Display help for command ``` There are two methods to set log: Direct configuration, for example: `s set log disable` Through an interactive method: ```shell script $ s set log Current log action: enable ? Choose an action? (Use arrow keys) enable disable ``` At this point, you just need to select the corresponding option to operate in a guided manner. Note: The system default for log is: `enable`
Project: Prefect (Orchestration & Management / Scheduling & Orchestration)
File: rate-limits.md

description: Prefect Cloud API rate limits. tags: API Prefect Cloud rate limits search: boost: 2 API rate limits restrict the number of requests that a single client can make in a given time period. They ensure Prefect Cloud's stability, so that when you make an API call, you always get a response. !!! info "Prefect Cloud rate limits are subject to change" The following rate limits are in effect currently, but are subject to change. Contact Prefect support at if you have questions about current rate limits. Prefect Cloud enforces the following rate limits: Flow and task creation rate limits Log service rate limits Prefect Cloud limits the `flowruns`, `taskruns`, and `flows` endpoints and their subroutes at the following levels: 400 per minute for personal accounts 2,000 per minute for Pro accounts The Prefect Cloud API will return a `429` response with an appropriate `Retry-After` header if these limits are triggered. Prefect Cloud limits the number of logs accepted: 700 logs per minute for personal accounts 10,000 logs per minute for Pro accounts The Prefect Cloud API will return a `429` response if these limits are triggered. !!! info "Prefect Cloud feature" The Flow Run Retention Policy setting is only applicable in Prefect Cloud. Flow runs in Prefect Cloud are retained according to the Flow Run Retention Policy set by your account tier. The policy setting applies to all workspaces owned by the account. The flow run retention policy represents the number of days each flow run is available in the Prefect Cloud UI, and via the Prefect CLI and API after it ends. Once a flow run reaches a terminal state (), it will be retained until the end of the flow run retention period. !!! tip "Flow Run Retention Policy keys on terminal state" Note that, because Flow Run Retention Policy keys on terminal state, if two flows start at the same time, but reach a terminal state at different times, they will be removed at different times according to when they each reached their respective terminal states. This retention policy applies to all , including its task runs. Subflow runs follow the retention policy independently from their parent flow runs, and are removed based on the time each subflow run reaches a terminal state. If you or your organization have needs that require a tailored retention period, .
Project: 3Scale (Orchestration & Management / API Gateway)
File: policy-development.md

Newcomers to APIcast development might be interested in the following resources. At first, you might need to learn the Lua language (with a focus on version 5.1/5.2). The should be your first read and followed by . Then, we suggest learning Nginx with the . You might then learn OpenResty , full of examples and going through the . As you start writing your first APIcast policy, you might be interested in , that present real world use cases and their implementation using OpenResty.
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.5.2-released.md

title: "Avro 1.5.2" linkTitle: "Avro 1.5.2" date: 2011-08-12 <!-- 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.5.2 has been released!
Project: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: 0005-maintain-changelog.md

Date: 14/12/2017 Accepted We need to track what changes have been made to RIG and make it clear to everyone. It should also help with identifying of issues that may be caused by changes in the past. We decided to use `CHANGELOG.md` to have it as a single source of truth to what happened in RIG. Every submitted Pull Request will contain update to this file as well. By this everyone can clearly see which version has which features or fixes. Every contributor submitting Pull Request has to also update `CHANGELOG.md` file and keep everything up to date. Update has to be done in form of ``, please put your change under suitable section - changed, added, fixed, removed, deprecated