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

title: "matchablehttpgateway.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Top-Level Resource A MatchableHttpGateway describes a single FilterChain configured with: The HttpConnectionManager NetworkFilter A FilterChainMatch and TransportSocket that support TLS configuration and Source IP matching A Gateway CR may select one or more MatchableHttpGateways on a single listener. This enables separate teams to own Listener configuration (Gateway CR) and FilterChain configuration (MatchableHttpGateway CR) ```yaml "namespacedStatuses": .core.solo.io.NamespacedStatuses "metadata": .core.solo.io.Metadata "matcher": .gateway.solo.io.MatchableHttpGateway.Matcher "httpGateway": .gateway.solo.io.HttpGateway ``` | Field | Type | Description | | -- | - | -- | | `namespacedStatuses` | | NamespacedStatuses indicates the validation status of this resource. NamespacedStatuses is read-only by clients, and set by gateway during validation. | | `metadata` | | Metadata contains the object metadata for this resource. | | `matcher` | | Matcher creates a FilterChainMatch and TransportSocket for a FilterChain For each MatchableHttpGateway on a Gateway CR, the matcher must be unique. If there are any identical matchers, the Gateway will be rejected. An empty matcher will produce an empty FilterChainMatch (https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/listener/v3/listener_components.proto#envoy-v3-api-msg-config-listener-v3-filterchainmatch) effectively matching all incoming connections. | | `httpGateway` | | HttpGateway creates a FilterChain with an HttpConnectionManager. | ```yaml "sourcePrefixRanges": []solo.io.envoy.config.core.v3.CidrRange "sslConfig": .gloo.solo.io.SslConfig ``` | Field | Type | Description | | -- | - | -- | | `sourcePrefixRanges` | | CidrRange specifies an IP Address and a prefix length to construct the subnet mask for a CIDR range. See https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/core/v3/address.proto#envoy-v3-api-msg-config-core-v3-cidrrange. | | `sslConfig` | | Ssl configuration applied to the FilterChain: - FilterChainMatch: https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/listener/v3/listener_components.proto#config-listener-v3-filterchainmatch) - TransportSocket: https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/core/v3/base.proto#envoy-v3-api-msg-config-core-v3-transportsocket. | <!-- 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: Skipper (Orchestration & Management / Service Proxy)
File: eskip-remote.md

Skipper can fetch routes in eskip format over HTTP: ```sh curl https://opensource.zalando.com/skipper/data-clients/example.eskip hello: Path("/hello") -> "https://www.example.org" skipper -routes-urls=https://opensource.zalando.com/skipper/data-clients/example.eskip curl -s http://localhost:9090/hello | grep title <title>Example Domain</title> ``` You may use multiple urls separated by comma and configure url poll interval via `-source-poll-timeout` flag.
Project: 3Scale (Orchestration & Management / API Gateway)
File: configuration.md

Gateway needs configuration in order to work. It needs it to determine service configuration, hostname, etc. Gateway can load the configuration from file, API or write it through management API (for debugging purposes). Can be loaded in `init` and `init_worker` before server starts serving requests. Can't be used in `init` or `init_worker` as cosocket API is not available. Would have to be pushed to background via `ngx.timer.at`. Can push configuration to the gateway via an API. Gateway needs to cache the configuration somewhere. Possibly even across restarts. Just not scalable. Disappears on every request with `luacodecache off`. Needs to serialize configuration into a string. Does not survive restarts. Size is allocated on boot. Shared across workers. Does not use shared memory, but has eviction algorithm to keep maximum number of items. Local to the worker. Can survive restart. Still needs some other method to act as cache. 3scale hosts thousands of gateways for its customers and needs a reasonable way to share resources between them. Multi-tenant deployment of this proxy is the preferred way. TODO: figure out how to store/load the configuration in multi-tenant way The following are the three main components in an APIcast configuration: configuration_loader: this is an object that retrieves the configuration and the OIDC config for all services. There are three type of configuration_loader: file: for using local file and THREESCALECONFIGFILE remote_v1: this is what we used in the past, to load all the config from system and spec.json, using THREESCALEPORTALENDPOINT. remotev2: This is the recommended way for retrieving the config for each service, to auto-discover the OIDC information, and it uses the THREESCALEPORTAL_ENDPOINT env variable. configuration_store: this object stores the configuration into the Openresty cache and uses it at different phases. policy/load-configuration: this policy loads first by default and works in the following scenarios: init phase: started the configuration_store initworker phase: retrieves the config using configurationloader and sends the configuration_store object, which saves the config retrieved rewrite phase: looks for the service for the requested host, and sets the service config on that request.
Project: Gloo (Orchestration & Management / API Gateway)
File: orca.proto.sk.md

title: "orca.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> ```yaml "reportInterval": .google.protobuf.Duration "requestCostNames": []string ``` | Field | Type | Description | | -- | - | -- | | `reportInterval` | | Interval for generating Open RCA core metric responses. | | `requestCostNames` | `[]string` | Request costs to collect. If this is empty, all known requests costs tracked by the load reporting agent will be returned. This provides an opportunity for the client to selectively obtain a subset of tracked costs. | <!-- 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: 3Scale (Orchestration & Management / API Gateway)
File: profiling.md

There is a Vagrantfile with performance inspection tools like SystemTap. ```shell vagrant up vagrant ssh ``` APIcast is mounted into `/home/vagrant/app` so you can start it by: ```shell cd app bin/apicast ``` For profiling with stapxx it is recommended to start just one process and worker: ```shell bin/apicast -c examples/configuration/echo.json > /dev/null ``` Then by opening another terminal you can use vegeta to create traffic: ```shell echo 'GET http://localhost:8080/?user_key=foo' | vegeta attack -rate=200 -duration=5m | vegeta report ``` Or you can use wrk to get as much throughtput as possible: ```shell wrk --connections 100 --threads 10 --duration 300 'http://localhost:8080/?user_key=foo' ``` And in another terminal you can create flamegraphs: ```shell lj-lua-stacks.sxx -x `pgrep -f 'nginx: worker'` --skip-badvars --arg time=10 | fix-lua-bt - | stackcollapse-stap.pl | flamegraph.pl > /vagrant/graph.svg ```
Project: Kestra (Orchestration & Management / Scheduling & Orchestration)
File: pull_request_template.md

<!-- Thanks for submitting a Pull Request to kestra. To help us review your contribution, please follow the guidelines below: Make sure that your commits follow the specification e.g. `feat(ui): add a new navigation menu item` or `fix(core): fix a bug in the core model` or `docs: update the README.md`. This will help us automatically generate the changelog. The title should briefly summarize the proposed changes. Provide a short overview of the change and the value it adds. Share a flow example to help the reviewer understand and QA the change. Use "close" to automatically close an issue. For example, `close #1234` will close issue #1234. --> <!-- Please include a brief summary of the changes included in this PR e.g. closes #1234. --> <!-- Include example code that shows how this PR has been QAed. The code should present a complete yet easily reproducible flow. ```yaml ``` Note that this is not a replacement for unit tests but rather a way to demonstrate how the changes work in a real-life scenario, as the end-user would experience them. Remove this section if this change applies to all flows or to the documentation only. --> <!--If there are any setup requirements like API keys or trial accounts, kindly include brief bullet-points-description outlining the setup process below. Steps to set up the necessary resources If there are no setup requirements, you can remove this section. Thank you for your contribution. -->
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2016-02-02-mesos-0-27-0-released.md

layout: post title: Apache Mesos 0.27.0 Released permalink: /blog/mesos-0-27-0-released/ published: true post_author: display_name: Kapil Arya twitter: karya0 tags: Release The latest Mesos release, 0.27.0, is now available for . This release includes the following features and improvements: : Support for resource quota that provides non-revocable resource guarantees without tying reservations to particular Mesos agents. Please refer to for more information. : Multiple disk support to allow for disk IO intensive applications to achieve reliable, high performance. : Flexible roles with the introduction of implicit roles. It deprecates the whitelist functionality that was implemented by specifying `--roles` during master startup to provide a static list of roles. : Performance improvement of the state endpoint for large clusters. Furthermore, 167+ bugfixes and improvements made it into this release. For full release notes with all features and bug fixes, please refer to the . Rolling upgrades from a Mesos 0.26.0 cluster to Mesos 0.27.0 are straightforward. There are just some minor, backwards compatible deprecations. Please refer to the for detailed information on upgrading to Mesos 0.27.0. 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 55 contributors who made 0.27.0 possible: Adam B, Alexander Rojas, Alexander Rukletsov, Alex Clemmer, Anand Mazumdar, Andy Pang, Anindya Sinha, Artem Harutyunyan, Avinash sridharan, Bartek Plotka, Benjamin Bannier, Benjamin Hindman, Benjamin Mahler, Bernd Mathiske, Bhuvan Arumugam, BrickXu, Chi Zhang, Cong Wang, Dario Rexin, David Forsythe, Diana Arroyo, Diogo Gomes, Felix Abecassis, Gilbert Song, Greg Mann, Guangya Liu, haosdent huang, James Peach, Jan Schlicht, Jian Qiu, Jie Yu, Jihun Kang, Jiri Simsa, Jocelyn De La Rosa, Joerg Schad, Jojy Varghese, Joris Van Remoortere, Joseph Wu, Kapil Arya, Kevin Klues, Klaus Ma, Mandeep Chadha, Michael Park, Neil Conway, Olivier Sallou, Qian Zhang, Shuai Lin, Stephan Erb, Steve Hoffman, Till Toenshoff, Timothy Chen, Vaibhav Khanduja, Vinod Kone, Vivek Juneja, and Zhitao Li.
Project: Service Mesh Interface (SMI) (Orchestration & Management / Service Mesh)
File: traffic-specs.md

This set of resources allows users to specify how their traffic looks. It is used in concert with and other policies to concretely define what should happen to specific types of traffic as it flows through the mesh. There are many different protocols that users would like to have be part of a mesh. Right now, this is primarily HTTP, but it is possible to imagine a world where service meshes are aware of other protocols. Each resource in this specification is meant to match 1:1 with a specific protocol. This allows users to define the traffic in a protocol specific fashion. This resource is used to describe HTTP/1 and HTTP/2 traffic. It enumerates the routes that can be served by an application. ```yaml apiVersion: specs.smi-spec.io/v1alpha1 kind: HTTPRouteGroup metadata: name: the-routes matches: name: metrics pathRegex: "/metrics" methods: GET name: health pathRegex: "/ping" methods: ["*"] ``` This example defines two matches, `metrics` and `health`. The name is the primary key and all fields are required. A regex is used to match against the URI and is anchored (`^`) to the beginning of the URI. Methods can either be specific (`GET`) or `*` to match all methods. These routes have not yet been associated with any resources. See for an example of how routes become associated with applications serving traffic. The `matches` field only applies to URIs. It is common to look at other parts of an HTTP request. This behaviour is not yet defined; however, the spec will be extended at a later date to accommodate capabilities such as HTTP header, Host, etc. ```yaml apiVersion: v1alpha1 kind: HTTPRouteGroup metadata: name: the-routes namespace: default matches: name: everything pathRegex: ".*" methods: ["*"] ``` This example defines a single route that matches anything. This resource is used to describe L4 TCP traffic. It is a simple route which configures an application to receive raw non protocol specific traffic. ```yaml apiVersion: specs.smi-spec.io/v1alpha1 kind: TCPRoute metadata: name: tcp-route ``` While it is possible for users to create these by hand, the recommended pattern is for tools to do it for the users. OpenAPI specifications can be consumed to generate the list of routes. gRPC protobufs can similarly be used to automatically generate the list of routes from code. These specifications are not* directly associated with applications and other resources. They're used to describe the type of traffic flowing through a mesh and used by higher level policies such as access control or rate limiting. The policies themselves bind these routes to the applications serving traffic. gRPC - there should be a gRPC specific traffic spec. As part of the first version, this has been left out as HTTPRouteGroup can be used in the interim. Arbitrary header filtering - there should be a way to filter based on headers. This has been left out for now, but the specification should be expanded to address this use case.
Project: Gloo (Orchestration & Management / API Gateway)
File: solo-kit.proto.sk.md

title: "solo-kit.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> ```yaml "shortName": string "pluralName": string "clusterScoped": bool "skipDocsGen": bool "skipHashingAnnotations": bool ``` | Field | Type | Description | | -- | - | -- | | `shortName` | `string` | becomes the kubernetes short name for the generated crd. | | `pluralName` | `string` | becomes the kubernetes plural name for the generated crd. | | `clusterScoped` | `bool` | the resource lives at the cluster level, namespace is ignored by the server. | | `skipDocsGen` | `bool` | indicates whether documentation generation has to be skipped for the given resource, defaults to false. | | `skipHashingAnnotations` | `bool` | indicates whether annotations should be excluded from the resource's generated hash function. if set to true, changes in annotations will not cause a new snapshot to be emitted. | <!-- 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: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: api-gateway-management.md

id: api-gateway-management title: API Gateway Management sidebar_label: API Gateway Management RIG offers an API for creating, changing, and removing API endpoint definitions at runtime. Changes caused by calling the API on one RIG node will automatically get distributed among the cluster, so all nodes share the same configuration without having to sync anything manually. Check out the to learn more. Easiest way how to work with internal REST API is via Swagger. NOTE: API running on port `4010` is intended to be internal and thus not publicly exposed without any authorization -- to prevent malicious actions. ```bash docker run -p 4000:4000 -p 4010:4010 accenture/reactive-interaction-gateway ``` You'll right away see list of all internal APIs. `POST /v2/apis` ```json { "id": "new-service", "name": "new-service", "auth_type": "jwt", "auth": { "use_header": true, "header_name": "Authorization", "use_query": false, "query_name": "" }, "versioned": false, "version_data": { "default": { "endpoints": [ { "id": "post-auth-register", "path_regex": "/auth/register", "method": "POST", "secured": false } ] } }, "proxy": { "use_env": true, "targeturl": "AUTHHOST", "port": 6666 } } ``` `GET /v2/apis` This is also way how to check if your APIs were loaded properly. `GET /v2/apis/:api_id` `PUT /v2/apis/:api_id` ```json { "id": "new-service", "name": "new-service", "auth_type": "jwt", "auth": { "use_header": true, "header_name": "Authorization", "use_query": false, "query_name": "" }, "versioned": false, "version_data": { "default": { "endpoints": [ { "id": "post-auth-register", "path_regex": "/auth/register", "method": "POST", "secured": false } ] } }, "proxy": { "use_env": true, "targeturl": "AUTHHOST", "port": 6666 } } ``` `DELETE /v2/apis/:api_id`
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl.md

title: "glooctl" weight: 5 CLI for Gloo glooctl is the unified CLI for Gloo. Find more information at https://solo.io ``` -c, --config string set the path to the glooctl config file (default "<home_directory>/.gloo/glooctl-config.yaml") --consul-address string address of the Consul server. Use with --use-consul (default "127.0.0.1:8500") --consul-allow-stale-reads Allows reading using Consul's stale consistency mode. --consul-datacenter string Datacenter to use. If not provided, the default agent datacenter is used. Use with --use-consul --consul-root-key string key prefix for for Consul key-value storage. (default "gloo") --consul-scheme string URI scheme for the Consul server. Use with --use-consul (default "http") --consul-token string Token is used to provide a per-request ACL token which overrides the agent's default token. Use with --use-consul -h, --help help for glooctl -i, --interactive use interactive mode --kube-context string kube context to use when interacting with kubernetes --kubeconfig string kubeconfig to use, if not standard one --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - Adds configuration to a top-level Gloo resource - Checks Gloo resources for errors (requires Gloo running on Kubernetes) - Checks Gloos CRDs for consistency against an official (or local) helm charts CRDs - Cluster commands - generate auto completion for your shell - Create a Gloo resource - Open Gloo dashboard - Debug a Gloo resource (requires Gloo running on Kubernetes) - Delete a Gloo resource - Demos (requires 4 tools to be installed and accessible via the PATH: glooctl, kubectl, docker, and kind.) - Edit a Gloo resource - Display one or a list of Gloo resources - Install the Gloo Edge Enterprise CLI plugin manager - install gloo on different platforms - Commands for interacting with Istio in Gloo - Commands for interacting with glooctl plugins - interact with proxy instances managed by Gloo - remove configuration items from a top-level Gloo resource - subcommands for interacting with routes within virtual services - uninstall gloo - upgrade glooctl binary - Print current version
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.6.6.md

+++ title = "CoreDNS-1.6.6 Release" description = "CoreDNS-1.6.6 Release Notes." tags = ["Release", "1.6.6", "Notes"] release = "1.6.6" date = 2019-12-11T10:00:00+00:00 author = "coredns" +++ The CoreDNS team has released . A fairly small release that polishes various plugins and fixes a bunch of bugs. The github.com/miekg/dns dependency has been updated to v1.1.25 to fix a DNS related security vulnerability (). A new plugin has been added that prevents IP fragmentation for the DNS Flag Day 2020 and to deal with DNS vulnerabilities. added a `servestale` option similar to `unbound`'s `serveexpired`. fix signing of authoritative data that we are not authoritative for. fixed calling wg.Add in main goroutine to avoid race conditons. Chris O'Haver Gonzalo Paniagua Javier Guangming Wang Kohei Yoshida Miciah Dashiel Butler Masters Miek Gieben Yong Tang Zou Nengren plugin/bufsize: A new bufsize plugin to prevent IP fragmentation and DNS Flag Day 2020 (https://github.com/coredns/coredns/pull/3401) plugin/transfer: Fixed calling wg.Add in main goroutine to avoid race conditions (https://github.com/coredns/coredns/pull/3433) plugin/pprof: Fixed a reloading issue (https://github.com/coredns/coredns/pull/3454) plugin/health: Fixed a reloading issue (https://github.com/coredns/coredns/pull/3473) plugin/redy: Fixed a reloading issue (https://github.com/coredns/coredns/pull/3473) plugin/cache: Added a `servestale` option similar to `unbound`'s `serveexpired` (https://github.com/coredns/coredns/pull/3468) plugin/sign: Fix signing of authoritative data (https://github.com/coredns/coredns/pull/3479) pkg/reuseport: Move the core server listening functions to a new package (https://github.com/coredns/coredns/pull/3455)
Project: BFE (Orchestration & Management / Service Proxy)
File: header.md

Description: Judge if key in Header of response matches configured key_list Parameters | Parameter | Description | | | - | | key_list | String<br>a list of header keys which are concatenated using &#124; | Example ```go resheaderkey_in("X-Bfe-Debug") ``` Description: Judge if value of key in response header matches configured patterns Parameters | Parameter | Description | | | - | | key | String<br>header name | | value_list | String<br>a list of header values which are concatenated using &#124; | | case_insensitive | Boolean<br>case insensitive | Example ```go resheadervalue_in("X-Bfe-Debug", "1", true) ```
Project: Kuma (Orchestration & Management / Service Mesh)
File: permissive-mtl.md

The goal for this proposal is to provide a more pragmatic way to enable mTLS in a service mesh. When working with existing applications, it is not practical to have mTLS enabled for everything or nothing, but we need to provide a more gradual way to do it. Therefore, a "permissive" mTLS mode (as opposed to the "strict" one we use today) would allow a team to enable mTLS yet allow traffic that is not part of the zero-trust infrastructure to still be able to make requests without a strict validation of the certificates on incoming requests. Add a new field `mode` under the `mtls.backends` section. The type of the field is enum with 2 values: `strict` and `permissive`. To keep backwards compatibility a default value should be `strict`. ```yaml apiVersion: kuma.io/v1alpha1 kind: Mesh metadata: name: default spec: mtls: enabledBackend: ca-1 backends: name: ca-1 type: builtin mode: strict|permissive dpCert: rotation: expiration: 1d conf: caCert: RSAbits: 2048 expiration: 10y ``` Inbound listener should be configured with to detect type of the traffic (`tls` or `plaintext`). Using we can distinguish traffic by `transportprotocol`, it could be either `rawbuffer` or `tls`. If the type is `tls` then FilterChain stays the same, if the type is `raw_buffer` then filter chain is the same but without `ServerSideMTLS` section.