cwielenb/CNCF-Dataset huggingface dataset:
Project: APISIX (Orchestration & Management / API Gateway)
File: ext-plugin-pre-req.md

title: ext-plugin-pre-req keywords: Apache APISIX API Gateway Plugin ext-plugin-pre-req description: This document contains information about the Apache APISIX ext-plugin-pre-req Plugin. <!-- --> The `ext-plugin-pre-req` Plugin is for running specific external Plugins in the Plugin Runner before executing the built-in Lua Plugins. See to learn more. :::note Execution of External Plugins will affect the behavior of the current request. ::: | Name | Type | Required | Default | Valid values | Description | |-||-||--|| | conf | array | False | | [{"name": "ext-plugin-A", "value": "{\"enable\":\"feature\"}"}] | List of Plugins and their configurations to be executed on the Plugin Runner. | | allow_degradation | boolean | False | false | | Sets Plugin degradation when the Plugin Runner is not available. When set to `true`, requests are allowed to continue. | The example below enables the `ext-plugin-pre-req` Plugin on a specific Route: :::note You can fetch the `admin_key` from `config.yaml` and save to an environment variable with the following command: ```bash adminkey=$(yq '.deployment.admin.adminkey[0].key' conf/config.yaml | sed 's/"//g') ``` ::: ```shell curl -i http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "uri": "/index.html", "plugins": { "ext-plugin-pre-req": { "conf" : [ {"name": "ext-plugin-A", "value": "{\"enable\":\"feature\"}"} ] } }, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } }' ``` Once you have configured the External Plugin as shown above, you can make a request to execute the Plugin: ```shell curl -i http://127.0.0.1:9080/index.html ``` This will reach the configured Plugin Runner and the `ext-plugin-A` will be executed. To remove the `ext-plugin-pre-req` Plugin, you can delete the corresponding JSON configuration from the Plugin configuration. APISIX will automatically reload and you do not have to restart for this to take effect. ```shell curl http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "uri": "/index.html", "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } }' ```
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: LICENSE.md

Copyright (C) 2014 by Oleku Konko Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: c-style-guide.md

GRPC C STYLE GUIDE ===================== Background Here we document style rules for C usage in the gRPC Core library. General Layout rules are defined by clang-format, and all code should be passed through clang-format. A (docker-based) script to do so is included in . Header Files Public header files (those in the include/grpc tree) should compile as pedantic C89. Public header files should be includable from C++ programs. That is, they should include the following: ```c extern "C" { / ... body of file ... / } ``` Header files should be self-contained and end in .h. All header files should have a `#define` guard to prevent multiple inclusion. To guarantee uniqueness they should be based on the file's path. For public headers: `include/grpc/grpc.h` `GRPCGRPCH` For private headers: `src/core/lib/channel/channel_stack.h` `GRPCCORELIBCHANNELCHANNELSTACKH` Variable Initialization -- When declaring a (non-static) pointer variable, always initialize it to `NULL`. Even in the case of static pointer variables, it's recommended to explicitly initialize them to `NULL`. C99 Features Variable sized arrays are not allowed. Do not use the 'inline' keyword. Flexible array members are allowed (https://en.wikipedia.org/wiki/Flexiblearraymember). Comments -- Within public header files, only `/ /` comments are allowed. Within implementation files and private headers, either single line `//` or multi line `/ /` comments are allowed. Only one comment style per file is allowed however (i.e. if single line comments are used anywhere within a file, ALL comments within that file must be single line comments). Symbol Names Non-static functions must be prefixed by `grpc_` Static functions must not be prefixed by `grpc_` Typenames of `struct`s , `union`s, and `enum`s must be prefixed by `grpc_` if they are declared in a header file. They must not be prefixed by `grpc_` if they are declared in a source file. Enumeration values and `#define` names must be uppercase. All other values must be lowercase. Enumeration values or `#define` names defined in a header file must be prefixed with `GRPC_` (except for `#define` macros that are being used to substitute functions; those should follow the general rules for functions). Enumeration values or `#define`s defined in source files must not be prefixed with `GRPC_`. Multiple word identifiers use underscore as a delimiter, never camel case. E.g. `variable_name`. Functions The use of is in forbidden in libgrpc.
Project: k8gb (Orchestration & Management / Coordination & Service Discovery)
File: admiralty.md

Combination of k8gb and admiralty.io provides powerful global multi-cluster capabilities. Admiralty will globally schedule. And k8gb will globally balance. This tutorial covers local end-to-end integration quick start of two projects. Just follow https://admiralty.io/docs/quick_start ```sh helm repo add k8gb https://www.k8gb.io kubectl --context kind-eu create ns k8gb helm --kube-context kind-eu --namespace k8gb upgrade --install k8gb k8gb/k8gb --set k8gb.clusterGeoTag=eu --set k8gb.extGslbClustersGeoTags=us kubectl --context kind-us create ns k8gb helm --kube-context kind-us --namespace k8gb upgrade --install k8gb k8gb/k8gb --set k8gb.clusterGeoTag=us --set k8gb.extGslbClustersGeoTags=eu ``` It will install k8gb instances to both Target clusters. Notice the GeoTag configuration. ```sh helm --kube-context kind-cd upgrade --install podinfo podinfo/podinfo --set replicaCount=2 --set ingress.enabled=true ``` Edit `podinfo` Deployment to add Admiralty `multicluster.admiralty.io/elect` scheduling Annotation to Pod spec template ```sh kubectl edit deploy podinfo ``` The Pod template spec part should look similar to ```yaml ... template: metadata: annotations: prometheus.io/port: "9898" prometheus.io/scrape: "true" multicluster.admiralty.io/elect: "" creationTimestamp: null ... ``` Observe that pods were scheduled to Target cluster the application of Annotation patch. ```sh kubectl --context kind-us get pod NAME READY STATUS RESTARTS AGE podinfo-557c458ddb-9qpjf-l29w6 1/1 Running 0 11s kubectl --context kind-eu get pod NAME READY STATUS RESTARTS AGE podinfo-557c458ddb-9nkmx-p7z9r 1/1 Running 0 15s ``` Observe that associated Ingress has also followed the Pods to the Target clusters ```sh kubectl --context kind-eu get ing NAME CLASS HOSTS ADDRESS PORTS AGE podinfo <none> * 80 10m kubectl --context kind-eu get ing NAME CLASS HOSTS ADDRESS PORTS AGE podinfo <none> * 80 10m ``` Observer that there are no Gslb resources in the Target clusters ```sh kubectl --context kind-eu get gslb No resources found in default namespace. kubectl --context kind-us get gslb No resources found in default namespace. ``` Add k8gb strategy annotation to the Ingress object in the Source cluster ```sh kubectl annotate ing podinfo k8gb.io/strategy=roundRobin ``` Observe that Gslb resources were properly created ```sh kubectl --context kind-eu get gslb NAME AGE podinfo 102s kubectl --context kind-us get gslb NAME AGE podinfo 69s ``` Note: it's not a real working k8gb setup but just a way to demonstrate multi-cluster Gslb CR propagation with Admiralty. Please refer to https://www.k8gb.io/ documentation to create fully working real-life Gslb setup.
Project: hami (Orchestration & Management / Scheduling & Orchestration)
File: offline-install.md

For some cluster that don't have external web access, you can install HAMi by the following step: Refer to until step 'Install and Uninstall' copy the source of project into the master node in your cluster, placed in a path like "/root/HAMi" pull the following images and save them into a '.tar' file, then move it into the master node in your cluster Image list: ``` projecthami/hami:{HAMi version} docker.io/jettech/kube-webhook-certgen:v1.5.2 liangjw/kube-webhook-certgen:v1.1.1 registry.cn-hangzhou.aliyuncs.com/google_containers/kube-scheduler:{your kubernetes version} ``` ``` docker pull {iamge} && docker save {imagename} -o {imagename}.tar ``` Load these images using docker load, tag these images with your registry, and push them into your registry ``` docker load -i {image_name}.tar docker tag projecthami/hami:{HAMi version} {registry}/hami:{HAMi version} docker push {registry}/hami:{HAMi version} ``` edit the following field in /root/HAMi/chart/vgpu/values.yaml to your image pushed ``` scheduler.kubeScheduler.image scheduler.extender.image scheduler.patch.image scheduler.patch.imageNew scheduler.devicePlugin.image scheduler.devicePlugin.monitorimage ``` Execute the following command in your /root/HAMi/chart folder ``` helm install hami hami --set scheduler.kubeScheduler.imageTag={your k8s server version} -n kube-system ``` Verify your installation execute the following command ``` kubectl get pods -n kube-system ``` If you can see both the 'device-plugin' and 'schduler' running, then HAMi is installed successfully, as the figure shown below: <img src="./develop/imgs/offline_validation.png" width = "600" />
Project: KEDA (Orchestration & Management / Scheduling & Orchestration)
File: design.md

This document outlines the design for this package. The `Topology` type handles monitoring the state of a MongoDB deployment and selecting servers. Updating the description is handled by finite state machine which implements the server discovery and monitoring specification. A `Topology` can be connected and fully disconnected, which enables saving resources. The `Topology` type also handles server selection following the server selection specification. The `Server` type handles heartbeating a MongoDB server and holds a pool of connections. Connections are handled by two main types and an auxiliary type. The two main types are `connection` and `Connection`. The first holds most of the logic required to actually read and write wire messages. Instances can be created with the `newConnection` method. Inside the `newConnection` method the auxiliary type, `initConnection` is used to perform the connection handshake. This is required because the `connection` type does not fully implement `driver.Connection` which is required during handshaking. The `Connection` type is what is actually returned to a consumer of the `topology` package. This type does implement the `driver.Connection` type, holds a reference to a `connection` instance, and exists mainly to prevent accidental continued usage of a connection after closing it. The connection implementations in this package are conduits for wire messages but they have no ability to encode, decode, or validate wire messages. That must be handled by consumers. The `pool` type implements a connection pool. It handles caching idle connections and dialing new ones, but it does not track a maximum number of connections. That is the responsibility of a wrapping type, like `Server`. The `pool` type has no concept of closing, instead it has concepts of connecting and disconnecting. This allows a `Topology` to be disconnected,but keeping the memory around to be reconnected later. There is a `close` method, but this is used to close a connection. There are three methods related to getting and putting connections: `get`, `close`, and `put`. The `get` method will either retrieve a connection from the cache or it will dial a new `connection`. The `close` method will close the underlying socket of a `connection`. The `put` method will put a connection into the pool, placing it in the cache if there is space, otherwise it will close it.
Project: Kuma (Orchestration & Management / Service Mesh)
File: 025-disable-default-policies.md

Status: Accepted Technical Story: https://github.com/kumahq/kuma/issues/3346 Everytime a mesh is created, we also create a set of default policies (TrafficPermission, Retry, Timeout, etc...). It's useful in a number of scenarios to be able to disable that default creation of policies selectively. Overload the `skipDefaultMesh` switch to also mean disabling the creation of all default policies (as suggested ). Add a binary (yes / no) `disableDefaultPolicies` option to the `Mesh` object. Add individual switches (e.g. `disableDefaultTrafficPermission`) for each policy. Add `skipCreatingInitialDefaultPolicies` []string field to allow comma-separated list of policies to skip. Chosen option: 4. Add `skipCreatingInitialDefaultPolicies` []string field to allow comma-separated list of policies to skip. More granular control over what's created (good for testing as well) Predictable, understandable behavior Only adds a single additional field to Mesh configuration CSV string fields can be a bit messy, but there is precedent in the codebase (`kumactl install observability --components`). This field is immutable once set, for the following reasons: Unpredictable / undesirable behavior (deleting policies) once the Mesh is created / in-use. The main probable use-case for this setting is to aid programmatic / automated flows for creating a Mesh with a 'blank slate'. In light of the above, name of the flag changed to `skipCreatingInitialDefaultPolicies`. Below is how the new fields would look on a `Mesh` object: ```protobuf // Mesh defines configuration of a single mesh. message Mesh { option (kuma.mesh.resource).name = "MeshResource"; option (kuma.mesh.resource).type = "Mesh"; // ... // List of policies to skip creating by default when the mesh is created. // e.g. TrafficPermission, MeshRetry, etc. repeated string skipCreatingInitialDefaultPolicies = 8; } ``` New configuration would look like: ```yaml skipCreatingInitialDefaultPolicies: "MeshTrafficPermission" "MeshRetry" ``` The `skipCreatingInitialDefaultPolicies` list can also contain a wildcard `*` entry which will skip all default policies. E.g. ```yaml skipCreatingInitialDefaultPolicies: "*" ```
Project: Armada (Orchestration & Management / Scheduling & Orchestration)
File: ui.md

Armada bundles a web UI referred to as Lookout. To understand its components see the In short, Lookout is made of two components: Lookout API: a Go service that provides an API to the Armada backend Lookout UI: a React application that provides a web interface to the Lookout API After running `mage localdev full` and `mage ui`, the Lookout UI should be accessible through your browser at `http://localhost:8089` You can also re-build a production build of the UI by running `mage ui` in the root of the repo. To quickly get started developing on the UI locally without having to build, ensure you have Docker, NPM and Yarn installed for your platform, then run: ```bash cd ./internal/lookout/ui yarn install yarn run openapi yarn start ``` This will start a live development server on . Note that this will require the Lookout V2 API and other Armada components to run as well in order to work. However, you can use fake data to develop locally without requiring any other component to run. In order to use fake data, navigate to the V2 tab, then specify `fakeData=` in the query parameters. Or, navigate to You can also enable the debug view by adding the `debug=` query parameter to the URL. Equivalently, navigate to This displays the TanStack table state as a JSON string, at the bottom of the page. Make sure you scroll at the bottom to see it. Note that you can have both `fakeData` and `debug` query parameters enabled at the same time:
Project: Fluid (Orchestration & Management / Scheduling & Orchestration)
File: accelerate_s3_minio.md

Start a standalone Minio locally as a remote S3 service. This example is for demonstration purposes only, not production ```shell docker run -ti -p 9000:9000 --name minio minio/minio server /data ``` ``` Endpoint: http://172.17.0.8:9000 http://127.0.0.1:9000 RootUser: minioadmin RootPass: minioadmin Browser Access: http://172.17.0.8:9000 http://127.0.0.1:9000 Command-line Access: https://docs.min.io/docs/minio-client-quickstart-guide $ mc alias set myminio http://172.17.0.8:9000 minioadmin minioadmin Object API (Amazon S3 compatible): Go: https://docs.min.io/docs/golang-client-quickstart-guide Java: https://docs.min.io/docs/java-client-quickstart-guide Python: https://docs.min.io/docs/python-client-quickstart-guide JavaScript: https://docs.min.io/docs/javascript-client-quickstart-guide .NET: https://docs.min.io/docs/dotnet-client-quickstart-guide Detected default credentials 'minioadmin:minioadmin', please change the credentials immediately using 'MINIOROOTUSER' and 'MINIOROOTPASSWORD' IAM initialization complete ``` ```shell $ mc mb myminio/fluid $ mc cp fluid/* myminio/fluid/ ``` ```yaml apiVersion: data.fluid.io/v1alpha1 kind: Dataset metadata: name: demo spec: mounts: mountPoint: s3://spark/fluid-data name: spark options: alluxio.underfs.s3.endpoint: http://{{$demo-minio-addr}}:9000 alluxio.underfs.s3.disable.dns.buckets: "true" alluxio.underfs.s3.inherit.acl: "false" encryptOptions: name: aws.accessKeyId valueFrom: secretKeyRef: name: mysecret key: aws.accessKeyId name: aws.secretKey valueFrom: secretKeyRef: name: mysecret key: aws.secretKey ``` create minio accessKeyId and accessKey ```yaml apiVersion: v1 kind: Secret metadata: name: mysecret stringData: aws.accessKeyId: minioadmin aws.secretKey: minioadmin ``` ```yaml apiVersion: data.fluid.io/v1alpha1 kind: AlluxioRuntime metadata: name: demo spec: replicas: 1 tieredstore: levels: mediumtype: MEM path: /dev/shm quota: 20M high: "0.95" low: "0.7" ``` ```yaml apiVersion: v1 kind: Pod metadata: name: demo-app spec: containers: name: demo image: nginx:latest volumeMounts: mountPath: /data name: demo volumes: name: demo persistentVolumeClaim: claimName: demo ``` ```shell $ k apply -f dataset.yaml $ k apply -f secret.yaml $ k apply -f runtime.yaml $ k apply -f pod.yaml $ k exec -ti demo-app sh $ ls /data data-mesh-in-practice-how-europes-leading-online-platform-for-fashion-goes-beyond-the-data-lake-iteblog.com.pdf data-science-across-data-sources-with-apache-arrow-iteblog.com.pdf from-hdfs-to-s3-migrate-pinterest-apache-spark-clusters-iteblog.com.pdf running-apache-spark-jobs-using-kubernetes-iteblog.com.pdf running-apache-spark-on-kubernetes-best-practices-and-pitfalls-iteblog.com.pdf scaling-data-and-ml-with-apache-spark-and-feast-iteblog.com.pdf using-ai-to-support-proliferating-merchant-changes-iteblog.com.pdf ```
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-configuration-apiportalheader.md

Add a list of name/value to display in the API aside. The name could be used as is, or could be a translated key. To add a translation, you need to update the json file (see on ). The value can also be a "hard coded" value, or you can use templating like in documentation pages. See following examples: | Name | Value | |--|--| | api.version | `${api.version}` | | api.endpoint | `${api.proxy.contextPath}` | | api.publishedAt | `${(api.deployedAt?date)!}` | | My hard coded name | `My hard coded value` | You are able to combine API attributes, metadata and strings. Additionally, the `API Page list options` section allows you to decide whether the top ranked API for the given environment should be emphasised at the top of the list.
Project: etcd (Orchestration & Management / Coordination & Service Discovery)
File: reporting_bugs.md

If any part of the etcd project has bugs or documentation mistakes, please let us know by . We treat bugs and mistakes very seriously and believe no issue is too small. Before creating a bug report, please check that an issue reporting the same problem does not already exist. To make the bug report accurate and easy to understand, please try to create bug reports that are: Specific. Include as many details as possible: which version, what environment, what configuration, etc. If the bug is related to running the etcd server, please attach the etcd log (the starting log with the etcd configuration is especially important). Reproducible. Include the steps to reproduce the problem. We understand some issues might be hard to reproduce, please include the steps that might lead to the problem. If possible, please attach the affected etcd data dir and stack trace to the bug report. Isolated. Please try to isolate and reproduce the bug with minimum dependencies. It would significantly slow down the speed to fix a bug if too many dependencies are involved in a bug report. Debugging external systems that rely on etcd is out of scope, but we are happy to provide guidance in the right direction or help with using etcd itself. Unique. Do not duplicate existing bug reports. Scoped. One bug per report. Do not follow up with another bug inside one report. It may be worthwhile to read before creating a bug report. We might ask for further information to locate a bug. A duplicated bug report will be closed. ``` bash $ kill -QUIT $PID ``` ``` bash $ etcd --version ``` ``` bash $ sudo systemctl cat etcd2 $ sudo journalctl -u etcd2 ``` Due to an upstream systemd bug, journald may miss the last few log lines when its processes exit. If journalctl says etcd stopped without a fatal or panic message, try `sudo journalctl -f -t etcd2` to get the full log.
Project: hami (Orchestration & Management / Scheduling & Orchestration)
File: roadmap.md

| feature | description | release | Example | Example expected behaviour | |--|-||--|| | Kubernetes schedule layer | Support Resource Quota for vgpu-memory | v3.2.0 | "requests.nvidia.com/gpu-memory: 30000" in ResourceQuota | Pods in this namespace can allocate up to 30G device memory in this namespace | | | Support Best-fit, idle-first, Numa-first Schedule Policy | v3.2.0 | add "scheduler policy configmap" | execute schedule policy according to configMap | | | Support k8s 1.28 version with compatable to v1.16 | v3.1.0 | | | | Add more Heterogeneous AI computing device | HuaWei Ascend Support | v3.1.0 | | | | | Iluvatar GPU support | v3.1.0 | | | | |Teco DPU Support | v3.2.0 | | |