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

title: Envoy Gzip filter with Gloo Edge weight: 70 description: Using Gzip filter in Envoy with Gloo Edge Gzip is an HTTP option which enables Gloo Edge to compress data returned from an upstream service upon client request. Compression is useful in situations where large payloads need to be transmitted without compromising the response time. This guide assumes you already have Gloo Edge installed. Support for the Envoy Gzip filter was added to Open Source Gloo Edge as of version 1.3.4 and to Gloo Edge Enterprise as of version 1.3.0-beta2. To get started with Gzip, modify the gateway and change the `httpGateway` object to include the gzip option. For example: ```shell kubectl patch gateway -n gloo-system gateway-proxy --type merge -p '{"spec":{"httpGateway":{"options":{"gzip":{"compressionLevel":"BEST","contentType":["text/plain"]}}}}}' ``` Here's an example of an edited gateway: {{< highlight yaml "hl_lines=11-16" >}} apiVersion: gateway.solo.io/v1 kind: Gateway metadata: labels: app: gloo name: gateway-proxy namespace: gloo-system spec: bindAddress: '::' bindPort: 8080 httpGateway: options: gzip: compressionLevel: BEST contentType: text/plain proxyNames: gateway-proxy useProxyProto: false {{< /highlight >}} Once that is saved, you're all set. Traffic on the http gateway will call the gzip filter. You can learn about the configuration options . More information about the Gzip filter can be found in the . If data is not being compressed, you may want to check that all the necessary conditions for the Envoy filter are met. See the section for information on when compression will be skipped. Let's see Gzip compression in action. First let's add the following Virtual Service: ```yaml apiVersion: gateway.solo.io/v1 kind: VirtualService metadata: name: sample-vs namespace: gloo-system spec: virtualHost: domains: '*' routes: matchers: exact: /helloworld directResponseAction: status: 200 body: "Hello, world! It's me. I've been wondering if after all these years you'd like to meet." ``` This can be added by copying the Virtual Service definition and using the `pbpaste | kubectl apply -f -` command or by saving the Virtual Service definition to a file and using `kubectl apply -f myFile.yaml`, among other options. Now, we'll send a request to the route referenced in our virtual service: ```shell curl -v $(glooctl proxy url)/helloworld -H "Accept-Encoding: gzip" ``` You should see that the response is in plain text. Now edit the gateway as described . If we send the same request: ```shell curl -v $(glooctl proxy url)/helloworld -H "Accept-Encoding: gzip" ``` We now see that the response includes the header `content-encoding: gzip` and that the body is binary.
Project: Prefect (Orchestration & Management / Scheduling & Orchestration)
File: usage.md

description: Prefect Integrations provide Prefect integrations that help you build dataflows quickly. tags: tasks flows blocks integrations task library contributing search: boost: 2 Install the Integration via `pip`. For example, to use `prefect-aws`: ```bash pip install prefect-aws ``` Once the Prefect Integration is installed, within the integration to view them in the Prefect Cloud UI: For example, to register the blocks available in `prefect-aws`: ```bash prefect block register -m prefect_aws ``` !!! tip "Updating blocks from an integrations" If you install an updated Prefect integration that adds fields to a block type, you will need to re-register that block type. !!! tip "Loading a block in code" To use the `load` method on a Block, you must already have a block document either through code or through the Prefect UI. Learn more about Blocks ! Integrations also contain pre-built tasks and flows that can be imported and called within your code. As an example, to read a secret from AWS Secrets Manager with the `read_secret` task: ```python from prefect import flow from prefect_aws import AwsCredentials from prefectaws.secretsmanager import read_secret @flow def connecttodatabase(): awscredentials = AwsCredentials.load("MYBLOCK_NAME") secretvalue = readsecret( secretname="dbpassword", awscredentials=awscredentials ) ``` To customize the settings of a task or flow pre-configured in a collection, use `with_options`: ```python from prefect import flow from prefect_dbt.cloud import DbtCloudCredentials from prefectdbt.cloud.jobs import triggerdbtcloudjobrunandwaitfor_completion customrundbtcloudjob = triggerdbtcloudjobrunandwaitforcompletion.with_options( name="Run My DBT Cloud Job", retries=2, retrydelayseconds=10 ) @flow def rundbtjob_flow(): runresult = customrundbtcloud_job( dbtcloudcredentials=DbtCloudCredentials.load("my-dbt-cloud-credentials"), job_id=1 ) rundbtjob_flow() ``` To learn more about how to use Integrations, check out on GitHub. These recipes provide examples of how Integrations can be used in various scenarios.
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: cors.md

CORS (Cross-Origin Resource Sharing) is a standard implemented by browsers for ensuring that only the allowed clients actually access your API, see . One of the biggest pain-points when deploying your API that is consumed by a browser application is not having the correct CORS configuration on your API Server. Fortunately, Kusk makes configuring CORS for your API easy - add the corresponding CORS extension to your OpenAPI definition at the desired level (usually the root): ```yaml openapi: 3.0.0 info: title: simple-api version: 0.1.0 x-kusk: cors: origins: "*" methods: POST GET OPTIONS headers: Content-Type credentials: true max_age: 86200 .. ``` If you want to override CORS settings for a specific operation or path you can do so. For example, to change the allowed origins for a specific operation you could add: ```yaml paths: /hello: get: operationId: getHello x-kusk: cors: origins: "gethello.com" .. ``` See all available CORS configuration options in the .
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-api-pathMappings.md

The path mappings allow you to get top resources on analytics dashboard. The resources will be grouped according to this mapping. Example: ```text /products /products/1 /products/2 /products/2 /products/1/characteristics ``` With the following path mapping: ```text /products /products/:productId ``` You will get the result below: ```text /products => 1 hit /products/:productId => 3 hits ```
Project: Gloo (Orchestration & Management / API Gateway)
File: extension.proto.sk.md

title: "extension.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Message type for extension configuration. ```yaml "name": string "typedConfig": .google.protobuf.Any ``` | Field | Type | Description | | -- | - | -- | | `name` | `string` | The name of an extension. This is not used to select the extension, instead it serves the role of an opaque identifier. | | `typedConfig` | | The typed config for the extension. The type URL will be used to identify the extension. In the case that the type URL is xds.type.v3.TypedStruct (or, for historical reasons, udpa.type.v1.TypedStruct), the inner type URL of TypedStruct will be utilized. See the :ref:`extension configuration overview <configoverviewextension_configuration>` for further details. | <!-- 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: Fluid (Orchestration & Management / Scheduling & Orchestration)
File: debug-fuse.md

If the application Pod is in the `ContainerCreating` or `Pending` state for a long time and cannot be created due to the CSI Plugin issue, it is usually caused by the state of the Fuse Pod in the same node is not correct. You can follow these steps to troubleshoot. The first step in debugging Fuse is to check the application Pod information. Use the following command to check the current status and recent events of the Pod. ```shell kubectl describe pods ${POD_NAME} ``` Similar to the following information, but may not be identical, but all point to the reason for FailedMount. ```shell kubectl describe po nginx-0 ... Events: Type Reason Age From Message - - - Normal Scheduled 30s default-scheduler Successfully assigned default/nginx-0 to testnode Warning FailedMount 1s kubelet MountVolume.MountDevice failed for volume "default-shared-data" : rpc error: code = Unknown desc = fuse pod on node testnode is not ready ``` At this point you need to check the status of the Fuse Pod of this node, first use the following command to get the information of the node where the current application Pod is located, the output corresponding to the NODE column is the node where the application Pod is located. ```shell kubectl get pods ${POD_NAME} -owide ``` For example, the following node where Fuse Pod is located is testnode: ```shell kubectl get pods nginx-0 -owide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-0 0/1 ContainerCreating 0 17m <none> testnode <none> <none> ``` Get this Fuse Pod's detail information: ```shell kubectl get po -owide | grep ${NODE_NAME} | grep -i fuse ``` In the following example, the Fuse Pod is `shared-data-alluxio-fuse-w6lcp`, and you can see that the Pod is in a failed state: ```shell kubectl get po -owide | grep testnode | grep fuse shared-data-alluxio-fuse-w6lcp 0/1 CrashLoopBackOff 10 29m 192.168.0.233 testnode <none> <none> ``` You can follow the to troubleshoot the issue with this Fuse Pod.
Project: Kubeflow (Orchestration & Management / Scheduling & Orchestration)
File: feature_request.md

name: Feature enhancement request about: Suggest an idea for this project /kind feature Why you need this feature: [Is your feature request related to a problem? Please describe in details] Describe the solution you'd like: [A clear and concise description of what you want to happen.] Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-002.md

+++ date = "2016-10-19T19:09:32Z" description = "CoreDNS-002 Release Notes." release = "002" tags = ["Release", "002", "Notes"] title = "CoreDNS-002 Release" author = "coredns" +++ CoreDNS-002 has been ! CoreDNS is a DNS server that chains plugins, where each plugin implements a DNS feature. `-port` was renamed to `-dns.port` to avoid clashing with Caddy's `-port` (which was renamed to `http.port`). Lumberjack logger was removed, this means no built in log rotation; use an external tool for that. Brushed up GoDoc for all packages. Brushed up all READMEs to be more standard and look like manual page. Golint-ed and go vet-ed the code - these can now (somewhat) useful tools before submitting PRs. Add more tests and show test coverage on submitting/PRs. Various Corefile parsing bugs fixed, better syntax error detection. plugin/root: a root plugin, same usage as in . See plugin/root/README.md for its use in CoreDNS. This makes stanzas like this shorter: ~~~ txt .:53 { file /etc/coredns/zones/db.example.net example.net file /etc/coredns/zones/db.example.org example.org file /etc/coredns/zones/db.example.com example.com } ~~~ Can be written as: ~~~ txt .:53 { root /etc/coredns/zones file db.example.net example.net file db.example.org example.org file db.example.com example.com } ~~~ plugin/auto: similar to the file* plugin, but automatically picks up new zones. The following Corefile will load all zones found under `/etc/coredns/org` and be authoritative for `.org.`: ~~~ corefile . { auto org { directory /etc/coredns/org } } ~~~ plugin/file: handle wildcards better. plugin/kubernetes: TLS support for kubernetes and other improvements. plugin/cache: use an LRU cache to make it memory bounded. Added more option to have more control on what is cached and for how long. The cache stanza was extended: ~~~ txt . { cache { success CAPACITY [TTL] denial CAPACITY [TTL] } } ~~~ See plugin/cache/README.md for more details. plugin/dnssec: replaced go-cache with golang-lru in dnssec. Also adds a `cache_capacity`. option in dnssec plugin so that the capacity of the LRU cache could be specified in the config file. plugin/logging: allow a response class to be specified on log on responses matching the name and* the response class. For instance only log denials for example.com: ~~~ corefile . { log example.com { class denial } } ~~~ plugin/proxy: performance improvements. The following people helped with getting this release done: Chris O'Haver, Manuel de Brito Fontes, Miek Gieben, Shawn Smith, Silas Baronda, Yong Tang, Zhipeng Jiang. If you want to help, please check out one of the and start coding! For documentation and help, see our .
Project: BFE (Orchestration & Management / Service Proxy)
File: bfe_callback.md

The Callback Points in the forwarding process are shown below. There are 9 callback points in BFE: HandleAccept: after TCP connection with client is established. HandleHandshake: after SSL/TLS handshake with client is finished. HandleBeforeLocation: before the destination product for the request is identified. HandleFoundProduct: after the destination product is identified. HandleAfterLocation: after the destination cluster is identified. HandleForward: after the destination subcluster is identified, and before the request is forwarded. HandleReadResponse: after response from backend is received by BFE. HandleRequestFinish: after response from backend is forwarded by BFE. HandleFinish: after connection with client is closed. The definition of callback points is in BFE takes different actions based on the return values of the callback functions. The return values and the actions are defined as follows: BfeHandlerFinish: send response, then close connection. BfeHandlerGoOn: go on to next callback function. BfeHandlerRedirect: redirect directly. BfeHandlerResponse: send response. BfeHandlerClose: close connection without sending response. The definition of return values is in The format of callback functions may be different for different callback points. There are 5 types of callback functions. HandlersAccept: Handler for processing connection estalishment HandlersRequest: Handler for processing request received HandlersForward: Handler for request forwarding process HandlersResponse: Handler for processing response received HandlersFinish: Handler for processing connection close The types of callback function are defined in The following describes each type of callback functions in detail Note: For the meaning of type int in the return value below, please refer to "Return Value of Callback Function" section above. Applicable callback points: HandleAccept HandleHandshake Function prototype: `handler(session *bfe_basic.Session) int` Applicable callback point: HandleBeforeLocation HandleFoundProduct HandleAfterLocation Function prototype: `handler(req bfe_basic.Request) (int, bfe_http.Response)` Applicable callback point: HandleForward Function prototype: `handler(req *bfe_basic.Request) int` Applicable callback point: HandleReadResponse HandleRequestFinish Function prototype: `handler(req bfe_basic.Request, res bfe_http.Response) int` Applicable callback point: HandleFinish Function prototype: `handler(session *bfe_basic.Session) int`
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.6.1-released.md

title: "Avro 1.6.1" linkTitle: "Avro 1.6.1" date: 2011-11-14 <!-- 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.6.1 has been released!
Project: WSO2 API Microgateway (Orchestration & Management / API Gateway)
File: CONTRIBUTING.md

Hello There! Thank you very much for taking some time for contributing to . This will provide you the required guidelines for contributing to - - - If you find an issue with the product, first search through the existing to find if the issue is already reported. If your issue is not already reported, fill the project and submit a new issue. Be kind enough to provide all the details you can provide, when submitting your issue. Not sure where to find a good issue to work on for the first time? We mark issues with `good first issue` label so that starters can easily find their way in to contributing. Visit label, read through the issues and select one for you to work on. After selecting the issue, communicate that to others by adding a comment. Before starting to work on the issue, discuss your plan/approach with project maintainers. Then follow section. If you are familiar with the project and its technologies, you no longer need to check `good first issue`. Browse through all open issues and pick one to work on. Check issues in label, where we prioritize issues we need help from you. If you are a developer, please refer to the to understand how you can proceed with the code structure. Follow the contribution guidelines. Run the build with tests before submitting your PR. Be polite and respectful when communicating with others.
Project: KubeGateway (Orchestration & Management / API Gateway)
File: README.md

English | Kube-gateway is a best practice for managing massive kubernetes clusters within ByteDance. It is a layer 7 load balancing proxy specifically designed and customized for HTTP2 flow for kube-apiserver. The goal is to provide flexible and stable flow governance solutions for massive large-scale kubernetes clusters (more than 1,000 nodes). In terms of traffic governance: It proactively performs request-level load balancing for multiple kube-apiservers; It provides kube-apiserver with routing rules customized for flow characteristics. It can distinguish requests through verb, apiGroup, resource, user, userGroup, serviceAccounts, nonResourceURLs and other information, and perform differentiated forwarding. It also has flow governance functions such as limited flow, degradation, and fuse; It converges the number of TCP connections on a single kube-apiserver instance by at least an order of magnitude; Its configuration, such as routing, takes effect immediately without restarting the service. In terms of massive cluster proxies It is able to dynamically add and remove proxy support for new clusters; It provides different TLS certificates and ClientCA for different clusters; It provides allow/disable list, monitoring alarm, fuse and other functions. Please refer to Please refer to for more details. Please refer to If you find a potential security issue in this project, or think you may have discovered a security issue. We hope you notify Bytedance Security via our or . Please do not create a public GitHub issue. This project follows .
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_debug.md

title: "glooctl debug" weight: 5 Debug a Gloo resource (requires Gloo running on Kubernetes) ``` glooctl debug [flags] ``` ``` -h, --help help for debug ``` ``` -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 --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - CLI for Gloo - Debug Gloo logs (requires Gloo running on Kubernetes) - Dump YAML representing the current Gloo state (requires Gloo running on Kubernetes)
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: TROUBLESHOOTING.md

The most common reason for this issue is improper use of struct tags (eg. `yaml` or `json`). Viper uses under the hood for unmarshaling values which uses `mapstructure` tags by default. Please refer to the library's documentation for using other struct tags. Viper installation seems to fail a lot lately with the following (or a similar) error: ``` cannot find package "github.com/hashicorp/hcl/tree/hcl1" in any of: /usr/local/Cellar/go/1.15.7_1/libexec/src/github.com/hashicorp/hcl/tree/hcl1 (from $GOROOT) /Users/user/go/src/github.com/hashicorp/hcl/tree/hcl1 (from $GOPATH) ``` As the error message suggests, Go tries to look up dependencies in `GOPATH` mode (as it's commonly called) from the `GOPATH`. Viper opted to use to manage its dependencies. While in many cases the two methods are interchangeable, once a dependency releases new (major) versions, `GOPATH` mode is no longer able to decide which version to use, so it'll either use one that's already present or pick a version (usually the `master` branch). The solution is easy: switch to using Go Modules. Please refer to the on how to do that. tl;dr* `export GO111MODULE=on` This is a YAML 1.1 feature according to . Potential solutions are: Quoting values resolved as boolean Upgrading to YAML v3 (for the time being this is possible by passing the `viper_yaml3` tag to your build)
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.10.0-released.md

title: "Avro 1.10.0" linkTitle: "Avro 1.10.0" date: 2020-06-29 <!-- 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.10.0 has been released!