cwielenb/CNCF-Dataset huggingface dataset:
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: docker-runtime.md

title: Apache Mesos - Docker Runtime Isolator in Mesos Containerizer layout: documentation The Docker Runtime isolator is used for supporting runtime configurations from the docker image (e.g., Entrypoint/Cmd, Env, etc.). This isolator is tied with `--image_providers=docker`. If `--image_providers` contains `docker`, this isolator must be used. Otherwise, the agent will refuse to start. To enable the Docker Runtime isolator, append `docker/runtime` to the `--isolation` flag when starting the agent. Currently, docker image default `Entrypoint`, `Cmd`, `Env`, and `WorkingDir` are supported with docker runtime isolator. Users can specify `CommandInfo` to override the default `Entrypoint` and `Cmd` in the image (see below for details). The `CommandInfo` should be inside of either `TaskInfo` or `ExecutorInfo` (depending on whether the task is a command task or uses a custom executor, respectively). If the user specifies a command in `CommandInfo`, that will override the default Entrypoint/Cmd in the docker image. Otherwise, we will use the default Entrypoint/Cmd and append arguments specified in `CommandInfo` accordingly. The details are explained in the following table. Users can specify `CommandInfo` including `shell`, `value` and `arguments`, which are represented in the first column of the table below. `0` represents `not specified`, while `1` represents `specified`. The first row is how `Entrypoint` and `Cmd` defined in the docker image. All cells in the table, except the first column and row, as well as cells labeled as `Error`, have the first element (i.e., `/Entrypt[0]`) as executable, and the rest as appending arguments. <table class="table table-striped"> <tr> <th></th> <th>Entrypoint=0<br>Cmd=0</th> <th>Entrypoint=0<br>Cmd=1</th> <th>Entrypoint=1<br>Cmd=0</th> <th>Entrypoint=1<br>Cmd=1</th> </tr> <tr> <td>sh=0<br>value=0<br>argv=0</td> <td>Error</td> <td>/Cmd[0]<br>Cmd[1]..</td> <td>/Entrypt[0]<br>Entrypt[1]..</td> <td>/Entrypt[0]<br>Entrypt[1]..<br>Cmd..</td> </tr> <tr> <td>sh=0<br>value=0<br>argv=1</td> <td>Error</td> <td>/Cmd[0]<br>argv</td> <td>/Entrypt[0]<br>Entrypt[1]..<br>argv</td> <td>/Entrypt[0]<br>Entrypt[1]..<br>argv</td> </tr> <tr> <td>sh=0<br>value=1<br>argv=0</td> <td>/value</td> <td>/value</td> <td>/value</td> <td>/value</td> </tr> <tr> <td>sh=0<br>value=1<br>argv=1</td> <td>/value<br>argv</td> <td>/value<br>argv</td> <td>/value<br>argv</td> <td>/value<br>argv</td> </tr> <tr> <td>sh=1<br>value=0<br>argv=0</td> <td>Error</td> <td>Error</td> <td>Error</td> <td>Error</td> </tr> <tr> <td>sh=1<br>value=0<br>argv=1</td> <td>Error</td> <td>Error</td> <td>Error</td> <td>Error</td> </tr> <tr> <td>sh=1<br>value=1<br>argv=0</td> <td>/bin/sh -c<br>value</td> <td>/bin/sh -c<br>value</td> <td>/bin/sh -c<br>value</td> <td>/bin/sh -c<br>value</td> </tr> <tr> <td>sh=1<br>value=1<br>argv=1</td> <td>/bin/sh -c<br>value</td> <td>/bin/sh -c<br>value</td> <td>/bin/sh -c<br>value</td> <td>/bin/sh -c<br>value</td> </tr> </table>
Project: APISIX (Orchestration & Management / API Gateway)
File: configure-routes.md

title: Configure Routes slug: /getting-started/configure-routes <head> <link rel="canonical" href="https://docs.api7.ai/apisix/getting-started/configure-routes" /> </head> The Getting Started tutorials are contributed by . Apache APISIX provides flexible gateway management capabilities based on routes, where routing paths and targets are defined for requests. This tutorial guides you on how to create a route and validate it. You will complete the following steps: Create a route with a sample upstream that points to . Use cURL to send a test request to see how APISIX proxies and forwards the request. A route is a routing path to upstream targets. In , routes are responsible for matching client's requests based on defined rules, loading and executing the corresponding plugins, as well as forwarding requests to the specified upstream services. In APISIX, a simple route can be set up with a path-matching URI and a corresponding upstream address. An upstream is a set of target nodes with the same work. It defines a virtual host abstraction that performs load balancing on a given set of service nodes according to the configured rules. Complete to install APISIX. In this section, you will create a route that forwards client requests to , a public HTTP request and response service. The following command creates a route, which should forward all requests sent to `http://127.0.0.1:9080/ip` to : ```shell curl -i "http://127.0.0.1:9180/apisix/admin/routes" -X PUT -d ' { "id": "getting-started-ip", "uri": "/ip", "upstream": { "type": "roundrobin", "nodes": { "httpbin.org:80": 1 } } }' ``` You will receive an `HTTP/1.1 201 Created` response if the route was created successfully. ```shell curl "http://127.0.0.1:9080/ip" ``` The expected response is similar to the following: ```text { "origin": "183.94.122.205" } ``` This tutorial creates a route with only one target node. In the next tutorial, you will learn how to configure load balancing with multiple target nodes.
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-009.md

+++ date = "2017-07-13T22:52:11Z" release = "009" description = "CoreDNS-009 Release Notes." tags = ["Release", "009", "Notes"] title = "CoreDNS-009 Release" author = "coredns" +++ CoreDNS-009 has been ! CoreDNS is a DNS server that chains plugins, where each plugin implements a DNS feature. Release v009 is mostly a bugfix release, with a few new features in the plugin. No changes. secondary*: fix functionality and improve matching of notify queries. cache*: fix data race. proxy*: async healthchecks. reverse*: new option `wildcard` that also catches all subdomains of a template. kubernetes*: experimental new option `autopath` that optimizes the search path and ndots combinatorial explosion, so clients with a large search path and high ndots will get a reply on the first query. The following people helped with getting this release done: Athir Nuaimi, Chris O'Haver, ghostflame, jremond, Mia Boulay, Miek Gieben, Ning Xie, Roman Mazur, Yong Tang. If you want to help, please check out one of the and start coding! For documentation and help, see our .
Project: BFE (Orchestration & Management / Service Proxy)
File: mod_tag.md

mod_tag sets tags for requests based on defined rules. conf/modtag/modtag.conf | Config Item | Description | | -- | | | Basic.DataPath | String<br>Path of rule configuration | | Log.OpenDebug | Boolean<br>Debug flag of module | ```ini [Basic] DataPath = modtag/tagrule.data [Log] OpenDebug = true ``` conf/modtag/tagrule.data | Config Item | Description | | -- | - | | Version | String<br>Version of the config file | | Config | Object<br>Tag rules for each product | | Config{k} | String<br>Product name | | Config{v} | Object<br>A list of tag rules | | Config{v}[] | Object<br>A tag rule | | Config{v} | | Config{v}[].Param.TagName | String<br>Tag name | | Config{v}[].Param.TagValue | String<br>Tag value | | Config{v}[].Last | Boolean<br>If true, stop to check the remaining rules | ```json { "Version": "20200218210000", "Config": { "example_product": [ { "Cond": "reqhostin(\"example.org\")", "Param": { "TagName": "tag", "TagValue": "bfe" }, "Last": false } ] } } ```
Project: APISIX (Orchestration & Management / API Gateway)
File: serverless.md

title: serverless keywords: Apache APISIX API Gateway Plugin Serverless description: This document contains information about the Apache APISIX serverless Plugin. <!-- --> There are two `serverless` Plugins in APISIX: `serverless-pre-function` and `serverless-post-function`. The former runs at the beginning of the specified phase, while the latter runs at the end of the specified phase. Both Plugins have the same attributes. | Name | Type | Required | Default | Valid values | Description | |--||-|||| | phase | string | False | ["access"] | ["rewrite", "access", "headerfilter", "bodyfilter", "log", "before_proxy"] | Phase before or after which the serverless function is executed. | | functions | array[string] | True | | | List of functions that are executed sequentially. | :::info IMPORTANT Only Lua functions are allowed here and not other Lua code. For example, anonymous functions are legal: ```lua return function() ngx.log(ngx.ERR, 'one') end ``` Closures are also legal: ```lua local count = 1 return function() count = count + 1 ngx.say(count) end ``` But code other than functions are illegal: ```lua local count = 1 ngx.say(count) ``` ::: :::note From v2.6, `conf` and `ctx` are passed as the first two arguments to a serverless function like regular Plugins. Prior to v2.12.0, the phase `before_proxy` was called `balancer`. This was updated considering that this method would run after `access` and before the request goes Upstream and is unrelated to `balancer`. ::: The example below enables the Plugin on a specific Route: :::note You can fetch the `admin_key` from `config.yaml` and save to an environment variable with the following command: ```bash adminkey=$(yq '.deployment.admin.adminkey[0].key' conf/config.yaml | sed 's/"//g') ``` ::: ```shell curl http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "uri": "/index.html", "plugins": { "serverless-pre-function": { "phase": "rewrite", "functions" : ["return function() ngx.log(ngx.ERR, \"serverless pre function\"); end"] }, "serverless-post-function": { "phase": "rewrite", "functions" : ["return function(conf, ctx) ngx.log(ngx.ERR, \"match uri \", ctx.currreqmatched and ctx.currreqmatched._path); end"] } }, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } }' ``` Once you have configured the Plugin as shown above, you can make a request as shown below: ```shell curl -i http://127.0.0.1:9080/index.html ``` You will find a message "serverless pre-function" and "match uri /index.html" in the error.log. To remove the `serverless` Plugin, you can delete the corresponding JSON configuration from the Plugin configuration. APISIX will automatically reload and you do not have to restart for this to take effect. ```shell curl http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "methods": ["GET"], "uri": "/index.html", "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } }' ```
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: code_of_conduct.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to make 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. 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: Gloo (Orchestration & Management / API Gateway)
File: azure.proto.sk.md

title: "azure.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Upstream Spec for Azure Functions Upstreams Azure Upstreams represent a collection of Azure Functions for a particular Azure Account within a particular Function App ```yaml "functionAppName": string "secretRef": .core.solo.io.ResourceRef "functions": []azure.options.gloo.solo.io.UpstreamSpec.FunctionSpec ``` | Field | Type | Description | | -- | - | -- | | `functionAppName` | `string` | The Name of the Azure Function App where the functions are grouped. | | `secretRef` | | A to an . Note that this secret is not required unless Function Discovery is enabled. | | `functions` | | | Function Spec for Functions on Azure Functions Upstreams The Function Spec contains data necessary for Gloo to invoke Azure functions ```yaml "functionName": string "authLevel": .azure.options.gloo.solo.io.UpstreamSpec.FunctionSpec.AuthLevel ``` | Field | Type | Description | | -- | - | -- | | `functionName` | `string` | The Name of the Azure Function as it appears in the Azure Functions Portal. | | `authLevel` | | Auth Level can bve either "anonymous" "function" or "admin" See https://vincentlauzon.com/2017/12/04/azure-functions-http-authorization-levels/ for more details. | | Name | Description | | -- | -- | | `Anonymous` | | | `Function` | | | `Admin` | | ```yaml "functionName": string ``` | Field | Type | Description | | -- | - | -- | | `functionName` | `string` | The Function Name of the FunctionSpec to be invoked. | <!-- 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: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-0.9.9.md

+++ title = "CoreDNS-0.9.9 Release" description = "CoreDNS-0.9.9 Release Notes." tags = ["Release", "0.9.9", "Notes"] draft = false release = "0.9.9" date = "2017-10-18T11:37:43-04:00" author = "coredns" +++ CoreDNS-0.9.9 has been ! (yes, we've moved to ) CoreDNS is a DNS server that chains plugins, where each plugin implements a DNS feature. Release 0.9.9 is a major release, with lots of fixes. We've renamed `middleware.Middleware` to `plugin.Plugin`. This is backwards incompatible for external middleware plugins, but you can update your plugin by just replacing `[Mm]iddleware` with `[Pp]lugin`: ~~~ sed 's/Middleware/Plugin/'g -i *.go sed 's/middleware/plugin/'g -i *.go ~~~ From now on we'll use the term plugin in our documentation and code. We've sent a proposal to make CoreDNS the default in Kubernetes: https://github.com/kubernetes/community/pull/1100 etcd*'s debug queries are removed. hosts* gets inline host definitions that add or overwrite those from `/etc/hosts`. auto, file* now poll every minute for on disk changes (inotify wasn't working). rewrite* can chain rules and perform multiple changes on a message. kubernetes* uses `protobuf` to communicate with the kubernetes API and performance improvements when there are a large number of services. dnstap* saw several fixes, including sending tap messages out-of-band. cache* apply configured TTL to first answer returned. Don't cache TTL=0 messages. proxy* smaller timeouts and the health check GET was given a timeout. Better metrics: add a request counter metrics and change the 'from' label to 'to' so we count/duration per upstream. dnssec* now signs NODATA responses. Two new were added: ipecho* parses the IP out of a subdomain and echos it back as an record. forward* facilitates proxying DNS messages to upstream resolvers. The following people helped with getting this release done: antonkyrylenko, Chris O'Haver, Chris West, Damian Myerscough, Isolus, John Belamaric, Miek Gieben, Sandeep Rajan, Thong Huynh, varyoo, Yong Tang. If you want to help, please check out one of the and start coding! For documentation and help, see our .
Project: kcp (Orchestration & Management / Scheduling & Orchestration)
File: helm.md

description: > Install kcp on an existing Kubernetes cluster via the official Helm chart. We provide a chart to install kcp on top of an existing Kubernetes cluster. Its source is available in . The chart repository can be added via: ```sh helm repo add kcp https://kcp-dev.github.io/helm-charts ``` The chart can then be installed as `kcp/kcp`: ```sh helm install my-kcp kcp/kcp -f my-values.yaml ``` At the very least, `.externalHostname` needs to be set and point to a DNS hostname that will point to the front-proxy's external hostname. A list of all values is . We are also working on a collection of charts that allow for a multi- deployment. Those are currently WIP and considered highly experimental, but instructions are also .
Project: Istio (Orchestration & Management / Service Mesh)
File: feature_request.md

name: Feature request about: Suggest an idea to improve Istio (This is used to request new product features, please visit <https://github.com/istio/istio/discussions> for questions on using Istio) Describe the feature request Describe alternatives you've considered Affected product area (please put an X in all that apply) [ ] Ambient [ ] Docs [ ] Dual Stack [ ] Installation [ ] Networking [ ] Performance and Scalability [ ] Extensions and Telemetry [ ] Security [ ] Test and Release [ ] User Experience [ ] Developer Infrastructure Affected features (please put an X in all that apply) [ ] Multi Cluster [ ] Virtual Machine [ ] Multi Control Plane Additional context
Project: BFE (Orchestration & Management / Service Proxy)
File: http2_state.md

The endpoint `/monitor/http2_state` exposes metrics about HTTP2 protocol. | Metric | Description | | | - | | H2ERRMAXHEADERLIST_SIZE | Counter for reaching max size of header list | | H2ERRMAXHEADERURI_SIZE | Counter for reaching max size of header URI | | H2ERRMAXSTREAMPER_CONN | Counter for reaching advertised concurrent stream limit | | H2ERRGOTRESET | Counter for getting RSTSTREAM | | H2PANICCONN | Counter for connection panic | | H2PANICSTREAM | Counter for stream panic | | H2REQHEADERCOMPRESSSIZE | Size of request header after compress | | H2REQHEADERORIGINALSIZE | Size of request header before compress | | H2RESHEADERCOMPRESSSIZE | Size of response header after compress | | H2RESHEADERORIGINALSIZE | Size of response header before compress | | H2TIMEOUTCONN | Counter for timeout of HTTP2 connection timeout | | H2TIMEOUTPREFACE | Counter for timeout of waiting for client preface | | H2TIMEOUTREAD_STREAM | Counter for timeout of waiting for reading stream | | H2TIMEOUTSETTING | Counter for timeout of waiting for SETTINGS frames | | H2TIMEOUTWRITE_STREAM | Counter for timeout of waiting for writing stream |
Project: Serverless Devs (Orchestration & Management / Scheduling & Orchestration)
File: readme.md

title: Intro description: 'Intro' position: 1 category: 'Package model' This topic describes a specification about serverless packages. Package developers must follow the specification to develop components and share applications. Otherwise, Serverless Devs cannot identify and load packages. In this case, the packages cannot be referenced by applications. - - - -
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.8.0.md

+++ title = "CoreDNS-1.8.0 Release" description = "CoreDNS-1.8.0 Release Notes." tags = ["Release", "1.8.0", "Notes"] release = "1.8.0" date = 2020-10-22T08:00:00+00:00 author = "coredns" +++ The CoreDNS team has released . If you are running 1.7.1 you want to upgrade for the cache plugin fixes. This release also adds three backwards incompatible changes. This will only affect you if you have an external plugin or use outgoing zone transfers. If you're using `dnstap` in your plugin, you'll need to upgrade to the new API as detailed in it's . Two, because Caddy is now developing a version 2 and we are using version 1, we've internalized Caddy into <https://github.com/coredns/caddy>. This means the `caddy` types change and all plugins need to fix the import path from: `github.com/caddyserver/caddy` to `github.com/coredns/caddy` (this can thankfully be automated). And lastly, the `transfer` plugin is now made a first class citizen and plugins wanting to perform outgoing zone transfers now use this plugin: file, auto, secondary and kubernetes are converted. For this you must change your Corefile from (e.g.): ``` txt example.org { file example.org.signed { transfer to * transfer to 10.240.1.1 } } ``` To ``` txt example.org { file example.org.signed transfer { to * 10.240.1.1 } } ``` Bob, Chris O'Haver, Johnny Bergstrm, Macks, Miek Gieben, Yong Tang. core: doh support: fix alpn for http/2 upgrade when using DoH (https://github.com/coredns/coredns/pull/4182) core: doh support: make no TLS config fatal (https://github.com/coredns/coredns/pull/4162) core: fix crash with no plugins (https://github.com/coredns/coredns/pull/4184) core: Move caddy v1 in our GitHub org (https://github.com/coredns/coredns/pull/4018) plugin/auto: allow fallthrough if no zones match (https://github.com/coredns/coredns/pull/4166) plugin/cache: Fix filtering (https://github.com/coredns/coredns/pull/4148) plugin/cache: Fix removing OPT (https://github.com/coredns/coredns/pull/4190) plugin/dnstap: various cleanups (https://github.com/coredns/coredns/pull/4179) plugin/ready: don't return 200 during shutdown (https://github.com/coredns/coredns/pull/4167) plugin/trace: root span names no longer contain the query data (https://github.com/coredns/coredns/pull/4171) plugin/transfer: Implement notifies for transfer plugin (https://github.com/coredns/coredns/pull/3972)