cwielenb/CNCF-Dataset huggingface dataset:
Project: Contour (Orchestration & Management / Service Proxy)
File: SECURITY.md

Contour is an ingress controller that works as an Envoy control plane, configuring the Envoy data plane, which actually carries traffic from outside to inside the cluster. For reporting security issues, please see the reporting process documentation available at https://projectcontour.io/resources/security-process. For more information about the threat model Contour uses, please see https://projectcontour.io/resources/security-threat-model.
Project: Contour (Orchestration & Management / Service Proxy)
File: table.md

| Name | Type | Labels | Description | | - | - | | -- | | contourbuildinfo | | branch, revision, version | Build information for Contour. Labels include the branch and git SHA that Contour was built from, and the Contour version. | | contourcachehandleronupdatedurationseconds | | | Histogram for the runtime of xDS cache regeneration. | | contourdagcache_object | | kind | Total number of items that are currently in the DAG cache. | | contourdagrebuildseconds | | | Duration in seconds of DAG rebuilds | | contourdagrebuildtimestamp | | | Timestamp of the last DAG rebuild. | | contourdagrebuildtotal | | | Total number of times DAG has been rebuilt since startup | | contoureventhandleroperation_total | | kind, op | Total number of Kubernetes object changes Contour has received by operation and object kind. | | contour_httpproxy | | namespace | Total number of HTTPProxies that exist regardless of status. | | contourhttpproxyinvalid | | namespace, vhost | Total number of invalid HTTPProxies. | | contourhttpproxyorphaned | | namespace | Total number of orphaned HTTPProxies which have no root delegating to them. | | contourhttpproxyroot | | namespace | Total number of root HTTPProxies. Note there will only be a single root HTTPProxy per vhost. | | contourhttpproxyvalid | | namespace, vhost | Total number of valid HTTPProxies. | | contourstatusupdateconflicttotal | | kind | Number of status update conflicts encountered by object kind. | | contourstatusupdatedurationseconds | | error, kind | How long a status update takes to finish. | | contourstatusupdatefailedtotal | | kind | Number of status updates that failed by object kind. | | contourstatusupdatenooptotal | | kind | Number of status updates that are no-ops by object kind. This is a subset of successful status updates. | | contourstatusupdatesuccesstotal | | kind | Number of status updates that succeeded by object kind. | | contourstatusupdate_total | | kind | Total number of status updates by object kind. |
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-alerts.md

Configure your own alerts. Be alerted by email when the HC status changed or when the quota reached a percent rate. You can find examples in the Gravitee documentation to configure <a href="https://documentation.gravitee.io/apim/getting-started/configuration/configure-alerts-and-notifications#configure-notifications-for-your-apis" target="blank">notifications</a> or <a href="https://documentation.gravitee.io/apim/getting-started/configuration/configure-alerts-and-notifications#configure-alerts" target="blank">alerts</a>
Project: Gloo (Orchestration & Management / API Gateway)
File: protocol_upgrade.proto.sk.md

title: "protocol_upgrade.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> ```yaml "websocket": .protocol_upgrade.options.gloo.solo.io.ProtocolUpgradeConfig.ProtocolUpgradeSpec "connect": .protocol_upgrade.options.gloo.solo.io.ProtocolUpgradeConfig.ProtocolUpgradeSpec ``` | Field | Type | Description | | -- | - | -- | | `websocket` | | Specification for websocket upgrade requests. Only one of `websocket` or `connect` can be set. | | `connect` | | Only one of `connect` or `websocket` can be set. | ```yaml "enabled": .google.protobuf.BoolValue ``` | Field | Type | Description | | -- | - | -- | | `enabled` | | Whether the upgrade should be enabled. If left unset, Envoy will enable the protocol upgrade. | <!-- 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: BFE (Orchestration & Management / Service Proxy)
File: command.md

bfe [options] -c &#60;config dir&#62; The root directory of configuration files, default directory is ./conf -l &#60;log dir&#62; The root directory of log files, default directory is ./log -s Print logs to stdout. By default, this flag is set false. -d Print debug logs. By default, this flag is set false. -v Display bfe version and exit. By default, this flag is set false. -V Display verbose version information and exit. By default, this flag is set false. -h Display help information and exit. By default, this flag is set false.
Project: Traefik (Orchestration & Management / API Gateway)
File: submitting-security-issues.md

title: "Traefik Security Documentation" description: "Security is a key part of Traefik Proxy. Read the technical documentation to learn about security advisories, CVE, and how to report a vulnerability." We strongly advise you to join our mailing list to be aware of the latest announcements from our security team. You can subscribe sending a mail to security+subscribe@traefik.io or on . Reported vulnerabilities can be found on . We want to keep Traefik safe for everyone. If you've discovered a security vulnerability in Traefik, we appreciate your help in disclosing it to us in a responsible manner, by creating a .
Project: Open Service Mesh (Orchestration & Management / Service Mesh)
File: wasm.md

OSM includes a to Envoy. It extends Envoy's statistics to enable and is built using the . Building the WASM module requires only Docker as a pre-requisite and is invoked as part of `make docker-build-osm-controller`. Each proxy is configured by xDS to add HTTP headers prefixed with `osm-` with the metadata required for the to each request and response, like workload name, namespace, etc. Because of the , response headers to add are configured by the router filter via RDS while request headers to add are configured via a Lua extension so that both sets of headers are made available to the WASM extension. Each proxy only knows about its own metadata, so metadata about the downstream proxy is read from request headers while metadata about the upstream proxy is read from response headers. Request durations represent the time between when stream context is created and ended/reset on the downstream proxy.
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: multi-volcano-schedulers.md

Sometimes we may want to the cluster be divided into multi sections for different usage. Each section can keep isolated. Each section include full scheduling capability. Support user monopolizing some nodes. System services can be scheduled in specific nodes. You should name each scheduler, and add `selector` to filter nodes. `selector`(label query) supports ':'.(e.g. --node-selector key1:value1,key2:value2) ```diff ... spec: containers: args: --logtostderr --scheduler-conf=/volcano.scheduler/volcano-scheduler.conf - --scheduler-name=gpu - --node-selector=zone:gpu -v=3 2>&1 ``` Controller need to specify multi `scheduler-name`s ```diff ... spec: containers: args: --logtostderr - --scheduler-name=volcano - --scheduler-name=gpu -v=4 2>&1 ``` ```diff apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: name: run-gpu spec: minAvailable: 3 schedulerName: gpu # need to specify scheduler name tasks: replicas: 3 name: worker template: metadata: name: worker spec: containers: image: tensorflow/tensorflow:latest-gpu name: tensorflow resources: requests: cpu: 1 memory: 10Gi nvidia.com/gpu: 2 ``` User also can use vc-scheduler to deploy system services by changing `schedulerName` from Deployment. ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: schedulerName: volcano containers: name: nginx image: nginx ```
Project: MetalLB (Orchestration & Management / Service Proxy)
File: taxonomy.en.md

+++ categories = ["taxonomy", "content"] tags = "tutorial" title = "Taxonomy" weight = 8 +++ The Relearn theme supports Hugo's default taxonomies tag and category out of the box. Just add tags and/or categories to any page. They can be given as a single string or an array of strings. {{< multiconfig fm=true >}} categories = ["taxonomy", "content"] tags = "tutorial" title = "Taxonomy" {{< /multiconfig >}} The tags are displayed at the top of the page in alphabetical order. The categories are displayed at the bottom of the page in alphabetical order in the default implementation of the theme but can be customized by providing your own `content-footer.html` partial. Each item is a link to a taxonomy page displaying all the articles with the given term. In the `hugo.toml` file you can add a shortcut to display all the tags and categories {{< multiconfig file=hugo >}} [[menu.shortcuts]] name = "<i class='fa-fw fas fa-tags'></i> Tags" url = "/tags" [[menu.shortcuts]] name = "<i class='fa-fw fas fa-layer-group'></i> Categories" url = "/categories" {{< /multiconfig >}} If you define and want to display a list of them somewhere on your page (often in the `layouts/partials/content-footer.html`) you can call a partial that does the job for you: ````go {{ partial "term-list.html" (dict "page" . "taxonomy" "categories" "icon" "layer-group" ) }} ```` | Name | Default | Notes | |--|--|-| | page | &lt;empty&gt; | Mandatory reference to the page. | | taxonomy | &lt;empty&gt; | The plural name of the taxonomy to display as used in your frontmatter. | | class | &lt;empty&gt; | Additional CSS classes set on the outermost generated HTML element.<br><br>If set to `tags` you will get the visuals for displaying the tags taxonomy, otherwise it will be a simple list of links as for the categories taxonomy. | | style | `primary` | The style scheme used if class is `tags`.<br><br>- by severity: `info`, `note`, `tip`, `warning`<br>- by brand color: `primary`, `secondary`, `accent`<br>- by color: `blue`, `green`, `grey`, `orange`, `red`<br>- by special color: `default`, `transparent`, `code` | | color | see notes | The to be used if class is `tags`. If not set, the chosen color depends on the style. Any given value will overwrite the default.<br><br>- for severity styles: a nice matching color for the severity<br>- for all other styles: the corresponding color | | icon | &lt;empty&gt; | An optional set to the left of the list. |
Project: hami (Orchestration & Management / Scheduling & Orchestration)
File: CONTRIBUTING.md

Welcome to HAMi! - - - - Please make sure to read and observe our . HAMi is a community project driven by its community which strives to promote a healthy, friendly and productive environment. Fork the repository on GitHub. Make your changes on your fork repository. Submit a PR. We will help you to contribute in different areas like filing issues, developing features, fixing critical bugs and getting your work reviewed and merged. If you have questions about the development process, feel free to . We are always in need of help, be it fixing documentation, reporting bugs or writing some code. Look at places where you feel best coding practices aren't followed, code refactoring is needed or tests are missing. Here is how you get started. There are within the HAMi organization. Each repository has beginner-friendly issues that provide a good first issue. For example, has and labels for issues that should not need deep knowledge of the system. We can help new contributors who wish to work on such issues. Another good way to contribute is to find a documentation improvement, such as a missing/broken link. Please see below for the workflow. When you are willing to take on an issue, just reply on the issue. The maintainer will assign it to you. While we encourage everyone to contribute code, it is also appreciated when someone reports an issue. Issues should be filed under the appropriate HAMi sub-repository. Example: a HAMi issue should be opened to . Please follow the prompted submission guidelines while opening an issue. Please do not ever hesitate to ask a question or send a pull request. This is a rough outline of what a contributor's workflow looks like: Create a topic branch from where to base the contribution. This is usually master. Make commits of logical units. Push changes in a topic branch to a personal fork of the repository. Submit a pull request to . Pull requests are often called simply "PR". HAMi generally follows the standard process. To submit a proposed change, please develop the code/fix and add new test cases. After that, run these local verifications before submitting pull request to predict the pass or fail of continuous integration. Run and pass `make verify` To make it easier for your PR to receive reviews, consider the reviewers will need you to: follow . write . break large changes into a logical series of smaller patches which individually make easily understandable changes, and in aggregate solve a broader issue.
Project: Gloo (Orchestration & Management / API Gateway)
File: unit-tests.md

Unit tests should be fully self-contained and not modify any global state All packages and any exported functions with non-trivial logic require unit tests The preferred method of testing multiple scenarios or input is table driven testing Tests using OS-specific features must clarify, using Concurrent unit test runs must pass Ensure that expected/actual are logged and if you can't see a difference, use a diff tool (like text-compare) Run with a debugger, adding breakpoints as close as possible to the unexpected behavior, and inspect relevant vars to confirm they appear as expected
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.22.5.md

We are delighted to present version v1.22.5 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. Update to Envoy v1.23.5. See the for more information about the content of the release. Update to Go v1.19.7. See the for more information. Update to golang.org/x/net@v0.8.0. Update to golang.org/x/image@v0.6.0. For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.22.5 is tested against Kubernetes 1.22 through 1.24. 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: Tengine (Orchestration & Management / Service Proxy)
File: ngx_http_user_agent.md

ngx\_http\_user\_agent\_module This module can analyse the header of User-Agent. This module is enabled by default. It can be disabled with the --without-httpuseragent_module configuration parameter. http { useragent $ngxbrowser { default unknown; greedy Firefox; Chrome 18.0+ chrome18; Chrome 17.0~17.9999 chrome17; Chrome 5.0- chrome_low; } } Syntax: user_agent $variable_name Default: none Context: http Set a variable whose value depends on the value of user_agent string.This block contains three parts, default, greedy and analysis items. Syntax: default value Default: none Context: user_agent block The default variable value if the user_agent string can't match any of the item. Syntax: greedy keyword Default: none Context: user_agent block If the keyword is greedy, it will continue to scan the user-agent string until it can find other item which is not greedy. If it can't find any other item, this keyword will be returned at last. e.g.: "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.112 Safari/535.1",this user_agent string will return Chrome13,if configuration file like this: greedy Safari; Chrome 13.0~13.9999 chrome13; Syntax: keyword version value Default: none Context: user_agent block keyword*: This is the word we want to match from the user_agent string. version*: the version of keyword. version\+:greater or equal should be matched; version\-:less or equal should be matched; version:equal should be matched; version1~version2:matched in [version1,version2]; value*:If this item is matched, the value will be filled to the defined variable.
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_delete_upstream.md

title: "glooctl delete upstream" weight: 5 delete an upstream usage: glooctl delete upstream [NAME] [--namespace=namespace] ``` glooctl delete upstream [flags] ``` ``` -h, --help help for upstream ``` ``` -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: 2016-08-23-mesos-1-0-1-released.md

layout: post title: Apache Mesos 1.0.1 Released permalink: /blog/mesos-1-0-1-released/ published: true post_author: display_name: Vinod Kone twitter: vinodkone tags: Release The latest Mesos release, 1.0.1, is now available for . This release includes some important bug fixes and improvements on top of 1.0.0. It is highly recommended to use this version if you are considering using Mesos 1.0. More specifically, this release includes the following fixes and improvements: MesosContainerizerLaunch flags execute arbitrary commands via shell. External links to .md files broken. Webui redirection to leader in browser does not work Stale socket FD usage when using libevent + SSL. mesos-agent --help exit status is 1 Ubuntu 14.04 LTS GPU Isolator "/run" directory is noexec Unable to run "scratch" Dockerfiles with Unified Containerizer. Agent's '--version' flag doesn't work Orphan tasks can show up as running after they have finished. Incremental http parsing of URLs leads to decoder error NvidiaVolume::create() should check for root before creating volume All non-root tests fail on GPU machine Linux 'MountInfoTable' entries not sorted as expected NvidiaVolume errors out if any binary is missing SSL Socket CHECK can fail after socket receives EOF PollSocketImpl can write to a stale fd. Make a sweep to trim excess space around angle brackets Remove HTTPPARSERVERSION_MAJOR < 2 code in decoder. Full release notes are available in the release Rolling upgrades from a Mesos 1.0.0 cluster to Mesos 1.0.1 are straightforward. Please refer to the for detailed information on upgrading to Mesos 1.0.1. We encourage you to try out this release and let us know what you think. If you run into any issues, please let us know on the . Thanks to the 12 contributors who made 1.0.1 possible Anand Mazumdar, Benjamin Mahler, Gilbert Song, Greg Mann, Jiang Yan Xu, Jie Yu, Joris Van Remoortere, Kevin Klues, Pierre Cheynier, Vinod Kone, haosdent huang and zhou xing.
Project: Gloo (Orchestration & Management / API Gateway)
File: solo-discovery-service.proto.sk.md

title: "solo-discovery-service.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> <!-- 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: gRPC (Orchestration & Management / Remote Procedure Call)
File: ABSEIL_MANUAL.md

This document explains how to use Abseil throughout gRPC. Note that this isn't supposed to explain general usage of Abseil. gRPC intends to use the LTS versions of Abseil only because it simplifies dependency management. Abseil is being distributed via package distribution systems such as vcpkg and cocoapods. If gRPC depends on the certain version that aren't registered, gRPC in that system cannot get the right version of Abseil when being built, resulting in a build failure. Therefore, gRPC will use the LTS version only, preferably the latest one. Most of Abseil libraries are okay to use but there are some exceptions because they're not going well yet on some of our test machinaries or platforms it supports. The following is a list of targets that are NOT ready to use. `absl/synchronization:*`: Blocked by b/186685878. `absl/random`: . You can use Abseil in gRPC Core and gRPC C++. But you cannot use it in the public interface of gRPC C++ because i) it doesn't gurantee no breaking API changes like gRPC C++ does and ii) it may make users change their build system to address Abseil.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: presto.md

| Datasource | Description | |-|--| | Datasource | Select Presto. | | Datasource Name | Enter the name of the datasource. | | Description | Enter a description of the datasource. | | IP/Host Name | Enter the Presto service IP. | | Port | Enter the Presto service port. | | Username | Set the username for Presto connection. | | Password | Set the password for Presto connection. | | Database Name | Enter the database name of the Presto connection. | | jdbc connect parameters | Parameter settings for Presto connection, in JSON format. | Yes, could use this datasource by default.
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.23.5.md

We are delighted to present version v1.23.5 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. Update to Envoy v1.24.5. See the for more information about the content of the release and details on the addressed CVEs can be found . Update to Go v1.19.8. See the for more information. For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.23.5 is tested against Kubernetes 1.23 through 1.25. 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 .