cwielenb/CNCF-Dataset huggingface dataset:
Project: Gloo (Orchestration & Management / API Gateway)
File: setting-up-dev-environment.md

menuTitle: "Dev Environment" title: "Setting up the Development Environment" weight: 1 Developing on Gloo Edge requires the following to be installed on your system: (`solo-io` projects are built using version `1.16.3`) `protoc` (`solo-io` projects are built using version `3.6.1`) the `github.com/gogo/protobuf` go package standard development tools like `gcc` To install all the requirements, run the following: On macOS: ```bash xcode-select --install curl -LO https://github.com/protocolbuffers/protobuf/releases/download/v3.6.1/protoc-3.6.1-osx-x86_64.zip unzip protoc-3.6.1-osx-x86_64.zip sudo mv bin/protoc /usr/local/bin/ rm -rf bin include protoc-3.6.1-osx-x86_64.zip readme.txt curl https://raw.githubusercontent.com/canha/golang-tools-install-script/master/goinstall.sh | bash go get -u github.com/gogo/protobuf/... ``` On Debian/Ubuntu linux: ```bash sudo apt install make unzip build-essential -y curl -LO https://github.com/protocolbuffers/protobuf/releases/download/v3.6.1/protoc-3.6.1-linux-x86_64.zip unzip protoc-3.6.1-linux-x86_64.zip sudo mv bin/protoc /usr/local/bin/ rm -rf bin include protoc-3.6.1-linux-x86_64.zip readme.txt curl https://raw.githubusercontent.com/canha/golang-tools-install-script/master/goinstall.sh | bash go get -u github.com/gogo/protobuf/... ``` Next, we'll clone the Gloo Edge and Solo-Kit source code. Solo-Kit is required for code generation in Gloo Edge. {{% notice info %}} Currently, Gloo Edge plugins must live inside the itself. {{% /notice %}} Ensure you've installed `go` and have a your `$GOPATH` set. If unset, it will default to `${HOME}/go`. The Gloo Edge repo should live in `${GOPATH}/src/github.com/solo-io/gloo`. To clone your fork of the repository: ```bash mkdir -p ${GOPATH}/src/github.com/solo-io cd ${GOPATH}/src/github.com/solo-io git clone https://github.com/solo-io/gloo ``` ```bash git clone git@github.com:solo-io/gloo.git ``` To run the `main.go` files locally in your system make sure to have a running. You should now be able to run any `main.go` file in the Gloo Edge repository using: ```bash go run <path-to-cmd>/main.go ``` For example: ```bash go run projects/gloo/cmd/main.go go run projects/discovery/cmd/main.go go run projects/gateway/cmd/main.go ``` Awesome! You're ready to start developing on Gloo Edge! Check out the to see how to add plugins to gloo. To generate or re-generate code in Gloo Edge, some additional dependencies are required. Follow these steps if you are making changes to Gloo Edge's Protobuf-based API. Install Solo-Kit and required go packages: ```bash cd ${GOPATH}/src/github.com/solo-io/gloo make install-go-tools ``` You can test that code generation works with Gloo Edge: ```bash make -B generated-code echo $? ``` The `echo` output should be `0` if everything worked correctly.
Project: Kuma (Orchestration & Management / Service Mesh)
File: OWNERS.md

This page lists all maintainers for this repository. Each repository in the will list their repository maintainers in their own `OWNERS.md` file. Please see for governance guidelines and responsibilities for the maintainers. Renews 2025/07/01: Jakub Dyszkiewicz @jakubdyszkiewicz (jakub.dyszkiewicz@gmail.com) Michael Beaumont @michaelbeaumont (mjboamail@gmail.com) Charly Molter @lahabana (charly@molter.io) kumahq org group: https://github.com/orgs/kumahq/teams/kuma-maintainers Bart Smykla @bartsmykla (bartek@smykla.com) Ilya Lobkov @lobkovilya (ilya.lobkov@konghq.com) Krzysztof Slonka @slonka (krzysztof.slonka@konghq.com) Marcin Skalski @Automaat (marcin.skalski@konghq.com) Lukasz Dziedziak @lukidzi (lukidzi@gmail.com) Austin Cawley-Edwards @austince James Peach @jpeach Nikolay Nikolaev @nickolaev Paul Parkanzky @parkanzky Marco Palladino @subnetmarco
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: bug_report_core.md

name: Report a gRPC Core bug about: Create a report to help us improve labels: kind/bug, priority/P2, lang/core, untriaged <!-- PLEASE DO NOT POST A QUESTION HERE. This form is for bug reports and feature requests ONLY! For general questions and troubleshooting, please ask/look for answers at StackOverflow, with "grpc" tag: https://stackoverflow.com/questions/tagged/grpc For questions that specifically need to be answered by gRPC team members, please ask/look for answers at grpc.io mailing list: https://groups.google.com/forum/#!forum/grpc-io Issues specific to grpc-java, grpc-go, grpc-node, grpc-dart, grpc-web should be created in the repository they belong to (e.g. https://github.com/grpc/grpc-LANGUAGE/issues/new) --> Please provide either 1) A unit test for reproducing the bug or 2) Specific steps for us to follow to reproduce the bug. If theres not enough information to debug the problem, gRPC team may close the issue at their discretion. Youre welcome to re-open the issue once you have a reproduction. Make sure you include information that can help us debug (full error message, exception listing, stack trace, logs). See for how to diagnose problems better.
Project: Kured (Orchestration & Management / Scheduling & Orchestration)
File: README.md

](https://artifacthub.io/packages/helm/kured/kured) ](https://app.fossa.com/projects/git%2Bgithub.com%2Fkubereboot%2Fkured?ref=badge_shield) ](https://clomonitor.io/projects/cncf/kured) ](https://www.bestpractices.dev/projects/8867) <img src="https://github.com/kubereboot/website/raw/main/static/img/kured.png" alt="kured logo" width="200" align="right"/> - - - Kured (KUbernetes REboot Daemon) is a Kubernetes daemonset that performs safe automatic node reboots when the need to do so is indicated by the package management system of the underlying OS. Watches for the presence of a reboot sentinel file e.g. `/var/run/reboot-required` or the successful run of a sentinel command. Utilises a lock in the API server to ensure only one node reboots at a time Optionally defers reboots in the presence of active Prometheus alerts or selected pods Cordons & drains worker nodes before reboot, uncordoning them after Find all our docs on <https://kured.dev>: And there's much more! If you have any questions about, feedback for or problems with `kured`: Invite yourself to the <a href="https://slack.cncf.io/" target="_blank">CNCF Slack</a>. Ask a question on the slack channel. . Join us in , every first Wednesday of the month at 16:00 UTC. You might want to as well. We follow the . Your feedback is always welcome! Kured is a Sandbox project. The Linux Foundation (TLF) has registered trademarks and uses trademarks. For a list of TLF trademarks, see . ](https://app.fossa.com/projects/git%2Bgithub.com%2Fkubereboot%2Fkured?ref=badge_large)
Project: BFE (Orchestration & Management / Service Proxy)
File: COMMUNITY.md

We are very interested in building a community around BFE. If you are interested in using it or need help, please feel free to contact us. BFE user forum: . BFE community on Slack: CNCF Slack and join bfe channel. WeChat developer group: with your WeChat ID and a contribution you have made to BFE(such as a PR/Issue). We will invite you right away. Twitter: Issue tracker: Use the to file bugs and features request. We sincerely appreciate your contribution. Please visit the and follow the . BFE is an independent open-source project. BFE community follow . To make BFE a welcoming and harassment-free experience for everyone, we follow the following . Welcome to .
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_cluster_list.md

title: "glooctl cluster list" weight: 5 List clusters registered to the Gloo Federation control plane ``` glooctl cluster list [flags] ``` ``` --federation-namespace string namespace of the Gloo Federation control plane (default "gloo-system") -h, --help help for list ``` ``` -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 --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - Cluster commands
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.28.3.md

We are delighted to present version v1.28.3 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. See the release notes for v1.29.3 . Note that this Envoy version retains the hop-by-hop TE header when set to `trailers`, fixing a regression seen in v1.29.0-v1.29.2 for HTTP/2, particularly gRPC. However, this version of Contour continues to set the `envoy.reloadablefeatures.sanitizete` Envoy runtime setting to `false` to ensure seamless upgrades. This runtime setting will be removed in Contour v1.29.0. See the release notes for v1.21.9 . For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.28.3 is tested against Kubernetes 1.27 through 1.29. If you're using Contour and want to add your organization to our adopters list, please visit this . If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this .
Project: Easegress (Orchestration & Management / API Gateway)
File: 2.8.HTTPS-Lets-Encrypt.md

- Easegress offers both manual and automated approach to manage HTTPS certificates. The automated method is using business controller AutoCertManager. This tutorial will guide you through setting up HTTPS in HTTPServer and configuring AutoCertManager for certificate management with Let's Encrypt. To implement HTTPS in HTTPServer, you have two options: manually providing certificates and keys, or using AutoCertManager for automated certificate management. For manual configuration, you need to set https to true and provide your certificates and keys. ```yaml name: demo kind: HTTPServer https: true autoCert: false certs: cert1: <public-key-data> cert2: <public-key-data> keys: cert1: <private-key-data> cert2: <private-key-data> ... ``` If you prefer automated management with Let's Encrypt, set autoCert to true. This will utilize the AutoCertManager. ```yaml name: demo kind: HTTPServer https: true autoCert: true ... ``` `AutoCertManager` is a business controller, which is more special than others. Because there can be at most one instance of AutoCerManager. It manages HTTPS certificates and handles challenge traffic from Let's Encrypt. ```yaml kind: AutoCertManager name: AutoCertManager email: someone@megaease.com directoryURL: https://acme-v02.api.letsencrypt.org/directory renewBefore: 720h enableHTTP01: true enableTLSALPN01: true enableDNS01: true domains: name: "*.megaease.com" dnsProvider: name: dnspod zone: megaease.com apiToken: <token value> ``` Explanation of Fields: email: Email address for Let's Encrypt registration. directoryURL: CA directory URL (default: Let's Encrypt official one). renewBefore: Time before expiry to renew the certificate. enableHTTP01, enableTLSALPN01, enableDNS01: Challenge types to enable. domains: Domains to manage, along with their DNS provider configurations. Assuming we have saved the config in `acm.yaml`, we could use this command to update global AutoCertManager. ```bash $ egctl apply -f acm.aml ``` See more details about `AutoCertManager` in .
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: install-kusk-cli.md

To install Kusk CLI, you will need the following tools available in your system: MacOS ```sh brew install kubeshop/kusk/kusk ``` Linux ```sh curl -sSLf https://raw.githubusercontent.com/kubeshop/kusk-gateway/main/cmd/kusk/scripts/install.sh | bash ``` Windows (Chocolatey) ```sh choco source add --name=kubeshop_repo --source=https://chocolatey.kubeshop.io/chocolatey choco install kusk -y ``` :::note For other installation methods, check the . :::
Project: APISIX (Orchestration & Management / API Gateway)
File: plugin-runner.md

title: The Implementation of Plugin Runner <!-- --> Each request which runs the extern plugin will trigger an RPC to Plugin Runner over a connection on Unix socket. The data of RPC are serialized with . Therefore, the Plugin Runner needs to: handle a connection on Unix socket support Flatbuffers use the proto & generated code in https://github.com/api7/ext-plugin-proto/ APISIX will pass the path of Unix socket as an environment variable `APISIXLISTENADDRESS` to the Plugin Runner. So the runner needs to read the value and listen to that address during starting. The Plugin Runner should be able to load plugins written in the particular language. There are two kinds of RPC: PrepareConf & HTTPReqCall As people can configure the extern plugin on the side of APISIX, we need a way to sync the plugin configuration to the Plugin Runner. When there is a configuration that needs to sync to the Plugin Runner, we will send it via the PrepareConf RPC call. The Plugin Runner should be able to handle the call and store the configuration in a cache, then returns a unique conf token that represents the configuration. In the previous design, an idempotent key is sent with the configuration. This field is deprecated and the Plugin Runner can safely ignore it. Requests run plugins with particular configuration will bear a particular conf token in the RPC call, and the Plugin Runner is expected to look up actual configuration via the token. When the configuration is modified, APISIX will send a new PrepareConf to the Plugin Runner. Currently, there is no way to notify the Plugin Runner that a configuration is removed. Therefore, we introduce another environment variable `APISIXCONFEXPIRETIME` as the conf cache expire time. The Plugin Runner should be able to cache the conf slightly longer than `APISIXCONFEXPIRETIME`, and APISIX will send another PrepareConf to refresh the cache if the configuration is still existing after `APISIXCONFEXPIRE_TIME` seconds. Each request which runs the extern plugin will trigger the HTTPReqCall. The HTTPReqCall is almost a serialized version of HTTP request, plus a conf token. The Plugin Runner is expected to tell APISIX what to update by the response of HTTPReqCall RPC call. Sometimes the plugin in the Plugin Runner needs to know some information that is not part of the HTTPReqCall request, such as the request start time and the route ID in APISIX. Hence the Plugin Runner needs to reply to an `ExtraInfo` message as the response on the connection which sends the HTTPReqCall request. APISIX will read the `ExtraInfo` message and return the asked information. Currently, the information below is passed by `ExtraInfo`: variable value request body The flow of HTTPReqCall procession is: ``` APISIX sends HTTPReqCall Plugin Runner looks up the plugin configuration by the token in HTTPReqCall (optional) loop: Plugin Runner asks for ExtraInfo APISIX replies the ExtraInfo Plugin Runner replies HTTPReqCall ```
Project: 3Scale (Orchestration & Management / API Gateway)
File: management-api.md

Management API is a simple API that allows updating or retrieving the configuration currently used by the gateway. The API is available on port `8090`. This is mean to be used for debugging purposes only. Offers no authentication or synchronization between several instances. It can be exposed via `APICASTMANAGEMENTAPI` environment variable with following options: debug*: full API with access to everything status*: just the `/status` endpoints disabled*: completely disabled The default value is status. Available endpoints: `GET /config` Returns the current configuration (in JSON format by default). ```shell curl -XGET http://gateway:8090/config ``` `POST /config` and `PUT /config` Update the configuration with the JSON set in a body. ```shell curl -XPOST http://gateway:8090/config -d @example-config.json ``` See file for an example of the payload. This JSON contains the configuration of the API(s) in 3scale account, and can be downloaded from the 3scale admin portal using the URL `https://ACCOUNT-admin.3scale.net/admin/api/nginx/spec.json`] (replace `ACCOUNT` with your 3scale account name). The call should return something like: ```shell {"status":"ok","config":{"services":[...]}} ``` `DELETE /config` Deletes the current configuration. ```shell curl -XDELETE http://gateway:8090/config ``` It returns: ```shell {"status":"ok","config":null} ``` `POST /boot` Run the initialization process. Try to download new configuration. `GET /dns/cache` Returns DNS cache like: ```json {"127.0.0.1.xip.io": {"expires_in":139.0790002346,"value":{"1":{"address":"127.0.0.1","section":1,"type":1,"class":1,"name":"127.0.0.1.xip.io","ttl":250},"name":"127.0.0.1.xip.io","ttl":250}} } ``` `GET /status/ready` Returns one of following responses: ```json { "status": "error", "error": "not configured", "success": false } ``` ```json { "status": "warning", "warning": "no services", "success": true } ``` ```json { "status": "ready", "success": true } ``` `GET /status/live` Returns: ```json { "status": "live", "success": true } ``` `GET /status/info` Returns internal information about timers and workers. ```json { "timers": { "pending": 0, "running": 0 }, "worker": { "count":1, "exiting": false, "id": 0 } } ```
Project: MuleSoft (Orchestration & Management / API Gateway)
File: I18N.md

There are two levels of internationalization functionality in Mule. Level 1 Core Internationalization Support Java provides basic internationalization functions in the language and bundled libraries. Mule supports message conversion by the specified encoding in metadata and configuration files. Level 2 Message Catalog Mule supports a locale-based message catalog. When writing code, respect the following priority order: encoding in metadata (HTTP headers, Mail headers, etc.) encoding in the configuration file hard-coded default encoding or platform default encoding Conversion between string and byte stream is locale-sensitive. If you write code for byte stream conversion, carefully consider the encoding you use. The following lists typically misused APIs. Incorrect: `String#getBytes()`. Correct: Use `String#getBytes(String charsetName)` if you handle non-ASCII strings. Incorrect: `String#String(byte[] bytes)`. Correct: Use `String(byte[] bytes, String charsetName)` if you handle non-ASCII byte stream. The following constructors are not friendly to internationalization and should be avoided. `String(byte ascii[], int hibyte, int offset, int count);` `String(byte ascii[], int hibyte);` `String(byte bytes[], int offset, int length);` Incorrect: InputStreamReader#InputStreamReader(InputStream in) and Friends. Correct: Use `InputStreamReader(InputStream in, String charsetName)` if you handle non-ASCII byte stream. If you use subclasses of Reader and Writer, use a constructor with charsetName (we consider charsetName as encoding name in this context).
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: powered-by-mesos.md

title: Apache Mesos - Powered By Mesos layout: documentation See the for a list of apps built on top of Mesos, and instructions on how to use them. If you're using Mesos, please add yourself to the list above, or email user@mesos.apache.org and we'll add you!
Project: Traefik (Orchestration & Management / API Gateway)
File: file.md

title: "Traefik File Static Configuration" description: "Reference the YAML and TOML files for static configuration in Traefik Proxy. Read the technical documentation." ```yml tab="YAML" --8<-- "content/reference/static-configuration/file.yaml" ``` ```toml tab="TOML" --8<-- "content/reference/static-configuration/file.toml" ```
Project: KEDA (Orchestration & Management / Scheduling & Orchestration)
File: TESTING.md

Running tests ============= The Datadog Go API client has 2 sorts of tests: regular tests and BDD tests. Both are using recodings to store HTTP interactions, allowing to run the tests without talking to the API. We also store the test time to be able to freeze. You can control the behavior with the `RECORD` environment variable: `RECORD=false`, the default value, means replaying HTTP requests from recordings. `RECORD=true` creates or updates recordings. This will need valid credentials in `DDTESTCLIENTAPIKEY` and `DDTESTCLIENTAPPKEY`. `RECORD=none` ignores recordings. This will also runs tests that we call `integration-only`, i.e. tests that we don't record for security reasons. It also needs valid credentials. Recording and freeze files are stored in `cassettes` directory in each test package with one file per tests (e.g. `tests/api/v1/datadog/cassettes/`). To run the tests, navigate to the `tests` directory and run: ```shell go test $(go list ./...) ``` You can get more verbose information with the `-v` flag, and run a specific test with the `-run` argument. For example: ```shell go test $(go list ./...) -run TestSLOEventLifecycle -v ``` This takes a regular expression, so you don't have to specify the whole exact string. The first time you run a test that needs recordings, it will fail with: `time file 'cassettes/$TEST_NAME.freeze' not found: create one setting 'RECORD=true' or ignore it using 'RECORD=none'`. BDD tests are triggered by a parent test named `TestScenarios`. To run a specific test, you need to specify the parent feature name in the `-run` argument, to look like `TestScenarios/$VERSION/Feature$NAME/$TESTNAME`. For example: ```shell go test ./scenarios -run TestScenarios/v2/FeatureUsers/ScenarioSendinvitationemails ``` Again we don't need to pass the full test name as it's a regular expression, but we do need to pass the full prefix. To get a better output you can use `gotestsum` in place of `go test`, with the `--format` option to customize the output. For example: ```shell gotestsum --format testname ./scenarios -run TestScenarios/FeatureUsers/ScenarioSendinvitationemails ```
Project: Gloo (Orchestration & Management / API Gateway)
File: gateway-proxy-config.md

title: Envoy Bootstrap Configuration weight: 60 description: Bootstrap configuration for Envoy Envoy's can be done in two ways: 1) with a configuration file that we represent as the config map `gateway-proxy-envoy-config` and 2) with command-line arguments that we pass in to the `gateway-proxy` pod. You do not need to set either of these manually - gloo has default settings for both in its Helm chart. The Helm value that overrides our default bootstrap configuration is `gatewayProxies.$PROXY_NAME.configMap`. To see an example config map, look no further than . To see the entire list of Gloo Edge Helm Overrides, see our . The Helm value that sets additional Envoy command line arguments is `gatewayProxies.NAME.extraEnvoyArgs`. To see a list of available Envoy command line arguments, see their . {{% notice note %}} We will always set `--disable-hot-restart` regardless of any value provided to `extraEnvoyArgs`. {{% /notice %}} An example `values.yaml` file that you could pass in to configure Envoy is: ``` gatewayProxies: gatewayProxy: extraEnvoyArgs: --component-log-level upstream:debug,connection:trace ``` This sets the log levels of individual Envoy components - setting the upstream log levels to `debug` and the `connection` component's log level to `trace`.