cwielenb/CNCF-Dataset huggingface dataset:
Project: Kubernetes (Orchestration & Management / Scheduling & Orchestration)
File: controller-client-go.md

The library contains various mechanisms that you can use when developing your custom controllers. These mechanisms are defined in the of the library. Here is a pictorial representation showing how the various components in the client-go library work and their interaction points with the custom controller code that you will write. <p align="center"> <img src="images/client-go-controller-interaction.jpeg" height="600" width="700"/> </p> Reflector: A reflector, which is defined in , watches the Kubernetes API for the specified resource type (kind). The function in which this is done is ListAndWatch. The watch could be for an in-built resource or it could be for a custom resource. When the reflector receives notification about existence of new resource instance through the watch API, it gets the newly created object using the corresponding listing API and puts it in the Delta Fifo queue inside the watchHandler function. Informer: An informer defined in the pops objects from the Delta Fifo queue. The function in which this is done is processLoop. The job of this base controller is to save the object for later retrieval, and to invoke our controller passing it the object. Indexer: An indexer provides indexing functionality over objects. It is defined in . A typical indexing use-case is to create an index based on object labels. Indexer can maintain indexes based on several indexing functions. Indexer uses a thread-safe data store to store objects and their keys. There is a default function named MetaNamespaceKeyFunc defined in that generates an objects key as `<namespace>/<name>` combination for that object. Informer reference: This is the reference to the Informer instance that knows how to work with your custom resource objects. Your custom controller code needs to create the appropriate Informer. Indexer reference: This is the reference to the Indexer instance that knows how to work with your custom resource objects. Your custom controller code needs to create this. You will be using this reference for retrieving objects for later processing. The base controller in client-go provides the NewIndexerInformer function to create Informer and Indexer. In your code you can either or Resource Event Handlers: These are the callback functions which will be called by the Informer when it wants to deliver an object to your controller. The typical pattern to write these functions is to obtain the dispatched objects key and enqueue that key in a work queue for further processing. Work queue: This is the queue that you create in your controller code to decouple delivery of an object from its processing. Resource event handler functions are written to extract the delivered objects key and add that to the work queue. Process Item: This is the function that you create in your code which processes items from the work queue. There can be one or more other functions that do the actual processing. These functions will typically use the , or a Listing wrapper to retrieve the object corresponding to the key.
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: timeouts.md

Kusk Gateway makes it easy to specify timeouts for your API operations, both globally and individually, for each path or operation. For example the API below defines a global 60-second request timeout, which is overridden for the getHello operation and set to 10 seconds: ```yaml openapi: 3.0.0 info: title: simple-api version: 0.1.0 x-kusk: qos: request_timeout: 60 paths: /hello: get: operationId: getHello x-kusk: qos: request_timeout: 10 .. ``` See all available timeout configuration options in the .
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.25.3.md

We are delighted to present version v1.25.3 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. This release includes various dependency bumps and fixes for , including: Update to Envoy v1.26.6. See the release notes for v1.26.5 and v1.26.6 . 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.25.3 is tested against Kubernetes 1.25 through 1.27. 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: etcd (Orchestration & Management / Coordination & Service Discovery)
File: CHANGELOG-4.0.md

Previous change logs can be found at . <hr> See and for any breaking changes. Again, before running upgrades from any previous release, please make sure to read change logs below and . ? Deprecate flags; no more v2 proxy. Deprecate ; no more v2 store. v2 API is still supported via . Deprecate command. `clientv3.Client.KeepAlive(ctx context.Context, id LeaseID) (<-chan *LeaseKeepAliveResponse, error)` is now . Similar to `Watch`, . If there's an unknown server error, kill all open channels and create a new stream on the next `KeepAlive` call. Rename `github.com/coreos/client` to `github.com/coreos/clientv2`. has been deprecated. Use instead. has been deprecated. Use instead. Enable TLS 1.13, deprecate TLS cipher suites. flag is now stable (`etcd --experimental-initial-corrupt-check` has been deprecated). `etcd --initial-corrupt-check=true` by default, to check cluster database hashes before serving client/peer traffic. flag is now stable (`etcd --experimental-corrupt-check-time` has been deprecated). `etcd --corrupt-check-time=12h` by default, to check cluster database hashes for every 12-hour. Enable TLS 1.13, deprecate TLS cipher suites. Require . <hr>
Project: wasmCloud (Orchestration & Management / Scheduling & Orchestration)
File: CONTRIBUTING.md

Install the dependencies. Start the wasmCloud host using the `wash` CLI. Read more about it . Ensure the NATS service is running with the websocket listener enabled. Start a local frontend development server. Read more about it . Make changes to the UI. Commit your changes. Open a pull request. Wait for the CI to pass. Wait for a maintainer to review your changes. Wait for a maintainer to merge your changes. Done Enable `corepack` and install `yarn` using the following commands: ```bash corepack enable yarn install ``` Run the following command to start a local frontend development server: ```bash yarn run dev ``` Run the following command to start the wasmCloud host using the wash CLI: ```bash wash up ``` `wasmcloud` uses as its message broker. The `wash` CLI can be used to start a local NATS or connect to an existing NATS server. The Washboard UI connects to a NATS server at , although this can be overridden via the UI. You can spawn the NATS server with a wasmCloud Host and wadm with the `wash` cli tool. See the documentation for . ```bash wash up ``` You can change the NATS websocket port using the `--nats-websocket-port` flag or `NATSWEBSOCKETPORT` environment variable. Note that you must stop the NATS Server to make this change. For example: ```bash wash down wash up --nats-websocket-port 4001 NATSWEBSOCKETPORT=4001 wash up ``` Otherwise, verify the port you are using to connect to the NATS server. Visit for more information. s they are functional and come with an easy-to-use example. Community capability providers should implement useful functionality, e.g. alternate implementations of HTTPservers or connectors to other services. Demo or one-off providers like or factorial are better suited for our examples repository. To submit a community capability provider open a adding an entry into the under the community section.
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_istio_inject.md

title: "glooctl istio inject" weight: 5 Enable SDS & istio-proxy sidecars in gateway-proxy pod Adds an istio-proxy sidecar to the gateway-proxy pod for mTLS certificate generation purposes. Also adds an sds sidecar to the gateway-proxy pod for mTLS certificate rotation purposes. ``` glooctl istio inject [flags] ``` ``` -h, --help help for inject --istio-discovery-address string Sets discoveryAddress field within PROXY_CONFIG environment variable --istio-meta-cluster-id string Sets ISTIOMETACLUSTER_ID environment variable --istio-meta-mesh-id string Sets ISTIOMETAMESH_ID environment variable --istio-namespace string Namespace in which Istio is installed (default "istio-system") ``` ``` -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) ``` - Commands for interacting with Istio in Gloo
Project: Gloo (Orchestration & Management / API Gateway)
File: connection_limit.proto.sk.md

title: "connection_limit.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> These options provide the ability to limit the active connections in envoy. Ref. https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/networkfilters/connectionlimit_filter ```yaml "maxActiveConnections": .google.protobuf.UInt32Value "delayBeforeClose": .google.protobuf.Duration ``` | Field | Type | Description | | -- | - | -- | | `maxActiveConnections` | | The maximum number of active connections for this gateway. When this limit is reached, any incoming connection will be closed after delay duration. Must be greater than or equal to one. | | `delayBeforeClose` | | The time to wait before a connection is dropped. Useful for DoS prevention. Defaults to zero and the connection will be closed immediately. | <!-- 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: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: reporting-an-issue.md

title: Apache Mesos - Reporting An Issue layout: documentation When reporting an issue (e.g. bug, improvement, feature request), please provide as much context as possible. We track all issues via Apache's hosted , so if you don't already have an account you'll need to register for one. It's quick and easy. A JIRA should be created for every task, feature, bug-fix, etc. This makes it easy to track progress. If you are planning to work on the ticket, please assign the JIRA issue to yourself before you start working on it. This helps to avoid duplication of work and alerts anyone who is following that issue. It is highly encouraged to start a discussion with others in the community about how to solve the issue. The and discuss how to contribute to Mesos development in more detail.
Project: BFE (Orchestration & Management / Service Proxy)
File: vip_rule.data.md

vip_rule.data records vip lists for each product. | Config Item | Description | | -- | | | Version | String<br>Version of config file | | Vips | Struct<br>Vip list for each product | | Vips{k} | String<br>Product name | | Vips{v} | Struct<br>Vip list for product | ```json { "Version": "20190101000000", "Vips": { "example_product": [ "111.111.111.111" ] } } ```
Project: BFE (Orchestration & Management / Service Proxy)
File: fastcgi.md

Imagine we have an http server which has two instances. One is responsible for processing fcgi protocol requests, and the other is responsible for http requests. Hostexample.org Requests that start with / fcgi are forwarded to the fcgi protocol service instance with address 10.0.0.1:8001 Other requests are forwarded to http service instance with address 10.0.0.1:8002 Modify example configurations (conf/) as the following steps: Step 1. Config path of forward rules in conf/bfe.conf ```ini hostRuleConf = serverdataconf/host_rule.data routeRuleConf = serverdataconf/route_rule.data clusterConf = serverdataconf/cluster_conf.data clusterTableConf = clusterconf/clustertable.data gslbConf = cluster_conf/gslb.data ``` Step 2. Config host rules (conf/serverdataconf/host_rule.data) ```json { "Version": "init version", "DefaultProduct": null, "Hosts": { "exampleTag":[ "example.org" // host name: example.org=>host tag: exampleTag ] }, "HostTags": { "example_product":[ "exampleTag" // host tag: exampleTag=>product name: example_product ] } } ``` Step 3. Config cluster configuration (conf/serverdataconf/cluster_conf.data) Note: Set backend conf params and use default value for other params ```json { "Version": "init version", "Config": { "clusterdemohttp": { "BackendConf": { "TimeoutConnSrv": 2000, "TimeoutResponseHeader": 50000, "MaxIdleConnsPerHost": 0, "RetryLevel": 0 } }, "clusterdemofcgi": { "BackendConf": { "Protocol": "fcgi", "TimeoutConnSrv": 2000, "TimeoutResponseHeader": 50000, "MaxIdleConnsPerHost": 0, "RetryLevel": 0, "FCGIConf": { "Root": "/home/work", "EnvVars": { "VarKey": "VarVal" } } } } } } ``` Step 4. Config instances of cluster (conf/clusterconf/clustertable.data) ```json { "Version": "init version", "Config": { "clusterdemofcgi": { // cluster => sub_cluster => instance list "demofcgi.all": [{ // subcluster: demofcgi.all "Addr": "10.0.0.1", "Name": "fcgi.A", "Port": 8001, "Weight": 1 }] }, "clusterdemohttp": { "demo_http.all": [{ "Addr": "10.0.0.1", "Name": "http.A", "Port": 8002, "Weight": 1 }] } } } ``` Step 5. Config gslb configuration (conf/cluster_conf/gslb.data) ```json { "Hostname": "", "Ts": "0", "Clusters": { "clusterdemofcgi": { // cluster => weight of subcluster "GSLBBLACKHOLE": 0, // GSLBBLACKHOLE == 0 means do not discard traffic "demofcgi.all": 100 // weight 100 means all traffic routes to demofcgi.all }, "clusterdemohttp": { "GSLB_BLACKHOLE": 0, "demo_http.all": 100 } } } ``` Step 6. Config route rules (conf/serverdataconf/route_rule.data) ```json { "Version": "init version", "ProductRule": { "example_product": [ // product => route rules { "Cond": "reqpathprefix_in(\"/fcgi\", false)", "ClusterName": "clusterdemofcgi" }, { "Cond": "default_t()", "ClusterName": "clusterdemohttp" } ] } } ``` Step 7. Verify configured rules ```bash curl -H "host: example.org" "http://127.1:8080/fcgi/test" curl -H "host: example.org" "http://127.1:8080/http/test" ```
Project: APISIX (Orchestration & Management / API Gateway)
File: script.md

title: Script <!-- --> Scripts lets you write arbitrary Lua code or directly call existing plugins and execute them during the HTTP request/response lifecycle. A Script configuration can be directly bound to a . Scripts and are mutually exclusive, and a Script is executed before a Plugin. This means that after configuring a Script, the Plugin configured on the Route will not be executed. Scripts also have a concept of execution phase which supports the `access`, `headerfilter`, `bodyfilter`, and the `log` phase. The corresponding phase will be executed automatically by the system in the Script. ```json { ... "script": "local M = {} \n function M.access(apictx) \n ngx.log(ngx.INFO,\"hit access phase\") \n end \nreturn M" } ```
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: zeppelin.md

Use `Zeppelin Task` to create a zeppelin-type task and execute zeppelin notebook paragraphs. When the worker executes `Zeppelin Task`, it will call `Zeppelin Client API` to trigger zeppelin notebook paragraph. Click for details about `Apache Zeppelin Notebook`. 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/zeppelin.png" width="15"/> from the toolbar to the canvas. Please refer to `Default Task Parameters` section for default parameters. | Parameter | Description | ||| | Zeppelin Note ID | The unique note id for a zeppelin notebook note. | | Zeppelin Paragraph ID | The unique paragraph id for a zeppelin notebook paragraph. If you want to schedule a whole note at a time, leave this field blank. | | Zeppelin Production Note Directory | The directory for cloned note in production mode. | | Zeppelin username | the login username of your zeppelin server . | | | | Zeppelin password | the login password of your zeppelin server . | | | | Zeppelin Rest Endpoint | The REST endpoint of your zeppelin server . | | Zeppelin Parameters | Parameters in json format used for zeppelin dynamic form. | Fill in the optional `Zeppelin Production Note Directory` parameter to enable `Production Mode`. In `Production Mode`, the target note gets copied to the `Zeppelin Production Note Directory` you choose. `Zeppelin Task Plugin` will execute the cloned note instead of the original one. Once execution done, `Zeppelin Task Plugin` will delete the cloned note automatically. Therefore, it increases the stability as the modification to a running note triggered by `Dolphin Scheduler` will not affect the production task. If you leave the `Zeppelin Production Note Directory` empty, `Zeppelin Task Plugin` will execute the original note. 'Zeppelin Production Note Directory' should both start and end with a `slash`. e.g. `/productionnotedirectory/` This example illustrates how to create a zeppelin paragraph task node.
Project: Gloo (Orchestration & Management / API Gateway)
File: parameters.proto.sk.md

title: "parameters.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> ```yaml "headers": map<string, string> "path": .google.protobuf.StringValue ``` | Field | Type | Description | | -- | - | -- | | `headers` | `map<string, string>` | headers that will be used to extract data for processing output templates Gloo will search for parameters by their name in header value strings, enclosed in single curly braces Example: extensions: parameters: headers: x-user-id: '{userId}'. | | `path` | | part of the (or the entire) path that will be used extract data for processing output templates Gloo will search for parameters by their name in header value strings, enclosed in single curly braces Example: extensions: parameters: path: /users/{ userId }. | <!-- 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: MOSN (Orchestration & Management / Service Proxy)
File: CONTRIBUTING.md

MOSN is released under the Apache 2.0 license, and follows a very standard Github development process, using Github tracker for issues and merging pull requests into master. If you would like to contribute something, or simply want to hack on the code this document should help you get started. Before we accept a non-trivial patch or pull request we will need you to sign the Contributor License Agreement. Signing the contributors agreement does not grant anyone commits rights to the main repository, but it does mean that we can accept your contributions, and you will get an author credit if we do. Active contributors might be asked to join the core team and given the ability to merge pull requests. None of these is essential for a pull request, but they will all help. Code format With cli, run `goimports -w yourfile.go` and `golint yourfile.go` to format the style With ide like goland, select 'Group stdlib imports', 'Move all stdlib imports in a single group', 'Move all imports in a single declaration' in Go->imports page We would check code format when run ci test, so please ensure that you have built project before you push branch. Make sure all new `.go` files to have a simple doc class comment with at least an `author` tag identifying you, and preferably at least a paragraph on what the class is for. Add the ASF license header comment to all new `.go` files (copy from existing files in the project) Add yourself as an `author` to the `.go` files that you modify substantially (more than cosmetic changes). Add some docs. A few unit tests would help a lot as wellsomeone has to do it. When writing a commit message please follow , if you are fixing an existing issue please add Fixes gh-XXXX at the end of the commit message (where XXXX is the issue number). Please ensure that code coverage will not decrease. Contribute a PR as the rule of Gitflow Workflow, and you should follow the pull request's rules. MOSN's version contains three-digit with the format x.x.x, the first one is for compatibility; the second one is for new features and enhancement; the last one is for a bug fix. The following strategies are recommended for project maintainers to review code: Check the issue with this PR Check the solution's reasonability Check UT's and Benchmark's result Pay attention to the code which makes the code structure change, the usage of the global variable, the handling of the corner case and concurrency