cwielenb/CNCF-Dataset huggingface dataset:
Project: Gloo (Orchestration & Management / API Gateway)
File: headers.proto.sk.md

title: "headers.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> This plugin provides configuration options to append and remove headers from requests and responses HeaderManipulation can be specified on routes, virtual hosts, or weighted destinations ```yaml "requestHeadersToAdd": []solo.io.envoy.api.v2.core.HeaderValueOption "requestHeadersToRemove": []string "responseHeadersToAdd": []headers.options.gloo.solo.io.HeaderValueOption "responseHeadersToRemove": []string ``` | Field | Type | Description | | -- | - | -- | | `requestHeadersToAdd` | | Specifies a list of HTTP headers that should be added to each request handled by this route or virtual host. For more information, including details on header value syntax, see the . | | `requestHeadersToRemove` | `[]string` | Specifies a list of HTTP headers that should be removed from each request handled by this route or virtual host. | | `responseHeadersToAdd` | | Specifies a list of HTTP headers that should be added to each response handled by this route or host. For more information, including details on header value syntax, see the [Envoy documentation](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/httpconnman/headers.html# . | | `responseHeadersToRemove` | `[]string` | Specifies a list of HTTP headers that should be removed from each response handled by this route or virtual host. | Header name/value pair plus option to control append behavior. ```yaml "header": .headers.options.gloo.solo.io.HeaderValue "append": .google.protobuf.BoolValue ``` | Field | Type | Description | | -- | - | -- | | `header` | | Header name/value pair that this option applies to. | | `append` | | Specifies if the value should be appended or overwrite an existing header. Defaults to true. If set to true, this maps to Envoy's `appendvalue: APPENDIFEXISTSORADD`, where the value gets be appended the header's value(s) if exists, or created if it does not. If set to false, this maps to Envoy's `appendvalue: OVERWRITEIFEXISTSORADD`, where the header's value will be overwritten if it exists, or created if it does not. | Header name/value pair. ```yaml "key": string "value": string ``` | Field | Type | Description | | -- | - | -- | | `key` | `string` | Header name. | | `value` | `string` | Header value. | <!-- 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: Kusk Gateway (Orchestration & Management / API Gateway)
File: staticroute.md

Static Routes define the entrypoint to static applications. This overcomes the limitation of OpenAPI specification that does not allow to define the entrypoint to a static application. It is useful to set up the routing to a non-API application, e.g. static pages or images or to route to legacy, possibly external to the cluster, APIs. Once the resource manifest is deployed, Kusk Gateway Manager will use it to configure routing for the Envoy Fleet. Static Routes assume entrypoints to your upstream hosts or services live at `/` For this reason, each `StaticRoute` must have its own dedicated `EnvoyFleet` Currently, the resource status field is not updated by the manager when the reconciliation of the configuration finishes. The main elements of the configuration are in the spec field. Below is the YAML structure of the configuration. Please read further for a full explanation. ```yaml apiVersion: gateway.kusk.io/v1alpha1 kind: StaticRoute metadata: name: staticroute-sample spec: fleet: name: default namespace: default hosts: [<string>, <string>, ...] auth: ... upstream: service: name: my-service namespace: my-namespace port: 80 ... ``` The spec.fleet optional field specifies to which Envoy Fleet (Envoy Proxy instances with the exposing K8s Service) this configuration applies. fleet.name and fleet.namespace reference the deployed Envoy Fleet Custom Resource name and namespace. You can deploy a Static Route configuration in any namespace with any name and it will be applied to the specific Envoy Fleet. If this option is missing, the autodetection will be performed to find the single fleet deployed in the Kubernetes cluster Fleet, which is then considered as the default Fleet. The deployed Static Route custom resource will be changed to map to that fleet accordingly. If there are multiple fleets deployed, spec.fleet is required to specify which in the manifest. We match the incoming request by HOST header, path and HTTP method. The following fields specify matching: hosts - Defines the list of HOST headers to which the current configuration applies. This will create the Envoy's VirtualHost with the same name and domain matching. Wildcards are possible, e.g. "*" means "any host". Prefix and suffix wildcards are supported, but not both (i.e. ```example., example.com```, but not ```example```). upstream - Defines the upstream host or service to which the request will be forwarded. ```yaml apiVersion: gateway.kusk.io/v1alpha1 kind: StaticRoute metadata: name: sample spec: hosts: [ "localhost", "*"] auth: oauth2: issuer: https://auth.example.com clientid: clientid clientsecret: clientsecret scopes: openid email profile callback_path: /callback callback_url: https://example.com/callback redirect_url: https://example.com token_path: /oauth2/token userinfopath: /userinfo userinfourl: https://auth.example.com/userinfo userinfomapping: email: email name: name picture: picture upstream: host: "httpbin.org" ```
Project: KrakenD (Orchestration & Management / API Gateway)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: '' assignees: '' Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: Configuration used Steps to run the software Expected behavior A clear and concise description of what you expected to happen. Logs If applicable, any logs and debugging information Additional context Add any other context about the problem here.
Project: Open Service Mesh (Orchestration & Management / Service Mesh)
File: ROADMAP.md

The OSM team uses the to track short term (1-3 months) and medium term (3-6 months) efforts. Once a broad objective (from the "Research & Scoping" column) is further scoped into a GitHub issue that has a clear objective, background and motive, it is moved into the "Planned & Scoped" column. From there, the team plans monthly releases via . At this time, the OSM community is working on: Hardening of the project with a rigorous testing environment. Implementing SMI Traffic Metrics and build tooling to leverage it. Iterating on SMI Traffic Split and Traffic Access implementations. In the medium to long term future, the OSM community will tackle the following: Iterate on the current Ingress/Egress functionality, experience, workflow. Iterate on existing tools for debugging the OSM control plane and data plane. Leverage xDS v3 protocol when limited by SMI to provide a "no cliffs" design. Extend OSM to support VMs, hybrid and multicluster scenarios. Please file to propose features and identify bugs. See more information about how to get involved with the community .
Project: Higress (Orchestration & Management / API Gateway)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at higress@googlegroups.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq
Project: Contour (Orchestration & Management / Service Proxy)
File: RELEASES.md

This document describes the versioning and release process of Contour. This document is a living document, contents will be updated according to each release. Contour releases will be versioned using dotted triples, similar to . The project refers to the respective components of this triple as `<major>.<minor>.<patch>`. The version number may have additional information, such as "-rc1,-rc2,-rc3" to mark release candidate builds for earlier access. Such releases will be considered as "pre-releases". Major and minor releases of Contour will be branched from main when the release reaches to `RC (release candidate)` state. The release cadence is currently once a month, but is migrating to quarterly as of the October 2021 release (which will be Contour 1.20). If for any reason this release cadence has to be adjusted (for example due to open source events), the project will communicate it clearly on Slack, Twitter, and distribution lists. There is no mandated timeline for major versions and there are currently no criteria for shipping a new major version (i.e. Contour 2.0.0). You can find additional resources on the portion of our website. Patch releases are based on the major/minor release branch. There is no specific release cadence for patch releases. However, the project will create patch releases to address critical community and security issues (for example to address high severity security issues in Contour or in Envoy).The project will issue patch releases for all supported versions of Contour. Per the , the project is in the process of transitioning to supporting three Contour releases. Please see the support policy page to see what versions are currently supported. Also, please consult the for details of what each version of Contour requires for each of its dependencies like Envoy, Kubernetes, and so on. Both of these details are also available in a machine-consumable (YAML) format via . The upgrade path for Contour, including upgrade instructions, is documented . Each Contour version also requires a specific release of Envoy, documented in the upgrading portion of our website. The activity for the next release is tracked in the . If your issue is not present the backlog, please reach out to the maintainers to add the issue to the project board.
Project: Gloo (Orchestration & Management / API Gateway)
File: extensions.proto.sk.md

title: "extensions.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> ```yaml "configs": map<string, .google.protobuf.Struct> ``` | Field | Type | Description | | -- | - | -- | | `configs` | `map<string, .google.protobuf.Struct>` | | ```yaml "config": .google.protobuf.Struct ``` | Field | Type | Description | | -- | - | -- | | `config` | | | <!-- 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: Traefik (Orchestration & Management / API Gateway)
File: include-acme-multiple-domains-from-rule-example.md

```yaml tab="Docker & Swarm" labels: traefik.http.routers.blog.rule=(Host(`example.com`) && Path(`/blog`)) || Host(`blog.example.org`) traefik.http.routers.blog.tls=true traefik.http.routers.blog.tls.certresolver=myresolver ``` ```yaml tab="Docker (Swarm)" deploy: labels: traefik.http.routers.blog.rule=(Host(`example.com`) && Path(`/blog`)) || Host(`blog.example.org`) traefik.http.routers.blog.tls=true traefik.http.routers.blog.tls.certresolver=myresolver traefik.http.services.blog-svc.loadbalancer.server.port=8080" ``` ```yaml tab="Kubernetes" apiVersion: traefik.io/v1alpha1 kind: IngressRoute metadata: name: blogtls spec: entryPoints: websecure routes: match: (Host(`example.com`) && Path(`/blog`)) || Host(`blog.example.org`) kind: Rule services: name: blog port: 8080 tls: certResolver: myresolver ``` ```yaml tab="File (YAML)" http: routers: blog: rule: "(Host(`example.com`) && Path(`/blog`)) || Host(`blog.example.org`)" tls: certResolver: myresolver ``` ```toml tab="File (TOML)" [http.routers] [http.routers.blog] rule = "(Host(`example.com`) && Path(`/blog`)) || Host(`blog.example.org`)" [http.routers.blog.tls] certResolver = "myresolver" ```
Project: Fluid (Orchestration & Management / Scheduling & Orchestration)
File: RELEASE.md

The `yaml` Project is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
Project: Capsule (Orchestration & Management / Scheduling & Orchestration)
File: MAINTAINERS.md

The current Maintainers Group for the [TODO: Projectname] Project consists of: | Name | Employer | Responsibilities | | - | -- | - | | Adriano Pezzuto | Clastix | Maintainer | | Dario Tranchitella | Clastix | Maintainer | | Maksim Fedotov | Wargaming | Maintainer | | Oliver Bhler | Peak Scale | Maintainer | | Massimiliano Giovagnoli | Proximus | Maintainer | This list must be kept in sync with the . See for how maintainers are selected and replaced.
Project: Contour (Orchestration & Management / Service Proxy)
File: overload-manager.md

Envoy uses heap memory when processing requests. When the system runs out of memory or memory resource limit for the container is reached, Envoy process is terminated abruptly. To avoid this, Envoy can be enabled. Overload manager controls how much memory Envoy will allocate at maximum and what actions it takes when the limit is reached. Overload manager is disabled by default. It can be enabled at deployment time by using `--overload-max-heap= command. The bootstrap command is executed in to generate initial configuration for Envoy. To enable overload manager, modify the deployment manifest and add for example `--overload-max-heap=2147483648` to set maximum heap size to 2 GiB. The appropriate number of bytes can be different from system to system. After the feature is enabled, following two overload actions are configured to Envoy: Shrink heap action is executed when 95% of the maximum heap size is reached. Envoy will stop accepting requests when 98% of the maximum heap size is reached. When requests are denied due to high memory pressure, `503 Service Unavailable` will be returned with a response body containing text `envoy overloaded`. Shrink heap action will try to free unused heap memory, eventually allowing requests to be processed again. NOTE: The side effect of overload is that Envoy will deny also requests `/ready` and `/stats` endpoints. This is due to the way how Contour secures Envoy's admin API and exposes only selected admin API endpoints by proxying itself. When readiness probe fails, the overloaded Envoy will be removed from the list of service endpoints. If the maximum heap size is set too low, Envoy may be unable to free enough memory and never become ready again.
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2014-02-11-mesos-0-16-0-released.md

layout: post title: Mesos 0.16.0 Released permalink: /blog/mesos-0-16-0-released/ published: true post_author: display_name: Yan Xu twitter: xujyan tags: Release, HighAvailability We recently released Mesos v0.16.0 on our page. It includes major of the leading master election and detection process. This improves the reliability and flexibility of running multiple masters in your cluster, which provides Mesos with high availability. In high availability mode, if a leading master machine fails, Mesos holds elections to determine a new leader. Slave machines and schedulers detect the new leading master and connect to it, without disrupting services running on Mesos. Leader election implementation details, including how it works with , are detailed in the . Aside from the refactoring, v0.16.0 includes fixes for bugs which caused incorrect termination of Mesos masters and slaves: Fixed ZooKeeper related bugs which terminated Mesos processes instead of automatically retrying them: , , . Non-leading Master now stays up after ZooKeeper session expiration or after it is partitioned from ZooKeeper. Slave no longer attempts to recover checkpointed data after a reboot: . Click to read the full . To upgrade a live cluster, please refer to the . We encourage you to try out this release, and let us know what you think on the . You can also get in touch with us via or via .
Project: Armada (Orchestration & Management / Scheduling & Orchestration)
File: MAINTAINERS.md

| Maintainer | GitHub ID | Affiliation | | -- | - | -- | | Chris Martin | | G-Research | | Dave Gantenbein | | G-Research | | Dejan Zele Pejchev | | G-Research | | James Murkin | | G-Research | | Mark Sumner | | G-Research | | Martynas Asipauskas | | G-Research | | Mia Mijovic | | G-Research | | Mustafa Ilyas | | G-Research | | Noah Held | | G-Research | | Rich Scott | | G-Research | | Robert Smith | | G-Research | | Sam Clark | | G-Research | | Maintainer | GitHub ID | Affiliation | | -- | - | -- | | Albin Severinson | | G-Research | | Alex Scammon | | G-Research | | Carlo Camurri | | G-Research | | Clifton Houck | | G-Research | | Daniel Rastelli | | G-Research | | Geoffrey Wilson | | G-Research | | Jamie Poole | | G-Research | | Kevin Hannon | | G-Research |
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: node-lock.md

`Node Lock` is a mechanism to ensure only one pod is requesting certain third-party resource on each node. In order to do this, we lock certain third-party resources on target node during `schedule.allocate` phase, and unlock them after all related resources have been successfully allocated during `devicePlugin.Allocate` We intended to provide volcano the ability to share third-party resources link GPU,NPU,etc in the near future. These resources are usually registered and allocated in a daemonset called `device plugin`. When a pod requests any third-party resource, the api-server send an `AllocateRequest` to device plugin, containing the target device uuid it requests. However, it does not contain any information about the pod or container requesting the device, so it is impossible for deviceplugin to access the annotation of pod, because is does not know which pod sends this request. Using `Node Lock` will resolve this problem because only one pod is requesting this resource on this node. So, device-plugin can access additional information in pod.annotations written by scheduler and will be able to do more fine-grained work As the figure shown below: Node Lock is implemented in the form of modifying node annotition. Each device will use its own node-lock. It contains the pod owning this lock, and timestamp. Releasing the lock means delete this annotation. Examples are shown below: nodeA.annotations["gpu"]="2022-10-28T03:10:22ZPODA" nodeA.annotations["npu"]="2022-10-28T03:10:22ZPODA" nodeA.annotations["gpu"]="2022-10-28T03:10:22ZPODA" both annotation "gpushare" and "npushare" are deleted
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2016-04-12-mesos-0-26-1-and-more-released.md

layout: post title: Apache Mesos 0.26.1 and More Released permalink: /blog/mesos-0-26-1-and-more-released/ published: true post_author: display_name: Michael Park gravatar: 2ab9cab3a7cf782261c583c1f48a81b0 twitter: mcypark tags: Release The latest Mesos 0.26.1, 0.25.1 and 0.24.2 are now available for . The applicable subset of the following issues were backported. - GLOG performance. - UUID performance. - Port Ranges performance. - Allocator filter performance. - Configurable task/framework history. - JSON-based credential files. - HDFS. - Mesos health check within docker container. , - SSL. - Agent upgrade compatibility - Health checks. - `/state` endpoint performance. - Offer filter timeout fix for backlogged allocator. - Fixed point resources math. - Libevent. - Deletion of special files. - Memory leak in subprocess. Full release notes are available in the release . Upgrading to 0.26.1 can be done seamlessly on a 0.26.0 cluster. If upgrading from an earlier version, please refer to the documentation. Thanks to the 20 contributors who made 0.26.1, 0.25.1, and 0.24.2 possible: Alexander Rojas, Alexander Rukletsov, Anand Mazumdar, Benjamin Mahler, Felix Abecassis, Gilbert Song, haosdent huang, Isabel Jimenez, James Peach, Joerg Schad, Jojy Varghese, Joris Van Remoortere, Joseph Wu, Kapil Arya, Kevin Klues, Klaus Ma, Michael Park, Neil Conway, Till Toenshoff, Timothy Chen.
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: rate-limit.md

Rate limiting ensures that your application doesn't get more than a specified number of requests over time. It effectively helps to protect your API from overloading. For requests above the threshold, Kusk Gateway returns HTTP Too Many Requests error. Kusk makes it easy to configure Rate Limiting, using the `rate_limit` option in the `x-kusk` extension: ```yaml openapi: 3.0.0 info: title: simple-api version: 0.1.0 x-kusk: rate_limit: requestsperunit: 2 unit: minute .. ``` The example above allows only up to two requests per minute to be sent to the whole API. You can also specify different rate-limiting settings for a specific operation or path. The following example shows rate limiting configuration for a specific operation: ```yaml ... paths: /hello: get: operationId: getHello x-kusk: rate_limit: requestsperunit: 2 unit: minute .. ``` See all available Rate Limiting configuration options in the .