cwielenb/CNCF-Dataset huggingface dataset:
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: have-questions.md

Chat rooms are great for quick questions or discussions on specialized topics. The following chat rooms are officially part of Apache DolphinScheduler: The Slack workspace URL: http://asf-dolphinscheduler.slack.com/. You can join through invitation url: https://join.slack.com/t/asf-dolphinscheduler/shared_invite/zt-1e0s4agia-Ofkxa93zStmqTm9UsQBE8g. This chat room is used for questions and discussions related to using DolphinScheduler. is for people who want to contribute code to DolphinScheduler. ) ) Some quick tips when using email: Tagging the subject line of your email will help you get a faster response, e.g. [api-server]: How to get open api interface? Tags may help identify a topic by: Component: MasterServer,ApiServer,WorkerServer,AlertServer, etc Level: Beginner, Intermediate, Advanced Scenario: Debug, How-to For error logs or long code examples, please use and include only a few lines of the pertinent code / log within the email.
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.11.3.md

+++ title = "CoreDNS-1.11.3 Release" description = "CoreDNS-1.11.3 Release Notes." tags = ["Release", "1.11.3", "Notes"] release = "1.11.3" date = "2024-04-24T16:57:00-04:00 author = "coredns" +++ This release contains some new features, bug fixes, and package updates. Because of the deployment issues with the previous release, all changed features from 1.11.2 have been included in this release. New features include: When the forward plugin receives a malformed upstream response that overflows, it will now send an empty response to the client with the truncated (TC) bit set to prompt the client to retry over TCP. The rewrite plugin can now rewrite response codes. The dnstap plugin now supports adding metadata to the dnstap `extra` field. Amila Senadheera, Ben Kochie, Benjamin, Chris O'Haver, Grant Spence, John Belamaric, Keita Kitamura, Marius Kimmina, Michael Grosser, Ondej Benkovsk, P. Radha Krishna, Rahil Bhimjiani, Sri Harsha, Tom Thorogood, Willow (GHOST), Yong Tang, Yuheng, Zhizhen He, guangwu, journey-c, pschou Ted Ford plugin/tls: respect the path specified by root plugin (https://github.com/coredns/coredns/pull/6138) plugin/auto: warn when auto is unable to read elements of the directory tree (https://github.com/coredns/coredns/pull/6333) plugin/etcd: the etcd client adds the DialKeepAliveTime parameter (https://github.com/coredns/coredns/pull/6351) plugin/cache: key cache on Checking Disabled (CD) bit (https://github.com/coredns/coredns/pull/6354) plugin/forward: Use the correct root domain name in the forward plugin's health checks (https://github.com/coredns/coredns/pull/6395) plugin/forward: Handle UDP responses that overflow with TC bit (https://github.com/coredns/coredns/pull/6277) plugin/rewrite: fix multi request concurrency issue in cname rewrite (https://github.com/coredns/coredns/pull/6407) plugin/rewrite: add rcode as a rewrite option (https://github.com/coredns/coredns/pull/6204) plugin/dnstap: add support for "extra" field in payload (https://github.com/coredns/coredns/pull/6226) plugin/cache: fix keepttl parsing (https://github.com/coredns/coredns/pull/6250) Return RcodeServerFailure when DNS64 has no next plugin (https://github.com/coredns/coredns/pull/6590) Change the log flags to be a variable that can be set (https://github.com/coredns/coredns/pull/6546) Bump go version to 1.21 (https://github.com/coredns/coredns/pull/6533) replace the mutex locks in logging with atomic bool for the "on" flag (https://github.com/coredns/coredns/pull/6525) Enable Prometheus native histograms (https://github.com/coredns/coredns/pull/6524)
Project: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: examples.md

id: examples title: Examples sidebar_label: Examples We provide set of examples that should give you an idea on how to integrate RIG into your current application. In the [`examples`] directory you can find several examples for both Server-Sent Events (SSE) and WebSocket (WS) based connections. The examples show how to use them in a simple way, but also in conjunction with JWT, constraints and extractors. They are designed to be executable with RIG as their only dependency. Available examples: API Gateway: This is a playground where you can test various use cases mentioned in the Section. Channels: A slightly bigger example that uses Kafka, a small NodeJS microservice and a React based UI that lets you choose between an SSE and a WebSocket connection. The Channels example lets you see the entire communication flow from client, through RIG, to the microservice, to Kafka, to RIG again and finally back to the client. It's also lets you play around with public as well as with private subscriptions. Avro: Find an example around Avro in the dedicated to the topic.
Project: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: README.md

A Java application used to consume messages from Amazon Kinesis Data Streams. It uses the official AWS Java SDK and the . Compile with `mvn package` or `mix compilekinesisclient` from the root folder. During development, `mvn exec:java` may be helpful as well. Note that maven uses a instead of the one included in your system Erlang distribution. This is just convenience in case your Erlang is not compiled with Java support. At runtime, the Jar file is expected to be on the classpath, i.e., considered a `provided` dependency. The KCL is the only Amazon-supported way of integration with Kinesis and it is responsible for a lot of complexity: Connects to the stream Enumerates the shards Coordinates shard associations with other workers (if any) Instantiates a record processor for every shard it manages Pulls data records from the stream Pushes the records to the corresponding record processor Checkpoints processed records Balances shard-worker associations when the worker instance count changes Balances shard-worker associations when shards are split or merged Implementing this in Elixir (and keeping the implementation up-to-date with the Kinesis API) seems more effort than using the library in a separate Java app. RIG manages the lifecycle of the Java app and processes its log messages. Messages coming from Kinesis are sent from the Java app to RIG using Erlang RPCs (see for details). The Java app is configured through RIG (a user should not have to deal with properties-files or any other Java stuff). The environment variables are documented in .
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.7.7-released.md

title: "Avro 1.7.7" linkTitle: "Avro 1.7.7" date: 2014-07-23 <!-- 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.7.7 has been released!
Project: Serverless Devs (Orchestration & Management / Scheduling & Orchestration)
File: purpose_and_goals.md

title: Objectives description: 'Objectives' position: 2 category: 'User model' Serverless User Model (SUM) defines a serverless developer model and developer specification. Based on the model and specification, developers can develop serverless applications in a convenient manner, which improves efficiency. Serverless applications can be deployed online, which play a role in the entire application lifecycle. ures as expected.
Project: BFE (Orchestration & Management / Service Proxy)
File: host_table_status.md

The endpoint `/monitor/hosttablestatus` expose metrics about routing configurations. | Metric | Description | | | | | HostTableSize | Size of host table | | HostTagTableSize | Size of host tag table | | VipTableSize | Size of vip table | | ProductRouteTableSize | Size of product route table |
Project: Gloo (Orchestration & Management / API Gateway)
File: grpc_web.md

title: gRPC Web weight: 20 description: Enable or disable the transcoding of messages to support gRPC web clients gRPC-Web is a Javascript library that lets browser clients using HTTP-1 or HTTP-2 access a gRPC service. Envoy supports the gRPC-Web protocol out of the box, functioning as a proxy between web clients and the gRPC service. In this guide you'll see how to enable or disable the gRPC-Web protocol on Envoy through Gloo Edge's gateway Custom Resource. In order to serve gRPC-Web clients, the server must first transcode the message into a format that the web client can understand . Gloo Edge configures Envoy to do this by default. If you would like to disable this behavior, you can do so by editing the gateway Custom Resource for the Gateway you would like to alter. The relevant section of the gateway CR is highlighted below. {{< highlight yaml "hl_lines=7-9" >}} apiVersion: gateway.solo.io/v1 kind: Gateway metadata: # collapsed for brevity spec: bindAddress: '::' bindPort: 8080 httpGateway: options: grpcWeb: disable: true useProxyProto: false status: # collapsed for brevity {{< /highlight >}} For more information on how to edit the gateway CR, take a look at the . You may also want to take a look at the Envoy docs regarding the with Envoy.
Project: Fluid (Orchestration & Management / Scheduling & Orchestration)
File: juicefs_setup.md

In order to get started with Fluid + JuiceFS, you can quickly build community version of JuiceFS environment in Kubernetes by following the steps below. This environment is only used for functional verification, without any tuning, and is not recommended for production environments. The following example uses MinIO as the back-end object storage and Redis as the metadata service. Create Minio Service ```yaml $ cat << EOF > minio.yaml apiVersion: v1 kind: Service metadata: name: minio spec: type: ClusterIP ports: port: 9000 targetPort: 9000 protocol: TCP selector: app: minio apiVersion: apps/v1 # for k8s versions before 1.9.0 use apps/v1beta2 and before 1.8.0 use extensions/v1beta1 kind: Deployment metadata: name: minio spec: selector: matchLabels: app: minio strategy: type: Recreate template: metadata: labels: app: minio spec: containers: name: minio image: minio/minio args: server /storage env: name: MINIOROOTUSER value: "minioadmin" name: MINIOROOTPASSWORD value: "minioadmin" ports: containerPort: 9000 hostPort: 9000 EOF ``` Create Deployment and Service ```bash $ kubectl create -f minio.yaml service/minio created deployment.apps/minio created ```` Check the result ```bash $ kubectl get deploy minio NAME READY UP-TO-DATE AVAILABLE AGE minio 0/1 1 0 40s $ kubectl get svc minio NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE minio ClusterIP 172.16.159.15 <none> 9000/TCP 77s ``` Create Redis service ```yaml $ cat << EOF > redis.yaml apiVersion: v1 kind: Service metadata: name: redis labels: app: redis spec: type: ClusterIP ports: name: redis port: 6379 selector: app: redis apiVersion: apps/v1 kind: Deployment metadata: name: redis labels: app: redis spec: replicas: 1 selector: matchLabels: app: redis template: metadata: labels: app: redis spec: containers: name: redis image: redis ports: containerPort: 6379 EOF ``` At this point, the basic environment of open source Juicefs has been prepared. You can see the corresponding configuration at this time. | Name | Value | Description | |-|--|--| | `metaurl` | redis://redis:6379/0 | Access URL of metadata service (such as Redis). For more information, refer to | | `access-key` | minoadmin |Access key for object storage | | `access-secret` | minoadmin |Access secret for object storage | | `storage type` | minio | Type of object storage |
Project: Skipper (Orchestration & Management / Service Proxy)
File: kubernetes.md

Skipper's Kubernetes dataclient can be used, if you want to run Skipper as . It will get its route information from provisioned . How to for cluster operators. Find out more for deployers. Kubernetes is a fast changing environment and traditional http routers are not made for frequently changing routing tables. Skipper is a http proxy made to apply updates very often. Skipper is used in production with more than 200.000 routing table entries. Skipper has Filters to change http data and Predicates to change the matching rules, both can combined and chained. You can set these in ingress.yaml files to build resiliency patterns like load shedding, ratelimit or circuitbreaker. You can also use them to build more highlevel deployment patterns, for example feature toggles, shadow traffic or blue-green deployments. Skipper's main features: Filters - create, update, delete all kind of HTTP data : for example , , and handling - : based on client or backend data - advanced matching capability URL match: `Path("/foo")` match: `Host("^www.example.org$")` : `QueryParam("featureX")` : `Cookie("alpha", /^enabled$/)` : `Source("1.2.3.4/24")` or `ClientIP("1.2.3.4/24")` - supports also sticky sessions Kubernetes integration All Filters and Predicates can be used with 2 Predicates: `zalando.org/skipper-predicate` Filters: `zalando.org/skipper-filter` Custom routes can be defined with the annotation `zalando.org/skipper-routes` to support all skipper features without limitation - access logs with fine granular control of logs by status codes Blue-Green deployments, with another Ingress annotation `zalando.org/backend-weights`
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: grpc_release_schedule.md

Below is the release schedule for gRPC , and and its dependent languages C++, C#, Objective-C, PHP, Python and Ruby. Releases are scheduled every six weeks on Tuesdays on a best effort basis. In some unavoidable situations a release may be delayed or released early or a language may skip a release altogether and do the next release to catch up with other languages. See the past releases in the links above. A six-week cycle gives us a good balance between delivering new features/fixes quickly and keeping the release overhead low. The gRPC release support policy can be found . Releases are cut from release branches. For Core and Java repos, the release branch is cut two weeks before the scheduled release date. For Go, the branch is cut just before the release. An RC (release candidate) is published for Core and its dependent languages just after the branch cut. This RC is later promoted to release version if no further changes are made to the release branch. We do our best to keep head of master branch stable at all times regardless of release schedule. Daily build packages from master branch for C#, PHP, Python, Ruby and Protoc plugins are published on . If you depend on gRPC in production we recommend to set up your CI system to test the RCs and, if possible, the daily builds. Names of gRPC releases are . Release |Scheduled Branch Cut|Scheduled Release Date --|--|- v1.17.0 |Nov 19, 2018 |Dec 4, 2018 v1.18.0 |Jan 2, 2019 |Jan 15, 2019 v1.19.0 |Feb 12, 2019 |Feb 26, 2019 v1.20.0 |Mar 26, 2019 |Apr 9, 2019 v1.21.0 |May 7, 2019 |May 21, 2019 v1.22.0 |Jun 18, 2019 |Jul 2, 2019 v1.23.0 |Jul 30, 2019 |Aug 13, 2019 v1.24.0 |Sept 10, 2019 |Sept 24, 2019 v1.25.0 |Oct 22, 2019 |Nov 5, 2019 v1.26.0 |Dec 3, 2019 |Dec 17, 2019 v1.27.0 |Jan 14, 2020 |Jan 28, 2020 v1.28.0 |Feb 25, 2020 |Mar 10, 2020 v1.29.0 |Apr 7, 2020 |Apr 21, 2020 v1.30.0 |May 19, 2020 |Jun 2, 2020 v1.31.0 |Jul 14, 2020 |Jul 28, 2020 v1.32.0 |Aug 25, 2020 |Sep 8, 2020 v1.33.0 |Oct 6, 2020 |Oct 20, 2020 v1.34.0 |Nov 17, 2020 |Dec 1, 2020 v1.35.0 |Dec 29, 2020 |Jan 12, 2021 v1.36.0 |Feb 9, 2021 |Feb 23, 2021 v1.37.0 |Mar 23, 2021 |Apr 6, 2021 v1.38.0 |May 4, 2021 |May 18, 2021 v1.39.0 |Jun 15, 2021 |Jun 29, 2021 v1.40.0 |Jul 27, 2021 |Aug 10, 2021 v1.41.0 |Sep 7, 2021 |Sep 21, 2021 v1.42.0 |Oct 19, 2021 |Nov 2, 2021 v1.43.0 |Nov 30, 2021 |Dec 14, 2021 v1.44.0 |Jan 11, 2022 |Jan 25, 2022 v1.45.0 |Feb 22, 2022 |Mar 8, 2022
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-api-documentation.md

At this date, two types of document are supported: Swagger Markdown (MD) You can access to your API data (name, version, description ...) on your APIs documentation by writing: `${api.name}` or `${api.metadata['foo-bar']}` in your documentation's content. By default, documentation pages are in staging mode and will be visible to API owners and API members with specific documentation roles. To make documentation visible for all users, you can switch on the published button. You can set a page to be a homepage by clicking on the house button. API homepage will be visible in the Portal main page of the API. You can also configure a page by clicking on the settings button. Page's configuration let you fetch page's content from an external resource such as Git repositories, or HTTP urls. In this case, you can configure an automatic fetch to refresh your pages periodically (see Auto Fetch here after). (+) button let you create a new documentation page. Another possibility is to add a whole directory. Click on the link at the top of the screen and import a directory. If this directory contains a Gravitee descriptor (a file named `.gravitee.json`) we will add the content according to the descriptor. Here is a descriptor sample: ```json { "version": 1, "documentation": { "pages": [ { "src": "/docs/readme.md", "dest": "/my/new/dir/", "name": "Homepage", "homepage": true }, { "src": "/docs/doc2.md", "dest": "/my/new/dir/", "name": "Business" } ] } } ``` To fetch periodically your documentation from external source, you can enable the 'Auto Fetch' option and specify the fetch frequency. This frequency definition uses a cron expression that is a string consisting of six fields that describe the schedule representing second, minute, hour, day, month and weekday. Here is some examples: Fetch every hour: ` /1 *` At 00:00 on Saturday: `0 0 0 * SAT` Note: Platform administrator may have configured a max frequency that you cannot exceed. For example, if you configure a refresh every minute and the platform administrator configure a maximum period of 5 minutes, the refresh will be applied every 5 minutes.
Project: wasmCloud (Orchestration & Management / Scheduling & Orchestration)
File: Completions.md

`wash` can generate scripts that enable auto-completion for several popular shells. With completion enabled, you can press TAB while entering a `wash` command to see available options and subcommands. (Depending on configuration, you may need to type a `-`, then TAB, to see options) In the set-up instructions below, `wash` generates the completion script file when the shell starts, ensuring that you always have the latest version of the script even if wash was just updated. Modify `~/.zshrc` by adding the following lines. The folder `$HOME/.wash` must be added to the `fpath` array before calling oh-my-zsh: ``` $HOME/.cargo/bin/wash completions -d $HOME/.wash zsh fpath=( $HOME/.wash "${fpath[@]}" ) [ -n "$ZSH" ] && [ -r $ZSH/oh-my-zsh.sh ] && source $ZSH/oh-my-zsh.sh ``` Completions will be enabled the next time you start a shell. Or, you can `source ~/.zshrc` for the completions to take effect in the current shell. Modify `~/.bashrc` by adding the following lines. ``` $HOME/.cargo/bin/wash completions -d $HOME/.wash bash source $HOME/.wash/wash.bash ``` Completions will be enabled the next time you start a shell. Or, you can `source ~/.bashrc` for the completions to take effect in the current shell. Modify `~/.fishrc` by adding the following lines. ``` mkdir -p ~/.config/fish/completions $HOME/.cargo/bin/wash completions -d ~/.config/fish/completions fish ``` Add the following line to your powershell profile script. This will generate `wash.ps1` in the specified folder. ``` wash completions -d "C:\Users\[User]\Documents\WindowsPowerShell" power-shell ```
Project: KubeBrain (Orchestration & Management / Coordination & Service Discovery)
File: storage_engine.md

Currently, we have the following feature requirements for the storage engine: Support snapshot read; Support bidirectional traversal; Supports read-write transactions or write transactions with CAS function; Expose logic clock. The following levels of transaction assurance are required for the storage engine: Isolation Guarantee: Snapshot Isolation; Session Guarantee: Linearizable. Possible anomalies to Snapshot Isolation as summarised in ): Write Skew: The current data structure and write design theoretically do not break the consistency constraint; Phantom: Using Snapshot Read, theoretically, reading the value written by concurrent transactions in advance does not affect the final consistency of the data. The storage engine is abstracted as an , and may be further optimized in the future. The goal is to make it possible to adapt to more KV databases.
Project: StackStorm (Orchestration & Management / Scheduling & Orchestration)
File: CHANGES.md

added `notify-errbot` rule to better support err-stackstorm users. `route` to `postresult` parameters to be propagated through to `postmessage`. `note` to `post_result` output to inform if the action-alias execution result was enabled or disabled. Ported `post_result` action-chain to orquesta for conditional branching. Introduce the following new actions: ``chatops.match`` ``chatops.matchandexecute`` ``chatops.run``
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: question.md

name: Question about: Question relating to Karmada. labels: kind/question <!-- Please use this template while asking a new question. Thanks! Please make sure you have read the FAQ and searched the issue list. FAQ: https://karmada.io/docs/faq Issues: https://github.com/karmada-io/karmada/issues?q=is%3Aissue+ --> Please provide an in-depth description of the question you have: What do you think about this question?: Environment: Karmada version: Kubernetes version: Others:
Project: Flomesh Service Mesh (FSM) (Orchestration & Management / Service Mesh)
File: pull_request_review_guide.md

This document outlines how to review a pull request and best practices and tips for reviewing pull requests in the FSM repository. Reviews are welcomed from everyone although each pull request (PR) needs at least two approvals from core maintainers from the repository before it can be merged into the main branch. Github outlines how to review a pull request and FSM does not deviate from this standard process. Leave comments if the PR author can make adjustments to write better Go according to the . Ask questions if the code does not make sense to you. Make sure each PR includes the appropriate unit tests and e2e tests and read the tests to make sure you understand what the author is changing and what is the expected behavior of the code. Although squashing commits , remind the author to squash commits into a single commit when it makes sense. Each commit merged into the main branch should be able to pass all CI tests. If the PR author is not a core maintainer and you are a core maintainer, merge the pull request when it has the required number of approvals. Add to this list of best practices and tips