cwielenb/CNCF-Dataset huggingface dataset:
Project: Open Service Mesh (Orchestration & Management / Service Mesh)
File: issue_triage_guide.md

title: "Issue Triage" description: "Issue Triage Guide" type: docs This guide describes how to triage GitHub issues on the for Open Service Mesh (OSM). Identify the cause of the issue as explained Tag the issue with relevant labels. Relevant labels would include what area of the codebase the issue is most aligned with (ex. cli) or if it is a bug, label the issue with the bug label Prioritize the issue with a P1, P2 or P3 label (if possible) where: P1: product cannot ship. Should be addressed as soon as possible. Eg: high priority bug P2: Product cannot ship, but it does not need to be addressed immediately. Eg: high priority feature, lower priority bug P3: Resolution of the work item is optional based on resources, time, and risk. Eg: a nice to have feature If you have time and can resolve the issue, resolve it. If not, put links to the code to where you see the problem arising If the issue looks like it is a bug that needs to be resolved immediately, either fix the issue or reach out to the core maintainers to see if you can assign the issue to someone for follow up If it's a bug: Reproduce the issue to make sure it is an actual issue Label it with the `bug` label If possible, fix it or else reference links to the code If it's a question: Ask around, go through docs, etc. Label it with the `question` label Respond to the question If it's a feature request Ask/understand the use cases Label it with the `Improvement/Feature Request` label and add other appropriate labels
Project: SRPC (Orchestration & Management / Remote Procedure Call)
File: docs-04-client.md

Each Client corresponds to one specific target/one specific cluster Each Client corresponds to one specific network communication protocol Each Client corresponds to one specific IDL You can follow the detailed example below: Following the above example, the client is relatively simple and you can call the method directly. Use `Example::XXXClient` to create a client instance of some RPC. The IP+port or URL of the target is required. With the client instance, directly call the rpc function `Echo`. This is an asynchronous request, and the callback function will be invoked after the request is completed. For the usage of the RPC Context, please check . ~~~cpp using namespace srpc; int main() { Example::SRPCClient client("127.0.0.1", 1412); EchoRequest req; req.set_message("Hello!"); req.set_name("SRPCClient"); WFFacilities::WaitGroup wait_group(1); client.Echo(&req, { if (ctx->success()) printf("%s\n", response->DebugString().c_str()); else printf("status[%d] error[%d] errmsg:%s\n", ctx->getstatuscode(), ctx->geterror(), ctx->geterrmsg()); wait_group.done(); }); wait_group.wait(); return 0; } ~~~ Client can be started directly by passing in ip, port, or through client startup parameters. The above example: ~~~cpp Example::SRPCClient client("127.0.0.1", 1412); ~~~ is equivalent to: ~~~cpp struct RPCClientParams param = RPCCLIENTPARAMS_DEFAULT; param.host = "127.0.0.1"; param.port = 1412; Example::SRPCClient client(&param); ~~~ also equivalent to: ~~~cpp struct RPCClientParams param = RPCCLIENTPARAMS_DEFAULT; param.url = "srpc://127.0.0.1:1412"; Example::SRPCClient client(&param); ~~~ Note that `RPCCLIENTPARAMSDEFAULT` must be used to initialize the client's parameters, which contains a `RPCTaskParams`, including the default datatype, compresstype, retrymax and various timeouts. The specific struct can refer to .
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_remove.md

title: "glooctl remove" weight: 5 remove configuration items from a top-level Gloo resource ``` -h, --help help for remove --name string name of the resource to read or write -n, --namespace string namespace for reading or writing resources (default "gloo-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 --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - CLI for Gloo - Remove a Route from a Virtual Service
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: cluster.md

Cluster deployment is to deploy the DolphinScheduler on multiple machines for running massive tasks in production. If you are a new hand and want to experience DolphinScheduler functions, we recommend you install follow . If you want to experience more complete functions and schedule massive tasks, we recommend you install follow . If you want to deploy DolphinScheduler in production, we recommend you follow or . Cluster deployment uses the same scripts and configuration files as , so the preparation and deployment steps are the same as pseudo-cluster deployment. The difference is that pseudo-cluster deployment is for one machine, while cluster deployment (Cluster) is for multiple machines. And steps of "Modify Configuration" are quite different between pseudo-cluster deployment and cluster deployment. Configure all the configurations refer to on every machine, except sections `Prerequisites`, `Start ZooKeeper` and `Initialize the Database` of the `DolphinScheduler Startup Environment`. This step differs quite a lot from , because the deployment script transfers the required resources for installation to each deployment machine by using `scp`. So we only need to modify the configuration of the machine that runs `install.sh` script and configurations will dispatch to cluster by `scp`. The configuration file is under the path `bin/env/install_env.sh`, here we only need to modify section INSTALL MACHINE, DolphinScheduler ENV, Database, Registry Server and keep other sections the same as , the following describes the parameters that must be modified: ```shell ips="ds1,ds2,ds3,ds4,ds5" masters="ds1,ds2" workers="ds3:default,ds4:default,ds5:default" alertServer="ds4" apiServers="ds5" ``` Same as Same as
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_get_virtualservice.md

title: "glooctl get virtualservice" weight: 5 read a virtualservice or list virtualservices in a namespace usage: glooctl get virtualservice [NAME] [--namespace=namespace] [-o FORMAT] ``` glooctl get virtualservice [flags] ``` ``` -h, --help help for virtualservice ``` ``` -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) --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - Display one or a list of Gloo resources - get a list of routes for a given virtual service
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: tdm-plugin.md

In a co-located environment, some nodes are in both Kubernetes cluster and Yarn cluster. For these nodes, Kubernetes and Yarn cluster can use these resource by time-sharing multiplexing. For example, in 8:00~24:00 the on-line service in kubernetes can use these nodes. And in 0:00~8:00, kubernetes need evict the workload on these nodes, left the resource for Yarn cluster. First, we need mark out these nodes(by add `volcano.sh/revocable-zone` for nodes) which are in both Kubernetes cluster and Yarn cluster. We call these node are `revocable node`. For the kubernetes workload, we add `volcano.sh/preemptable: "true"` annotation for pod/podgroup to distinguish which pod can be dispatched to the `revocable node`. We call these pod are `preemptable task`. TDM plugin enhance the volcano time-sharing multiplexing resource ability. It will try to dispatch `preemptable task` to `revocable node` in node revocable time and evict the `preemptable task` from `revocable node` out of revocable time. Add `volcano.sh/preemptable` annotaion for Pod/PodGroup. For volcano job when add this annotaion in job level, Pod/PodGroup will inherit this annotation. The pod with `volcano.sh/preemptable: "true"` annotation can be dispatched to `revocable node`. Otherwise, the pod can not be dispatched to `revocable node`. Add `tdm` plugin and config for volcano scheduler. `tdm.revocable-zone` is a const prefix(), `rz1` is the revocable zone name and the value is a time frame. ``` tiers: plugins: name: tdm arguments: tdm.revocable-zone.rz1: 1:00-4:00 tdm.evict.period: 1m ``` Add `volcano.sh/revocable-zone: rz1` label for nodes. Nodes which have this label is a `revocable node`. The value indicates in which time period, the node can be used by kubernetes (run pod). Add `VictimTasksFn` for scheduler framework, it returns all the tasks which will be evicted in the scheduler period. TDM plugin: PredicateFn: For the `non-preemptable task`, they can not use `revocable nodes`; For the `preemptable task`, they can use `revocable node` in revocable time period, otherwise they also can not use the `revocable node`. NodeOrderFn: For the `preemptable task`, they preferred to use `revocable nodes` in revocable time period. VictimTasksFn: In 1VictimTasksFn1, the plugin can decide which tasks/pods should be evicted, e.g. based on Job/PodGroup info. PreemptableFn: When there is `non-preemptable task` pending, select appropriate `preemptable task` on `non-revocable nodes` to evict. Preempt action: This TDM plugin need work with preempt action. If does not config preempt action, TDM plugin will miss PreemptableFn.
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: recordio.md

title: Apache Mesos - RecordIO Data Format layout: documentation RecordIO is the name for a set of binary data exchange formats. The basic idea is to divide the data into individual chunks, called 'records', and then to prepend to every record its length in bytes, followed by the data. Since there is no formal specification of the RecordIO format, there tend to be slight incompatibilities between RecordIO implementations. Common differences include, for example, a magic value at the beginning of the stream to indicate the stream format, encoding the record length using fixed-size fields with native integers or extra fields to suppord compressed record content. Therefore, when using a third-party library, one needs to verify that the implementation matches the RecordIO format used by Mesos, as described below. The for a RecordIO-encoded streaming response is: ``` records = *record record = record-size LF record-data record-size = 1*DIGIT record-data = record-size(OCTET) ``` `record-size` should be interpreted as an unsigned 64-bit integer (`uint64`). For example, a stream may look like: ``` 128\n {"type": "SUBSCRIBED","subscribed": {"frameworkid": {"value":"12220-3440-12532-2345"},"heartbeatinterval_seconds":15.0}20\n {"type":"HEARTBEAT"}675\n ... ``` In pseudo-code, this could be parsed with something like the following: ``` while (true) { do { lengthBytes = readline() } while (lengthBytes.length < 1) messageLength = parseInt(lengthBytes); messageBytes = read(messageLength); process(messageBytes); } ``` Network intermediaries (e.g., proxies) are free to change the chunk boundaries; this should not have any effect on the recipient application. Within Mesos, RecordIO is used as data format for API endpoints that support streaming responses. The implementation expects the client to be aware of the following non-standard HTTP header fields when using such endpoints: The `Message-Accept` header must be set by clients that request a streaming response from the server by setting the `Accept` header to `application/recordio`. It specifies which media types the client accepts encoded in the RecordIO stream, and its content must have the same format as the standard HTTP `Accept` header. The `Message-Content-Type` is set by the server when streaming the response to an API call. It specifies the content type of the data encoded in the RecordIO stream and has the same format as the standard HTTP `Content-Type` header. Currently, the only supported MIME types for both header fields are `application/json` and `application/x-protobuf`.
Project: KubeGateway (Orchestration & Management / API Gateway)
File: PULL_REQUEST_TEMPLATE.md

What type of PR is this? Uncomment only one ` /kind <>` line, hit enter to put that in a new line, and remove leading whitespace from that line: /kind api-change /kind bug /kind cleanup /kind deprecation /kind design /kind documentation /kind failing-test /kind feature /kind flake What this PR does / why we need it: Which issue(s) this PR fixes: <!-- *Automatically closes linked issue when PR is merged. Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. If PR is about `failing-tests or flakes`, please post the related issues/tests in a comment and do not use `Fixes`* --> Fixes # Special notes for your reviewer: Does this PR introduce a user-facing change?: <!-- If no, just write "NONE" in the release-note block below. If yes, a release note is required: Enter your extended release note in the block below. If the PR requires additional action from users switching to the new release, include the string "action required". For more information on release notes see: https://git.k8s.io/community/contributors/guide/release-notes.md --> ```release-note ```
Project: Gloo (Orchestration & Management / API Gateway)
File: security.proto.sk.md

title: "security.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> These annotations indicate metadata for the purpose of understanding the security significance of fields. ```yaml "configureForUntrustedDownstream": bool "configureForUntrustedUpstream": bool ``` | Field | Type | Description | | -- | - | -- | | `configureForUntrustedDownstream` | `bool` | Field should be set in the presence of untrusted downstreams. | | `configureForUntrustedUpstream` | `bool` | Field should be set in the presence of untrusted upstreams. | <!-- 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: Armada (Orchestration & Management / Scheduling & Orchestration)
File: PULL_REQUEST_TEMPLATE.md

<!-- Thanks for sending a pull request! Here are some tips for you: <!-- *Automatically closes linked issue when PR is merged. Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. If PR is about `failing-tests or flakes`, please post the related issues/tests in a comment and do not use `Fixes`* --> Fixes #
Project: Gloo (Orchestration & Management / API Gateway)
File: server_name_matcher.proto.sk.md

title: "servernamematcher.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Matches a specific server name provided in the client request against a set server names configured for the matcher to handle, with possible prefix wildcard. ```yaml "serverNameMatchers": []envoy.config.matching.custommatchers.servername.v3.ServerNameMatcher.ServerNameSetMatcher ``` | Field | Type | Description | | -- | - | -- | | `serverNameMatchers` | | Match server names. Order doesn't matter, the most specific server name is matched. | Specifies a list of server names and a match action. ```yaml "serverNames": []string "onMatch": .xds.type.matcher.v3.Matcher.OnMatch ``` | Field | Type | Description | | -- | - | -- | | `serverNames` | `[]string` | A non-empty set of server names. Server name can start with a wildcard prefix, e.g. "*.example.com". | | `onMatch` | | Match action to apply when the input matches the server name. | <!-- 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: KubeAdmiral (Orchestration & Management / Scheduling & Orchestration)
File: code-style.md

KubeAdmiral uses for linting. All code should adhere to the rules specified in the . In order to check if your code adheres to our rules, you may use golangci-lint. First, ensure that you have golangci-lint installed. Then, run the following command: ```console $ golangci-lint run --timeout=2m --max-issues-per-linter=10 --go=1.19 ``` Logs play an important role when troubleshooting issues. Thus, it is also important to ensure that our logs are readable, navigable and doesn't devolve into noise. In order to achieve this, KubeAdmiral follows a set of logging conventions described below. Use of is REQUIRED. Klog is the de facto logging package for Kubernetes development. Use contextual logging whenever possible. `klog.FromContext` MUST be used to obtain a logger whenever there is a `Context` available. Consequently, top-level controllers or reconciliation workers MUST inject a logger into its `Context` using `klog.NewContext` before passing it to any nested calls. The injected logger MUST have the following values: `controller`: indicating the name of the controller `object`: indicating the qualified name of the object being reconciled `ftc` (if applicable): indicating the name of the controller's corresponding ftc Log messages MUST have the following format: MUST begin with a capital letter (with the exception of identifiers that conventionally begin with a lowercase) The ending period is MUST be omitted Use structured logging fields to record variable arguments is REQUIRED (as opposed to using format strings). Kebab case MUST be used for keys of structured logging fields. Use the appropriate log level based on the following rules: 0: reserved for errors, warnings and controller lifecycle logs 1: document "what happened" by describing effectual actions[^1] taken by a controller to reconcile an object (e.g. "Updating object placements") 2: document "how it happened" by describing non-effectual actions in a reconcile loop (e.g. "Creating scheduling profile", "Computing object placements") 3: any additional reconciliation logs that do not correspond to an action but still provide useful information 4: logs for non-controller code such as utility packages &ge;=5: can be used for debugging purposes, but MUST be removed before committing Log levels MUST only be set at the log call site, to prevent unexpected log levels due to addition. A loggable action MUST be logged in the present continuous tense (i.e. -ing) before it happens so that an immediate visual correlation between the action log and the error log is visible in case of errors. The successful result of such action MAY be logged as a separate message after the result is available.
Project: Open Cluster Management (Orchestration & Management / Scheduling & Orchestration)
File: CHANGELOG-v0.9.md

Add AddOnDeploymentConfig v1alpha1 API ( ) Add PlacementDisableAnnotation to disable scheduling for a placement( ) Add WorkConfiguration to config Work API( ) Deprecate ManagedClusterSet and ManagedClusterSetBinding v1beta2 API( ) N/A N/A Remove Placement and PlacementDecision v1alpha1 API( ) Remove ManagedClusterSet and ManagedClusterSetBinding v1alpha1 API( ) Deprecate ManagedClusterSet and ManagedClusterSetBinding v1beta1 API( ) Remove InstallModeDetached config( )
Project: BFE (Orchestration & Management / Service Proxy)
File: monitor.md

BFE has a variety of built-in metrics which can be exposed in various formats. Set monitor port in the BFE core configuration file (conf/bfe.conf). ```ini [Server] MonitorPort = 8421 ``` Visit the following address for a list of available metric categories ``` http://<addr>:8421/monitor ``` ``` http://<addr>:8421/monitor/<category> ``` Currently supported formats: kv json (default) Specify the format of the output like below: ``` http://<addr>:8421/monitor/proxy_state?format=prometheus ```
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: validation.md

Validating request payloads and providing meaningful error messages to consumers of an API can go a long way to provide a better developer experience. Instead of just receiving a 40X response without further details, it can help immensely to know what was actually wrong in the payload - missing properties? incorrect formatting? etc. Writing the code on the server is tedious and often overlooked, making it harder for both consumers and testers to resolve issues they might have when working with your API. Kusk Gateway provides end-user friendly validation against the provided OpenAPI definition automatically, without requiring the implementer of the API to write any code, saving development time for both BE and API consumers. Enabling validation is straight-forward - simply add the corresponding x-kusk property to your OpenAPI definition: ```yaml x-kusk: validation: request: enabled: ``` Adding this at the global level will ensure all incoming requests are validated against the corresponding OpenAPI definition in regard to request parameters and payload. If the request does not match the specified metadata, a meaningful error is returned to the user without any request being forward to your actual API implementation. Another positive side effect of this functionality is that it provides a "security-gate" for your API; malicious requests that are outside your defined operations will not reach the target service where they could do potential harm. See all available validation configuration options in the . Strict validation means that the request body must conform exactly to the schema specified in your OpenAPI spec. Any fields not in the schema will cause the validation to fail the request/response. To enable this, please add the following field to your schema block if the request body is of type `object`: ```yaml paths: /todos/{id}: ... patch: ... requestBody: content: application/json: schema: type: object additionalProperties: false properties: title: type: string completed: type: boolean order: type: integer format: int32l ```