cwielenb/CNCF-Dataset huggingface dataset:
Project: APISIX (Orchestration & Management / API Gateway)
File: plugin-metadata.md

title: Plugin Metadata keywords: API Gateway Apache APISIX Plugin Metadata description: Plugin Metadata in Apache APISIX. <!-- --> In this document, you will learn the basic concept of plugin metadata in APISIX and why you may need them. Explore additional resources at the end of the document for more information on related topics. In APISIX, a plugin metadata object is used to configure the common metadata field(s) of all plugin instances sharing the same plugin name. It is useful when a plugin is enabled across multiple objects and requires a universal update to their metadata fields. The following diagram illustrates the concept of plugin metadata using two instances of plugins on two different routes, as well as a plugin metadata object setting a `log_format` for the syslog plugin: Without otherwise specified, the `logformat` on plugin metadata object should apply the same log format uniformly to both `syslog` plugins. However, since the `syslog` plugin on the `/orders` route has a different `logformat`, requests visiting this route will generate logs in the `log_format` specified by the plugin in route. Metadata properties set at the plugin level is more granular and has a higher priority over the "global" metadata object. Plugin metadata objects should only be used for plugins that have metadata fields. Check the specific plugin documentation to know more. The example below shows how you can configure through the Admin API: :::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/plugin_metadata/http-logger \ -H "X-API-KEY: $admin_key" -X PUT -d ' { "log_format": { "host": "$host", "@timestamp": "$time_iso8601", "clientip": "$remoteaddr" } }' ``` With this configuration, your logs would be formatted as shown below: ```json {"host":"localhost","@timestamp":"2020-09-23T19:05:05-04:00","clientip":"127.0.0.1","routeid":"1"} {"host":"localhost","@timestamp":"2020-09-23T19:05:05-04:00","clientip":"127.0.0.1","routeid":"1"} ``` Key Concepts -
Project: wasmCloud (Orchestration & Management / Scheduling & Orchestration)
File: 0012-rfc-management.md

| Status | Deciders | Date | | -- | | - | | accepted | wasmCloud community call members and maintainers | 07-20-2023 | RFCs in wasmCloud were unclear in terms of status of acceptance, implementation, when they are ready to be worked on. Additionally, it's difficult to tell when an RFC is completed, or if it has been abandoned or superseded by another RFC. This ADR proposes a new process for managing RFCs and their status. I personally have closed a handful of RFCs months after they have been implemented or abandoned I know what RFCs are in progress, but I do not know their status and the RFC itself does not communicate that Very few RFCs are contributed by community members and/or worked on by community members. Continue with the current process Manage RFCs in GitHub with clear labels and issue templates to communicate status Look for a different tool to manage RFCs We chose to modify the way we propose RFCs from beginning to end, starting with the RFC issue template and ending with the ADR that closes the RFC. Inbetween, we will communicate the status of RFCs using the following labels: `rfc-proposed` - For when an RFC is newly proposed `rfc-discussion-needed` - For when active discussion is going on in the RFC and it's not scoped enough for work to begin `rfc-accepted` - For when an RFC is adequately scoped and ready for implementation. It's up to maintainers to decide if an RFC is scoped enough for work, and affected projects should be indicated. As an additional note, `rfc-accepted` combined with `good-first-issue` should be a great place to begin contributing meaningful features to wasmCloud. Additionally, the condition to close an RFC as completed is a written ADR that is contributed to this (wasmcloud/wasmcloud) repository. This ADR is the first example of such an ADR. It is easier to propose RFCs for all contributors RFCs have a clear definition of when they are ready for implementation and when they are completed. Completed RFCs as ADRs leaves a clear decision log of work and serves as an easy place to see more significant decisions in the project. A formal process here may overcomplicate things Changes to this process, including labels, may inspire changes to this ADR which is heavyhanded
Project: Kubernetes (Orchestration & Management / Scheduling & Orchestration)
File: MAINTAINERS.md

This page lists all active maintainers of this repository. If you were a maintainer and would like to add your name to the Emeritus list, please send us a PR. See for governance guidelines and how to become a maintainer. See for general contribution guidelines. , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC
Project: Gloo (Orchestration & Management / API Gateway)
File: http_output_sink.proto.sk.md

title: "httpoutputsink.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> HTTP output sink definition ```yaml "serverUri": .solo.io.envoy.config.core.v3.HttpUri ``` | Field | Type | Description | | -- | - | -- | | `serverUri` | | URI of the HTTP server to which output traces should be submitted. | <!-- 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: Gloo (Orchestration & Management / API Gateway)
File: glooctl_get_upstream.md

title: "glooctl get upstream" weight: 5 read an upstream or list upstreams in a namespace usage: glooctl get upstream [NAME] [--namespace=namespace] [-o FORMAT] ``` glooctl get upstream [flags] ``` ``` -h, --help help for upstream ``` ``` -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 -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 --name string name of the resource to read or write -n, --namespace string namespace for reading or writing resources (default "gloo-system") -o, --output OutputType output format: (yaml, json, table, kube-yaml, wide) (default table) --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - Display one or a list of Gloo resources
Project: Prefect (Orchestration & Management / Scheduling & Orchestration)
File: orchestration.md

description: Prefect Python client API for communicating with the Prefect REST API. tags: Python API REST API Asynchronous client implementation for communicating with the . Explore the client by communicating with an in-memory webserver &mdash; no setup required: <div class="terminal"> ``` $ # start python REPL with native await functionality $ python -m asyncio >> from prefect import get_client >> async with get_client() as client: ... response = await client.hello() ... print(response.json()) ``` </div> ::: prefect.client.orchestration options: filters: ["!^_", "!Config", "!copy", "!dict", "!json"] members_order: source
Project: Kubernetes (Orchestration & Management / Scheduling & Orchestration)
File: rest_docs.md

Generating ReST pages from a cobra command is incredibly easy. An example is as follows: ```go package main import ( "log" "github.com/spf13/cobra" "github.com/spf13/cobra/doc" ) func main() { cmd := &cobra.Command{ Use: "test", Short: "my test program", } err := doc.GenReSTTree(cmd, "/tmp") if err != nil { log.Fatal(err) } } ``` That will get you a ReST document `/tmp/test.rst` This program can actually generate docs for the kubectl command in the kubernetes project ```go package main import ( "log" "io/ioutil" "os" "k8s.io/kubernetes/pkg/kubectl/cmd" cmdutil "k8s.io/kubernetes/pkg/kubectl/cmd/util" "github.com/spf13/cobra/doc" ) func main() { kubectl := cmd.NewKubectlCommand(cmdutil.NewFactory(nil), os.Stdin, ioutil.Discard, ioutil.Discard) err := doc.GenReSTTree(kubectl, "./") if err != nil { log.Fatal(err) } } ``` This will generate a whole series of files, one for each command in the tree, in the directory specified (in this case "./") You may wish to have more control over the output, or only generate for a single command, instead of the entire command tree. If this is the case you may prefer to `GenReST` instead of `GenReSTTree` ```go out := new(bytes.Buffer) err := doc.GenReST(cmd, out) if err != nil { log.Fatal(err) } ``` This will write the ReST doc for ONLY "cmd" into the out, buffer. Both `GenReST` and `GenReSTTree` have alternate versions with callbacks to get some control of the output: ```go func GenReSTTreeCustom(cmd *Command, dir string, filePrepender func(string) string, linkHandler func(string, string) string) error { //... } ``` ```go func GenReSTCustom(cmd Command, out bytes.Buffer, linkHandler func(string, string) string) error { //... } ``` The `filePrepender` will prepend the return value given the full filepath to the rendered ReST file. A common use case is to add front matter to use the generated documentation with : ```go const fmTemplate = ` date: %s title: "%s" slug: %s url: %s ` filePrepender := func(filename string) string { now := time.Now().Format(time.RFC3339) name := filepath.Base(filename) base := strings.TrimSuffix(name, path.Ext(name)) url := "/commands/" + strings.ToLower(base) + "/" return fmt.Sprintf(fmTemplate, now, strings.Replace(base, "_", " ", -1), base, url) } ``` The `linkHandler` can be used to customize the rendered links to the commands, given a command name and reference. This is useful while converting rst to html or while generating documentation with tools like Sphinx where `:ref:` is used: ```go // Sphinx cross-referencing format linkHandler := func(name, ref string) string { return fmt.Sprintf(":ref:`%s <%s>`", name, ref) } ```
Project: KubeStellar (Orchestration & Management / Scheduling & Orchestration)
File: testing-doc-prs.md

Here are the steps to checkout a git pull request for local testing. STEP-1: Checkout the Pull Request Helpers: , &nbsp;&nbsp;&nbsp;&nbsp;Fetch the reference to the pull request based on its ID number, creating a new branch locally. Replace ID with your PR # and BRANCH_NAME with the desired branch name. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;```git fetch origin pull/ID/head:BRANCH_NAME``` &nbsp;&nbsp;&nbsp;Checkout the BRANCH_NAME where you have all the changes from the pull request. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;```git switch BRANCH_NAME``` &nbsp;&nbsp;&nbsp;&nbsp;At this point, you can do anything you want with this branch. You can run some local tests, or merge other branches into the branch. STEP-2: Test and Build the Documentation (optional) &nbsp;&nbsp;&nbsp;&nbsp;Use this procedure if you want to view and modify the documentation in the branch you have checked out. Helpers: , ``` cd docs pip install mkdocs pip install -r requirements.txt ``` &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;```mkdocs serve``` &nbsp;&nbsp;&nbsp;&nbsp;Next, open a browser to and review the changes.
Project: Kuma (Orchestration & Management / Service Mesh)
File: universal-health-checks.md

Since `Kuma 1.0.4` Dataplane model has a new field `health`: ```yaml type: Dataplane mesh: default name: web-01 networking: address: 127.0.0.1 inbound: port: 11011 health: ready: true servicePort: 11012 tags: kuma.io/service: backend kuma.io/protocol: http port: 11013 health: ready: false servicePort: 11014 tags: kuma.io/service: backend kuma.io/protocol: http ``` This field is intended to be set automatically by various health checkers. When Kuma runs in Kubernetes this field is automatically set by Kuma CP based on data from `Pod.Status`. But when Kuma runs in Universal this doesnt happen. Thanks to Envoy HDS (Health Discovery Service) we can configure Envoy to do active health checking of applications ports and report status back to management server. PR provides basic implementation of HDS, but it doesnt introduce good way to configure health checks. There are several types of health checkers - TCP, HTTP and GRPC, each of them has own set of parameters. We want flexibility in specifying those health checks on a per Dataplane basis. In order to do that we have to either extend of the existing policy or introduce new one. Current proposal aims to cover all possible options with pros and cons. Enable/Disable application health check for all Dataplanes or only for specific ones. Parametrise port and path for health checkers (if application has special endpoints for checking health) ```yaml type: Dataplane mesh: default name: web-01 networking: address: 127.0.0.1 inbound: port: 11011 servicePort: 11012 tags: kuma.io/service: backend kuma.io/protocol: http probe: checkInbounds: true readiness: interval: 5s timeout: 1s http: path: /health port: 80 ``` New section `AppHealthChecks` for `HealthCheck` policy: ```yaml type: HealthCheck name: web-to-backend-check mesh: default sources: match: kuma.io/service: web destinations: match: kuma.io/service: backend conf: interval: 10s timeout: 2s unhealthyThreshold: 3 healthyThreshold: 1 protocol: tcp: {} appHealthChecks: ... ``` Downsides: because of the way we pick matched policy it will be problematic to support. it is implied that HealthCheck is matched for pair - source + destination, application health check is designed to be applied on a per Dataplane basis ```yaml type: Probe mesh: default name: custom-probe selectors: match: kuma.io/service: '*' conf: readiness: interval: 5s timeout: 1s http: path: /health port: 80 tcp: port: 9000 ``` ```yaml type: Probe mesh: default name: default-probe selectors: match: kuma.io/service: '*' conf: readiness: tcp: {} ``` Extend dataplane module, specifically Inbound section: ```yaml type: Dataplane mesh: default name: web-01 networking: address: 127.0.0.1 inbound: port: 11011 servicePort: 11012 tags: kuma.io/service: backend kuma.io/protocol: http serviceProbe: interval: 10s timeout: 3s healthyThreshold: 1 unhealthThreshold: 1 tcp: {} ``` Parameters `interval`, `timeout`, `healthyThreshold` and `unhealthyThreshold` could be omitted, default values for them could be specified in kuma-cp config. In the future we can add `http` checker section as well.
Project: BFE (Orchestration & Management / Service Proxy)
File: tls_rule_conf.data.md

tlsruleconf.data records the tls protocol config | Config Item | Description | | -- | | | Version | String<br>Version of configure file | | Config | Object<br>TLS rule config. | | Config{k} | String<br>Unique label | | Config{v} | Object<br>TLS rule detail | | Config{v}.CertName | String<br>Name of server certificate (Note: defined in servercertconf.data) | | Config{v}.NextProtos | Object<br>TLS application layer protocol list <br>Default ["http/1.1"] | | Config{v}.NextProtos[] | String<br>TLS application layer protocol (h2, spdy/3.1, http/1.1) | | Config{v}.Grade | String<br>TLS Security grade ( A+, A, B, C) | | Config{v}.ClientAuth | Bool<br>Enable TLS Client Authentication | | Config{v}.ClientCAName | String<br>Name of Client CA certificate | | Config{v}.VipConf | Object Array<br>List of VIPs<br>Note: TLS policy selection is based on VIP | | Config{v}.VipConf[] | String Array<br>VIP | | Config{v}.SniConf | Object Array<br>List of hostnames (optional) | | Config{v}.SniConf[] | String Array<br>Hostname | | DefaultNextProtos | Object<br>Default application layer protocols over TLS | | DefaultNextProtos[] | String<br>TLS application layer protocol (h2, spdy/3.1, http/1.1) | ```json { "Version": "20190101000000", "DefaultNextProtos": ["h2", "http/1.1"], "Config": { "example_product": { "VipConf": [ "10.199.4.14" ], "SniConf": null, "CertName": "example.org", "NextProtos": [ "h2", "http/1.1" ], "Grade": "C", "ClientCAName": "" } } } ``` BFE supports multiple security grades(A+/A/B/C) for ease of TLS configuration. Security grades vary depending on the protocols and the cipher suites supported. | Supported Protocols | Supported Cipher Suites | | - | -- | | TLS1.2 | TLSECDHERSAWITHCHACHA20POLY1305SHA256<br>TLSECDHERSAWITHCHACHA20POLY1305OLDSHA256<br>TLSECDHERSAWITHAES128GCMSHA256<br>TLSECDHERSAWITHAES128CBCSHA<br>TLSECDHERSAWITHAES256CBCSHA<br>TLSRSAWITHAES128CBCSHA<br>TLSRSAWITHAES256CBCSHA | | Supported Protocols | Supported Cipher Suites | | - | -- | | TLS1.2<br>TLS1.1<br>TLS1.0 | TLSECDHERSAWITHCHACHA20POLY1305SHA256<br>TLSECDHERSAWITHCHACHA20POLY1305OLDSHA256<br>TLSECDHERSAWITHAES128GCMSHA256<br>TLSECDHERSAWITHAES128CBCSHA<br>TLSECDHERSAWITHAES256CBCSHA<br>TLSRSAWITHAES128CBCSHA<br>TLSRSAWITHAES256CBCSHA | | Supported Protocols | Supported Cipher Suites | | - | -- | | TLS1.2<br>TLS1.1<br>TLS1.0 | TLSECDHERSAWITHCHACHA20POLY1305SHA256<br>TLSECDHERSAWITHCHACHA20POLY1305OLDSHA256<br>TLSECDHERSAWITHAES128GCMSHA256<br>TLSECDHERSAWITHAES128CBCSHA<br>TLSECDHERSAWITHAES256CBCSHA<br>TLSRSAWITHAES128CBCSHA<br>TLSRSAWITHAES256CBCSHA | | SSLv3 | TLSECDHERSAWITHRC4128SHA<br>TLSRSAWITHRC4128_SHA | | Supported Protocols | Supported Cipher Suites | | - | -- | | TLS1.2<br>TLS1.1<br>TLS1.0 | TLSECDHERSAWITHCHACHA20POLY1305SHA256<br>TLSECDHERSAWITHCHACHA20POLY1305OLDSHA256<br>TLSECDHERSAWITHAES128GCMSHA256<br>TLSECDHERSAWITHAES128CBCSHA<br>TLSECDHERSAWITHAES256CBCSHA<br>TLSRSAWITHAES128CBCSHA<br>TLSRSAWITHAES256CBCSHA<br>TLSECDHERSAWITHRC4128SHA<br>TLSRSAWITHRC4128_SHA | | SSLv3 | TLSECDHERSAWITHRC4128SHA<br>TLSRSAWITHRC4128_SHA |
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.3.1.md

+++ title = "CoreDNS-1.3.1 Release" description = "CoreDNS-1.3.1 Release Notes." tags = ["Release", "1.3.1", "Notes"] release = "1.3.1" date = "2019-01-13T15:00:29+00:00" author = "coredns" +++ We are pleased to announce the of CoreDNS-1.3.1! This is a fairly small release that allows us to announce some backwards incompatible changes in the next (1.4.0) release: The `upstream` directive used in various plugin will start to default* to the coredns process itself. This allow those resolutions to take advantage of other plugins (i.e. caching). The etcd's plugin StubDomain subsystem relied heavily on this functionality and as such will be removed from that plugin. Multiple endpoints in kubernetes will not be supported going forward. Mostly documentation updates in various plugins. Plus a small fix where we stop setting the RA (recursion available) flag on responses in plugins that don't provide recursion. now allows multiple names to be specified. was added to give it a README.md to make its documentation more discoverable. `TTL` is also applied to negative responses (NXDOMAIN, etc). Chris O'Haver, ckcd, Isolus, jmpcyc, Miek Gieben, Taras Tsugrii, Yong Tang. For documentation see our (in progress!) . For help and other resources, see our .
Project: Capsule (Orchestration & Management / Scheduling & Orchestration)
File: overview.md

Capsule Operator can be easily installed on a Managed Kubernetes Service. Since you do not have access to the Kubernetes APIs Server, you should check with the provider of the service: the default `cluster-admin` ClusterRole is accessible the following Admission Webhooks are enabled on the APIs Server: PodNodeSelector LimitRanger ResourceQuota MutatingAdmissionWebhook ValidatingAdmissionWebhook
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.0.6.md

+++ title = "CoreDNS-1.0.6 Release" description = "CoreDNS-1.0.6 Release Notes." tags = ["Release", "1.0.6", "Notes"] draft = false release = "1.0.6" date = "2018-02-21T11:10:29+00:00" author = "coredns" enabled = "default" +++ We are pleased to announce the of CoreDNS-1.0.6! This release has bug fixes, documentation fixes, polish and new plugins. We've moved to a OWNERS model, where each plugin (and CoreDNS itself) now has an OWNERS file listing people involved with this code. The startup and shutdown plugin are deprecated (but working and included) in this release in favor of the on* plugin. If you use them, this is the moment to move to . A plugin called has been included in CoreDNS, this was, up until now, an external plugin. Supports DNS-over-TLS and has different way of health checking an upstream. The plugin has a new policy, first* which always chooses the first healthy upstream host. It also contains an important fix where a non-health checked target could be mark unhealthy forever. We now support zone transfers in the plugin. The now supports multiple listening addresses. Bugfixes, improvements and documentation fixes in various other plugins. The following people helped with getting this release done: Chris O'Haver, Francois Tur, Freddy, Harshavardhana, John Belamaric, Miek Gieben, Pat Moroney, Paul Greenberg, Sandeep Rajan, Tobias Schmidt, Uladzimir Trehubenka, Yong Tang. For documentation and help, see our .
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.17.1.md

Today we present version v1.17.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. This is a security release, which fixes the advisory at . Thanks to @josh-ferrell for the initial report. Kubernetes Services of type `ExternalName` will now not be processed by Contour without active action by Contour's operator. This prevents a vulnerability where an attacker with access to create Service objects inside a cluster running Contour could force Contour's Envoy to expose its own admin interface to the internet with a Service with an ExternalName of `localhost` or similar. With access to Envoy's admin page, an attacker can force Envoy to restart or drain connections (which will cause Kubernetes to restart it eventually). The attacker can also see the names and metadata of TLS Secrets, but not their contents. This version includes two main changes: ExternalName Service processing is now disabled by default, and must be enabled. Even when processing is enabled, obvious attempts to expose `localhost` will be prevented. This is quite a porous control, and should not be relied on as your sole means of mitigation. In short, we recommend migration away from ExternalName Services as soon as you can. If you are currently using ExternalName Services with your Contour installation, it's still recommended that you update to this version. However, as part of updating, you will need to add the `enableExternalNameService: "true"` directive to your Contour configuration file. This is not recommended for general use, because of the concerns above, but we have but some mitigations in place to stop obvious misuse of ExternalName Services if you must have them enabled. Note that because of the cross-namespace control issues documented at kubernetes/kubernetes#103675, you should definitely consider if you can move away from using ExternalName Services in any production clusters. The ability to enable ExternalName Services for Contour is provided to help with migration, it is not recommended for use in production clusters.