cwielenb/CNCF-Dataset huggingface dataset:
Project: Traefik (Orchestration & Management / API Gateway)
File: concepts.md

title: Concepts description: Traefik - base concepts and main features This page explains the base concepts of Traefik. Traefik is based on the concept of EntryPoints, Routers, Middlewares and Services. The main features include dynamic configuration, automatic service discovery, and support for multiple backends and protocols. : EntryPoints are the network entry points into Traefik. They define the port which will receive the packets, and whether to listen for TCP or UDP. : A router is in charge of connecting incoming requests to the services that can handle them. : Attached to the routers, middlewares can modify the requests or responses before they are sent to your service : Services are responsible for configuring how to reach the actual services that will eventually handle the incoming requests. Traefik is an Edge Router; this means that it's the door to your platform, and that it intercepts and routes every incoming request: it knows all the logic and every that determine which services handle which requests (based on the path, the host, headers, etc.). Where traditionally edge routers (or reverse proxies) need a configuration file that contains every possible route to your services, Traefik gets them from the services themselves. Deploying your services, you attach information that tells Traefik the characteristics of the requests the services can handle. This means that when a service is deployed, Traefik detects it immediately and updates the routing rules in real time. Similarly, when a service is removed from the infrastructure, the corresponding route is deleted accordingly. You no longer need to create and synchronize configuration files cluttered with IP addresses or other rules. !!! info "Many different rules" In the example above, we used the request to determine which service was in charge. Certainly, you can use many other different . !!! info "Updating the requests" In the section, you can learn about how to update the requests before forwarding them to the services. !!! question "How does Traefik discover the services?" Traefik is able to use your cluster API to discover the services and read the attached information. In Traefik, these connectors are called because they provide the configuration to Traefik. {!traefik-for-business-applications.md!}
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-001.md

+++ date = "2016-09-18T11:40:37+01:00" description = "CoreDNS-001 Release Notes." release = "001" tags = ["Release", "001", "Notes"] title = "CoreDNS-001 Release" author = "coredns" +++ CoreDNS-001 has been . This is the first release! It provides a complete DNS server, that also does DNSSEC and is useful for service discovery in cloud setups. is a DNS server that started its life as a fork of the [Caddy web(!)server](https://caddyserver.com). It chains , where each plugin implements some DNS feature. CoreDNS is a complete replacement (with more features, and maybe less bugs) for . It is also useful as a normal DNS server, featuring DNSSEC, on-the-fly signing and zone transfers. CoreDNS is now a (the first!) server type plugin in Caddy - this means we can leverage a lot of code from Caddy without having to fork (and maintain) it all. By doing so we were able to remove 9000 lines of code from CoreDNS. The core (ghe!) of CoreDNS is now in a good shape. Future work will focus on making the plugin better, e.g. the proxy implementation is slow and needs to be . There is now a [specific plugin](https://github.com/coredns/coredns/tree/master/plugin/kubernetes) to deal with . The bind* allows you to bind to a specific IP address, instead of using the wildcard address. A whoami* reports back your address and port. All other plugins are reworked to fit in the new plugin framework from Caddy version 0.9 (and up). The whoami plugin is also used when CoreDNS starts up and can't find a Corefile. The following people helped with getting this release done: Cricket Liu, elcore, Flix Cantournet, Ilya Dmitrichenko, Joe Blow, Lee, Matt Layher, Michael Richmond, Miek Gieben, pixelbender, Yong Tang. If you want to help, please check out one of the and start coding! For documentation and help, see our .
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2016-06-13-mesos-0-28-2-released.md

layout: post title: Apache Mesos 0.28.2 Released permalink: /blog/mesos-0-28-2-released/ published: true post_author: display_name: Jie Yu twitter: jie_yu tags: Release The latest Mesos release, 0.28.2, is now available for . This release includes some important bug fixes and improvements on top of 0.28.1. It is highly recommended that users use this version if you are considering using Mesos 0.28. More specifically, this release includes the following fixes and improvements: - Linux 'perf' parsing logic may fail when OS distribution has perf backports. - Persistent volume DockerContainerizer support assumes proper mount propagation setup on the host. - Isolator cleanup should not be invoked if they are not prepared yet. - Destroy container while provisioning volume images may lead to a race. - Env `MESOS_SANDBOX` is not set properly for command tasks that changes rootfs. - Unzip should force overwrite. - Memory leak in SchedulerProcess.declineOffer. - Killing a queued task can cause the corresponding command executor to never terminate. - Sandbox mounts should not be in the host mount namespace. Full release notes are available in the release Rolling upgrades from a Mesos 0.28.1 cluster to Mesos 0.28.2 are straightforward. Please refer to the for detailed information on upgrading to Mesos 0.28.2. 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 10 contributors who made 0.28.2 possible: Fan Du, Tomasz Janiszewski, Vinod Kone, Shuai Lin, Ben Mahler, Dario Rexin, Silas Snider, Gilbert Song, Yongqiao Wang, Jie Yu
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: inspecting-apis.md

Selecting a deployed API in the dashboard opens a corresponding details panel to the right containing 3 tabs: API Definition: Shows an extended Swagger UI for the OpenAPI that was deployed to Kusk Gateway. Kusk Extensions: Shows an overview of all `x-kusk` extensions in the deployed OpenAPI definition. Public API Definition: Shows Swagger UI for the OpenAPI definition that would be exposed to consumers. The API definition tab shows a Swagger UI for the deployed API definition - together with a table of contents at the top, making it easy to navigate to individual operations. An indicator is shown next to any level in the Table of Contents if there is a `x-kusk` extension defined. Clicking it will open the corresponding extension in the Kusk Extensions tab (see below). The Kusk Extensions tab contains a tree view showing all `x-kusk` extensions that have been specified in the deployed OpenAPI definition - making it easy to understand how the API has been configured for Kusk Gateway. The Public API Definition tab contains the "post-processed" OpenAPI definition as you would provide publicly to consumers of your API. This differs from the deployed OpenAPI definition in the following ways: All `x-kusk` extensions have been removed. All disabled operations have been removed - see . A Table of Contents is available as in the API Definition tab. This tab includes the possibility to specify server(s) to be used when executing requests through the integrated Swagger UI: Specifying the server used by the dashboard itself allows us to execute requests against the Dashboard API. For example, to get a list of APIs (as seen in the dashboard), we can execute the `GET /apis` operation.
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2019-03-19-mesos-1-5-3-released.md

layout: post title: Apache Mesos 1.5.3 Released permalink: /blog/mesos-1-5-3-released/ published: true post_author: display_name: Gilbert Song gravatar: 05d3596cf7ef7751c02545b1eaac64ac twitter: Gilbert_Songs tags: Release The latest Mesos 1.5.x release, 1.5.3, is now available for . This release includes important bug fixes and improvements on top of 1.5.0. It is recommended to use this version if you are considering using Mesos 1.5. More specifically, this release includes the following: - Mesos fetcher cache doesn't retry when missed. - Unreachable tasks are not GC'ed when unreachable agent is GC'ed. - Docker image fetcher fails with HTTP/2. - Mesos v1 scheduler library does not properly handle SUBSCRIBE retries. - Create cgoup recursively to workaround systemd deleting cgroups_root. - Some master endpoints do not handle failed authorization properly. - Nested container should run as the same user of its parent container by default. - Container stuck at ISOLATING state due to libevent poll never returns. - Test `CgroupsIsolatorTest.ROOTCGROUPSCreateRecursively` is flaky. - Validation of JWT tokens using HS256 hashing algorithm is not thread safe. - Persist CNI working directory across reboot. - Agent could not recover due to empty docker volume checkpointed files. - CNI_NETNS should not be set for orphan containers that do not have network namespace. - ResourceOffersTest.ResourceOfferWithMultipleSlaves is flaky. - CniIsolatorTest.ROOT_CleanupAfterReboot is flaky. - Allocator CHECK failure: reservationScalarQuantities.contains(role). - Mesos package naming appears to be undeterministic. Full release notes are available in the release Rolling upgrades from a Mesos 1.5.0 cluster to Mesos 1.5.3 are straightforward. Please refer to the for detailed information on upgrading to Mesos 1.5.3 from 1.4.x, 1.3.x, or 1.2.x. Please try out this release and let us know what you think. If you run into any issues, let us know on the . Thanks to the 7 contributors who made 1.5.3 possible: Andrei Budnik, Benjamin Mahler, Gilbert Song, Jie Yu, Qian Zhang, Till Toenshoff, Vinod Kone
Project: OpenNebula (Orchestration & Management / Scheduling & Orchestration)
File: pull_request_template.md

<! Please leave a helpful description of the PR here. > <! Please check you didn't forget a branch this needs to be cherry picked to. Leave them unchecked, they will be checked by the merger > [ ] master [ ] one-X.X <hr> [ ] Check this if this PR should not be squashed
Project: KubeGateway (Orchestration & Management / API Gateway)
File: support.md

name: Support Request about: Support request or question relating to Kubernetes labels: triage/support <!-- STOP -- PLEASE READ! GitHub is not the right place for support requests. If you're looking for help, check and the . You can also post your question on the or the forum. If the matter is security related, please disclose it privately via https://kubernetes.io/security/. -->
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: slack.md

If you need to use `Slack` for alerting, create an alert instance in the alert instance management and select the `Slack` plugin. The following shows the `Slack` configuration example: Webhook > Copy the `Incoming Webhooks` address from the APP, check the image below: UserName > (Deprecated) The sender name. Currently, Slack use APP as the sender name due to the Slack updates. Please refer to the official article to create new webhooks. Visit and create a new APP. When finish creating a new APP, select `Incoming Webhooks` of the column `Feature` on the left of the APP page, and switch `Activate Incoming Webhooks` to `ON`. Click `Add New Webhook to Workspace` and select a group to post messages. Copy the `Incoming Webhooks` address to DolphinScheduler, check the image below: The default format of the `Incoming Webhooks`: `https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX` Reference
Project: Clusterpedia (Orchestration & Management / Scheduling & Orchestration)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: aliyun-voice.md

If you need to use `Voice` for alerting, create an alert instance in the alert instance management and select the `Voice` plugin. Called number > Called display number Call display number > The number for receiving voice notifications VoiceCode > Voice ID of the VoiceCode accessKeyId > Your AccessKey ID accessKeySecret > Your AccessKey Secret Voice notification Sends a voice notification of the file type to a specified number The following shows the `voice` configuration example:
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: healthcheck.md

Health check are designed to provide a unique way to check the health of the dolphinscheduler service. It includes the health status of modules, such as DB, cache, network, etc. ```shell curl --request GET 'http://localhost:12345/dolphinscheduler/actuator/health' {"status":"UP","components":{"db":{"status":"UP","details":{"database":"H2","validationQuery":"isValid()"}}}} ``` ```shell curl --request GET 'http://localhost:5679/actuator/health' {"status":"UP","components":{"db":{"status":"UP","details":{"database":"H2","validationQuery":"isValid()"}}}} ``` ```shell curl --request GET 'http://localhost:1235/actuator/health' {"status":"UP","components":{"db":{"status":"UP","details":{"database":"H2","validationQuery":"isValid()"}}}} ``` ```shell curl --request GET 'http://localhost:50053/actuator/health' {"status":"UP","components":{"db":{"status":"UP","details":{"database":"H2","validationQuery":"isValid()"}}}} ``` Notice: If you modify the default service port and address, you need to modify the IP+Port to the modified value.
Project: Traefik Mesh (Orchestration & Management / Service Mesh)
File: helm-chart.md

title: "Traefik Helm Chart Documentation" description: "Migrate to the latest version of Traefik Mesh, a simple and lightweight service mesh, in your cluster's Helm chart. Read the technical documentation." Helm Chart {: .subtitle } All existing resources have been renamed and prefixed by `traefik-mesh`. For example, the `maesh-controller`resource has been renamed to `traefik-mesh-controller`. Inside the Traefik Mesh helm chart, the `mesh` property has been renamed to `proxy`. Since version `v1.4`, Traefik Mesh uses plain Docker image for proxies. Therefore, to change the image version used for the controller, or the proxies you should use the `controller.image` and `proxy.image` options. The `mesh.defaultMode` option has been removed. You should use the new `defaultMode` option to configure the default traffic mode. The `mesh.defaultMode` option has been deprecated and will be removed in a future major release. You should use the new `defaultMode` option to configure the default traffic mode. Prior to version `v2.1`, when the Metrics chart is deployed, Prometheus and Grafana services are exposed by default through a `NodePort`. For security reasons, those services are not exposed by default anymore. To expose them you should use the new `prometheus.service` and `grafana.service` options, more details in the corresponding . Since version `v1.2`, is used as a library. Therefore, the `controller.image` and `mesh.image` options have been removed. You should use the new `image` option as described in the . The `controller.logging.debug` and `mesh.logging` options have been removed. You should use the new `controller.logLevel` and `mesh.logLevel` options to configure the logging level for the controller and proxies. The `smi.enable` option has been deprecated and removed. You should use the new and backward compatible ACL mode option as described in the .
Project: Aeraki Mesh (Orchestration & Management / Service Mesh)
File: CONTRIBUTING.md

<!-- --> Welcome to Aeraki! You are welcome toor. It's recommended to read the following Contributing Guide first before contributing. We use Github issues to track public bugs and feature requests. Please search the existing issues to see if any similar issue or feature request has already been filed. You should make sure your issue isn't redundant. If you open an issue, the more information the better. Such as detailed description, screenshot or video of your problem, logcat or code blocks for your crash. We strongly welcome your pull request to make Aeraki better. The code team will monitor all pull request, we run some code check and test on it. After all tests passed, we will accept this PR. But it won't merge tomasterbranch at once, which have some delay. Before submitting a pull request, please make sure the followings are done: Fork the repo and create your branch frommaster. Update code or documentation if you have changed APIs. Add the copyright notice to the top of any new files you've added. Check your code lints and checkstyles. Test and test again your code. Now, you can submit your pull request ondev. You must sign thein order to contribute. By contributing to Aeraki, you agree that your contributions will be licensed under itsApache v2 License.
Project: Pipy (Orchestration & Management / Service Proxy)
File: quic-connID-retire.md

QUIC Route Requirements ======================= Two connection IDs -- one local, one remote MVP MVP does most of one side of the CID management. The major outstanding items for a complete implementation are: possibly increase the number of CIDs we permit (from 2) use more than the just latest CID for packet transmission round robin non-retired CIDs Non zero Length Connection ID -- MVP does not issue multiple connection CIDs, instead it uses a zero length CID. To achieve this, more work is required: creation of new CIDs (coded but not used) responding to new CIDs by returning new CIDs to peer match managing the number of CIDs presented to our peer limiting the number of CIDs issued & retired retirement of CIDs that are no longer being used ensuring only one retire connection ID frame is in flight Connection Migration -- Supporting migration goes well beyond CID management. The additions required to the CID code should be undertaken when/if connection migration is supported. I.e. do this later in a just in time manner. Retiring Connection ID When a remote asks to retire a connection ID (RETIRECONNECTIONID) we have to: Send retirement acks for all retired CIDs Immediately delete all CIDs and routes associated with these CIDs Retransmits use different route, so they are good. Out of order delivery will initiate retransmits Should respond with a NEWCONNECTIONID frame if we are low on CIDs Not sure if it is mandatory to send a retirement. When a remote creates a new connection ID: May respond with a new connection ID frame (it's a good idea) It reads like the NEWCONNECTIONID frame can't be used to retire routes. However, see above. Suggest we accept either. When we want to retire one (or more) connection IDs we have to: Flag the route(s) as retired Send a retirement frame (RETIRECONNECTIONID) Delete the connection(s) once they are retired by our peer (either NEWCONNECTIONID or RETIRECONNECTIONID can do this) State -- routes we've retired until they are acked as being retired (uint64_t max CID) routes our peer has retired don't need tracking, we can remove immediately retired routes where we've outstanding data to send will have that data sent before the retirement acks are send. If these fragments need to be retransmitted, they'll be done so using a new CID on a new route. This means, there is no requirement to wait for data to be flushed before sending the retirement ack.
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: deploy-cmd.md

The `deploy` accepts your OpenAPI definition as input, either as a local file or a URL pointing to your file and deploys the API to Kusk Gateway. Configuration of the API resource is done via the `x-kusk` extension. ```sh kusk deploy -i spec.yaml ``` Using the file watcher: ```sh kusk deploy -i spec.yaml --watch ``` This will watch your file for changes and deploy them automatically for you. OpenAPI definition from URL: ```sh kusk deploy -i https://raw.githubusercontent.com/$ORGORUSER/$REPO/myspec.yaml ``` This will fetch the OpenAPI document from the provided URL and apply the API. | Argument | Description | Required? | |:--|:-|::| | `--in` / `-i` | The file path or URL to OpenAPI definition to generate mappings from. e.g. --in apispec.yaml. | | | `--watch / -w` | Watches the file for changes. | |
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-configuration-portal-pages.md

At this date, four types of document are supported: Swagger/OpenApi. Markdown (MD). AsciiDoc. AsyncApi. By default, portal pages are in staging mode and will be visible to administrators and users with management portal roles. To make documentation visible for all users, switch on the published button. Portal pages can be accessed from the main DOCUMENTATION section. You can set the homepage by clicking on the house button. The portal homepage will be visible in the portal landing page. 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. To create a new page of documentation, click the (+) button. You can also add an entire directory. Click the link at the top of the screen to 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" } ] } } ```
Project: KEDA (Orchestration & Management / Scheduling & Orchestration)
File: ISSUE_TEMPLATE.md

Which version of Kivik are you using? Which version of Go are you using? (Output of `go version`) -- Kivik 1.x aims to support all versions of Go from 1.7. The master branch aims to support Go 1.8 and later. What did you do? (Include your code if possible) What did you expect to see? What did you see instead?