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

The MIT License (MIT) Copyright (c) 2014 Mitchell Hashimoto 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: Easegress (Orchestration & Management / API Gateway)
File: 1.3.Concepts.md

Easegress operates on the foundational concepts of controllers, pipelines, and filters. The Easegress controller is the central unit responsible for various operations. Different controllers perform specific tasks; for example, the `HTTPServer` controller handles HTTP traffic. These controllers can be created, updated, edited, or deleted using `egctl` commands along with YAML files. Controllers like `ConsulServiceRegistry`, `EtcdServiceRegistry`, `EurekaServiceRegistry`, `ZookeeperServiceRegistry`, and `NacosServiceRegistry` are specialized for service registry tasks. Others, such as `HTTPServer` and `GRPCServer`, focus on managing network traffic. Still others, like `AutoCertManager` and `GlobalFilter`, are designed to handle specific business logic. For more information, refer to . The `Pipeline` is a built-in Easegress mechanism designed to orchestrate a sequence of filters for handling requests. It often operates in conjunction with `HTTPServer` and serves as its backend. The pipeline comprises a flow of filters executed in a defined sequence. A sample configuration might look like: ```yaml name: pipeline-demo kind: Pipeline flow: filter: validator filter: proxy ... filters: name: validator kind: Validator ... name: proxy kind: Proxy ... ... ``` For more information, refer to . A Filter acts as a processor for handling requests and responses. In a pipeline, multiple filters are orchestrated to process the input sequentially, each returning a string result upon completion. Filters are primarily utilized within `Pipelines`. For instance, the `Proxy` filter serves as a gateway to backend services, while the `RateLimiter` filter enhances service reliability and availability by regulating the rate of incoming requests within a specified time frame. For more information, refer to .
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2016-02-12-mesoscon-2016-cfp-is-now-open.md

layout: post title: MesosCon 2016 CFP is now open! permalink: /blog/mesoscon-2016-cfp-is-now-open/ published: true post_author: display_name: Michael Park gravatar: 2ab9cab3a7cf782261c583c1f48a81b0 twitter: mcypark tags: MesosCon, Announcement MesosCon North America 2016 will be held in Denver, CO on June 1-2, 2016. Talk submissions, sponsorship opportunities, and early-bird registration are now open for the conference. Several formats are being accepted for speaking proposals, including: Presentations, Panels, Keynotes and Lightning Talks. Submissions are being accepted through March 9, 2016. You can take a look at for ideas. If you're unsure about your proposal, or want some feedback or advice in general, please don't hesitate to reach out to the mailing list. We'll be happy to help out! Further details are available on the . All submissions for MesosCon North America will also be considered for the upcoming MesosCon Europe and China events (details to be announced shortly). The is now available, including several opportunities with limited availability. is open through April 22nd! We look forward to seeing you at MesosCon North America, as well as MesosCon Europe and MesosCon China taking place later this year!
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: plugin-conf.md

* * * Created by There are several plugins and actions in `kube-batch` right now; the users may want to only enable part of plugins and actions. This document is going to introduce dynamic plugins configuration, so the users can configure `kube-batch` according to their scenario on the fly. The following YAML format will be introduced for dynamic plugin configuration: ```yaml actions: "listofactioninorder" tiers: plugins: name: "plugin_1" disableJobOrder: true name: "plugin_2" plugins: name: "plugin_3" disableJobOrder: true ``` The `actions` is a list of actions that will be executed by `kube-batch` in order, separated by commas. Refer to the for the list of supported actions in `kube-batch`. Those actions will be executed in order, although the "order" maybe incorrect; the `kube-batch` does not enforce that. The `tiers` is a list of plugins that will be used by related actions, e.g. `allocate`. It includes several tiers of plugin list by `plugins`; if it fits plugins in high priority tier, the action will not go through the plugins in lower priority tiers. In each tier, it's considered passed if all the plugins are fitted in `plugins.names`. The `options` defines the detail behaviour of each plugins, e.g. whether preemption is enabled. If not specific, `true` is default value. For now, `preemptable`, `jobOrder`, `taskOrder` are supported. Takes following example as demonstration: The actions `"reclaim, allocate, backfill, preempt"` will be executed in order by `kube-batch` `"priority"` has higher priority than `"gang, drf, predicates, proportion"`; a job with higher priority will preempt other jobs, although it's already allocated "enough" resource according to `"drf"` `"tiers.plugins.drf.disableTaskOrder"` is `true`, so `drf` will not impact task order phase/action ```yaml actions: "reclaim, allocate, backfill, preempt" tiers: plugins: name: "priority" name: "gang" plugins: name: "drf" disableTaskOrder: true name: "predicates" name: "proportion" ``` `kube-batch` will read the plugin configuration from command line argument `--scheduler-conf`; user can use `ConfigMap` to acesss the volume of `kube-batch` pod during deployment.
Project: Koordinator (Orchestration & Management / Scheduling & Orchestration)
File: ADOPTERS.md

This list shows adopters of Koordinator. If you're using Koordinator in some way, even only evaluating, then please feel free to get in touch. Sample (for demonstrating and inspiring purpose) Alpha (used in companies for pilot projects) Beta (used in companies and developed actively) Stable (used in companies for production workloads) | Organization | Contact | Maturity | Description of Use | ||--|-|--| | | | Stable | Koordinator is used to manage highly-loaded internal infrastructure providing reliable business solutions for scheduling and ML. | | | | Stable | Heavily use Koordinator as base building block and inspiration in production for online/offline colocation, including qos-ensurance and fine-grained CPU/GPU scheduling. | | | | Stable | Use Koordinatior in production cluster for online/offline colocation to improve k8s cluster resource utilization. | | | | Stable | Use Koordinatior in production cluster for online/offline colocation to improve k8s cluster resource utilization. | | | | Stable | 1. Machines running some middleware procs they can limit the resources they use and we will use the idle resources to run some online/offline pods to increase resource utilization; 2. To improve the resource utilization in production clusters with online/offline colocation. | | | | Sample | Koordinatior is used as the elastic scheduler of flink, hudi, and alloxio to maximize the use of resources by using resource quotas and fair scheduling | | | | Stable | Use Koordinatior in production cluster for online/offline/flink colocation to improve k8s cluster resource utilization. | | | | Sample | Use Koordinatior in production cluster for online/offline colocation to improve cluster resource utilization. | | | | Stable| Use Koordinatior in production cluster for online/offline colocation to improve k8s cluster resource utilization. | Send a PR to with a brief description of how you're using Koordinator, this should include your use-case. And please kindly reformat the above table after you added yourself to the list.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: chunjun.md

ChunJun task type for executing ChunJun programs. For ChunJun nodes, the worker will execute `${CHUNJUN_HOME}/bin/start-chunjun` to analyze the input json file. Click `Project Management -> Project Name -> Workflow Definition`, and click the `Create Workflow` button to enter the DAG editing page. Drag the <img src="../../../../img/tasks/icons/chunjun.png" width="15"/> from the toolbar to the drawing board. Please refer to `Default Task Parameters` section for default parameters | Parameter | Description | |-|| | Custom template | Custom the content of the ChunJun node's json profile. | | json | json configuration file for ChunJun synchronization. | | Custom parameters | It is a user-defined parameter, and will replace the content with `${variable}` in the script. | | Deploy mode | Execute chunjun task mode, eg local standalone. | | Option Parameters | Support such as `-confProp "{\"flink.checkpoint.interval\":60000}"` | | Predecessor task | Selecting a predecessor task for the current task will set the selected predecessor task as upstream of the current task. | This example demonstrates importing data from Hive into MySQL. If you are using the ChunJun task type in a production environment, it is necessary to configure the required environment first. The configuration file is as follows: `/dolphinscheduler/conf/env/dolphinscheduler_env.sh`. After the environment has been configured, DolphinScheduler needs to be restarted. As the data to be read from Hive, a custom json is required, refer to: . After writing the required json file, you can configure the node content by following the steps in the diagram below. Before execute ${CHUNJUNHOME}/bin/start-chunjun, need to change the shell ${CHUNJUNHOME}/bin/start-chunjun, remove '&' in order to run in front. such as: ```shell nohup $JAVARUN -cp $JARDIR $CLASS_NAME $@ & ``` update to following: ```shell nohup $JAVARUN -cp $JARDIR $CLASS_NAME $@ ```
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: startup-parameter.md

Parameters are valid for all task nodes of the entire workflow. It can be configured on the task launch page. Usage of startup parameters is: at the task launch page, click the '+' below the 'Startup Parameter' and fill in the key and value to save. The workflow will add them into global parameters. This example shows how to use startup parameters to print different date. Create a shell task and enter `echo ${dt}` in the script content. In this case, dt is the global parameter we need to declare. As shown below: Set startup parameter as follows: Note: The dt parameter defined here can be referenced by the local parameters of any other node. On the task instance page, you can check the log to verify the execution result of the task and determine whether the parameters are valid. You can check the log to verify whether the shell task output different dates.
Project: Open Cluster Management (Orchestration & Management / Scheduling & Orchestration)
File: clusterset.md

ManagedClusterSet defines a group of ManagedClusters that user's workload can run on. Put label `cluster.open-cluster-management.io/clusterset=<clusterset_name>` on a ManagedCluster to assign it to a ManagedClusterSet. To remove a ManagedCluster from a ManagedClusterSet, just remove the label `cluster.open-cluster-management.io/clusterset` from the ManagedCluster. User must have a RBAC rule `CREATE` on a virtual subresource of `managedclustersets/join` to add/remove label `cluster.open-cluster-management.io/clusterset` to/from a ManagedCluster. In order to update this label on a ManagedCluster, user must have the permission on both the old and new ManagedClusterSet.
Project: Traefik Mesh (Orchestration & Management / Service Mesh)
File: api.md

title: "Traefik Mesh API" description: "Traefik Mesh includes a built-in API that can be used for debugging purposes. Read the documentation to learn more." Traefik Mesh includes a built-in API that can be used for debugging purposes. This can be useful when Traefik Mesh is not working as intended. The API is accessed via the controller pod, and for security reasons is not exposed via service. The API can be accessed by making a `GET` request to `http://<control pod IP>:9000` combined with one of the following paths: This endpoint provides raw json of the current configuration built by the controller. !!! Note This may change on each request, as it is a live data structure. This endpoint provides a json array containing some details about the readiness of the Traefik Mesh nodes visible by the controller. This endpoint will still return a 200 if there are no visible nodes. This endpoint provides raw json of the current configuration on the Traefik Mesh node with the pod name given in `{traefik-mesh-pod-name}`. This endpoint provides a 404 response if the pod cannot be found, or other non-200 status codes on other errors. If errors are encountered, the error will be returned in the body, and logged on the controller. This endpoint returns a 200 response if the controller has successfully started. Otherwise, it will return a 500.
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.24.2.md

We are delighted to present version v1.24.2 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. Update to Envoy v1.25.2. See the for more information about the content of the release. Update to Go v1.19.7. See the for more information. Update to golang.org/x/net@v0.8.0. Update to golang.org/x/image@v0.6.0. For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.24.2 is tested against Kubernetes 1.24 through 1.26. If you're using Contour and want to add your organization to our adopters list, please visit this . If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this .
Project: Clusterpedia (Orchestration & Management / Scheduling & Orchestration)
File: ROADMAP.md

Currently, it is only a tentative roadmap and the specific schedule depends on the community needs. About some features not added to Roadmap, we can discuss in . Expose resource metrices for multiple clusters like Clusterpedia APIServer supports log query for pods MQTT-based Agent Resource Collection Model ClusterSynchro manager exposes cluster state and resource synchronization status related metrics Supports resource watching for multiple clusters Support Graph Database* Storage Layer Support for requests with relevant resources Support for custom resource columns when accepting data in Table format Support for , such as watch/create/update/delete operations Build-in multi-cluster metrics server in the clusterpedia apiserver Provide multi-cluster metrics server via OpenTelemery in Agent mode The `Default Storage Layer` supports for Custom Collection Resource Support filter namespaces when sync resources
Project: Gloo (Orchestration & Management / API Gateway)
File: datadog.proto.sk.md

title: "datadog.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Configuration for the Datadog tracer. [#extension: envoy.tracers.datadog] ```yaml "collectorUpstreamRef": .core.solo.io.ResourceRef "clusterName": string "serviceName": .google.protobuf.StringValue ``` | Field | Type | Description | | -- | - | -- | | `collectorUpstreamRef` | | The upstream to use for submitting traces to the Datadog agent. Only one of `collectorUpstreamRef` or `clusterName` can be set. | | `clusterName` | `string` | The name of the cluster to use for submitting traces to the Datadog agent. Note that the cluster must be defined in the :ref:`Bootstrap static cluster resources <envoyapifield_config.bootstrap.v3.Bootstrap.StaticResources.clusters>`. Only one of `clusterName` or `collectorUpstreamRef` can be set. | | `serviceName` | | The name used for the service when traces are generated by envoy. | <!-- 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: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.7.5-released.md

title: "Avro 1.7.5" linkTitle: "Avro 1.7.5" date: 2013-08-19 <!-- 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.5 has been released!
Project: KubeGateway (Orchestration & Management / API Gateway)
File: flaking-test.md

name: Flaking Test about: Report flaky tests or jobs in Kubernetes CI labels: kind/flake <!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --> Which jobs are flaking: Which test(s) are flaking: Testgrid link: Reason for failure: Anything else we need to know: links to go.k8s.io/triage appreciated links to specific failures in spyglass appreciated
Project: Gloo (Orchestration & Management / API Gateway)
File: solo_xff_offset_filter.proto.sk.md

title: "soloxffoffset_filter.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Envoy filter configuration for the soloxffoffset filter, not set by the user. ```yaml "offset": int ``` | Field | Type | Description | | -- | - | -- | | `offset` | `int` | The amount of addresses from the left of x-forwarded-for (xff) header which should be skipped to get the client address. | <!-- 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: BFE (Orchestration & Management / Service Proxy)
File: gslb.data.md

gslb.data records the load balancing config between sub-clusters. | Config Item | Description | | -- | | | Clusters | Object<br>cluster config | | Clusters{k} | String<br>cluster name | | Clusters{v} | Object<br>weight config for each sub-cluster | | Clusters{v}{k} | String<br>name of sub-cluster<br>GSLB_BLACKHOLE is the name of blackhole sub-cluster which discards all incoming requests | | Clusters{v}{v} | Integer<br>weight of sub-cluster<br>The weight should be [0, 100] and the weight sum of all sub-cluster should be 100 | | Hostname | String<br>Hostname of gslb scheduler | | Ts | String<br>Timestamp of config file | ```json { "Clusters": { "cluster_example": { "GSLB_BLACKHOLE": 0, "example.bfe.bj": 100 } }, "Hostname": "gslb-sch.example.com", "Ts": "20190101000000" } ```
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: corefile.5.md

corefile - configuration file for CoreDNS. A corefile specifies the internal servers CoreDNS should run and what plugins each of these should chain. The syntax is as follows: ~~~ txt [SCHEME://]ZONE [[SCHEME://]ZONE]...[:PORT] { [PLUGIN]... } ~~~ The ZONE defines for which name this server should be called, multiple zones are allowed and should be white space separated. You can use a "reverse" syntax to specify a reverse zone (i.e. ip6.arpa and in-addr.arpa), by using an IP address in the CIDR notation. The optional SCHEME defaults to `dns://`, but can also be `tls://` (DNS over TLS), `grpc://` (DNS over gRPC) or `https://` (DNS over HTTP/2). The optional PORT controls on which port the server will bind, this default to 53. If you use a port number here, you can't override it with `-dns.port` (coredns(1)), also see coredns-bind(7). Specifying a ZONE and PORT combination multiple times for different servers will lead to an error on startup. When a query comes in, it is matched again all zones for all servers, the server with the longest match on the query name will receive the query. PLUGIN defines the plugin(s) we want to load into this server. This is optional as well, but as server with no plugins will just return SERVFAIL for all queries. Each plugin can have a number of properties than can have arguments, see the documentation for each plugin. Comments are allowed and begin with an unquoted hash `#` and continue to the end of the line. Comments may be started anywhere on a line. Environment variables are supported and either the Unix or Windows form may be used: `{$ENVVAR1}` or `{%ENVVAR2%}`. You can use the `import` "plugin" (See coredns-import(7)) to include parts of other files. If CoreDNS cant find a Corefile to load it loads the following builtin one: ~~~ corefile . { whoami log } ~~~ You can use the `import` "plugin" to include parts of other files, see <https://coredns.io/plugins/import>, and coredns-import(7). If you want to reuse a snippet you can define one with and then use it with import. ~~~ corefile (mysnippet) { log whoami } . { import mysnippet } ~~~ The ZONE is root zone `.`, the PLUGIN is chaos. The chaos plugin takes an (optional) argument: `CoreDNS-001`. This text is returned on a CH class query: `dig CH TXT version.bind @localhost`. ~~~ corefile . { chaos CoreDNS-001 } ~~~ When defining a new zone, you either create a new server, or add it to an existing one. Here we define one server that handles two zones; that potentially chain different plugins: ~~~ corefile example.org { whoami } org { whoami } ~~~ Is identical to: ~~~ corefile example.org org { whoami } ~~~ Reverse zones can be specified as domain names: ~~~ corefile 0.0.10.in-addr.arpa { whoami } ~~~ or by just using the CIDR notation: ~~~ corefile 10.0.0.0/24 { whoami } ~~~ This also works on a non octet boundary: ~~~ corefile 10.0.0.0/27 { whoami } ~~~ CoreDNS Authors. Apache License 2.0 The manual page for CoreDNS: coredns(1) and more documentation on <https://coredns.io>. Also see the 's documentation and all the manual pages for the plugins.