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

You can install Grafana in various ways, like using the [Grafana official Helm chart](https://github.com/grafana/helm-charts/tree/main/charts/grafana), or the . Hosted solutions are also available, like [Grafana Cloud](https://grafana.com/products/cloud/). The file `grafana/values.yaml` provides a default Helm config for the [Grafana official Helm chart](https://github.com/grafana/helm-charts/tree/main/charts/grafana), which pulls the Linkerd dashboards published at <https://grafana.com/orgs/linkerd/dashboards>. You can install the chart like this: ```shell helm repo add grafana https://grafana.github.io/helm-charts helm install grafana -n grafana --create-namespace grafana/grafana \ -f https://raw.githubusercontent.com/linkerd/linkerd2/main/grafana/values.yaml ``` Please make sure to update the entries in `grafana/values.yaml` before using the file; in particular: auth and log settings under `grafana.ini` `datasources.datasources.yaml.datasources[0].url` should point to your Prometheus service The other installation methods can easily import those same dashboards using their IDs, as listed in `grafana/values.yaml`. In order to have the Linkerd Viz Dashboard show the Grafana icon there where relevant, and have it link to the appropriate Grafana dashboard, make sure you have a proper location set up in the `grafana.url` setting in Linkerd Viz's `values.yaml`. As of linkerd `stable-2.13.0` (or `edge-23.1.1`), the access to Linkerd Viz' Prometheus instance has been restricted through the `prometheus-admin` AuthorizationPolicy, granting access only to the `metrics-api` ServiceAccount. In order to grant access to Grafana, you need to add an AuthorizationPolicy pointing to its ServiceAccount. You can apply which grants permission for the `grafana` ServiceAccount. The `grafana/dashboards` directory contains the same dashboard definitions published under <https://grafana.com/orgs/linkerd>. Please keep them in sync when making any changes. After logging into grafana.com (using the linkerd account), the dashboards can be managed under Org Settings -> My Dashboards.
Project: Tengine (Orchestration & Management / Service Proxy)
File: ngx_http_core_module.md

ngx\_http\_core\_module Tengine added some enhancements to this module. The new directives are listed below. Syntax: client\_body\_buffers `number size` Default: 16 4k/8k Context: `http, server, location` Specify the number and size of buffers used when reading non buffered client request body, all the buffers are stored in the memory. Buffers are allocated only on demand. By default, the buffer size is equal to your OS's pagesize. The total buffer size should be larger than `clientbodypostpone_size`, otherwise, it will be enlarged by force. Syntax: client\_body\_postpone\_size `size` Default: 64k Context: `http, server, location` When you turn off the `proxyrequestbuffering` or `fastcgirequestbuffering`, Tengine will send the body to backend either it receives more than `size` data or the whole request body has been received. It can save the connection and reduce the network system call number with backend. Syntax: proxy\_request\_buffering `on | off` Default: `on` Context: `http, server, location` Specify the request body will be buffered to the disk or not. If it's off, the request body will be stored in the memory and sent to backend after Tengine receives more than `clientbodypostpone_size` data. It can avoid the disk IO with large request body. By default in the buffered mode, the whole request body larger than the `clientbodybuffer_size` will always be saved into the disk. This behavior may increase the server load greatly with heavy upload application. Note that, if you turn it off, the nginx retry mechanism with unsuccessful response will be broken after you sent part of the request to backend. It just returns 500 directly when it encounters an unsuccessful response. This directive also breaks these variables: $requestbody, $requestbody_file. You should not use them any more while their values are incomplete. Also note that, enabling spdy will prevent `proxyrequestbuffering off` from taking effect. Syntax: fastcgi\_request\_buffering `on | off` Default: `on` Context: `http, server, location` The same as `proxyrequestbuffering`. Syntax: gzip\_clear\_etag `on | off` Default: `on` Context: `http, server, location` Determines whether gzip module should clear the ETag response header field.
Project: BFE (Orchestration & Management / Service Proxy)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: '' assignees: '' Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior. Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here.
Project: Service Mesh Performance (Orchestration & Management / Service Mesh)
File: unsubscribed.md

layout: post description: "Service Mesh Performance (SMP): Measure your service mesh performance using SMP. SMP provides a universal performance index to gauge your meshs efficiency against deployments in other organizations environments." author: Newsletter twitter: smp_spec lang: en image: path: /assets/img/logo/smp.png width: 1500 <h2 style="text-align:center;">Unsubscription successful.</h2> <p style="text-align:center;">You have been unsubscribed from the Service Mesh Performance newsletter.</p> <br /> <br /> <hr /> <div style="display:flex;align-items:center;justify-content:center;"> <img src="/assets/img/visual-topology.svg" width="20%" /> <div style="text-align:center;justify-content:center;"> <h3 style="width:100%;margin-left:1.5rem;"><a href="https://layer5.io/learn/service-mesh-labs">Learn to Service Mesh with Interactive Labs</a></h3> <input type="button" class="btn-primary" style="margin-top:1.5rem" onclick="location.href='https://layer5.io/learn/service-mesh-labs';" value="Let's Learn" /> </div> </div>
Project: Xline (Orchestration & Management / Coordination & Service Discovery)
File: USAGE.md

The Xline configuration file is written in toml format and the default path is /etc/xlineserver.conf. If you need to change the path of the configuration file, you can set it via the environment variable XLINESERVER_CONFIG. The configuration file has four sections, as follows: cluster section: contains information about curp cluster, including basic information, cluster member configuration, curp server timeout settings (optional), curp client timeout settings (optional). log section: contains the Xline log-related configuration, where path is required, rotation (optional, default value is 'daily'), level (optional, default value is 'info') trace section: contains the jaeger's trace mode (online or offline), trace level and the log directory in offline mode auth section: contains the address of the key pair required for authentication A minimum config file looks like: ```toml [cluster] name = 'node1' # server identity is_leader = true # leader flag which indicates that the current server [cluster.members] node1 = '127.0.0.1:2379' # the server name and its address node2 = '127.0.0.1:2380' node3 = '127.0.0.1:2381' [log] path = '/var/log/xline' [trace] jaeger_online = false # jaeger tracing online pattern jaeger_offline = false # jaeger tracing offline pattern jaegeroutputdir = 'var/log/xline/jaeger_jsons' jaeger_level = 'info' # tracing log level [auth] authpublickey = '/etc/xline/public_key.pem' authprivatekey = '/etc/xline/private_key.pem' ``` For tuning and development purpose, the cluster section provides two subsections, curpcfg, and clientconfig, with the following definitions and default values. ```toml [cluster.curp_config] heartbeat_interval = '300ms' # the curp heartbeat(tick) interval of which default value is 300ms waitsyncedtimeout = '5s' # server wait synced timeout rpc_timeout = '50ms' # the rpc timeout of which default value is 50ms retry_timeout = '50ms' # the rpc retry interval of which default value is 50ms followertimeoutticks = 5 # if a follower cannot receive heartbeats from a leader during candidatetimeoutticks = 2 # if a candidate cannot win an election, it will retry election [cluster.client_config] propose_timeout = '1s' # client propose timeout waitsyncedtimeout = '2s' # client wait synced timeout retry_timeout = '50ms' # the rpc retry interval, of which the default is 50ms ``` Download binary from page. Use the following command to start cluster: ```bash ./xline --name node1 --members node1=127.0.0.1:2379,node2=127.0.0.1:2380,node3=127.0.0.1:2381 --is-leader ./xline --name node2 --members node1=127.0.0.1:2379,node2=127.0.0.1:2380,node3=127.0.0.1:2381 ./xline --name node3 --members node1=127.0.0.1:2379,node2=127.0.0.1:2380,node3=127.0.0.1:2381 ``` Download or build `etcdctl` from project. Use `etcdctl` to operate the cluster: ```bash etcdctl --endpoints=http://127.0.0.1:2379 put foo bar etcdctl --endpoints=http://127.0.0.1:2379 get foo ```
Project: Pipy (Orchestration & Management / Service Proxy)
File: HACKING.md

MODIFYING OPENSSL SOURCE ======================== This document describes the way to add custom modifications to OpenSSL sources. If you are adding new public functions to the custom library build, you need to either add a prototype in one of the existing OpenSSL header files; or provide a new header file and edit to pick up that file. After that, perform the following steps: ./Configure -Werror --strict-warnings [your-options] make update make make test `make update` ensures that your functions declarations are added to `util/libcrypto.num` or `util/libssl.num`. If you plan to submit the changes you made to OpenSSL (see ), it's worth running: make doc-nits after running `make update` to ensure that documentation has correct format. `make update` also generates files related to OIDs (in the `crypto/objects/` folder) and errors. If a merge error occurs in one of these generated files, then the generated files need to be removed and regenerated using `make update`. To aid in this process, the generated files can be committed separately so they can be removed easily.
Project: Open Service Mesh (Orchestration & Management / Service Mesh)
File: release_pull_request_template.md

<!-- Use the checklist below to ensure your release PR is complete before marking it ready for review. --> `needs-cherry-pick-vX.Y.Z` [ ] I have made all of the following version and patch updates: Updated the container image tag in charts/osm/values.yaml Updated the chart and app version in charts/osm/Chart.yaml Updated the image tags used in the automated demo Regenerated the Helm chart README.md [ ] I have checked that the base branch for this PR is correct as defined by the release guide <!-- If this PR is for updating the release branch, ensure the base branch is `release-vX.Y`. If this PR is for making changes on the main branch, ensure the base branch is `main`. --> Is this a release candidate?
Project: Armada (Orchestration & Management / Scheduling & Orchestration)
File: auth.md

Kubernetes native authentication defines a flow where the Armada Executor cluster's in-built token handling is used to authenticate the Executor requesting jobs from the Armada Server. The Executor requests a temporary Service Account Token from its own cluster's Kubernetes API using TokenRequest The Executor sends this Token to the Server in an Authorization Header. The Server decodes the token to read the KID (Kubernetes Key ID). The Server swaps for the Callback URL of the executor's API server. The KID to URL mapping is stored in a prior generated ConfigMap or Secret. The Server uses the URL to call the Executor Cluster's TokenReview endpoint. On successful review the Server caches the Token for its lifetime, on unsuccessful review the Token is cached for a configuration defined time. The Armada Server must have a ConfigMap in its namespace with the following format for entries: ```yaml data: "<CLUSTERKID>": "<EXECUTORCLUSTERCALLBACKURL>" ... ``` This ConfigMap may be mounted anywhere on the Server's Pod. Three things need to be configured in the Server Config: The location of the KID-mapping config map mounted on the Pod The retry timeout for failed Tokens The full service account name in the permissionGroupMapping Example Config: ```yaml applicationConfig: auth: kubernetesAuth: kidMappingFileLocation: "/kid-mapping/" invalidTokenExpiry: 60 permissionGroupMapping: execute_jobs: ["system:serviceaccount:armada:armada-executor"] ``` For the Executor authentication you will need to specify: The desired token Expiry The Executor's Namespace and ServiceAccount Example Config: ```yaml applicationConfig: kubernetesNativeAuth: expiry: 3600 namespace: "armada" serviceAccount: "armada-executor" ```
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: feature_request_cpp.md

name: Request a gRPC C++ feature about: Suggest an idea for this project labels: kind/enhancement, priority/P2, lang/c++, 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) --> A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] A clear and concise description of what you want to happen. A clear and concise description of any alternative solutions or features you've considered. Add any other context about the feature request here.
Project: Open Service Mesh (Orchestration & Management / Service Mesh)
File: improvement---feature-request.md

name: Improvement / Feature Request about: Suggest an enhancement for the OSM project title: '' labels: improvement / feature request assignees: '' Please describe the Improvement and/or Feature Request <!-- A clear and concise description of the proposal. --> Scope (please mark with X where applicable) New Functionality [ ] Install [ ] SMI Traffic Access Policy [ ] SMI Traffic Specs Policy [ ] SMI Traffic Split Policy [ ] Permissive Traffic Policy [ ] Ingress [ ] Egress [ ] Envoy Control Plane [ ] CLI Tool [ ] Metrics [ ] Certificate Management [ ] Sidecar Injection [ ] Logging [ ] Debugging [ ] Tests [ ] CI System [ ] Demo [ ] Project Release [ ] Possible use cases <!-- A clear and concise description of possible use cases for this proposal. -->
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: install-kusk-gateway.md

Kusk Gateway can be installed in the Kubernetes cluster using Kusk CLI, which was installed in the first step. This will install Kusk's Ingress Controller and additional components to run Kusk in your cluster. ```sh kusk cluster install ``` ```sh title="Expected output:" Installing Kusk in your cluster Installing Kusk Gateway Installing Envoyfleet Installing API Server Installing Dashboard Installation complete Access the dashboard by using the following command kusk dashboard Deploy your first API kusk deploy -i <path or url to your api definition> Access Help and useful examples to help get you started kusk --help ```
Project: BFE (Orchestration & Management / Service Proxy)
File: ABOUT.md

BFE is an open-source layer 7 load balancer from Baidu. The BFE documentation is composed of a few major sections: Introduction*: This section covers a general overview of what BFE is, an architecture overview, etc. Getting started*: Quickly get started with BFE. Installation*: How to build/install BFE. Configuration*: Detailed configuration instructions for BFE. Operations*: General information on how to operate BFE. How to contribute*: Information on how to contribute to BFE project. FAQ*: Answers to frequently ask question. Monitor reference*: metrics detailed reference. Condition reference*: Condition detailed reference. If you cant find what you are looking for, or have an issue not covered here, wed love to hear from you on .
Project: Traefik (Orchestration & Management / API Gateway)
File: submitting-issues.md

title: "Traefik Submitting Issues Documentation" description: "Help us help you! Learn how to submit an issue, following the guidelines, so the Traefik Proxy team can help. Read the technical documentation." Help Us Help You! {: .subtitle } Issues are perfect for requesting a feature/enhancement or reporting a suspected bug. We use the to keep track of issues in Traefik. The process of sorting and checking the issues is a daunting task, and requires a lot of work. To help maintainers (and other community members) quickly and effortlessly understand what you need, be sure to follow the guidelines below. !!! important "Getting Help Vs Reporting an Issue" The issue tracker is not a general support forum, but a place to report bugs and asks for new features. For end-user related support questions, try using the ](https://community.traefik.io/) The title must be short and descriptive. (~60 characters) Examples: Bug: Duplicate requests in access logs Feature: Support TCP Traefik is an open source project and aims to be the best edge router possible. Remember when asking for new features that these must be useful to the majority (and not only useful in edge case scenarios, or hack-like setups). Follow the as much as possible. Do your best to explain what you're looking for, and why it would improve Traefik for everyone. Be detailed and share the use-case(s) to allow us to see the value of your feature request as quickly as possible. Features with a lot of positive interaction (claps, +1s, conversation about how this would impact them) indicate higher community interest and help us to prioritize. If you are interested in creating a PR for your feature request, let us know in the issue, so we can work with you. It can take a lot of work to make sure a PR can integrate with our existing code and planning with the team ahead of time can make sure that your PR can be accepted and merged quickly. Follow the as much as possible. Explain the conditions in which you encountered the issue; what is your context? Share any logs you may have, and make sure to share the steps it takes to reproduce your issue or bug. Remain as clear and concise as possible. Take time to polish the format of your message, so we'll enjoy reading it and working on it. Help your readers focus on what matters and help them understand the structure of your message (see the ). Every maintainer / Traefik user is not a native English speaker, so if you sometimes feel that some messages sound rude, remember that it probably is a language barrier problem from someone willing to help you.
Project: Gloo (Orchestration & Management / API Gateway)
File: regex.proto.sk.md

title: "regex.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> A regex matcher designed for safety when used with untrusted input. ```yaml "googleRe2": .xds.type.matcher.v3.RegexMatcher.GoogleRE2 "regex": string ``` | Field | Type | Description | | -- | - | -- | | `googleRe2` | | Google's RE2 regex engine. | | `regex` | `string` | The regex match string. The string must be supported by the configured engine. | Google's `RE2 <https://github.com/google/re2>`_ regex engine. The regex string must adhere to the documented `syntax <https://github.com/google/re2/wiki/Syntax>`_. The engine is designed to complete execution in linear time as well as limit the amount of memory used. Envoy supports program size checking via runtime. The runtime keys `re2.maxprogramsize.errorlevel` and `re2.maxprogramsize.warnlevel` can be set to integers as the maximum program size or complexity that a compiled regex can have before an exception is thrown or a warning is logged, respectively. `re2.maxprogramsize.error_level` defaults to 100, and `re2.maxprogramsize.warn_level` has no default if unset (will not check/log a warning). Envoy emits two stats for tracking the program size of regexes: the histogram `re2.program_size`, which records the program size, and the counter `re2.exceededwarnlevel`, which is incremented each time the program size exceeds the warn level threshold. ```yaml ``` | Field | Type | Description | | -- | - | -- | <!-- 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: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: task-minavailable.md

@; Nov 19th, 2020 As mentioned, Volcano should support set minAvailable in task level. Before talking about the specific implementation, l will first describe the purpose of `MinAvailable` field: Currently `MinAvailable` field only supported at job level. `MinAvailable` decides whether a vcjob can be scheduled during gang scheduling. If sumof(valid tasks) >= job.minavailable, we take this job as valid(can be scheduled). `MinAvailable` decides the final status of the vcjob. E.g. If the number of successful tasks in a finished job >= job.minavailable, we set the status of this job as `Completed`, or we set it as `Failed`. So if we want to support minAvailable for task level, I think the changes involved in this feature are as follows: We need to define `minAvailable` field at the task level & verify/set the default value in the webhook. The new field is as follows ``` // TaskSpec specifies the task specification of Job. type TaskSpec struct { ... // The minimal available pods to run for this Task // Defaults to the task replicas // +optional MinAvailable *int32 `json:"minAvailable,omitempty" protobuf:"bytes,2,opt,name=minAvailable"` } ``` Since the scheduler does not aware jobs, it schedules based on `PodGroup`, we need to add a field to the `PodGroup` to describe the minMember corresponding to different tasks. The new field is as follows ``` // PodGroupSpec represents the template of a pod group. type PodGroupSpec struct { ... // MinTaskMember defines the minimal number of pods to run each task in the pod group; // if there's not enough resources to start each task, the scheduler // will not start anyone. MinTaskMember map[string]int32 } ``` Add a new judgment logic to the current gang scheduling. The current logic is if sumof(valid tasks) >= job.minavailable, we take this job as valid(can be scheduled). We need to add a logic before that. The logic is that if the `minAvailable` field of the task is set, the task under current job must meet the conditions of (valid pod of the task) >= job.task.minAvailable, then we can take the job as valid. Modify the judgment of job status. The current logic is that if the sumof(successful pods) >= job.minAvailable, then we can take the status of the job as `Completed`. This change may need another field in `JobStatus` to record the status of the pods under each task, currently `JobStatus` only records the number of pods in different states which we cannot distinguish which task pod belongs to. The newly added fields are as follows ``` // TaskState contains details for the current state of the task. type TaskState struct { // The phase of Task. // +optional Phase map[v1.PodPhase]int32 `json:"phase,omitempty" protobuf:"bytes,11,opt,name=phase"` } // JobStatus represents the current status of a Job. type JobStatus struct { ... // The status of pods for each task // +optional TaskStatusCount map[string]TaskState `json:"taskStatusCount,omitempty" protobuf:"bytes,21,opt,name=taskStatusCount"` } ```