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

see sql files in `dolphinscheduler/dolphinscheduler-dao/src/main/resources/sql` One tenant can own Multiple users. The queue field in the `tdsuser` table stores the `queuename` information in the `tdsqueue` table, `tdstenant` stores queue information using `queueid` column. During the execution of the process definition, the user queue has the highest priority. If the user queue is null, use the tenant queue. The `userid` field in the `tdsdatasource` table shows the user who create the data source. The userid in `tdsrelationdatasourceuser` shows the user who has permission to the data source. User can have multiple projects, user project authorization completes the relationship binding using `projectid` and `userid` in `tdsrelationprojectuser` table. The `userid` in the `tdsprojcet` table represents the user who create the project, and the `userid` in the `tdsrelationprojectuser` table represents users who have permission to the project. The `userid` in the `tdsresources` table represents the user who create the resource, and the `userid` in `tdsrelationresourcesuser` represents the user who has permissions to the resource. The `userid` in the `tdsudfs` table represents the user who create the UDF, and the `userid` in the `tdsrelationudfsuser` table represents a user who has permission to the UDF. A project can have multiple process definitions, and each process definition belongs to only one project. A tenant can be used by multiple process definitions, and each process definition must select only one tenant. A workflow definition can have one or more schedules. A process definition corresponds to multiple task definitions, which are associated through `tdsprocesstaskrelation` and the associated key is `code + version`. When the pre-task of the task is empty, the corresponding `pretasknode` and `pretaskversion` are 0. A process definition can have multiple process instances `tdsprocessinstance`, one process instance corresponds to one or more task instances `tdstaskinstance`. The data stored in the `tdsrelationprocessinstance` table is used to handle the case that the process definition contains sub-processes. `parentprocessinstanceid` represents the id of the main process instance containing the sub-process, `processinstanceid` represents the id of the sub-process instance, `parenttaskinstanceid` represents the task instance id of the sub-process node. The process instance table and the task instance table correspond to the `tdsprocessinstance` table and the `tdstaskinstance` table, respectively.
Project: BFE (Orchestration & Management / Service Proxy)
File: mod_auth_basic.md

modauthbasic implements the HTTP basic authentication. conf/modauthbasic/modauthbasic.conf | Config Item | Description | | - | - | | Basic.DataPath | String<br>Path of rule configuration | | Log.OpenDebug | Boolean<br>Whether enable debug log<br>Default False | ```ini [Basic] DataPath = modauthbasic/authbasicrule.data [Log] OpenDebug = false ``` | Config Item | Description | | | - | | Version | String<br>Version of config file | | Config | Object<br>Auth rules for each product | | Config{k} | String<br>Product name | | Config{v} | Object<br> A list of auth rules | | Config{v}[] | Object<br> A auth rule | | Config{v} | | Config{v}[].UserFile | String<br>Path of password configuration | | Config{v}[].Realm | String<br>Realm, ie. protection space<br>Default "Restricted" | Description about password configuration: The password configuration can be generated using htpasswd or openssl Generated using openssl: ``` printf "user1:$(openssl passwd -apr1 123456)\n" >> ./userfile ``` Password configuration example ``` user1:$apr1$mI7SilJz$CWwYJyYKbhVDNl26sdUSh/ user2:{SHA}fEqNCco3Yq9h5ZUglD3CZJT4lBs=:user2, 123456 ``` ```json { "Config": { "example_product": [ { "Cond": "reqhostin(\"www.example.org\")", "UserFile": "../conf/modauthbasic/userfile", "Realm": "example_product" } ] }, Version": "20190101000000" } ```
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-application-subscriptions.md

Retrieve all the registered subscriptions per API. Subscription represents the plans the application has subscribed to. Subscriptions can be: Accepted Subscription is valid and the application can use its API Key to perform operations of the API. The subscription can be renewed, revoked or valid until its expiration date. Pending The application has asked access for the API and wait for the API owners approvals. Rejected Subscription is rejected and the application cannot use the API. Closed Subscription is closed and the application cannot use the API.
Project: Gloo (Orchestration & Management / API Gateway)
File: gloo_solo_io.project.sk.md

title: "gloosoloio.project" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> API Version: `gloo.solo.io.v1` Gloo is a high-performance, plugin-extendable, platform-agnostic API Gateway built on top of Envoy. Gloo is designed for microservice, monolithic, and serverless applications. By employing function-level routing, Gloo can completely decouple client APIs from upstream APIs at the routing level. Gloo serves as an abstraction layer between clients and upstream services, allowing front-end teams to work independently of teams developing the microservices their apps connect to. <!-- 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: Kuma (Orchestration & Management / Service Mesh)
File: extend_circuit-breaker.md

Kuma already has a policy CircuitBreaker, but it relies only on Envoy outlier detector mechanism under the hood. The current proposal aims to provide a way to extend CircuitBreaker. Extended CircuitBreaker policy should support Envoys circuit breaker thresholds alongside the outlier detector. Extended CircuitBreaker policy should give a way to configure the following Envoy parameters: - the maximum number of connections that Envoy will make to the upstream cluster. If not specified, the default is 1024. - the maximum number of pending requests that Envoy will allow to the upstream cluster. If not specified, the default is 1024. - the maximum number of parallel retries that Envoy will allow to the upstream cluster. If not specified, the default is 3. - the maximum number of parallel requests that Envoy will make to the upstream cluster. If not specified, the default is 1024. Add a new section `thresholds` alongside `detectors`: ```yaml type: CircuitBreaker mesh: default name: circuit-breaker-example sources: match: kuma.io/service: web destinations: match: kuma.io/service: backend conf: detectors: totalErrors: {} standardDeviation: {} thresholds: maxConnections: 2 maxPendingRequests: 2 maxRetries: 2 maxRequests: 2 ```
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2017-05-03-mesos-1-0-4-released.md

layout: post title: Apache Mesos 1.0.4 Released permalink: /blog/mesos-1-0-4-released/ published: true post_author: display_name: Vinod Kone twitter: vinodkone tags: Release The latest Mesos release, 1.0.4, is now available for . This release includes some important bug fixes and improvements on top of 1.0.0. It is highly recommended to use this version if you are considering using Mesos 1.0. More specifically, this release includes the following fixes and improvements: ACARGENABLED checks are broken Reject optimized builds with libcxx before 3.9 Quota not recovered from registry in empty cluster. Containerizer startup may cause sensitive data to leak into sandbox logs. Agent sandbox gc could accidentally delete the entire persistent volume content. Docker executor logs possibly sensitive parameters. Docker containerizer should not leak possibly sensitive data to agent log. Full release notes are available in the release Rolling upgrades from a Mesos 1.0.0 cluster to Mesos 1.0.4 are straightforward. Please refer to the for detailed information on upgrading to Mesos 1.0.4. We encourage you to try out this release and let us know what you think. If you run into any issues, please let us know on the . Thanks to the 8 contributors who made 1.0.4 possible Alexander Rukletsov, Benjamin Bannier, James Peach, Jie Yu, Kapil Arya, Neil Conway, Till Toenshoff, Vinod Kone.
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_proxy_served-config.md

title: "glooctl proxy served-config" weight: 5 dump Envoy config being served by the Gloo xDS server ``` glooctl proxy served-config [flags] ``` ``` -h, --help help for served-config ``` ``` -c, --config string set the path to the glooctl config file (default "<home_directory>/.gloo/glooctl-config.yaml") --consul-address string address of the Consul server. Use with --use-consul (default "127.0.0.1:8500") --consul-allow-stale-reads Allows reading using Consul's stale consistency mode. --consul-datacenter string Datacenter to use. If not provided, the default agent datacenter is used. Use with --use-consul --consul-root-key string key prefix for for Consul key-value storage. (default "gloo") --consul-scheme string URI scheme for the Consul server. Use with --use-consul (default "http") --consul-token string Token is used to provide a per-request ACL token which overrides the agent's default token. Use with --use-consul -i, --interactive use interactive mode --kube-context string kube context to use when interacting with kubernetes --kubeconfig string kubeconfig to use, if not standard one --name string the name of the proxy service/deployment to use (default "gateway-proxy") -n, --namespace string namespace for reading or writing resources (default "gloo-system") --port string the name of the service port to connect to (default "http") --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - interact with proxy instances managed by Gloo
Project: Envoy (Orchestration & Management / Service Proxy)
File: header_transforms.md

`RouteEntry::requestHeaderTransforms` and `ResponseEntry::responseHeaderTransforms` allows filters to obtain request and response header transformations that would be applied by `RouteEntry::finalizeRequestHeaders` and `ResponseEntry::finalizeResponseHeaders` respectively. If you do not have full knowledge that there will be no further route modifications later in the filter chain, you should not use these APIs. To obtain the response header transformations at request time: ``` cpp Http::FilterHeadersStatus MyFilter::decodeHeaders( Http::RequestHeaderMap& headers, bool) { auto transforms = decodercallbacks->route()->routeEntry()->responseHeaderTransforms( decodercallbacks->streamInfo()); // Send the response headers back to the client; they will process them later. decodercallbacks->sendLocalReply( Envoy::Http::Code::OK, MySerializedTransforms(transforms), nullptr, Envoy::Grpc::Status::Ok, "local_reply"); } ``` If you want to retrieve the original values rather than the formatted ones, pass `/do_formatting=/false` as the second argument to `responseHeaderTransforms`.
Project: Pipy (Orchestration & Management / Service Proxy)
File: NOTES-DJGPP.md

Notes for the DOS platform with DJGPP ===================================== OpenSSL has been ported to DJGPP, a Unix look-alike 32-bit run-time environment for 16-bit DOS, but only with long filename support. If you wish to compile on native DOS with 8+3 filenames, you will have to tweak the installation yourself, including renaming files with illegal or duplicate names. You should have a full DJGPP environment installed, including the latest versions of DJGPP, GCC, BINUTILS, BASH, etc. This package requires that PERL and the PERL module `Text::Template` also be installed (see ). All of these can be obtained from the usual DJGPP mirror sites or directly at <http://www.delorie.com/pub/djgpp>. For help on which files to download, see the DJGPP "ZIP PICKER" page at <http://www.delorie.com/djgpp/zip-picker.html>. You also need to have the WATT-32 networking package installed before you try to compile OpenSSL. This can be obtained from <http://www.watt-32.net/>. The Makefile assumes that the WATT-32 code is in the directory specified by the environment variable WATT_ROOT. If you have watt-32 in directory `watt32` under your main DJGPP directory, specify `WATT_ROOT="/dev/env/DJDIR/watt32"`. To compile OpenSSL, start your BASH shell, then configure for DJGPP by running `./Configure` with appropriate arguments: ./Configure no-threads --prefix=/dev/env/DJDIR DJGPP And finally fire up `make`. You may run out of DPMI selectors when running in a DOS box under Windows. If so, just close the BASH shell, go back to Windows, and restart BASH. Then run `make` again. RUN-TIME CAVEAT LECTOR -- Quoting FAQ: "Cryptographic software needs a source of unpredictable data to work correctly. Many open source operating systems provide a "randomness device" (`/dev/urandom` or `/dev/random`) that serves this purpose." As of version 0.9.7f DJGPP port checks upon `/dev/urandom$` for a 3rd party "randomness" DOS driver. One such driver, `NOISE.SYS`, can be obtained from <http://www.rahul.net/dkaufman/index.html>.
Project: OpenELB (Orchestration & Management / Service Proxy)
File: bug_report.md

name: Bug report about: Help us fix a problem title: "" labels: "" assignees: "" Describe the bug <!-- A clear and concise description of what the bug is. --> To Reproduce <!-- Steps to reproduce the behaviour: Go to '...' Click on '....' Scroll down to '....' See error --> Expected behaviour <!-- What did you expect to happen? --> Output <!-- Add the output you're seeing to help explain your problem. --> Version Info Version of Kubernetes: Version of OpenELB:
Project: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: api-gateway-synchronization.md

id: api-gateway-synchronization title: API Gateway Synchronization sidebar_label: API Gateway Synchronization The reverse proxy configuration consists of API definitions, which are synchronized among RIG nodes (eventually consistent). API definitions, like everything else in RIG, are stored in-memory only, which makes accessing them very fast. The image below shows how a change to an API definition on any node will eventually spread to all other nodes. The initial synchronization happens on RIG startup. Indeed, as long as one node has a JSON file with API definitions the configuration will be automatically spread among all nodes. In case there are two different JSON files found in the cluster, both are loaded and synchronized - eventually, all nodes have them configured. Note that the JSON file is only used at startup and is not used thereafter; for example, changes done to an API definition through RIG's API are not reflected in the file. Conflicts are resolved using several rules: `ref_number` - Describes the version of the API definition. The higher the number, the newer the API and the higher the priority in the merging process. Data comparison - compares the API definitions directly. If they are different, the API is also checked on other nodes. Finally, the version that is used on most nodes is determined to be current. If multiple versions of the API definition are used evenly among nodes then timestamps are compared and the newer definition is selected. You can change API definitions also during runtime via the REST API. Again, it's enough to change an API definition on single node and changes will be spread to the others. For this type of synchronization we use the same rules as above.
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: new-pmc-michael-a-smith.md

title: "New PMC member: Michael A. Smith" linkTitle: "New PMC member: Michael A. Smith" date: 2023-08-09 <!-- 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 Project Management Committee (PMC) for Apache Avro has invited Michael A. Smith to the PMC and we are pleased to announce that he has accepted. Notably, Michael has taken a leadership role in ensuring the quality of the Python SDK, lending his expertise to ensure that Avro has a place in the python community, while keeping our implementation up-to-date with standards and modern versions. It's not an easy task, and we appreciate all he does!
Project: Contour (Orchestration & Management / Service Proxy)
File: health-checking.md

title: Health Checking Contour exposes two health endpoints `/health` and `/healthz`. By default these paths are serviced by `0.0.0.0:8000` and are configurable using the `--health-address` and `--health-port` flags. e.g. `--health-port 9999` would create a health listener of `0.0.0.0:9999` Note: the `Service` deployment manifest when installing Contour must be updated to represent the same port as the above configured flags. The health endpoints perform a connection to the Kubernetes cluster's API.
Project: Flomesh Service Mesh (FSM) (Orchestration & Management / Service Mesh)
File: release_process.md

Flomesh Service Mesh will target a release every quarter. These releases will be targeted in the first half of February, May, August, and November. These target release months are subject to change if a release is pushed. In other words, if a release misses February and is pushed out in March then the next release will target June instead of May. If you would like to see a new feature added to Flomesh Service Mesh, please . This issue will be discussed and, if approved, prioritized in the backlog. When there is a new release being planned and developed, a will be created. This new milestone will have issues added to it that will be prioritized from the . Once the release milestone is complete, a new release of Flomesh Service Mesh will be created and this milestone will be closed. At that moment, the next release milestone will be created and items from vFuture will be added. For larger projects where development will likely span multiple releases we should have a separate feature milestone created. This feature milestone should have a projected end date. Once a release milestone is opened up that has an end date that includes the feature milestone end date, this feature should be considered to be included in the next release. The progression of approved work items will go through this lifecycle: Added to the when approved Added to the when set for the next release Added to the column when prioritized for "next work" Moved to the In progress column when being actively worked on Moved to the Done column when completed At the end of this lifecycle it will be included in the next release of FSM. Release candidates (RCs) should be created before each significant release so final testing can be performed. RCs are tagged as `vX.Y.Z-rc.W`. After the following steps have been performed to publish the RC, perform any final testing with the published release artifacts for about one week. If issues are found, submit patches to the RC's release branch and create a new RC with the tag `vX.Y.Z-rc.W+1`. Apply those same patches to the `main` branch. Repeat until the release is suitably stable.
Project: KubeStellar (Orchestration & Management / Scheduling & Orchestration)
File: example-wecs.md

The following steps show how to create two new `kind` clusters and register them with the hub as descibed in the . Note that `kind` does not support three or more concurrent clusters unless you raise some limits as described in this `kind` "known issue": . Execute the following commands to create two kind clusters, named `cluster1` and `cluster2`, and register them with the OCM hub. These clusters will serve as workload clusters. If you have previously executed these commands, you might already have contexts named `cluster1` and `cluster2`. If so, you can remove these contexts using the commands `kubectl config delete-context cluster1` and `kubectl config delete-context cluster2`. ```shell : set flags to "" if you have installed KubeStellar on an OpenShift cluster flags="--force-internal-endpoint-lookup" clusters=(cluster1 cluster2); for cluster in "${clusters[@]}"; do kind create cluster --name ${cluster} kubectl config rename-context kind-${cluster} ${cluster} clusteradm --context its1 get token | grep '^clusteradm join' | sed "s/<cluster_name>/${cluster}/" | awk '{print $0 " --context '${cluster}' --singleton '${flags}'"}' | sh done ``` The `clusteradm` command grabs a token from the hub (`its1` context), and constructs the command to apply the new cluster to be registered as a managed cluster on the OCM hub. Repeatedly issue the command: ```shell kubectl --context its1 get csr ``` until you see that the certificate signing requests (CSR) for both cluster1 and cluster2 exist. Note that the CSRs condition is supposed to be `Pending` until you approve them in step 4. Once the CSRs are created approve the csrs to complete the cluster registration with the command: ```shell clusteradm --context its1 accept --clusters cluster1 clusteradm --context its1 accept --clusters cluster2 ``` Check the new clusters are in the OCM inventory and label them: ```shell kubectl --context its1 get managedclusters kubectl --context its1 label managedcluster cluster1 location-group=edge name=cluster1 kubectl --context its1 label managedcluster cluster2 location-group=edge name=cluster2 ```
Project: BFE (Orchestration & Management / Service Proxy)
File: install_using_binaries.md

of BFE for your platform. Extract the files to the installation directory: ```bash $ tar zxvf bfe<version><os>_<arch>.tar.gz ``` Run BFE with example configuration files: ```bash $ cd bfe/bin $ ./bfe -c ../conf -l ../log ``` Get familiar with Get started with
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: MAINTAINERS.md

This page lists all active maintainers of this repository. If you were a maintainer and would like to add your name to the Emeritus list, please send us a PR. See for governance guidelines and how to become a maintainer. See for general contribution guidelines. , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC
Project: Merbridge (Orchestration & Management / Service Mesh)
File: ROADMAP.md

[ ] Metrics [X] Linkerd2 Supported [X] Kuma Support [ ] Cross-node mode(XDP?) [X] IPv6 Support [ ] Dual stack [X] DNS Redirect [ ] Ambient Mesh Support [ ] Lower kernel required (5.4? limited) [ ] Optimize prog performance [X] OSM/OSM-Edge Support [ ] Metrics [X] Istio sidecar annotations [ ] Ambient Mesh Support [X] Merbridge CNI [X] Website [X] Blog