cwielenb/CNCF-Dataset huggingface dataset:
Project: Kuma (Orchestration & Management / Service Mesh)
File: DEVELOPER.md

Hello, and welcome! If you're thinking about contributing to Kuma's code base, you came to the right place. This document serves as guide/reference for technical contributors. The following dependencies are all necessary. Please follow the installation instructions for any tools/libraries that you may be missing. # normally included in system's clang package with some exceptions, please check with the following command: ```bash clang-format --version ``` Throughout this guide, we will use `make` to run pre-defined tasks in the . Use the following command to list out all the possible commands: ```bash make help ``` We packaged the remaining dependencies into one target: ```bash make dev/tools ``` You can install each commands individually if you prefer. ATTENTION: By default, development tools will be installed at `$HOME/.kuma-dev/bin`. Remember to include this directory into your `PATH`, e.g. by adding `export PATH=$HOME/.kuma-dev/bin:$PATH` line to the `$HOME/.bashrc` file or `$HOME/.zshrc` if using zsh. This can be overridden by setting the env var `CITOOLSDIR`, but it isn't recommended. To run all code formatting, linting and vetting tools use the target: ```bash make check ``` We use Ginkgo as our testing framework. To run the existing test suite, you have several options: For all tests, run: ```bash make test ``` And you can run tests that are specific to a part of Kuma by appending the app name as shown below: ```bash make test/kumactl ``` For even more specific tests you can specify the package you want to run tests from: ```bash make test TESTPKGLIST=<pkgPath> ``` `pkgPath` is a package list selector for example: `./pkg/xds/...` will run all tests in the `pkg/xds` subtree. There's a large set of integration tests that can be run with: ```bash make test/e2e ``` These tests are big and slow, it is recommended to read before running them. To build all the binaries run: ```bash make build ``` Like `make test`, you can append the app name to the target to build a specific binary. For example, here is how you would build the binary for only `kumactl`: ```bash make build/kumactl ``` This could help expedite your development process if you only made changes to the `kumactl` files. Execute ```bash make -j k3d/restart ``` To stop any existing Kuma K3D cluster, start a new K3D cluster, load images, deploy Kuma and Kuma counter demo. You can test development versions by first pushing to `gcr.io`: ```bash gcloud auth configure-docker make images/push DOCKER_REGISTRY=gcr.io/proj-123456 ``` then setting up `kubectl` to connect to your cluster and installing Kuma: ```bash gcloud container clusters get-credentials cluster-name kumactl install control-plane --registry=gcr.io/proj-123456 | kubectl apply -f - ```
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.24.5.md

We are delighted to present version v1.24.5 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. Update to Envoy v1.25.9. See the for more information about the content of the release. Update to Go v1.19.11. See the for more information. For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.24.5 is tested against Kubernetes 1.24 through 1.26. 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: Contour (Orchestration & Management / Service Proxy)
File: envoy-debug-log.md

The `envoy` command has a `--log-level` that can be useful for debugging. By default, it's set to `info`. To change it to `debug`, edit the `envoy` DaemonSet in the `projectcontour` namespace and replace the `--log-level info` flag with `--log-level debug`. Setting the Envoy log level to `debug` can be particilarly useful for debugging TLS connection failures.
Project: Lunar.dev (Orchestration & Management / API Gateway)
File: CONTRIBUTING.md

Welcome, fellow space explorer! We appreciate your interest in contributing to Lunar Proxy. Your contributions will help us take a giant leap towards a more reliable and secure browsing experience. Note: Before embarking on your mission, please review our . There are many ways you can contribute to Lunar Proxy. You can: To ensure a smooth journey aboard our lunar mission, please follow these guidelines: We employ a feature branch approach for development. This approach allows contributors to work on new features or bug fixes in isolated branches before merging them into the main codebase. Every feature or bug should have a corresponding GitHub issue. Before starting work on a new feature, please check if an issue exists. If not, [create ](https://github.com/TheLunarCompany/lunar-proxt/issues/new/choose) a new one to track the progress. When creating a branch for a new feature or bug fix, please use the following naming convention: ```text <username>.<issue#>-<description> ``` We have a handy script which automates the branch creation process. Feel free to use it and embark on your coding expedition: ```sh ./scripts/new_branch.sh ``` When you believe your code is ready for review and integration into the main codebase, open a pull request (PR) on GitHub. You can do this by running: ```sh gh pr create ``` We encourage you to seek early feedback, even if your code is not yet ready to be merged. In such cases, mark the pull request as a draft to indicate its work-in-progress nature. Once your PR has been reviewed and approved, and all continuous integration (CI) checks have successfully passed, it's time for the ultimate space maneuver: Squash and Merge. This operation combines all your commits into a single, coherent commit, preserving the integrity of our code history. Thank you for joining us on this cosmic journey. Together, we'll propel Lunar to new heights and conquer the challenges that lie ahead. Happy coding, and may the lunar light guide your way!
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: how_to_use_task_topology_plugin.md

Refer to to install volcano. After installed, update the scheduler configuration: ```shell kubectl edit configmap -n volcano-system volcano-scheduler-configmap ``` Register `task-topology` plugin in configmap ```yaml kind: ConfigMap apiVersion: v1 metadata: name: volcano-scheduler-configmap namespace: volcano-system data: volcano-scheduler.conf: | actions: "enqueue, allocate, backfill" tiers: plugins: name: priority name: gang name: conformance plugins: name: drf name: predicates name: task-topology arguments: task-topology.weight: 10 name: proportion name: nodeorder name: binpack ``` Take tensorflow job as sample. Refer to to install kubeflow, tf-operator included. add annotations in volcano job or tensorflow job in format below. `affinity` annotation indicates that tasks have connections between each other, so they should be set on same nodes; `anti-affinity` annotation indicates that tasks do not have connections between each other, so they should be set on different nodes; `task-order` annotation indicates the order that tasks should be allocated. For example, `ps,worker` means scheduler should schedule `ps` tasks first. After all `ps` tasks were allocated, scheduler started to schedule `worker` tasks. This annotation is not a required field. ```yaml volcano.sh/task-topology-affinity: "ps,worker;ps,evaluator" volcano.sh/task-topology-anti-affinity: "ps;worker,chief;chief,evaluator" volcano.sh/task-topology-task-order: "ps,worker,chief,evaluator" ```
Project: KEDA (Orchestration & Management / Scheduling & Orchestration)
File: CHANGES.md

auth/oauth2adapt:* Bump x/net to v0.24.0 () auth/oauth2adapt:* Adapt Token Types to be translated () (), refs auth/oauth2adapt:* Add helpers for working with credentials types () () auth/oauth2adapt:* Update protobuf dep to v1.33.0 () auth/oauth2adapt:* Adds a new module to translate types () () auth/oauth2adapt:* Fixup deps for release () () auth/oauth2adapt:* Update golang.org/x/net to v0.17.0 ()
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: filesystem-shared.md

title: Apache Mesos - Shared Filesystem Isolator in Mesos Containerizer layout: documentation This document describes the `filesystem/shared` isolator. You can turn on this isolator by specifying the `--isolation` agent flag (i.e., `--isolation=filesystem/shared,...`). NOTE: This isolator has been deprecated in favor of using `filesytem/linux` isolator. The `filesystem/shared` isolator can optionally be used on Linux hosts to enable modifications to each container's view of the shared filesystem. The modifications are specified in the ContainerInfo included in the ExecutorInfo, either by a framework or by using the `--defaultcontainerinfo` agent flag. ContainerInfo specifies Volumes which map parts of the shared filesystem (host\_path) into the container's view of the filesystem (container\path), as read-write or read-only. The host\path can be absolute, in which case it will make the filesystem subtree rooted at host\path also accessible under container\path for each container. If host\_path is relative then it is considered as a directory relative to the executor's work directory. The directory will be created and permissions copied from the corresponding directory (which must exist) in the shared filesystem. The primary use-case for this isolator is to selectively make parts of the shared filesystem private to each container. For example, a private "/tmp" directory can be achieved with `host_path="tmp"` and `container_path="/tmp"` which will create a directory "tmp" inside the executor's work directory (mode 1777) and simultaneously mount it as /tmp inside the container. This is transparent to processes running inside the container. Containers will not be able to see the host's /tmp or any other container's /tmp.
Project: APISIX (Orchestration & Management / API Gateway)
File: server-info.md

title: server-info keywords: Apache APISIX API Gateway Plugin Server info server-info description: This document contains information about the Apache APISIX server-info Plugin. <!-- --> The `server-info` Plugin periodically reports basic server information to etcd. The information reported by the Plugin is explained below: | Name | Type | Description | |--||| | boot_time | integer | Bootstrap time (UNIX timestamp) of the APISIX instance. Resets when hot updating but not when APISIX is just reloaded. | | id | string | APISIX instance ID. | | etcd_version | string | Version of the etcd cluster used by APISIX. Will be `unknown` if the network to etcd is partitioned. | | version | string | Version of APISIX instance. | | hostname | string | Hostname of the machine/pod APISIX is deployed to. | None. This Plugin exposes the endpoint `/v1/server_info` to the Add `server-info` to the Plugin list in your configuration file (`conf/config.yaml`): ```yaml title="conf/config.yaml" plugins: ... server-info ``` We can change the report configurations in the `plugin_attr` section of `conf/config.yaml`. The following configurations of the server info report can be customized: | Name | Type | Default | Description | | | | -- | -- | | report_ttl | integer | 36 | Time in seconds after which the report is deleted from etcd (maximum: 86400, minimum: 3). | To customize, you can modify the `plugin_attr` attribute in your configuration file (`conf/config.yaml`): ```yaml title="conf/config.yaml" plugin_attr: server-info: report_ttl: 60 ``` After you enable the Plugin as mentioned above, you can access the server info report through the Control API: ```shell curl http://127.0.0.1:9090/v1/server_info -s | jq . ``` ```json { "etcd_version": "3.5.0", "id": "b7ce1c5c-b1aa-4df7-888a-cbe403f3e948", "hostname": "fedora32", "version": "2.1", "boot_time": 1608522102 } ``` :::tip You can also view the server info report through the . ::: To remove the Plugin, you can remove `server-info` from the list of Plugins in your configuration file: ```yaml title="conf/config.yaml" plugins: ... ```
Project: Skipper (Orchestration & Management / Service Proxy)
File: eskip-file.md

Eskip file dataclient can be used to serve static defined routes, read from an eskip file. The shows your route definitions in a clear way: ```sh % cat example.eskip hello: Path("/hello") -> "https://www.example.org" ``` The has two binaries, one is `skipper`, the other is `eskip`. can be used to validate the syntax of your routes file before reloading a production server: % eskip check example.eskip To run Skipper serving routes from an `eskip` file you have to use `-routes-file <file>` parameter: % skipper -routes-file example.eskip A more complicated example with different routes, matches, and shows that you can name your route and use preconditions and create, change, delete HTTP headers as you like: ```sh % cat complicated_example.eskip hostHeaderMatch: Host("^skipper.teapot.org$") -> setRequestHeader("Authorization", "Basic YWRtaW46YWRtaW5zcGFzc3dvcmQK") -> "https://target-to.auth-with.basic-auth.enterprise.com"; baiduPathMatch: Path("/baidu") -> setRequestHeader("Host", "www.baidu.com") -> setPath("/s") -> setQuery("wd", "godoc skipper") -> "http://www.baidu.com"; googleWildcardMatch: -> setPath("/search") -> setQuery("q", "godoc skipper") -> "https://www.google.com"; yandexWildacardIfCookie: && Cookie("yandex", "true") -> setPath("/search/") -> setQuery("text", "godoc skipper") -> tee("http://127.0.0.1:12345/") -> "https://yandex.ru"; ``` The former example shows 4 routes: hostHeaderMatch, baiduPathMatch, googleWildcardMatch and yandexWildcardIfCookie. hostHeaderMatch: used if HTTP host header is exactly: "skipper.teapot.org", sets a Basic Authorization header and sends the modified request to https://target-to.auth-with.basic-auth.enterprise.com baiduPathMatch: used in case the request patch matches /baidu it will set the Host header to the proxy request it will set the path from /baidu to /s it will set the querystring to "ws=godoc skipper" and sends the modified request to http://baidu.com googleWildcardMatch: used as default if no other route matches it will set the path to /search it will set the querystring to "q=godoc skipper" and sends the modified request to https://www.google.com yandexWildcardIfCookie: used as default if a Cookie named "yandex" has the value "true" it will set the path to /search/ it will set the querystring to "text=godoc skipper" it will send a copy of the modified request to http://127.0.0.1:12345/ (similar to unix `tee`) and drop the response and sends the modified request to https://yandex.ru More examples you find in description, in and in . Eskip file format is also used if you print your current routes in skipper, for example: ```sh % curl localhost:9911/routes -> setResponseHeader("Content-Type", "application/json; charset=utf-8") -> inlineContent("{\"foo\": 3}") -> <shunt> ```
Project: Armada (Orchestration & Management / Scheduling & Orchestration)
File: etcd-localdev.md

When developing or testing Armada in the Localdev setup, it's sometimes helpful to directly query the etcd database to gather various statistics. However, by default, the `kind` tool (for running Kubernetes clusters inside a local Docker side) does not expose the etcd interface for direct querying. The following steps give a solution for querying an etcd instance running inside of `kind`. First, verify the running nodes and podes. ```bash $ kubectl get nodes -A NAME STATUS ROLES AGE VERSION armada-test-control-plane Ready control-plane 78m v1.24.7 armada-test-worker Ready <none> 77m v1.24.7 $ kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE ingress-nginx ingress-nginx-admission-create-9xnpn 0/1 Completed 0 78m ingress-nginx ingress-nginx-admission-patch-phkgm 0/1 Completed 1 78m ingress-nginx ingress-nginx-controller-646df5f698-zbgqz 1/1 Running 0 78m kube-system coredns-6d4b75cb6d-9z87w 1/1 Running 0 79m kube-system coredns-6d4b75cb6d-flz4r 1/1 Running 0 79m kube-system etcd-armada-test-control-plane 1/1 Running 0 79m kube-system kindnet-nx952 1/1 Running 0 79m kube-system kindnet-rtqkc 1/1 Running 0 79m kube-system kube-apiserver-armada-test-control-plane 1/1 Running 0 79m kube-system kube-controller-manager-armada-test-control-plane 1/1 Running 0 79m kube-system kube-proxy-cwl2r 1/1 Running 0 79m kube-system kube-proxy-wjqft 1/1 Running 0 79m kube-system kube-scheduler-armada-test-control-plane 1/1 Running 0 79m local-path-storage local-path-provisioner-6b84c5c67f-22m8m 1/1 Running 0 79m ``` You should see an etcd control plane pod in the list of pods. Copy the etcdclient deployment YAML into the cluster control plane node: ```bash $ docker cp developer/config/etcdclient.yaml armada-test-control-plane:/ ``` Then, open a shell in the control plane node: ```bash $ docker exec -it -u 0 --privileged armada-test-control-plane /bin/bash ``` In the container shell, move the deployment YAML file to the Kubernetes deployments source directory. Kubernetes (Kind) will notice the file's appearance and will deploy the new pod. ```bash root@armada-test-control-plane:/# mv etcdclient.yaml /etc/kubernetes/manifests/ root@armada-test-control-plane:/# exit $ kubectl get pods -A ``` You should see an etcdclient pod running. Open a shell in the new etcdclient utility pod, and start using `etcdctl` to query etcd. ```bash $ kubectl exec -n kube-system -it etcdclient-armada-test-control-plane -- sh / # etcdctl endpoint status -w table +-++++--+--++ | ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | RAFT TERM | RAFT INDEX | +-++++--+--++ | https://172.19.0.2:2379 | d7380397c3ec4b90 | 3.5.3 | 3.9 MB | true | 2 | 16727 | +-++++--+--++ / # / # exit ``` At this point, you can use `etcdctl` to query etcd for key-value pairs, get the health and/or metrics of the etcd server. https://mauilion.dev/posts/etcdclient/
Project: Nacos (Orchestration & Management / Coordination & Service Discovery)
File: bug-report.md

name: Bug report about: Create a report to help us improve title: '' labels: '' assignees: '' <!-- Here is for bug reports and feature requests ONLY! If you're looking for help, please check our mail listWeChat group and the Gitter room. Please try to use English to describe your issue, or at least provide a snippet of English translation. --> Describe the bug A clear and concise description of what the bug is. Expected behavior A clear and concise description of what you expected to happen. Actually behavior A clear and concise description of what you actually to happen. How to Reproduce Steps to reproduce the behavior: Go to '...' Click on '....' Scroll down to '....' See errors Desktop (please complete the following information): OS: [e.g. Centos] Version [e.g. nacos-server 1.3.1, nacos-client 1.3.1] Module [e.g. naming/config] SDK [e.g. original, spring-cloud-alibaba-nacos, dubbo] Additional context Add any other context about the problem here.
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: resourceinterpreter_test.md

| Test Case | E2E Describe Text | Comments | |--|--|| | Test InterpreterOperation InterpretReplica | InterpretReplica testing | | | Test InterpreterOperation Retain when construct two values that need to be changed, and only one value is retained | Retain testing | | | Test InterpreterOperation ReviseReplica | ReviseReplica testing | | | Test InterpreterOperation AggregateStatus whether the workload status can be correctly collected | AggregateStatus testing | | | Test InterpreterOperation InterpretStatus | InterpretStatus testing | | | Test InterpreterOperation InterpretHealth whether the health status can be correctly collected | InterpretHealth testing | | | Test InterpreterOperation InterpretDependency whether the workload's dependency can be interpreted | InterpretDependency testing | | | Test InterpreterOperation InterpretDependency whether will update/delete the dependency cr correctly | Dependency cr propagation testing | | | Test Case | E2E Describe Text | Comments | |--|-|-| | Test InterpreterOperation InterpretReplica with Lua scripts | InterpretReplica testing | | | Test InterpreterOperation ReviseReplica with Lua scripts | ReviseReplica testing | | | Test InterpreterOperation Retain when construct by Lua scripts two values that need to be changed, and only one value is retained | Retain testing | | | Test InterpreterOperation AggregateStatus whether the workload status can be correctly collected | AggregateStatus testing | | | Test InterpreterOperation InterpretStatus with Lua scripts | InterpretStatus testing | | | Test InterpreterOperation InterpretHealth whether the health status can be correctly collected | InterpretHealth testing | | | Test InterpreterOperation InterpretDependency whether will create the dependency cr correctly | DependencyInterpretation testing | |
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: install.md

Kusk CLI is available for macOS, Linux and Windows. The Kusk CLI is used to configure Kusk Gateway, the Ingress Controller for Kubernetes. System requirements: :::note If you are missing an installation method you'd like us to support, please and we will try to address it right away! ::: Using `brew`: ```sh brew install kubeshop/kusk/kusk ``` Using install script: ```sh curl -sSLf https://raw.githubusercontent.com/kubeshop/kusk-gateway/main/cmd/kusk/scripts/install.sh | bash ``` Using install script: ```sh curl -sSLf https://raw.githubusercontent.com/kubeshop/kusk-gateway/main/cmd/kusk/scripts/install.sh | bash ``` Using APT (Debian/Ubuntu): ```sh wget -qO - https://repo.kubeshop.io/key.pub | sudo apt-key add - echo "deb https://repo.kubeshop.io/kusk linux main" | sudo tee -a /etc/apt/sources.list sudo apt-get update sudo apt-get install -y kusk ``` ```sh choco source add --name=kubeshop_repo --source=https://chocolatey.kubeshop.io/chocolatey choco install kusk -y ``` For other ways of installation, you can download the or use the following command ( needed): ```sh go install -x github.com/kubeshop/kusk-gateway/cmd/kusk@latest ```