cwielenb/CNCF-Dataset huggingface dataset:
Project: Aeraki Mesh (Orchestration & Management / Service Mesh)
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: Go to '...' Click on '....' Scroll down to '....' See error 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: Tengine (Orchestration & Management / Service Proxy)
File: ngx_http_ssl_asynchronous_mode.md

Name ==== Nginx SSL/TLS asynchronous mode Description =========== Provide information about how to enable SSL/TLS asynchronous in Nginx. SSL/TLS asynchronous mode is provided by OpenSSL 1.1.0+ version Compilation =========== Build Nginx with configuration item '--with-openssl-async' Directives =========== Syntax: ssl_async on | off; Default: ssl_async off; Context: http, server Enables SSL/TLS asynchronous mode for the given virtual server. Example ========== file: conf/nginx.conf ''' http { ssl_async on; server { ... } } } ''' OR ''' http { server { ssl_async on; } } } ''' Note ======================== To demostrate the asynchronous mode of SSL/TLS, it needs an asynchronous enabled engine support. As a reference implementation, OpenSSL 1.1.0+ version provides an 'dasync' engine which support the asynchronous working flow. 'dasync' engine will be built as a shared library 'dasync.so' in engines/ Please use below reference openssl.cnf file to enable it for RSA offloading. opensslconf = openssldef [openssl_def] engines = engine_section [engine_section] dasync = dasync_section [dasync_section] engine_id = dasync dynamic_path = /path/to/openssl/source/engines/dasync.so default_algorithms = RSA For more details information, please refer to https://www.openssl.org
Project: Traefik (Orchestration & Management / API Gateway)
File: replacepath.md

title: "Traefik ReplacePath Documentation" description: "In Traefik Proxy's HTTP middleware, ReplacePath updates paths before forwarding requests. Read the technical documentation." Updating the Path Before Forwarding the Request {: .subtitle } <!-- TODO: add schema --> Replace the path of the request URL. ```yaml tab="Docker & Swarm" labels: "traefik.http.middlewares.test-replacepath.replacepath.path=/foo" ``` ```yaml tab="Kubernetes" apiVersion: traefik.io/v1alpha1 kind: Middleware metadata: name: test-replacepath spec: replacePath: path: /foo ``` ```yaml tab="Consul Catalog" "traefik.http.middlewares.test-replacepath.replacepath.path=/foo" ``` ```yaml tab="File (YAML)" http: middlewares: test-replacepath: replacePath: path: "/foo" ``` ```toml tab="File (TOML)" [http.middlewares] [http.middlewares.test-replacepath.replacePath] path = "/foo" ``` The ReplacePath middleware will: replace the actual path with the specified one. store the original path in a `X-Replaced-Path` header. The `path` option defines the path to use as replacement in the request URL.
Project: APISIX (Orchestration & Management / API Gateway)
File: customize-nginx-configuration.md

title: Customize Nginx configuration <!-- --> The Nginx configuration used by APISIX is generated via the template file `apisix/cli/ngx_tpl.lua` and the options from `conf/config-default.yaml` / `conf/config.yaml`. You can take a look at the generated Nginx configuration in `conf/nginx.conf` after running `./bin/apisix start`. If you want to customize the Nginx configuration, please read through the `nginxconfig` in `conf/config-default.yaml`. You can override the default value in the `conf/config.yaml`. For instance, you can inject some snippets in the `conf/nginx.conf` via configuring the `xxxsnippet` entries: ```yaml ... nginx_config: mainconfigurationsnippet: | daemon on; httpconfigurationsnippet: | server { listen 45651; servername ; access_log off; location /ysec_status { reqstatusshow; allow 127.0.0.1; deny all; } } chunkedtransferencoding on; httpserverconfiguration_snippet: | set $my "var"; httpadminconfiguration_snippet: | logformat admin "$requesttime $pipe"; httpendconfiguration_snippet: | servernameshashbucketsize 128; streamconfigurationsnippet: | tcp_nodelay off; ... ``` Pay attention to the indent of `nginx_config` and sub indent of the sub entries, the incorrect indent may cause `./bin/apisix start` to fail to generate Nginx configuration in `conf/nginx.conf`.
Project: Gloo (Orchestration & Management / API Gateway)
File: buffer.proto.sk.md

title: "buffer.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> copied from https://github.com/envoyproxy/envoy/blob/3b52fc36373272902d9817f0db97dd2fccc40784/api/envoy/extensions/filters/http/buffer/v3/buffer.proto ```yaml "maxRequestBytes": .google.protobuf.UInt32Value ``` | Field | Type | Description | | -- | - | -- | | `maxRequestBytes` | | The maximum request size that the filter will buffer before the connection manager will stop buffering and return a 413 response. | ```yaml "disabled": bool "buffer": .solo.io.envoy.extensions.filters.http.buffer.v3.Buffer ``` | Field | Type | Description | | -- | - | -- | | `disabled` | `bool` | Disable the buffer filter for this particular vhost or route. Only one of `disabled` or `buffer` can be set. | | `buffer` | | Override the global configuration of the buffer filter with this new config. Note: If you have not set a global config (at the gateway level), this override will not do anything by itself. Only one of `buffer` or `disabled` can be set. | <!-- 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: APISIX (Orchestration & Management / API Gateway)
File: real-ip.md

title: real-ip keywords: Apache APISIX API Gateway Plugin Real IP description: This document contains information about the Apache APISIX real-ip Plugin. <!-- --> The `real-ip` Plugin is used to dynamically change the client's IP address and port as seen by APISIX. This is more flexible but functions similarly to Nginx's . :::info IMPORTANT This Plugin requires APISIX to run on . ::: | Name | Type | Required | Valid values | Description | |-||-|--|| | source | string | True | Any Nginx variable like `argrealip` or `httpxforwardedfor`. | Dynamically sets the client's IP address and an optional port, or the client's host name, from APISIX's view. | | trustedaddresses | array[string] | False | List of IPs or CIDR ranges. | Dynamically sets the `setrealipfrom` field. | | recursive | boolean | False | True to enable, false to disable, default is false | If recursive search is disabled, the original client address that matches one of the trusted addresses is replaced by the last address sent in the configured `source`. If recursive search is enabled, the original client address that matches one of the trusted addresses is replaced by the last non-trusted address sent in the configured `source`. | :::note If the address specified in `source` is missing or invalid, the Plugin would not change the client address. ::: The example below enables the `real-ip` Plugin on the specified Route: :::note You can fetch the `admin_key` from `config.yaml` and save to an environment variable with the following command: ```bash adminkey=$(yq '.deployment.admin.adminkey[0].key' conf/config.yaml | sed 's/"//g') ``` ::: ```shell curl -i http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "uri": "/index.html", "plugins": { "real-ip": { "source": "arg_realip", "trusted_addresses": ["127.0.0.0/24"] }, "response-rewrite": { "headers": { "remoteaddr": "$remoteaddr", "remoteport": "$remoteport" } } }, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } }' ``` After you have enabled the Plugin as mentioned above, you can test it as shown below: ```shell curl 'http://127.0.0.1:9080/index.html?realip=1.2.3.4:9080' -I ``` ```shell ... remote-addr: 1.2.3.4 remote-port: 9080 ``` To remove the `real-ip` Plugin, you can delete the corresponding JSON configuration from the Plugin configuration. APISIX will automatically reload and you do not have to restart for this to take effect. ```shell curl http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "uri": "/index.html", "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } }' ```
Project: wasmCloud (Orchestration & Management / Scheduling & Orchestration)
File: ADOPTERS.md

If you are using wasmCloud in your organization, please add your company name to this list. To add your organization as an , open a pull request that adds your organization's name. The list is in alphabetical order. Note: There are several other organizations and users that are unable to publicly share their stories but are active in the wasmCloud community. We appreciate all our users and their contributions to making wasmCloud a successful CNCF project. | Organization | Contact | Status | Description of Use | | - | - | - | - | | | | | Cosmonic is a distributed app platform built on wasmCloud for wasmCloud apps. | | | | | Developing support for service logic as customer provided Actors | | | | | Prototyping distributed rating in multi-tiers ecosystem | This file is part of the CNCF official documentation for projects.
Project: Contour (Orchestration & Management / Service Proxy)
File: httpproxy-protocol-selection.md

Status: Draft This document specifies a design for overriding annotation-based protocol selection in HTTPProxy. Allow for the HTTPProxy to encode all of the additional configuration needed to program Envoy beyond what's provided in a vanilla K8s Service. Deprecation of existing annotation-based mechanisms Today, Contour requires K8s Services to be annotated with additional protocol metadata encoded in annotations to use more than `http1`. This presents a problem for controllers looking to emit HTTPProxy resources which don't own the K8s services being targeted because it involves manipulating resources they don't control. The motivating issue (https://github.com/projectcontour/contour/issues/1962) also calls out the use of annotations as somewhat anithetical to some of the underlying motivations for HTTPProxy in the first place! Add a single new field to `Service` that encodes the protocol data that must currently be extracted from the annotation `projectcontour.io/upstream-protocol.{protocol}`. From #1962: ```yaml spec: virtualhost: fqdn: dashboard.kubernetes.com tls: secretName: kubernetes-dashboard-tls routes: conditions: prefix: / services: name: kubernetes-dashboard protocol: https # < NEW FIELD port: 443 ``` At creation the `dag.Cluster` will incorporate either the specified protocol, or fallback on the protocol of the referenced service, then the protocol selection logic in `envoy.Cluster` can simply key off of the `Protocol` field of the `dag.Cluster` instead of `c.Upstream.Protocol`. Require downstream consumers to annotate K8s Services with Contour annotations (and every other provider they might integrate with). Adopt a port-naming convention like the one defined by . Waiting for , which proposes building similar hints into the Kubernetes service itself. Realistically this is over a year away from being a viable alternative. None at this time.
Project: Docker Swarm (Orchestration & Management / Scheduling & Orchestration)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at oss-conduct@uber.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at .
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: cpp-style-guide.md

GRPC C++ STYLE GUIDE ===================== The majority of gRPC's C++ requirements are drawn from the [Google C++ style guide] (https://google.github.io/styleguide/cppguide.html). Additionally, as in C, layout rules are defined by clang-format, and all code should be passed through clang-format. A (docker-based) script to do so is included in .
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.10.1.md

We are delighted to present version 1.10.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. Upgrades the default Envoy version from 1.16.0 to 1.16.2 for security and bug fixes. See the Envoy and changelogs for details. Fixes a concurrent map access issue which could lead to Contour crashing/restarting (#3199).
Project: APISIX (Orchestration & Management / API Gateway)
File: THREAT_MODEL.md

<!-- --> Here is the threat model of Apache APISIX, which is relative to our developers and operators. As a proxy, Apache APISIX needs to be able to run in front of untrusted downstream traffic. However, some features need to assume the downstream traffic is trusted. They should be either not exposed to the internet by default (for example, listening to 127.0.0.1), or disclaim in the doc explicitly. As Apache APISIX is evolving rapidly, some newly added features may not be strong enough to defend against potential attacks. Therefore, we need to divide the features into two groups: premature and mature ones. Features that are just merged in half a year or are declared as experimental are premature. Premature features are not fully tested on the battlefield and are not covered by the security policy normally. Additionally, we require the components below are trustable: the upstream the configuration the way we relay the configuration the 3rd party components involved in the Apache APISIX, for example, the authorization server As the user: First of all, don't expose the components which are required to be trustable to the internet, including the control plane (Dashboard or something else) and the configuration relay mechanism (etcd or etcd adapter or something else). Then, harden the trusted components. For example, if possible, enable authentication or use https for the etcd read the doc and disable plugins that are not needed, so that we can reduce the attack vector restrict and audit the change of configuration As the developer: We should keep security in mind, and validate the input from the client before use. As the maintainer: We should keep security in mind, and review the code line by line. We are open to discussion from the security researchers.
Project: Envoy (Orchestration & Management / Service Proxy)
File: non--crash-security--bug.md

name: Non-{crash,security} bug about: Bugs which are not crashes (including asserts in debug builds), DoS or other security issue title: '' labels: bug,triage assignees: '' If you are reporting any crash or any potential security issue, do not open an issue in this repo. Please report the issue via emailing envoy-security@googlegroups.com where the issue will be triaged appropriately. Title: One line description Description: What issue is being seen? Describe what should be happening instead of the bug, for example: Envoy should not crash, the expected value isn't returned, etc. Repro steps: Include sample requests, environment, etc. All data and inputs required to reproduce the bug. Note: The gathers a tarball with debug logs, config and the following admin endpoints: /stats, /clusters and /server_info. Please note if there are privacy concerns, sanitize the data prior to sharing the tarball/pasting. Admin and Stats Output: Include the admin output for the following endpoints: /stats, /clusters, /routes, /server_info. For more information, refer to the Note: If there are privacy concerns, sanitize the data prior to sharing. Config: Include the config used to configure Envoy. Logs: Include the access logs and the Envoy logs. Note: If there are privacy concerns, sanitize the data prior to sharing. Call Stack: If the Envoy binary is crashing, a call stack is required. Please refer to the .
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: libprocess.md

title: Apache Mesos - Libprocess Options layout: documentation The bundled libprocess library can be controlled with the following environment variables. <table class="table table-striped"> <thead> <tr> <th width="30%"> Variable </th> <th> Explanation </th> </tr> </thead> <tr> <td> LIBPROCESS_IP </td> <td> Sets the IP address for communication to and from libprocess. </td> </tr> <tr> <td> LIBPROCESS_PORT </td> <td> Sets the port for communication to and from libprocess. </td> </tr> <tr> <td> LIBPROCESSADVERTISEIP </td> <td> If set, this provides the IP address that will be advertised to the outside world for communication to and from libprocess. This is useful, for example, for containerized tasks in which communication is bound locally to a non-public IP that will be inaccessible to the master. </td> </tr> <tr> <td> LIBPROCESSADVERTISEPORT </td> <td> If set, this provides the port that will be advertised to the outside world for communication to and from libprocess. Note that this port will not actually be bound (the local LIBPROCESS_PORT will be), so redirection to the local IP and port must be provided separately. </td> </tr> <tr> <td> LIBPROCESSREQUIREPEERADDRESSIP_MATCH </td> <td> If set, the IP address portion of the libprocess UPID in incoming messages is required to match the IP address of the socket from which the message was sent. This can be a security enhancement since it prevents unauthorized senders impersonating other libprocess actors. This check may break configurations that require setting LIBPROCESS_IP, or LIBPROCESSADVERTISEIP. Additionally, multi-homed configurations may be affected since the address on which libprocess is listening may not match the address from which libprocess connects to other actors. </td> </tr> <tr> <td> LIBPROCESSENABLEPROFILER </td> <td> To enable the profiler, this variable must be set to 1. Note that this variable will only work if Mesos has been configured with <code>--enable-perftools</code>. </td> </tr> <tr> <td> LIBPROCESSMETRICSSNAPSHOTENDPOINTRATE_LIMIT </td> <td> If set, this variable can be used to configure the rate limit applied to the /metrics/snapshot endpoint. The format is `<number of requests>/<interval duration>`. Examples: `10/1secs`, `100/10secs`, etc. </td> </tr> <tr> <td> LIBPROCESSNUMWORKER_THREADS </td> <td> If set to an integer value in the range 1 to 1024, it overrides the default setting of the number of libprocess worker threads, which is the maximum of 8 and the number of cores on the machine. </td> </tr> </table>
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: shell.md

Shell task type, used to create a shell type task and execute a series of shell scripts.When the worker executes this task, a temporary shell script is generated and executed using the linux user with the same name as the tenant. Click `Project Management -> Project Name -> Workflow Definition`, and click the `Create Workflow` button to enter the DAG editing page. Drag from the toolbar <img src="../../../../img/tasks/icons/shell.png" width="15"/> to the canvas. Please refer to `Default Task Parameters` section for default parameters. | Parameter | Description | ||--| | Script | A SHELL program developed by the user. | | User-defined parameter | It is a user-defined parameter of Shell, which will replace the content with `${variable}` in the script. | This example shows how to simulate simple tasks with just one or more simple lines of command. In this example, we will see how to print a line in a log file. This example simulates a custom parameter task. In order to reuse existing tasks more conveniently, or when faced with dynamic requirements, we will use variables to ensure the reusability of scripts.In this example, we first define the parameter "paramkey" in the custom script and set its value to "paramval".Then the echo command is declared in the "script", and the parameter "paramkey" is printed out.When we save and run the task, we will see in the log that the value "paramval" corresponding to the parameter "param_key" is printed out. The shell task type resolves whether the task log contains ```applicationxxxxxx``` to determine whether is the yarn task. If so, the corresponding application will be use to judge the running state of the current shell node. At this time, if stops the operation of the workflow, the corresponding ```application_id``` will be killed. If you want to use resource files in Shell tasks, you can upload corresponding files through the resource center and then use the resources in the Shell task. Reference: .