cwielenb/CNCF-Dataset huggingface dataset:
Project: Gloo (Orchestration & Management / API Gateway)
File: gloo.solo.io.project.sk.md

title: "gloo.solo.io.project" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> API Version: `gloo.solo.io.v1` Gloo is a high-performance, plugin-extendable, platform-agnostic API Gateway built on top of Envoy. Gloo is designed for microservice, monolithic, and serverless applications. By employing function-level routing, Gloo can completely decouple client APIs from upstream APIs at the routing level. Gloo serves as an abstraction layer between clients and upstream services, allowing front-end teams to work independently of teams developing the microservices their apps connect to. <!-- 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: 3Scale (Orchestration & Management / API Gateway)
File: ISSUE_TEMPLATE.md

[provide a description of the issue] [provide output of the `nginx -V` or `openresty -V` command from openshift/local terminal] [provide timestamp of the docker image from `docker inspect --format='{{.Created}}' quay.io/3scale/apicast:master` ] [step 1 (json configuration file, if applies)] [step 2 (curl commands to reproduce, if applies)] [step 3] [Gist with minimal reproducible configuration, see guidelines for contributing for details] [Gist with nginx log output]
Project: OpenFunction (Orchestration & Management / Scheduling & Orchestration)
File: development-workflow.md

Visit https://github.com/OpenFunction/OpenFunction Click `Fork` button to create a fork of the project to your GitHub account. Per Go's , place OpenFunction code on your `GOPATH` using the following cloning procedure. Define a local working directory: ```shell export working_dir=$GOPATH/src/openfunction.io export user={your github profile name} ``` Create your clone locally: ```shell mkdir -p $working_dir cd $working_dir git clone https://github.com/$user/OpenFunction.git cd $working_dir/OpenFunction git remote add upstream https://github.com/OpenFunction/OpenFunction.git git remote set-url --push upstream no_push git remote -v ``` ```shell git fetch upstream git checkout main git rebase upstream/main ``` Create a branch from master: ```shell git checkout -b myfeature ``` Then edit code on the `myfeature` branch. You can refer to while writing code. Currently, the make rules only contain simple checks such as vet, unit test, will add e2e tests soon. For Linux OS, you can download and execute this . For MacOS, you can install KubeBuilder by following this . Run `make help` for additional information on these make targets. ```shell make all make test ``` We recommend using the following commands for e2e testing: You need to first look at the `test/e2e_env` file, which serves to provide the necessary environment variables for the e2e testing process. You must complete the configuration of these environment variables before you can run the e2e test. ```shell DOCKERHUB_USERNAME= DOCKERHUB_PASSWORD= DOCKERHUBREPOPREFIX= ``` You can run all e2e tests with a single command: ```shell make e2e ``` You can also run e2e test on individual functions: ```shell make e2e-knative make e2e-async make e2e-plugin make e2e-events ``` After the test is completed, it is a good practice to keep your local in sync with upstream to avoid conflicts. ```shell git checkout main git rebase upstream/main git checkout new_feature git rebase -i main ``` *Note:* A script is provided in the `hack` directory to generate the certificate information required by the webhook and you can execute it using the following command. This script can generate certificates for a lifetime of 3650 days, so we recommend not running it until OpenFunction's certificate has expired. ```shell cd hack && bash generate-cert.sh ``` ```shell git add <file> git commit -s -m "add your description" ``` When ready to review (or just to establish an offsite backup of your work), push your branch to your fork on GitHub: ```shell git push -f ${yourremotename} myfeature ``` Visit your fork at https://github.com/$user/OpenFunction Click the` Compare & Pull Request` button next to your myfeature branch. Check out the for more details and advice.
Project: APISIX (Orchestration & Management / API Gateway)
File: ext-plugin-post-req.md

title: ext-plugin-post-req keywords: Apache APISIX Plugin ext-plugin-post-req description: This document contains information about the Apache APISIX ext-plugin-post-req Plugin. <!-- --> `ext-plugin-post-req` differs from the Plugin in that it runs after executing the built-in Lua Plugins and before proxying to the Upstream. You can learn more about the configuration from the Plugin document.
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_version.md

title: "glooctl version" weight: 5 Print current version Get the version of Glooctl and Gloo ``` glooctl version [flags] ``` ``` -h, --help help for version -n, --namespace string namespace for reading or writing resources (default "gloo-system") -o, --output OutputType output format: (yaml, json, table, kube-yaml, wide) (default json) ``` ``` -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
Project: Kubeflow (Orchestration & Management / Scheduling & Orchestration)
File: policies-and-procedures.md

Currently the team is working to finalize this work and have it completed for the 1.8 Release and for the transition to the CNCF. These policies and procedures will be based of the We are working on updating and editing these policies and procedures for the Kubeflow Community. Our very rough DRAFT and working docs can be found . Kubeflow Security Team - Please note this is only a WORKING Document. We are always looking for Kubeflow community users and contributors to help us. If you would like to help the security team with these docs or other items please consider doing the following: Join the Kubeflow Slack Security Channel: #security Join our meetings bi-weekly on the Wednesday's at 8am Pacific/10am Central. (To find out what that is in your time zone go to . This meeting is on the Kubeflow community calendar; however if you would like to be added to the invite please reach out to Amber Graner on Slack (@akgraner) The invite information is also pinned to the security slack channel. Meeting Notes: If you would like to see what we have previously discussed you can see the meetings folder in the security folder or you can go to our
Project: APISIX (Orchestration & Management / API Gateway)
File: control-plane-service-discovery.md

title: Control Plane Service Discovery keywords: API Gateway Apache APISIX ZooKeeper Nacos APISIX-Seed description: This documentation describes implementing service discovery through Nacos and ZooKeeper on the API Gateway APISIX Control Plane. <!-- --> This document describes how to implement service discovery with Nacos and Zookeeper on the APISIX Control Plane. Apache APISIX has supported Data Plane service discovery in the early days, and now APISIX also supports Control Plane service discovery through the project. The following figure shows the APISIX-Seed architecture diagram. The specific information represented by the figures in the figure is as follows: Register an upstream with APISIX and specify the service discovery type. APISIX-Seed will watch APISIX resource changes in etcd, filter discovery types, and obtain service names. APISIX-Seed subscribes the specified service name to the service registry to obtain changes to the corresponding service. After the client registers the service with the service registry, APISIX-Seed will obtain the new service information and write the updated service node into etcd; When the corresponding resources in etcd change, APISIX worker will refresh the latest service node information to memory. :::note It should be noted that after the introduction of APISIX-Seed, if the service of the registry changes frequently, the data in etcd will also change frequently. So, it is best to set the `--auto-compaction` option when starting etcd to compress the history periodically to avoid etcd eventually exhausting its storage space. Please refer to . ::: Network topology becomes simpler APISIX does not need to maintain a network connection with each registry, and only needs to pay attention to the configuration information in etcd. This will greatly simplify the network topology. Total data volume about upstream service becomes smaller Due to the characteristics of the registry, APISIX may store the full amount of registry service data in the worker, such as consul_kv. By introducing APISIX-Seed, each process of APISIX will not need to additionally cache upstream service-related information. Easier to manage Service discovery configuration needs to be configured once per APISIX instance. By introducing APISIX-Seed, Apache APISIX will be in different to the configuration changes of the service registry. ZooKeeper and Nacos are currently supported, and more service registries will be supported in the future. For more information, please refer to: . If you want to enable control plane ZooKeeper service discovery, please refer to: . If you want to enable control plane Nacos service discovery, please refer to: .
Project: Fluid (Orchestration & Management / Scheduling & Orchestration)
File: multiple-client-support.md

Fluid using kube-openapi and swagger-codegen to support multiple clients, including Java and Python. Java Client: https://github.com/fluid-cloudnative/fluid-client-java ```shell $ cd $GOPATH/src/github.com/fluid-cloudnative $ hack/sdk/gen-sdk.sh ``` `hack/sdk/gen-sdk.sh` script will generate Java and Python client in sdk folder. If you want to generate other client, You can modify script by adding these code: ```shell java -jar ${SWAGGERCODEGENJAR} generate -i ${SWAGGERCODEGENFILE} -l <language> -o ${JAVASDKOUTPUTPATH} -c ${SWAGGERCODEGEN_CONF} --model-package com.github.fluid-cloudnative.fluid ``` It is suggested that you should use ApiClient and CustomObjectsApi from io.kubernetes:client-java. The only thing you should import from fluid-cloudnative.fluid:fluid-client-java is com.github.fluid_cloudnative.fluid.* ```java import io.kubernetes.client.openapi.ApiClient; import io.kubernetes.client.openapi.apis.CustomObjectsApi; import com.github.fluid_cloudnative.fluid.*; public class MyExample { // generate this client from a kubeconfig file or something else ApiClient apiClient; public void createAlluxioRuntime(String namespace, AlluxioRuntime runtime) throws ApiException { CustomObjectsApi customObjectsApi = new CustomObjectsApi(apiClient); customObjectsApi.createNamespacedCustomObject( AlluxioRuntime.group, AlluxioRuntime.version, namespace, AlluxioRuntime.plural, runtime, "true" ); } public AlluxioRuntime getAlluxioRuntime(String namespace, String name) throws Exception { CustomObjectsApi customObjectsApi = new CustomObjectsApi(apiClient); Object obj = customObjectsApi.getNamespacedCustomObject( AlluxioRuntime.group, AlluxioRuntime.version, namespace, AlluxioRuntime.plural, name ); Gson gson = new JSON().getGson(); return gson.fromJson(gson.toJsonTree(obj).getAsJsonObject(), AlluxioRuntime.class); } /* Note that currently ClientJava can only support merge-patch+json */ public void patchAlluxioRuntime(String namespace, String name, String patchBody) throws ApiException { CustomObjectsApi customObjectsApi = new CustomObjectsApi(apiClient); customObjectsApi.patchNamespacedCustomObject( AlluxioRuntime.group, AlluxioRuntime.version, namespace, AlluxioRuntime.plural, name, patchpatchBody.getBytes()ody ); } } ```
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: question.md

name: Ask a question about: Ask a question labels: kind/question, priority/P3, untriaged PLEASE DO NOT POST A QUESTION HERE. This form is for bug reports and feature requests ONLY! For general questions and troubleshooting, please ask/look for answers at StackOverflow, with "grpc" tag: https://stackoverflow.com/questions/tagged/grpc For questions that specifically need to be answered by gRPC team members, please ask/look for answers at grpc.io mailing list: https://groups.google.com/forum/#!forum/grpc-io This issue will be closed down once seen by the repo managers.
Project: Apache Thrift (Orchestration & Management / Remote Procedure Call)
File: HeaderFormat.md

<link href="http://kevinburke.bitbucket.org/markdowncss/markdown.css" rel="stylesheet"></link> Header format for the THeader.h =============================== 0 1 2 3 4 5 6 7 8 9 a b c d e f 0 1 2 3 4 5 6 7 8 9 a b c d e f +-+ | 0| LENGTH | +-+ | 0| HEADER MAGIC | FLAGS | +-+ | SEQUENCE NUMBER | +-+ | 0| Header Size(/32) | ... Header is of variable size: (and starts at offset 14) +-+ | PROTOCOL ID (varint) | NUM TRANSFORMS (varint) | +-+ | TRANSFORM 0 ID (varint) | TRANSFORM 0 DATA ... +-+ | ... ... | +-+ | INFO 0 ID (varint) | INFO 0 DATA ... +-+ | ... ... | +-+ | | | PAYLOAD | | | +-+ The `LENGTH` field is 32 bits, and counts the remaining bytes in the packet, NOT including the length field. The header size field is 16 bits, and defines the size of the header remaining NOT including the `HEADER MAGIC`, `FLAGS`, `SEQUENCE NUMBER` and header size fields. The Header size field is in bytes/4. The transform ID's are varints. The data for each transform is defined by the transform ID in the code - no size is given in the header. If a transform ID is specified from a client and the server doesn't know about the transform ID, an error MUST be returned as we don't know how to transform the data. Conversely, data in the info headers is ignorable. This should only be things like timestamps, debugging tracing, etc. Using the header size you should be able to skip this data and read the payload safely if you don't know the info ID. Info's should be oldest supported to newest supported order, so that if we read an info ID we don't support, none of the remaining info ID's will be supported either, and we can safely skip to the payload. Info ID's and transform ID's should share the same ID space. Header will be padded out to next 4-byte boundary with `0x00`. Max frame size is `0x3FFFFFFF`, which is slightly less than `HTTP_MAGIC`. This allows us to distinguish between different (older) transports. ZLIB_TRANSFORM 0x01 - No data for this. Use zlib to (de)compress the data. HMAC_TRANSFORM 0x02 - Variable amount of mac data. One byte to specify size. Mac data is appended at the end of the packet. SNAPPY_TRANSFORM 0x03 - No data for this. Use snappy to (de)compress the data. INFO_KEYVALUE 0x01 - varint32 number of headers. key/value pairs of varstrings (varint16 length plus no-trailing-null string). Implementations MUST NOT alter either key or value in any way.
Project: Linkerd (Orchestration & Management / Service Mesh)
File: ROADMAP.md

This document is intended to describe high-level plans for the Linkerd project and is neither comprehensive nor prescriptive. For a more granular view of planned work, please refer to the project's upcoming [milestones]. Following best practices, Custom Resource Definitions are being migrated to their own helm chart As we identify new primitives/patterns for server-side configuration, we plan to replace the current `ServiceProfile` APIs with new client-side primitives that support the existing resources as well as: Circuit-breakers Non-cluster-local traffic targets TLS requirements Route-Specific Authorization Outbound Route Configuration Header-based Routing Linkerd's mTLS identity only works for resources managed by Kubernetes. We plan to extend Linkerd to support non-Kubernetes workloads. The OpenMetrics working group is developing a new standard for metric exposition. We plan to support this format and follow best practices identified by this project. The foundation for this feature exists in the multi-cluster gateway which provides connectivity between clusters using the multi-cluster extension. As the need for tighter ingress integration develops, the gateway functionality will develop into a multi-purpose entry point for traffic entering the cluster, reducing the dependency on features and development cycles for current ingress providers. <!-- references -->
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: global.md

Global parameters can be configured on the workflow definition page. The `IN` direction parameter is valid for all task nodes of the entire workflow. The `OUT` direction parameter is the output parameter of the workflow and passed to the downstream task of the corresponding SubProcess task in the parent workflow. The specific use method can be determined according to the actual production situation. This example uses a shell task to print out the date value of yesterday. Create a shell task and enter `echo ${dt}` in the script content. In this case, dt is the global parameter we need to declare. As shown below: Set global parameter: On the workflow definition page, click the plus sign to the right of "Set Global", after filling in the variable name and value, save it. Note: The dt parameter defined here can be referenced by the local parameters of any other node. On the task instance page, you can check the log to verify the execution result of the task and determine whether the parameters are valid.
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: workarounds.md

This document lists the workarounds implemented on gRPC servers for record and reference when users need to enable a certain workaround. Workaround ID: WORKAROUND\ID\CRONET\_COMPRESSION Date added: May 06, 2017 Status: Implemented in C core and C++ Issue: Before version v1.3.0-dev, gRPC iOS client's Cronet transport did not implement compression. However the clients still claim to support compression. As a result, a client fails to parse received message when the message is compressed. The problem above was resolved in gRPC v1.3.0-dev. For backward compatibility, a server must forcingly disable compression for gRPC clients of version lower than or equal to v1.3.0-dev. Workaround Description: Implemented as a server channel filter in C core. The filter identifies the version of peer client with incoming `user-agent` header of each call. If the client's gRPC version is lower that or equal to v1.3.x, a flag GRPCWRITENOCOMPRESS is marked for all sendmessage ops which prevents compression of the messages to be sent out.
Project: Azure Service Fabric (Orchestration & Management / Scheduling & Orchestration)
File: help.md

Use these props files to set the appropriate configuration for each Visual C++ that requires the Windows SDK or the Windows WDK toolset. This also includes the Razzle-based Windows libs. To use these files, determine first the type of artifact you're trying to build. This can be either kernel or user mode, and a driver (.sys extension), static library (.lib extension) or dynamic library (DLL). Then, import the corresponding file under the `props/` folder. This will also add the correct Windows SDK include directory and additional libs, from the property files under the `props/imports/` path. *Note, the files in `props/imports/` should not be imported directly by a project.* The following sections describe the individual imports. A kernel driver. An example is the KTL Logger itself. This will produce a `.sys` file. A user mode test that requires the use of `TAEF.exe`. This is commonly the logger tests. User mode tools that run as an executable. Commonly a static lib, but can be any configuration type. Always user mode. Use this if you only require the standard headers and libraries. A project that can describe either a user mode console test or a user mode dynamic library. Use this if you're writing a new test that does not require `TAEF.exe`.
Project: KEDA (Orchestration & Management / Scheduling & Orchestration)
File: 4_release_tracker.md

name: KEDA Release Tracker about: Template to keep track of the progress for a new KEDA release. title: "Release: " labels: governance,release-management assignees: tomkerkhove,zroubalik,jorturfer This issue template is used to track the rollout of a new KEDA version. For the full release process, we recommend reading . [ ] List items that are still open, but required for this release We aim to release this release in the week of <week range, example March 27-31>. [ ] Prepare changelog are up-to-date template - [ ] Update k8s go modules and pin to the 2nd most recent minor version [ ] Check if new Go has been released and if KEDA can be safely built by it [ ] Create KEDA release [ ] Publish new documentation version [ ] Setup continuous container scanning with Snyk [ ] Prepare & ship Helm chart [ ] Prepare next release [ ] Provide update in Slack [ ] Tweet about new release
Project: Tyk (Orchestration & Management / API Gateway)
File: PULL_REQUEST_TEMPLATE.md

<!-- Provide a general summary of your changes in the Title above --> <!-- Describe your changes in detail --> <!-- This project only accepts pull requests related to open issues. --> <!-- If suggesting a new feature or change, please discuss it in an issue first. --> <!-- If fixing a bug, there should be an issue describing it with steps to reproduce. --> <!-- OSS: Please link to the issue here. Tyk: please create/link the JIRA ticket. --> <!-- Why is this change required? What problem does it solve? --> <!-- Please describe in detail how you tested your changes --> <!-- Include details of your testing environment, and the tests --> <!-- you ran to see how your change affects other areas of the code, etc. --> <!-- This information is helpful for reviewers and QA. --> <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> [ ] Bug fix (non-breaking change which fixes an issue) [ ] New feature (non-breaking change which adds functionality) [ ] Breaking change (fix or feature that would cause existing functionality to change) [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality) <!-- Go over all the following points, and put an `x` in all the boxes that apply --> <!-- If there are no documentation updates required, mark the item as checked. --> <!-- Raise up any additional concerns not covered by the checklist. --> [ ] I ensured that the documentation is up to date [ ] I explained why this PR updates go.mod in detail with reasoning why it's required [ ] I would like a code coverage CI quality gate exception and have explained why
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: pigeon.md

Pigeon is a task used to trigger remote tasks, acquire logs or status by calling remote WebSocket service. It is DolphinScheduler uses a remote WebSocket service to call tasks. Click `Project Management -> Project Name -> Workflow Definition`, and click the `Create Workflow` button to enter the DAG editing page. Drag from the toolbar <img src="../../../../img/pigeon.png" width="20"/> to the canvas to create a new Pigeon task. Please refer to `Default Task Parameters` section for default parameters. | Parameter | Description | ||| | Target task name | Target task name of this Pigeon node. |