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

title: "glooctl create upstream consul" weight: 5 Create a Consul Upstream Consul Upstreams represent a collection of endpoints for Services registered with Consul. Typically, Gloo will automatically discover these upstreams, meaning you don't have to create them. However, if upstream discovery in Gloo is disabled, or ACL permissions have not been granted to Gloo to read from the registry, Consul services can be added to Gloo manually via the CLI. ``` glooctl create upstream consul [flags] ``` ``` --consul-service string name of the service in the consul registry --consul-service-tags strings comma-separated list of tags for choosing a subset of the service in the consul registry -h, --help help for consul --service-spec-type string if set, Gloo supports additional routing features to upstreams with a service spec. The service spec defines a set of features ``` ``` -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 --dry-run print kubernetes-formatted yaml rather than creating or updating a resource -i, --interactive use interactive mode --kube-context string kube context to use when interacting with kubernetes --kubeconfig string kubeconfig to use, if not standard one --name string name of the resource to read or write -n, --namespace string namespace for reading or writing resources (default "gloo-system") -o, --output OutputType output format: (yaml, json, table, kube-yaml, wide) (default table) --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - Create an Upstream
Project: Open Cluster Management (Orchestration & Management / Scheduling & Orchestration)
File: CHANGELOG-v0.5.md

N/C Add delete option in work api. ( ) Add `prioritizerConfigs` in placement api. ( ) Add `nodeSelector` and `tolerations` in the operator api. ( ) add clusterset v1beta1. ( ) N/C Fix capitalized name/namespace. ( ) Deprecate clusterset v1alpha1. ( )
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: dinky.md

Use `Dinky Task` to create a dinky-type task and support one-stop development, debugging, operation and maintenance of FlinkSql, Flink jar and SQL. When the worker executes `Dinky Task`, it will call `Dinky API` to trigger dinky task. Click for details about `Dinky`. Click Project Management-Project Name-Workflow Definition, and click the "Create Workflow" button to enter the DAG editing page. Drag <img src="../../../../img/tasks/icons/dinky.png" width="15"/> from the toolbar to the canvas. Please refer to `Default Task Parameters` section for default parameters. | Parameter | Description | ||-| | Dinky Address | The url for a dinky server. | | Dinky Task ID | The unique task id for a dinky task. | | Online Task | Specify whether the current dinky job is online. If yes, the submitted job can only be submitted successfully when it is published and there is no corresponding Flink job instance running. | This example illustrates how to create a dinky task node.
Project: Gloo (Orchestration & Management / API Gateway)
File: proxylatency.proto.sk.md

title: "proxylatency.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Configure the proxy latency filter. This filter measures the latency incurred by the filter chain in a histogram. ```yaml "request": .envoy.config.filter.http.proxylatency.v2.ProxyLatency.Measurement "measureRequestInternally": bool "response": .envoy.config.filter.http.proxylatency.v2.ProxyLatency.Measurement "chargeClusterStat": .google.protobuf.BoolValue "chargeListenerStat": .google.protobuf.BoolValue "emitDynamicMetadata": .google.protobuf.BoolValue ``` | Field | Type | Description | | -- | - | -- | | `request` | | How to measure the request. | | `measureRequestInternally` | `bool` | When FIRSTOUTGOING (i.e. LASTINCOMINGFIRSTOUTGOING or FIRSTINCOMINGFIRST_OUTGOING) is instead of when the first byte is sent upstream. This has the advantage of not measuring the time selected for request measurment, finish measuring proxy latency when decodeHeader for this it takes a connection to form, which may skew the P99. filter is hit instead of when the first byte is sent upstream. This has the advantage of not for this to work the filter should be inserted last, just before the router filter. measuring the time it takes a connection to form, which may skew the P99. For this to work this filter should be inserted last, just before the router filter. This has no effect if other measurement type is selected, and has no effect on how response is measured. | | `response` | | How measure the response. | | `chargeClusterStat` | | Charge a stat per upstream cluster. If not specified, defaults to true. | | `chargeListenerStat` | | Charge a stat per listener. If not specified, defaults to true. | | `emitDynamicMetadata` | | Should we emit request timing to dynamic metadata. defaults to true. | How to perform the latency measurement. Given an incoming request from downstream and outging request to upstream; or incoming response from upstream and outgoing repsonse to downstream, This outlines how to measure the latency used by the proxy. | Name | Description | | -- | -- | | `LASTINCOMINGFIRST_OUTGOING` | Count from the last byte of the incoming request\response to the first byte of the outgoing request\response. | | `FIRSTINCOMINGFIRST_OUTGOING` | Count from the first byte of the incoming request\response to the first byte of the outgoing request\response. | | `LASTINCOMINGLAST_OUTGOING` | Count from the last byte of the incoming request\response to the last byte of the outgoing request\response. | | `FIRSTINCOMINGLAST_OUTGOING` | Count from the first byte of the incoming request\response to the last byte of the outgoing request\response. | <!-- 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: Gravitee.io (Orchestration & Management / API Gateway)
File: management-configuration-sharding-tags.md

Shard tags let you constrain/deployed certain APIs to certain Gateway instances sharing the same shard tags. You can create a new shard tag by clicking on the New tag input and press SAVE button. A shard tag's ID will be automatically created. To make the association between APIs and Gateway instances, you must choose this shard tag in the API configuration page and copy/paste the shard tag's ID to the `gravitee.yml` file of the gateway instance: ```yaml ```
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.26.1.md

We are delighted to present version v1.26.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. This release includes various dependency bumps and fixes for , including: Updates Envoy to v1.27.2. See the release notes for v1.27.1 and v1.27.2 . Update to Go v1.20.10. See the for more information. Additional mitigations have been added for CVE-2023-44487 in the form of new configuration fields: Envoy mitigates CVE-2023-44487 with some default runtime settings, however the `http.maxrequestsperiocycle` does not have a default value. This change allows configuring this runtime setting via Contour configuration to allow administrators of Contour to prevent abusive connections from starving resources from other valid connections. The default is left as the existing behavior (no limit) so as not to impact existing valid traffic. The Contour ConfigMap can be modified similar to the following (and Contour restarted) to set this value: ``` listener: max-requests-per-io-cycle: 10 ``` (Note this can be used in addition to the existing Listener configuration field `listener.max-requests-per-connection` which is used primarily for HTTP/1.1 connections and is an approximate limit for HTTP/2) This field can be used to limit the number of concurrent streams Envoy will allow on a single connection from a downstream peer. It can be used to tune resource usage and as a mitigation for DOS attacks arising from vulnerabilities like CVE-2023-44487. The Contour ConfigMap can be modified similar to the following (and Contour restarted) to set this value: ``` listener: http2-max-concurrent-streams: 50 ``` For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.26.1 is tested against Kubernetes 1.26 through 1.28. 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: Gloo (Orchestration & Management / API Gateway)
File: glooctl_delete_virtualservice.md

title: "glooctl delete virtualservice" weight: 5 delete a virtualservice usage: glooctl delete virtualservice [NAME] [--namespace=namespace] ``` glooctl delete virtualservice [flags] ``` ``` -h, --help help for virtualservice ``` ``` -c, --config string set the path to the glooctl config file (default "<home_directory>/.gloo/glooctl-config.yaml") --consul-address string address of the Consul server. Use with --use-consul (default "127.0.0.1:8500") --consul-allow-stale-reads Allows reading using Consul's stale consistency mode. --consul-datacenter string Datacenter to use. If not provided, the default agent datacenter is used. Use with --use-consul --consul-root-key string key prefix for for Consul key-value storage. (default "gloo") --consul-scheme string URI scheme for the Consul server. Use with --use-consul (default "http") --consul-token string Token is used to provide a per-request ACL token which overrides the agent's default token. Use with --use-consul -i, --interactive use interactive mode --kube-context string kube context to use when interacting with kubernetes --kubeconfig string kubeconfig to use, if not standard one --name string name of the resource to read or write -n, --namespace string namespace for reading or writing resources (default "gloo-system") --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - Delete a Gloo resource
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: markdown-style-guide.md

title: Apache Mesos - Markdown Style Guide layout: documentation This guide introduces a consistent documentation style to be used across the entire non-code documentation. User guides and non-code technical documentation are stored in markdown files in the `docs/` folder. These files get rendered for the . NOTE: As of right now this is work in progress and the existing documentation might not yet comply to this style. Any new substantial feature should be documented in its own markdown file. If the link between source code and documentation is not obvious, consider inserting a short code comment stating that there is non-code documentation that needs to be kept in sync and indicating where it is located. When changing code consider whether you need to update the documentation. This is especially relevant when introducing new or updating existing command line flags. These should be reflected in `configuration.md`! Use for section headings, preferably the variant: Capitalize the first word of any heading, including title, subtitle, subheading. Capitalize all "major" words (nouns, verbs, adjectives, adverbs, and pronouns) in any heading, including the second part of hyphenated major words (e.g., Self-Report not Self-report). Capitalize all words of five letters or more. Effectively, only "minor" words of four letters or fewer, namely, conjunctions (words like and, or, nor, and but), articles (the words a, an, and the), and prepositions (words like as, at, by, for, from, in, of, on, per, to, with), are lowercased in any heading, as long as they aren't the first word. Code examples should be specified as follows: ~~~{.cpp} int main(int argc, char argv) { .... } ~~~ NOTE: Because of shortcomings of Doxygen's markdown parser we currently use indentation for wrapping all non C++ code blocks. Notes are used to highlight important parts of the text and should be specified as follows. ~~~{.txt} NOTE: Short note. Continued longer note. ~~~ We use single backticks to highlight individual words in a sentence such as certain identifiers: ~~~{.txt} Use the default `HierarchicalDRF` allocator.... ~~~ We use single backticks to highlight sample commands as follows: ~~~{.txt} `mesos-master --help` ~~~ Files and path references should be specified as follows: ~~~{.txt} Remember you can also use the `file:///path/to/file` or `/path/to/file` ~~~ In order to avoid problems with markdown formatting we should specify tables in html directly: <table class="table table-striped"> <thead> <tr> <th width="30%"> Flag </th> <th> Explanation </th> </thead> <tr> <td> --ip=VALUE </td> <td> IP address to listen on </td> </tr> <tr> <td> --[no-]help </td> <td> Prints this help message (default: false) </td> </tr> </table> We use no extra indentation in markdown files. We have one new line after section headings and two blank lines in between sections. ~~~{.txt} ... end of previous section. Beginning of new section .... ~~~
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: bug-report.md

name: Bug Report about: Report a bug encountered while using CoreDNS labels: bug <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via security@coredns.io --> What happened: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: the version of CoreDNS: Corefile: logs, if applicable: OS (e.g: `cat /etc/os-release`): Others:
Project: BFE (Orchestration & Management / Service Proxy)
File: terminology.md

The product equals "tenant" in BFE, which has its own configuration, such as forwarding policies, permission, etc. A Cluster means a set of backend servers which provide the same functionality. Multiple clusters can be defined within a product. Usuallya cluster may span multiple IDC. A cluster may be composed of multiple sub clusters conceptually. Usually, backend servers within the same IDC are defined as a sub cluster. A sub cluster contains multiple instances (i.e. backend servers). Each instance is identified by IP address and port.
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: ideas.md

Hello students! We want gRPC to be the universal remote procedure call protocol for all computing platforms and paradigms, so while these are our ideas of what we think would make good projects for the summer, we're eager to hear your ideas and proposals as well. and get to know the gRPC code and team! Required skills for all projects: git version control, collaborative software development on github.com, and software development in at least one of gRPC's ten languages on at least one of Linux, macOS, and Windows. gRPC Core: Implement . The gRPC wire protocol allows servers to complete an RPC with OK status without having processed all requests ever sent to the client; it's the gRPC Core that currently restricts applications from so behaving. This behavioral gap in the gRPC Core should be filled in. Required skills:* C programming language, C++ programming language. Likely mentors:* , . . Anything worth waiting for is worth cancelling. The fact that channel connectivity is currently poll-based means that clean shutdown of gRPC channels can take as long as the poll interval. No one should have to wait two hundred milliseconds to garbage-collect an object. Required skills:* C programming language, C++ programming language, Python programming language. Likely mentors:* , . gRPC Python: Support static type-checking of both gRPC Python itself and of code that uses gRPC Python. No one likes dynamic typing and Python is finally outgrowing it! There are probably errors in the implementation of gRPC Python that or could detect. There are certainly errors in other code that uses gRPC Python that they could detect. Required skills:* Python programming language, open source development across multiple repositories and projects. Likely mentors:* , . . Bazel is the designated replacement for our constellation of crufty build scripts, but it's still under active development itself. Up for a challenge? gRPC Python could easily be the most complex codebase to be built with Bazel. Required skills:* Python programming language, Bazel toolchain, Cython, open source development across multiple repositories and projects. Likely mentors:* .
Project: APISIX (Orchestration & Management / API Gateway)
File: cas-auth.md

title: cas-auth keywords: Apache APISIX API Gateway Plugin CAS AUTH cas-auth description: This document contains information about the Apache APISIX cas-auth Plugin. <!-- --> The `cas-auth` Plugin can be used to access CAS (Central Authentication Service 2.0) IdP (Identity Provider) to do authentication, from the SP (service provider) perspective. | Name | Type | Required | Description | | -- | -- | -- | -- | | `idp_uri` | string | True | URI of IdP. | | `cascallbackuri` | string | True | redirect uri used to callback the SP from IdP after login or logout. | | `logout_uri` | string | True | logout uri to trigger logout. | You can enable the Plugin on a specific Route as shown below: :::note You can fetch the `admin_key` from `config.yaml` and save to an environment variable with the following command: ```bash adminkey=$(yq '.deployment.admin.adminkey[0].key' conf/config.yaml | sed 's/"//g') ``` ::: ```shell curl http://127.0.0.1:9180/apisix/admin/routes/cas1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "methods": ["GET", "POST"], "host" : "127.0.0.1", "uri": "/anything/*", "plugins": { "cas-auth": { "idp_uri": "http://127.0.0.1:8080/realms/test/protocol/cas", "cascallbackuri": "/anything/cas_callback", "logout_uri": "/anything/logout" } }, "upstream": { "type": "roundrobin", "nodes": { "httpbin.org": 1 } } }' ``` Once you have enabled the Plugin, a new user visiting this Route would first be processed by the `cas-auth` Plugin. If no login session exists, the user would be redirected to the login page of `idp_uri`. After successfully logging in from IdP, IdP will redirect this user to the `cascallbackuri` with GET parameters CAS ticket specified. If the ticket gets verified, the login session would be created. This process is only done once and subsequent requests are left uninterrupted. Once this is done, the user is redirected to the original URL they wanted to visit. Later, the user could visit `logouturi` to start logout process. The user would be redirected to `idpuri` to do logout. Note that, `cascallbackuri` and `logout_uri` should be either full qualified address (e.g. `http://127.0.0.1:9080/anything/logout`), or path only (e.g. `/anything/logout`), but it is recommended to be path only to keep consistent. These uris need to be captured by the route where the current APISIX is located. For example, if the `uri` of the current route is `/api/v1/*`, `cascallbackuri` can be filled in as `/api/v1/cas_callback`. To remove the `cas-auth` 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/cas1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "methods": ["GET", "POST"], "uri": "/anything/*", "plugins": {}, "upstream": { "type": "roundrobin", "nodes": { "httpbin.org:80": 1 } } }' ```
Project: Nasp (Orchestration & Management / Service Mesh)
File: CONTRIBUTING.md

Thank you for taking the time to start contributing! We want to make contributing to this project as easy and transparent as possible, whether it's: Reporting a bug Sending a PR to submit a fix Proposing new features Helping new users with issues they may encounter Becoming a maintainer To get started: Support the development of this project and star this repo! :star: We use GitHub to host code, track issues or feature requests, and accept pull requests. We use GitHub issues to track bugs and problems. Report a bug by . Please format your issues in such a way as to help others who might be facing similar challenges. Give your issues meaningful titles, that offer context and help us and the community to understand and quickly ramp up on it. Consider including the following in a bug report: A quick summary and/or background Steps to reproduce Be specific! Provide sample code if you can. What you expected would happen What happened Notes (possibly including why you think this might be happening, or things you tried that didn't work) We are grateful for any issues submitted. Questions, feature requests, or ideas are all welcomed. We will try to respond to your issues promptly, but please note that as the project is open-source, volunteers may offer help on a limited, goodwill basis. Please be respectful of any help offered, and accept that the person you are requesting help from may not reside in your time zone. We are always happy to receive contributions via pull requests. Wasm Kernel Module follows the standard GitHub pull request process: Fork the repo, write your code, test your changes and submit a PR to the repo's `main` branch. Following the pull request template, describe the change(s) you're proposing, including context about why the change(s) are being made, and an explanation of any feature usage or behavior changes. The PR must pass the CI/CD checks (that include builds, tests, and linters - see below) We'll do our best to review the PR as soon as we can, but please accept if it takes time to respond. When working on a PR, consider these best practices: Write clear and meaningful commit messages. If you're fixing a bug or a smaller issue, squash your commits to help us maintain a clear git history. We prefer if you rebase your commits before submitting the PR. Explain the context of why you're making the changes to help reviewers. Before starting to work on a larger feature, contact the maintainers to ensure the work is in line with the product roadmap. A pull request must pass all tests and linters of the project. Running these on your local machine is as easy as running these two commands: `make test` and `make lint` By contributing, you agree that your contributions will be licensed under MIT.