cwielenb/CNCF-Dataset huggingface dataset:
Project: APISIX (Orchestration & Management / API Gateway)
File: plugin-config.md

title: Plugin Config keywords: API Gateway Apache APISIX Plugin Config description: Plugin Config in Apache APISIX. <!-- --> Plugin Configs are used to extract commonly used configurations and can be bound directly to a . While configuring the same plugin, only one copy of the configuration is valid. Please read the and . The example below illustrates how to create a Plugin Config and bind it to a 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 http://127.0.0.1:9180/apisix/admin/plugin_configs/1 \ -H "X-API-KEY: $admin_key" -X PUT -i -d ' { "desc": "blah", "plugins": { "limit-count": { "count": 2, "time_window": 60, "rejected_code": 503 } } }' ``` ```shell curl http://127.0.0.1:9180/apisix/admin/routes/1 \ -H 'X-API-KEY:edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d ' { "uris": ["/index.html"], "pluginconfigid": 1, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } }' ``` When APISIX can't find the Plugin Config with the `id`, the requests reaching this Route are terminated with a status code of `503`. :::note If a Route already has the `plugins` field configured, the plugins in the Plugin Config will effectively be merged to it. The same plugin in the Plugin Config will not override the ones configured directly in the Route. For more information, see . ::: For example, if you configure a Plugin Config as shown below: ```shell curl http://127.0.0.1:9180/apisix/admin/plugin_configs/1 \ -H "X-API-KEY: $admin_key" -X PUT -i -d ' { "desc": "I am plugin_config 1", "plugins": { "ip-restriction": { "whitelist": [ "127.0.0.0/24", "113.74.26.106" ] }, "limit-count": { "count": 2, "time_window": 60, "rejected_code": 503 } } }' ``` to a Route as shown below, ```shell curl http://127.0.0.1:9180/apisix/admin/routes/1 \ -H "X-API-KEY: $admin_key" -X PUT -i -d ' { "uris": ["/index.html"], "pluginconfigid": 1, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } "plugins": { "proxy-rewrite": { "uri": "/test/add", "host": "apisix.iresty.com" }, "limit-count": { "count": 20, "time_window": 60, "rejected_code": 503, "key": "remote_addr" } } }' ``` the effective configuration will be as the one shown below: ```shell curl http://127.0.0.1:9180/apisix/admin/routes/1 \ -H "X-API-KEY: $admin_key" -X PUT -i -d ' { "uris": ["/index.html"], "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } "plugins": { "ip-restriction": { "whitelist": [ "127.0.0.0/24", "113.74.26.106" ] }, "proxy-rewrite": { "uri": "/test/add", "host": "apisix.iresty.com" }, "limit-count": { "count": 20, "time_window": 60, "rejected_code": 503 } } }' ```
Project: wasmCloud (Orchestration & Management / Scheduling & Orchestration)
File: 0004-enforce-signed-artifacts.md

Status: Accepted Date: 2020-11-19 When a user uses `wash`, the `waSCC Shell`, should they be able to interact with provider archives or actors that are not signed? Any developer can create `WASM` files or gzipped archives with the file type `.par.gz`, but without an embedded JWT we have no way to verify the creator, origin, and safety of these files. Allowing developers to interact with OCI artifacts freely without `waSCC` specific restrictions Confidence that artifacts `push`ed and `pull`ed with `wash` are signed Difficulty of signing artifacts Difficulty of verifying artifacts Inability to prevent developers from hosting their own registry with unsigned artifacts No restriction on artifacts `push`ed or `pull`ed with `wash` Provider archives and waSCC actors must be signed (embedded JWT) before `push`ed or `pull`ed using `wash` Chosen option: Provider archives and waSCC actors must be signed (embedded JWT) before `push`ed or `pull`ed using `wash` because our official `waSCC` tooling should enforce our security stance. Artifacts produced for consumption by `waSCC` MUST be signed to ensure a verifiable source and verifiable attestations of capabilities for actors. `wash` is intended to make signing easier, and the difficulty of signing a provider archive or actor does not outweigh the benefits of verifiable artifacts. In the scenario where a user would like to push other types of artifacts, use of the is encouraged. Users can freely `pull` artifacts using `wash` knowing that provider archives or actor modules MUST be signed Artifacts `push`ed using `wash` cannot accidentally be left unsigned Developers must use a tool other than `wash` to distribute unsigned WASM/provider archives
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.8.1-released.md

title: "Avro 1.8.1" linkTitle: "Avro 1.8.1" date: 2016-05-19 <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> Apache Avro 1.8.1 has been released!
Project: Contour (Orchestration & Management / Service Proxy)
File: cors.md

A CORS (Cross-origin resource sharing) policy can be set for a HTTPProxy in order to allow cross-domain requests for trusted sources. If a policy is set, it will be applied to all the routes of the virtual host. Contour allows configuring the headers involved in cross-domain requests. In this example, cross-domain requests will be allowed for any domain (note the `*` value). ```yaml apiVersion: projectcontour.io/v1 kind: HTTPProxy spec: virtualhost: fqdn: www.example.com corsPolicy: allowCredentials: true allowOrigin: "*" # allows any origin allowMethods: GET POST OPTIONS allowHeaders: authorization cache-control exposeHeaders: Content-Length Content-Range maxAge: "10m" # preflight requests can be cached for 10 minutes. routes: conditions: prefix: / services: name: s1 port: 80 ``` In the following example, cross-domain requests are restricted to `https://client.example.com` only. ```yaml apiVersion: projectcontour.io/v1 kind: HTTPProxy spec: virtualhost: fqdn: www.example.com corsPolicy: allowCredentials: true allowOrigin: "https://client.example.com" allowMethods: GET POST OPTIONS allowHeaders: authorization cache-control exposeHeaders: Content-Length Content-Range maxAge: "10m" routes: conditions: prefix: / services: name: s1 port: 80 ``` `MaxAge` durations are expressed in the Go . Valid time units are "ns", "us" (or "s"), "ms", "s", "m", "h". Only positive values are allowed and 0 disables the cache requiring a preflight `OPTIONS` check for all cross-origin requests.
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-configuration-group.md

A group entity represents an API or an application group of users. Each member of a group has roles to perform certain actions on an API or an application. Users are fetched from identity providers configured at Management API level. the `Group Admin` checkbox let you delegate the administration of a group to a user, `API Role` is the default role a user have on each API associated to this group, `Application Role` is the default role a user have on each Application associated to this group. (+) button let you add users to the group.
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-configuration-apilogging.md

Here you can enable to audit the consultation of log detail. This can be useful to track who has accessed to a specific data from the audit view. You will be able to display or not the end user in case of a OAuth2/JWT plan. It will be extracted from the sub claim. You can also limit the duration of API full logging (0 means no max duration). This can be useful to avoid to API publishers to log headers / body payloads during too much time and avoid to consume too much CPU/memory. By default, the calls are logged with the minimal information.
Project: Nomad (Orchestration & Management / Scheduling & Orchestration)
File: testing.md

The Nomad repository strives to maintain comprehensive unit test coverage. Any new features, bug fixes, or refactoring should include additional or updated test cases demonstrating correct functionality. Each unit test should meet a few criteria: Use Prefer using `must.*`` functions Use `test.*`` functions when cleanup must happen, etc Feel free to refactor testify tests; but consider separate commits / PRs Undo any changes to the environment Set environment variables must be unset (use `t.Setenv`) Scratch files/dirs must be removed (use `t.TempDir`) Able to run in parallel All package level `Test*` functions should start with `ci.Parallel` Always use dynamic scratch dirs, files Always get ports via `ci.PortAllocator.Grab()` Log control Logging must go through the `testing.T` (use `helper/testlog.HCLogger`) Avoid excessive logging in test cases - prefer failure messages Annotate failures with `must.Sprint\f` post-scripts Testing in the `api` package requires an already-built Nomad binary. If you're writing `api` tests, you'll need to build a Nomad binary (ex. with `make dev`) that includes any changes your API exercises. See Github Action works.
Project: Gloo (Orchestration & Management / API Gateway)
File: rbac_configuration.md

title: Gloo Edge RBAC Configuration weight: 70 description: Options for Gloo Edge's RBAC configuration You may want to prevent Gloo Edge's RBAC resources from being created at install time. An example of this use case is if you are installing to a cluster where you have insufficient permissions to create privileged resources like RBAC roles and role-bindings. Gloo Edge's RBAC resources will not be installed if the Helm flag `global.glooRbac.create` is set to `false`. In Enterprise deployments of Gloo Edge, our Grafana and Prometheus subcharts will still attempt to create their own RBAC resources. If you would like to prevent those resources from being created as well, you must also set the flags `grafana.rbac.create` and `prometheus.rbac.create` to `false`. By default, Gloo Edge's RBAC resources are created as cluster-scoped. This may present a problem if, for example, you upgrade Gloo Edge by performing a and deploying Gloo Edge to two namespaces simultaneously within the same cluster. The identically-named cluster-scoped roles and role-bindings will conflict with each other and will cause an error. To resolve this, you may set the Helm flag `global.glooRbac.nameSuffix` to some string of your choosing. That will cause the string `"-$nameSuffix"` to be appended to the roles' and role-bindings' names, where `$nameSuffix` is the string you passed to the Helm flag. For example, setting `global.glooRbac.nameSuffix` to the string `"blue-deployment"` will cause the ClusterRole normally named `gloo-resource-reader` to instead be named `gloo-resource-reader-blue-deployment`. {{% notice note %}} For Enterprise deployments of Gloo Edge: Our Grafana and Prometheus subcharts currently do not allow customization of their own RBAC resources' names, so you may still have a conflict on these. The current best-practice is to either disable the install of Grafana/Prometheus, or manually fix after installation. {{% /notice %}}
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_proxy_address.md

title: "glooctl proxy address" weight: 5 print the socket address for a proxy Use this command to view the address (host:port) of a Proxy reachable from outside the cluster. You can connect to this address from a host on the same network (such as the host machine, in the case of minikube/minishift). ``` glooctl proxy address [flags] ``` ``` -h, --help help for address -l, --local-cluster use when the target kubernetes cluster is running locally, e.g. in minikube or minishift. this will default to true if LoadBalanced services are not assigned external IPs by your cluster -p, --local-cluster-name string name of the locally running minikube cluster. (default "minikube") ``` ``` -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 the name of the proxy service/deployment to use (default "gateway-proxy") -n, --namespace string namespace for reading or writing resources (default "gloo-system") --port string the name of the service port to connect to (default "http") --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - interact with proxy instances managed by Gloo
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_edit_virtualservice.md

title: "glooctl edit virtualservice" weight: 5 edit a virtualservice in a namespace usage: glooctl edit virtualservice [NAME] [--namespace=namespace] [-o FORMAT] ``` glooctl edit virtualservice [flags] ``` ``` -h, --help help for virtualservice --ssl-remove Remove SSL configuration from this virtual service --ssl-secret-name string name of the ssl secret for this virtual service --ssl-secret-namespace string namespace of the ssl secret for this virtual service --ssl-sni-domains stringArray SNI domains for this virtual service ``` ``` -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") -o, --output OutputType output format: (yaml, json, table, kube-yaml, wide) (default table) --resource-version string the resource version of the resource we are editing. if not empty, resource will only be changed if the resource version matches --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - Edit a Gloo resource - Configure rate limit settings (Enterprise)
Project: ngrok (Orchestration & Management / API Gateway)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to make 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, education, socio-economic status, 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 The ngrok documentation team is 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. The ngrok documentation team has 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 ngrok docs 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 . All complaints will be reviewed and investigated and will result in a response that is deemed necessary and 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 Contributor Covenant, version 2.1, available at . For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq
Project: Docker Swarm (Orchestration & Management / Scheduling & Orchestration)
File: RELEASE.md

The `klog` is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: bug_report_php.md

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

This page is maintained and updated periodically to reflect our roadmap and any decisions around feature deprecation. | Feature | Deprecated | End of Support | Removal | |-||-|| | | 3.0 | N/A | 4.0 | | | N/A | N/A | 3.0 | | | N/A | N/A | 3.0 | The Kubernetes CRD provider API Version `traefik.io/v1alpha1` is deprecated in Traefik v3. Please use the API Group `traefik.io/v1` instead. The Kubernetes Ingress API Version `networking.k8s.io/v1beta1` support is removed in v3. Please use the API Group `networking.k8s.io/v1` instead. The Traefik CRD definitions API Version `apiextensions.k8s.io/v1beta1` support is removed in v3. Please use the API Group `apiextensions.k8s.io/v1` instead.
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: cherry-pick.md

name: CherryPick Track about: Track tasks when release branches need cherry-pick. labels: help wanted Which PR needs cherry-picks: <!-- For example: "PR #1234" --> PR # Which release branches need this patch: <!-- Karmada now maintains 3 latest releases. If a branch doesn't need this cherry-pick, please explain the reason. --> [ ] release-1.x [ ] release-1.y [ ] release-1.z How to cherry-pick PRs: The `hack/cherrypickpull.sh` script can help you initiate a cherry-pick automatically, please follow the instructions at . The script will send the PR for you, please remember `copy the release notes` from the original PR by to the new PR description part. How to join or take the task: Just reply on the issue with the message `/assign` in a separate line. Then, the issue will be assigned to you. Useful References: Release timeline: https://karmada.io/docs/releases How to cherry-pick PRs: https://karmada.io/docs/contributor/cherry-picks Anything else we need to know:
Project: Apache Thrift (Orchestration & Management / Remote Procedure Call)
File: SequenceNumbers.md

Apache Thrift built sequence numbers into every protocol exchange to allow for clients that may submit multiple outstanding requests on a single transport connection. This is typically done by asynchronous clients. The following rules apply to sequence numbers: A sequence number is a signed 32-bit integer. Negative values are allowed. Sequence numbers `MUST` be unique across all outstanding requests on a given transport connection. There is no requirement for unique numbers between different transport connections even if they are from the same client. A server `MUST` reply to a client with the same sequence number that was used in the request. This includes any exception-based reply. A client `MAY` use sequence numbers if it needs them for proper operation. A client `SHOULD` set the sequence number to zero if it does not rely on them. Wrapped protocols (such as THeaderProtocol) `SHOULD` use the same sequence number on the wrapping as is used on the payload protocol. Servers will not inspect or make any logic choices based on the sequence number sent by the client. The server's only job is to process the request and reply with the same sequence number.