cwielenb/CNCF-Dataset huggingface dataset:
Project: Envoy (Orchestration & Management / Service Proxy)
File: cache_filter.md

Work in Progress--not ready for deployment HTTP caching can improve system throughput, latency, and network/backend load levels when the same content is requested multiple times. Caching is particularly valuable for edge proxies and browser-based traffic, which typically include many cacheable static resources, but it can be useful any time there is enough repeatedly served cacheable content. CacheFilter is configured with envoy.config.filter.http.cache.v2alpha.CacheConfig. The only required configuration field is typed_config. The type of this message will select what HttpCache plugin to use, and will be passed to the selected plugin. HttpCache plugins are located in subdirectories of source/extensions/filters/http/cache. Specifying a message of type envoy.source.extensions.filters.http.cache.SimpleHttpCacheConfig will select a proof-of-concept implementation included in the Envoy source. More implementations can be provided by implementing Envoy::Extensions::HttpFilters::Cache::HttpCache. To write a cache storage implementation, see [Writing Cache Filter Implementations](cachefilterplugins.md). TODO(toddmgreer) Describe other fields as they get implemented. The remaining configuration fields control caching behavior and limits. By default, this filter will cache almost all responses that are considered cacheable by , with handling of conditional (), and range requests. Those RFC define which request methods and response codes are cacheable, subject to the cache-related headers they also define: cache-control, range, if-match, if-none-match, if-modified-since, if-unmodified-since, if-range, authorization, date, age, expires, and vary. Responses with a vary header will only be cached if the named headers are accepted by one of the matching rules in allowed_vary_headers. ready for developers to write cache storage plugins; please contribute them to the Envoy repository if possible. ready for contributions to help finish its implementation of HTTP caching semantics. not* ready for actual use. Please see TODOs in the code.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: monitor.md

Service management is mainly to monitor and display the health status and basic information of each service in the system. Mainly related to master information. Mainly related to worker information. Mainly related to alert server information. Mainly the health status of the DB. Shows the command list in the system. Data is from the `tdscommand` table. Shows the failure command list in the system. Data is from the `tdserror_command` table. The audit log provides information about who accesses the system and the operations made to the system and record related time, which strengthen the security of the system and maintenance.
Project: Contour (Orchestration & Management / Service Proxy)
File: bug_report.md

name: Bug report about: Tell us about a problem you are experiencing title: '' labels: kind/bug, lifecycle/needs-triage assignees: '' What steps did you take and what happened: [A clear and concise description of what the bug is.] What did you expect to happen: Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.] Environment: Contour version: Kubernetes version: (use `kubectl version`): Kubernetes installer & version: Cloud provider or hardware configuration: OS (e.g. from `/etc/os-release`):
Project: Knative (Orchestration & Management / Scheduling & Orchestration)
File: TRIAGE.md

This is heavily inspired by , but that's a long read, so here's the short version. The goal of triage is to make sure that the following are handled quickly: New bugs or issues, some of which might be high priority Consumer (developer or administrator) updates to an issue which might not be on the immediate radar of a contributor The goal is for the project to be responsive to outside requests, while shielding most of the team from the interrupt-y work of watching the triage queue. An additional goal is to protect and respect the time of the triager / support user. For triage, the goal is to handle all the bugs on the following lists (searches): -- YOU NEED TO UPDATE THE DATE IN THE QUERY When doing triage, the goal is to quickly process issues, getting them into the right "bin". For small issues and user questions, it's reasonable to reply in the issue with documentation or a reference to another issue, but you should avoid fixing anything when triaging -- if you're making PRs during triage, you're doing it wrong. At the end of reading an issue, you should do one of the following: If the issue is clear and applies to serving, ensure it has the correct `/kind` and `/area` assigned. If you know enough, feel free to `/assign` to an individual, but area assignments should be sufficient for triage. Also consider if it is a `/good-first-issue`. After this, also mark the issue as `/triage accepted`, so it drops out of the list above. Move it to the correct repo (for example, Istio-specific questions should probably go to `net-istio`). In some cases, you may need to create a new issue in the new repo and link / copy the current issue. If you do this, be sure to `@mention` the requestor and others on the old issue, and then `/close` the issue is serving with a link to the other repo. If it's not clear what the problem or issue is, add a note for the requestor (or occasionally some other user on the thread), make sure that there is a reasonable `/kind` on the issue and mark it as `/triage needs-user-input` so that it's off the list for a few days. If a `needs-user-input` issue persists for longer than a week or so (past a second followup), it's reasonable to `/close` the issue and encourage the requester to reopen if they have more detail. If the request can be resolved with documentation, is infeasable, or complete, follow up directly in the issue with the information, and `/close` the issue.
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: drf.md

Dominant Resource Fairness (DRF), a generalization of max-min fairness to multiple resource types is a resource allocation policy that handles multiple resource types. Dominant resource - a resource of specific type (cpu, memory, gpu) which is most demanded by given job among other resources it needs. This resource is identified as a share of the total cluster resources of the same type. DRF computes the share of dominant resource allocated to a job (dominant share) and tries to maximize the smallest dominant share in the system. Schedule the task of the job with smallest dominant resource DRF calculate shares for each job. The share is the highest value of ratio of the (allocated resource/Total Resource) of the three resource types CPU, Memory and GPU. This share value is used for job ordering and task premption. The job having the lowest share will have higher priority. In the example below all the tasks task1, task2 of job1 and task3 and task4 of job2 is already allocated to the cluster. Gang scheduling sorts the job based on whether the job has at least minAvailable task already (allocated + successfully completed + pipelined) or not. Jobs which has not met the minAvailable criteria has higher priority than jobs which has met the minAvailable criteria. For the jobs which has met the minAvailable criteria will be sorted according to DRF. The preemptor can only preempt other tasks only if the share of the preemptor is less than the share of the preemptee after recalculating the resource allocation of the premptor and preemptee.
Project: BFE (Orchestration & Management / Service Proxy)
File: config.md

This document explain how to configure BFE Server directly. For guide of configure BFE via BFE control plane components, see documents of and . Normal configuration: For changes to the configuration file to take effect, you must restart the bfe process. Dynamic configuration: For changes to the configuration file to take effect, you can either restart or reload the bfe process. Normal configuration file: INI format Dynamic configuration file: JSON format (except for cerfificate/dict file, etc) The main configuration file is named bfe.conf (conf/bfe.conf). To make the configuration easier to maintain, we split it into a set of feature-specific files stored in the conf/&#60;feature&#62;/ directory. | Category | Layout | | | -- | | Main configuration | conf/bfe.conf | | Configuration about protocol | conf/tls_conf/ | | Configuration about routing | conf/serverdataconf/ | | Configuration about balancing | conf/cluster_conf/ | | Configuration about modules | conf/mod_&#60;name&#62; | See
Project: BFE (Orchestration & Management / Service Proxy)
File: route_rule.data.md

route_rule.data records route rule config for each product. | Config Item | Description | | -- | | | Version | String<br>Time of generating config file | | ProductRule | Struct<br>Route rules for each product | | ProductRule{k} | String<br>Product name | | ProductRule{v} | Struct<br>A ordered list of route rules | | ProductRule{v}[].Cond | String<br>Condition expression | | ProductRule{v}[].ClusterName | String<br>Destination cluster name | ```json { "Version": "20190101000000", "ProductRule": { "example_product": [ { "Cond": "reqhostin(\"example.org\")", "ClusterName": "cluster_example1" }, { "Cond": "default_t()", "ClusterName": "cluster_example2" } ] } } ```
Project: Gloo (Orchestration & Management / API Gateway)
File: gateway_solo_io.project.sk.md

title: "gatewaysoloio.project" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> API Version: `gateway.solo.io.v1` <!-- 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: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: containerizers.md

title: Apache Mesos - Containerizers layout: documentation Containerizers are used to run tasks in 'containers', which in turn are used to: Isolate a task from other running tasks. 'Contain' tasks to run in limited resource runtime environment. Control a task's resource usage (e.g., CPU, memory) programatically. Run software in a pre-packaged file system image, allowing it to run in different environments. Mesos plays well with existing container technologies (e.g., docker) and also provides its own container technology. It also supports composing different container technologies (e.g., docker and mesos). Mesos implements the following containerizers: User can specify the types of containerizers to use via the agent flag `--containerizers`. <a name="Composing"></a> This feature allows multiple container technologies to play together. It is enabled when you configure the `--containerizers` agent flag with multiple comma seperated containerizer names (e.g., `--containerizers=mesos,docker`). The order of the comma separated list is important as the first containerizer that supports the task's container configuration will be used to launch the task. Use cases: For testing tasks with different types of resource isolations. Since 'mesos' containerizers have more isolation abilities, a framework can use composing containerizer to test a task using 'mesos' containerizer's controlled environment and at the same time test it to work with 'docker' containers by just changing the container parameters for the task. <a name="Docker"></a> Docker containerizer allows tasks to be run inside docker container. This containerizer is enabled when you configure the agent flag as `--containerizers=docker`. Use cases: If a task needs to be run with the tooling that comes with the docker package. If Mesos agent is running inside a docker container. For more details, see . <a name="Mesos"></a> This containerizer allows tasks to be run with an array of pluggable isolators provided by Mesos. This is the native Mesos containerizer solution and is enabled when you configure the agent flag as `--containerizers=mesos`. Use cases: Allow Mesos to control the task's runtime environment without depending on other container technologies (e.g., docker). Want fine grained operating system controls (e.g., cgroups/namespaces provided by Linux). Want Mesos's latest container technology features. Need additional resource controls like disk usage limits, which might not be provided by other container technologies. Want to add custom isolation for tasks. For more details, see . for implementation details of containerizers.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: telegram.md

If you need `Telegram` to alert, create an alert instance in the alert instance management, and choose the `Telegram` plugin. The following shows the `Telegram` configuration example: | Parameter | Description | ||| | WebHook | The WebHook of Telegram when use robot to send message. | | botToken | The access token of robot. | | chatId | Sub Telegram Channel. | | parseMode | Message parse type (support txt, markdown, markdownV2, html). | | EnableProxy | Enable proxy sever. | | Proxy | The proxy address of the proxy server. | | Port | The proxy port of proxy server. | | User | Authentication(Username) for the proxy server. | | Password | Authentication(Password) for the proxy server. | The webhook needs to be able to receive and use the same JSON body of HTTP POST that DolphinScheduler constructs and the following shows the JSON body: ```json { "text": "[{\"projectId\":1,\"projectName\":\"p1\",\"owner\":\"admin\",\"processId\":35,\"processDefinitionCode\":4928367293568,\"processName\":\"s11-3-20220324084708668\",\"taskCode\":4928359068928,\"taskName\":\"s1\",\"taskType\":\"SHELL\",\"taskState\":\"FAILURE\",\"taskStartTime\":\"2022-03-24 08:47:08\",\"taskEndTime\":\"2022-03-24 08:47:09\",\"taskHost\":\"192.168.1.103:1234\",\"logPath\":\"\"}]", "chat_id": "chat id number" } ```
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: api-py.md

title: "Python API" linkTitle: "Python API" weight: 104 manualLink: /docs/++version++/api/py/html/ <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> The Python API documentation can be found <a href="/docs/++version++/api/py/html/">here</a>.
Project: Gloo (Orchestration & Management / API Gateway)
File: README.md

This folder contains custom rules we define ourselves for this particular project. If you find an anti-pattern that you want to prevent, you should first check to see if there's a linter in the list to make sure there is not a check that already exists. However, if you can't find such a check, it is fairly easy to build a custom check using the ruleguard DSL. Rather than getting into details of how to write rules, here are some links to the most useful documentation: This directory must be flat. Subdirectories of this directory will not be checked for Golang files. This is controlled by the `/linters-settings/gocritic/settings/ruleguard/rules` setting in `.golangci.yaml`. Often, rules are all piled into a single file, but I've tried to break them up a little bit to keep a single file of rules from being difficult to manage. Break them as best you see fit.
Project: Consul (Orchestration & Management / Service Mesh)
File: fork-the-project.md

Community members wishing to contribute code to Consul must fork the Consul project (`your-github-username/consul`). Branches pushed to that fork can then be submitted as pull requests to the upstream project (`hashicorp/consul`). To locally clone the repo so that you can pull the latest from the upstream project (`hashicorp/consul`) and push changes to your own fork (`your-github-username/consul`): (`your-github-username/consul`) Clone the `hashicorp/consul` repository and `cd` into the folder Make `hashicorp/consul` the `upstream` remote rather than `origin`: `git remote rename origin upstream`. Add your fork as the `origin` remote. For example: `git remote add origin https://github.com/myusername/consul` Checkout a feature branch: `git checkout -t -b new-feature` Push changes to the fork when ready to : `git push -u origin new-feature`
Project: kcp (Orchestration & Management / Scheduling & Orchestration)
File: README.md

Controller to manage workspace mounts for workspace. Workspace mounts are external implementations of workspace mounts and are currently configured using annotations on the workspace. Add an ability to change workspace status to not ready when a mount is not ready. Controller has 2 queues, one for workspace mounts (gvk) and one for workspaces. So it has 2 reconcilers loops running in parallel for each queue. Overall controllers do not update any other resources, except for the workspace itself, annotation for now. In the future, it will be updating status once we promote the status to be status and spec fields. When the generic informer receives an event, checks if it's a mount and extracts the workspace that owns it from annotation. Then controller enqueues the workspace object for reconciliation. The Workspace reconciler checks if the workspace mount is already present in the system, and updates the the status of the workspace annotations with the mount status.
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.11.1.md

+++ title = "CoreDNS-1.11.1 Release" description = "CoreDNS-1.11.1 Release Notes." tags = ["Release", "1.11.1", "Notes"] release = "1.11.1" date = "2023-08-15T00:00:00+00:00" author = "coredns" +++ This release fixes a major performance regression introduced in 1.11.0 that affected DoT (TLS) forwarded connections. It also adds a new option to dnstap to add metadata to the dnstap extra field, and fixes a config parsing bug in cache. Chris O'Haver, P. Radha Krishna, Yong Tang, Yuheng, Zhizhen He Revert "plugin/forward: Continue waiting after receiving malformed responses (https://github.com/coredns/coredns/pull/6014)" (#6270) 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)
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: weights.md

title: Apache Mesos - Weights layout: documentation In Mesos, weights can be used to control the relative share of cluster resources that is offered to different . In Mesos 0.28 and earlier, weights can only be configured by specifying the `--weights` command-line flag when starting the Mesos master. If a role does not have a weight specified in the `--weights` flag, then the default value (1.0) will be used. Weights cannot be changed without updating the flag and restarting all Mesos masters. Mesos 1.0 contains a operator endpoint that allows weights to be changed at runtime. The `--weights` command-line flag is deprecated. The master `/weights` HTTP endpoint enables operators to configure weights. The endpoint currently offers a REST-like interface and supports the following operations: weights with PUT. the currently set weights with GET. The endpoint can optionally use authentication and authorization. See the for details. <a name="putRequest"></a> The operator can update the weights by sending an HTTP PUT request to the `/weights` endpoint. An example request to the `/weights` endpoint could look like this (using the JSON file below): $ curl -d @weights.json -X PUT http://<master-ip>:<port>/weights For example, to set a weight of `2.0` for `role1` and set a weight of `3.5` for `role2`, the operator can use the following `weights.json`: [ { "role": "role1", "weight": 2.0 }, { "role": "role2", "weight": 3.5 } ] If the master is configured with an explicit , the request is only valid if all specified roles exist in the role whitelist. Weights are now persisted in the registry on cluster bootstrap and after any updates. Once the weights are persisted in the registry, any Mesos master that subsequently starts with `--weights` still specified will emit a warning and use the registry value instead. The operator will receive one of the following HTTP response codes: `200 OK`: Success (the update request was successful). `400 BadRequest`: Invalid arguments (e.g., invalid JSON, non-positive weights). `401 Unauthorized`: Unauthenticated request. `403 Forbidden`: Unauthorized request. <a name="getRequest"></a> The operator can query the configured weights by sending an HTTP GET request to the `/weights` endpoint. $ curl -X GET http://<master-ip>:<port>/weights The response message body includes a JSON representation of the current configured weights, for example: [ { "role": "role2", "weight": 3.5 }, { "role": "role1", "weight": 2.0 } ] The operator will receive one of the following HTTP response codes: `200 OK`: Success. `401 Unauthorized`: Unauthenticated request.