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

title: "glooctl edit" weight: 5 Edit a Gloo resource ``` -h, --help help for edit --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 ``` ``` -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 - - root command for settings - edit an upstream in a namespace - edit a virtualservice in a namespace
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: cpu-careful-regulation.md

@ProgramerGu; September 15, 2020 On the basis of kubernetes scheduling, the CPU fine core binding scheduling function of multi specification pod without manual intervention is realized to meet the needs of users for high-performance instances and CPU core binding, and 500 virtual machines on-line for 1 minute are guaranteed/ On this basis, the cluster resources should be balanced as much as possible to improve the utilization rate of CPU & MEM resources. Output CPU fine binding core scheduling function to the community. node ``` apiVersion: v1 kind: Node metadata: name: annotations: "cpu-map":'{"socket1": ["1", "2"],"socket2": ["11", "12"]}' labels: status: allocatable: cpu: "40" memory: 171301360Ki capacity: cpu: "48" memory: 196569584Ki ... ``` pod ``` apiVersion: v1 kind: Pod metadata: annotations: cpu-set: one-socket "cpu-map":'{"socket1": ["1"],"socket2": ["11"]}' //"cpu-map":'{"socket1": ["1","2"]}' labels: name: namespace: spec: resources: limits: requests: cpu: "2" ``` Declare to implement the scheduleextender interface build node cachebuild cpu map managedResources: is pod annotation Declare cpu-set? implement the filter interface Filter circular serial call: pass the filter results to the next extender, remote filtering interface: return results priority interface(It can be left out of consideration at the initial stage) parallel priority statistics merge priority result priority interface call: return results binding phase update pod to write the selected CPU device result to the pod's annotation ("CPU map": '{"Socket1": ["1", "2"]) call the bind function and write suggesthost Plugin-pod binds the core according to the CPU device map specified in pod annotation Kubevirt binds the core according to the CPU device map specified in pod annotation
Project: Gloo (Orchestration & Management / API Gateway)
File: local_ratelimit.proto.sk.md

title: "local_ratelimit.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Configures the token bucket, used for rate limiting. Ref. https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/networkfilters/localratelimitfilter ```yaml "maxTokens": int "tokensPerFill": .google.protobuf.UInt32Value "fillInterval": .google.protobuf.Duration ``` | Field | Type | Description | | -- | - | -- | | `maxTokens` | `int` | The maximum tokens that the bucket can hold. This is also the number of tokens that the bucket initially contains. Must be greater than or equal to one. | | `tokensPerFill` | | The number of tokens added to the bucket during each fill interval. If not specified, defaults to a single token. Must be greater than zero. | | `fillInterval` | | The fill interval that tokens are added to the bucket. During each fill interval tokensperfill are added to the bucket. The bucket will never contain more than maxtokens tokens. The fillinterval must be >= 50ms and defaults to 1 second. | The Local Rate Limit settings define the default local rate limit token bucket to apply as well as other configurations ```yaml "defaultLimit": .local_ratelimit.options.gloo.solo.io.TokenBucket "localRateLimitPerDownstreamConnection": .google.protobuf.BoolValue "enableXRatelimitHeaders": .google.protobuf.BoolValue ``` | Field | Type | Description | | -- | - | -- | | `defaultLimit` | | The token bucket configuration to use for rate limiting requests. These options provide the ability to locally rate limit the connections in envoy. Each request processed by the filter consumes a single token. If the token is available, the request will be allowed. If no tokens are available, the request will receive the configured rate limit status. This default limit can be overridden in the vHost or route options.localRatelimit. | | `localRateLimitPerDownstreamConnection` | | Specifies the scope of the rate limiters token bucket. If set to false, the token bucket is shared across all worker threads, thus the rate limits are applied per Envoy process. If set to true, a token bucket is allocated for each connection, thus the rate limits are applied per connection thereby allowing one to rate limit requests on a per connection basis. This setting applies to all token buckets in the vHost and route as well. Defaults to false. | | `enableXRatelimitHeaders` | | Set this to true to return Envoy's X-RateLimit headers to the downstream. reference docs here: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/common/ratelimit/v3/ratelimit.proto#envoy-v3-api-enum-extensions-common-ratelimit-v3-xratelimitheadersrfcversion This setting applies at the vHost and route local rate limit as well Defaults to false. | <!-- 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: kratos (Orchestration & Management / Remote Procedure Call)
File: README.md

eware for Kratos This middleware helps you to catch panics and report them to You could check the full demo in example folder. ```go // Step 1: // init sentry in the entry of your application import "github.com/getsentry/sentry-go" sentry.Init(sentry.ClientOptions{ Dsn: "<your dsn>", AttachStacktrace: true, // recommended }) // Step 2: // set middleware import ksentry "github.com/go-kratos/kratos/contrib/errortracker/sentry/v2" // for HTTP server, new HTTP server with sentry middleware options var opts = []http.ServerOption{ http.Middleware( recovery.Recovery(), tracing.Server(), ksentry.Server(ksentry.WithTags(map[string]interface{}{ "tag": "some-custom-constant-tag", "trace_id": tracing.TraceID(), // If you want to use the TraceID valuer, you need to place it after the A middleware. })), // must after Recovery middleware, because of the exiting order will be reversed logging.Server(logger), ), } // for gRPC server, new gRPC server with sentry middleware options var opts = []grpc.ServerOption{ grpc.Middleware( recovery.Recovery(), tracing.Server(), ksentry.Server(ksentry.WithTags(map[string]interface{}{ "tag": "some-custom-constant-tag", "trace_id": tracing.TraceID(), // If you want to use the TraceID valuer, you need to place it after the A middleware. })), // must after Recovery middleware, because of the exiting order will be reversed logging.Server(logger), ), } // Then, the framework will report events to Sentry when your trigger panics. // Or your can push events to Sentry manually ```
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: kyuubi.md

| Datasource | Description | |-|--| | Datasource | Select KYUUBI. | | Datasource name | Enter the name of the DataSource. | | Description | Enter a description of the DataSource. | | IP/Host Name | Enter the KYUUBI service IP. | | Port | Enter the KYUUBI service port. | | Username | Set the username for KYUUBI connection. | | Password | Set the password for KYUUBI connection. | | Database name | Enter the database name of the KYUUBI connection. | | Jdbc connection parameters | Parameter settings for KYUUBI connection, in JSON format. | ```Kerberos Authentication just simply configure them in the connection parameters if kerberos authentication is required. clientKeytab: path of Kerberos keytab file for client authentication clientPrincipal: Kerberos principal for client authentication serverPrincipal: Kerberos principal configured by kyuubi.kinit.principal at the server side. ``` Yes, could use this datasource by default.
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_edit_upstream.md

title: "glooctl edit upstream" weight: 5 edit an upstream in a namespace usage: glooctl edit upstream [NAME] [--namespace=namespace] ``` glooctl edit upstream [flags] ``` ``` -h, --help help for upstream --ssl-remove Remove SSL configuration from this upstream --ssl-secret-name string name of the ssl secret for this upstream --ssl-secret-namespace string namespace of the ssl secret for this upstream --ssl-sni string SNI value to provide when contacting this 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") -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
Project: Open Cluster Management (Orchestration & Management / Scheduling & Orchestration)
File: RELEASE.md

The `yaml` Project 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: ssl-performance.md

The SSL requirement of gRPC isn't necessarily making it easy to integrate. The HTTP/2 protocol requires ALPN support, which is a fairly new handshake protocol only supported by recent implementations. As a result, we've tried hard to provide a smooth experience to our users when compiling and distributing gRPC, but this may come at performance costs due to this. More specifically, we will sometime build the SSL library by disabling assembly code (by setting the `OPENSSLNOASM` option), which can impact performance by an order of magnitude when processing encrypted streams. Build system | Condition | Platform | Uses assembly optimizations |||-- Makefile | with OpenSSL 1.0.2 development files | all | :heavycheckmark: Makefile | all other cases | all | :x: Bazel | | Linux | :heavycheckmark: Bazel | | MacOS | :heavycheckmark: Bazel | | Windows | :x: CMake | boringssl from submodule (default) | Linux or MacOS | :heavycheckmark: CMake | boringssl from submodule (default), generator=Ninja | Windows | :heavycheckmark: CMake | boringssl from submodule (default), generator=Visual Studio | Windows | :x: CMake | pre-installed OpenSSL 1.0.2+ (`gRPCSSLPROVIDER=package`) | all | :heavycheckmark: In addition, we are shipping packages for language implementations. These packages are source packages, but also have pre-built binaries being distributed. Building packages from source may give a different result in some cases. Language | From source | Platform | Uses assembly optimizations ||| C# | n/a | Linux, 64bit | :heavycheckmark: C# | n/a | Linux, 32bit | :x: C# | n/a | MacOS | :heavycheckmark: C# | n/a | Windows | :heavycheckmark: Node.JS | n/a | Linux | :heavycheckmark: Node.JS | n/a | MacOS | :heavycheckmark: Node.JS | n/a | Windows | :x: Electron | n/a | all | :heavycheckmark: ObjC | Yes | iOS | :x: PHP | Yes | all | Same as the `Makefile` case from above PHP | No | all | :x: Python | n/a | Linux, 64bit | :heavycheckmark: Python | n/a | Linux, 32bit | :x: Python | n/a | MacOS, 64bit | :heavycheckmark: Python | n/a | MacOS, 32bit | :x: Python | n/a | Windows | :x: Ruby | No | all | :x:
Project: kcp (Orchestration & Management / Scheduling & Orchestration)
File: architecture.md

The virtual workspace apiserver is based on k8s.io/apiserver and bundles multiple delegated apiservers into a single apiserver. Usual k8s.io/apiserver delegation would mean a common filter chain and hence common authentication common authorization common OpenAPI endpoint all APIs under the same /apis/<group>. common discovery endpoints In other words, an apiserver delegation chain serves one workspace only. For virtual workspace apiserver in contrast, we need to serve multiple workspaces, i.e. common authentication, as above, this is fine, but independent (custom) authorization independent OpenAPI endpoint <some-prefix>/openapi independent sets of APIs under <some-prefix>/apis/<group> independent discovery endpoints <some-prefix>/apis. On the other hand, we want to keep using k8s.io/apiserver. To make this work with the upper requirements, the handler chain will a) inject the virtual workspace into the context b) rewrite the request path to remove the virtual workspace prefix. The delegated apiserver will wrap the s.Handler's director (which usually decides which requests to pass to gorestful) and check for the virtual workspace name in the context. If it matches, the request is forwarded to the original director, and otherwise the request is passed on to the delegate. the authorizer needs a switch by virtual workspace, to implement custom authorization priority & fairnesss, if enabled, would not be by virtual workspace
Project: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: 0001-record-architecture-decisions.md

Date: 16/04/2017 Accepted We need to record the architectural decisions made on this project. We will use Architecture Decision Records, as . In order to make this easier to handle, should be used to create new entries, as well as to supersede existing ones. In a nutshell: ADRs are basically lightweight RFCs. We will keep a collection of records for "architecturally significant" decisions: those that affect the structure, non-functional characteristics, dependencies, interfaces, or construction techniques. The files are similar to this one (plaintext, same structure). ADRs are numbered sequentially. Numbers will not be reused. A decision will be considered immutable* (except for the status). Amendments go to a new ADR that supersedes the old one. If a decision is reversed or changed, the original file is kept around, but marked as superseded. Use `adr` for doing that -- e.g., `adr new -s 12 Use PostgreSQL Database` (see `adr help new`) -- in order to do this with a consistent style (the ADR's status is changed and links are inserted). See Michael Nygard's article, linked above.
Project: Gloo (Orchestration & Management / API Gateway)
File: stats.proto.sk.md

title: "stats.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> This plugin provides additional configuration options to expose statistics. ```yaml "virtualClusters": []stats.options.gloo.solo.io.VirtualCluster ``` | Field | Type | Description | | -- | - | -- | | `virtualClusters` | | Virtual clusters allow exposing additional statistics for traffic served by a Virtual Host. | Virtual clusters allow you to expose statistics for virtual host traffic that matches certain criteria. This is useful because what the application considers to be an endpoint does often not map directly to the routing configuration, so Envoy does not emit per endpoint statistics. Using virtual clusters you can define logical endpoints and have Envoy emit dedicated statistics for any matching request. Virtual cluster statistics are emitted on the downstream side and thus include network level failures. Please note that virtual clusters add overhead to the processing of each requests and should not be overused. ```yaml "name": string "pattern": string "method": string ``` | Field | Type | Description | | -- | - | -- | | `name` | `string` | The name of the virtual cluster. This value will be used together with the virtual host name to compute the name of the statistics emitted by this virtual cluster. Statistics names will be in the form: vhost.<virtual host name>.vcluster.<virtual cluster name>.<stat name>. See for more information about the statistics emitted when virtual cluster configurations are specified. Note: This string should not contain any dots ("."), as this is a reserved character for Envoy statistics names. Any dot present in the virtual cluster name will be replaced with an underscore ("_") character by Gloo. | | `pattern` | `string` | The regex pattern used by Envoy to decide whether to expose statistics for a particular request. Please note that the entire path of the request must match the regex (e.g. the regex `/rides/d+` matches the path `/rides/0`, but not `/rides/123/456`). The regex grammar used is defined . | | `method` | `string` | If specified, statistics will be exposed only for requests matching the given HTTP method. | <!-- 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: Gloo (Orchestration & Management / API Gateway)
File: artifact.proto.sk.md

title: "artifact.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Top-Level Resource Gloo Artifacts are used by Gloo to store small bits of binary or file data. Certain options such as the gRPC option read and write artifacts to one of Gloo's configured storage layer. Artifacts can be backed by files on disk, Kubernetes ConfigMaps, and Consul Key/Value pairs. Supported artifact backends can be selected in Gloo's boostrap options. ```yaml "data": map<string, string> "metadata": .core.solo.io.Metadata ``` | Field | Type | Description | | -- | - | -- | | `data` | `map<string, string>` | Raw data data being stored. | | `metadata` | | Metadata contains the object metadata for this resource. | <!-- 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 bRPC (Orchestration & Management / Remote Procedure Call)
File: builtin_service.md

Builtin services expose internal status of servers in different pespectives, making development and debugging over brpc more efficient. brpc serves builting services via HTTP, which can be easily accessed through curl and web browsers. Servers respond plain text or html according to `User-Agent` in the request header, or you may append `?console=1` to the uri to force the server to respond in plain text. Check the running on our dev machine(only accessible from Baidu internal) for more details. If the port is forbidden from where you run curl or web browser (e.g. not all ports are accessible from a web browser inside Baidu), you can use for proxying. Following 2 screenshots show accesses to builtin services from a web browser and a terminal respectively. Note that the logo is the codename inside Baidu, and being modified to brpc in opensourced version. From a web browser From a terminal To avoid potential attacks and information leaks, builtin services must be hidden on servers that may be accessed from public, including the ones proxied by nginx or other http servers. Click for more details. : displays brief status of all services. : lists user-customizable counters on miscellaneous metrics. : lists all connections and their stats. : lists all gflags, some of them are modifiable at run-time. : traces all RPCs. : analyzes CPU hotspots. : shows how memory are allocated. : analyzes lock contentions. shows version of the server. Call Server::setversion() to specify version of the server, or brpc would generate a default version like `brpcserver<service-name1><service-name2> ...` shows whether this server is alive or not. shows scheme of all protobuf messages inside the server. shows all the that can be enabled(not working with glog). /dir: browses all files on the server, convenient but too dangerous, disabled by default. /threads: displays information of all threads of the process, hurting performance significantly when being turned on, disabled by default.