cwielenb/CNCF-Dataset huggingface dataset:
Project: wasmCloud (Orchestration & Management / Scheduling & Orchestration)
File: README.md

s repository contains a hello world HTTP component, written in . This component: Uses Typescript for it's implementation Uses the standard WIT definitions Relies on the (which exposes the ) Return `"hello from Typescript"` to all HTTP requests Can be declaratively provisioned with This relies on the following installed software: | Name | Description | | | -- | | `wash` | controls your host instances and enables building components | | `npm` | which manages packages for for the NodeJS ecosystem | | `node` | (see `.nvmrc` for version) | If you have the basic dependencies installed, you can install NodeJS-level dependcies: ```console npm install ``` To start a wasmcloud host you can use `wash`: ```console wash up ``` This command won't return (as it's the running host process), but you can view the output of the host. To build the , we can use `wash`: ```console wash build ``` This will build and sign the component and place a signed at `build/index_s.wasm`. `build` performs many substeps (see `package.json` for details): (`build:tsc`) transpiles Typescript code into Javascript code (`build:js`) builds a javascript module runnable in NodeJS from a using the (`build:component`) build and sign a WebAssembly component for this component using `wash` To start the component, HTTP server provider and everything we need to run: ```console npm run wadm:start ``` This command will deploy the application to your running wasmcloud host, using , a declarative WebAssembly orchestrator. To send a request to the running component (via the HTTP server provider): ```console curl localhost:8081 ``` [!NOTE] Confused as to why it is port 8081? See `typescript-http-hello-world.wadm.yaml` for more information on the pieces of the architecture; components, providers, and link definitions. To quickly reload your application after changing the code in `index.ts`: ```console npm run reload ``` To learn how to extend this example with additional capabilities, see the section of the wasmCloud documentation. | | UNKNOWN | string | | | JSON | string | | | XID | string | | | CID | string | | | XML | string | | | BYTEA | bytes | | | UUID | string | uuid converted to string | | TIMESTAMP | string | RFC3339 format, in UTC | | DATE | string | | | TIME | string | | | INET | string | ip address converted to string | | BIT | bytes | bit vectors converted to byte array | | * | bytes | All other types returned as raw byte array | Note that NULL values are not currently supported. If any query results contain null values, the results are undefined and will likely generate errors. If you are querying tables that contain null values, modify the SELECT query to replace NULLs with another value of the same data type as the column. Build with 'make'. Test with 'make test'.
Project: Knative (Orchestration & Management / Scheduling & Orchestration)
File: feature-request.md

name: Feature Request about: Create a feature request for knative/serving title: '' labels: kind/feature assignees: '' <!-- If you need to report a security issue with Knative, send an email to knative-security@googlegroups.com. --> <!-- Remove the '> ' to select /area API /area autoscale /area build /area monitoring /area networking /area test-and-release Other classifications: /kind good-first-issue /kind process /kind spec -->
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: sub-process.md

The sub-process node is to execute an external workflow definition as a task node. 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/tasks/icons/sub_process.png" width="15"/> task node to canvas to create a new SubProcess task. Please refer to `Default Task Parameters` section for default parameters. | Parameter | Description | ||| | Child node | It is the workflow definition of the selected sub-process. Enter the child node in the upper right corner to jump to the workflow definition of the selected sub-process. | This example simulates a common task type, here we use a child node task to recall the to print out "hello". This means executing a shell task as a child node. Create a shell task to print "hello" and define the workflow as `test_dag01`. To use the subprocess, you need to create the sub-node task, which is the workflow `testdag01` we created in the first step. After that, as shown in the diagram below, select the corresponding sub-node in position . After creating the sub_process, create a corresponding shell task for printing "world" and link both together. Save the current workflow and run it to get the expected result. When using `subprocess` to recall a sub-node task, you need to ensure that the defined sub-node is online status, otherwise, the subprocess workflow will not work properly.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: alert_plugin_user_guide.md

In version 2.0.0, users need to create alert instances, and needs to choose an alarm policy when defining an alarm instance, there are three options: send if the task succeeds, send on failure, and send on both success and failure. when the workflow or task is executed, if an alarm is triggered, calling the alarm instance send method needs a logical judgment, which matches the alarm instance with the task status, executes the alarm instance sending logic if it matches, and filters if it does not match. When create alert instances then associate them with alert groups. Alert group can use multiple alert instances. The alarm module supports the following scenarios: <img src="../../../../img/alert/alertscenariosen.png"> Steps to be used are as follows: Go to `Security -> Alarm Group Management -> Alarm Instance Management -> Alarm Instance`. Select the corresponding alarm plug-in and fill in the relevant alarm parameters. Select `Alarm Group Management`, create an alarm group, and choose the corresponding alarm instance. You can click `Test Send` button to test whether the alarm instance is configured correctly.
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: dashboard-cmd.md

Kusk provides a Kusk Dashboard command to expose and navigate easily to the Kusk Gateway Dashboard in the browser. `kusk dashboard` will start a port-forward session on port 8080, by default, to the envoyfleet serving the dashboard and will open the dashboard in the browser. By default this is kusk-gateway-private-envoy-fleet.kusk-system. If you installed all the components using `kusk install` without changing any of the default values, running `kusk dashboard` will be sufficient to open the dashboard. The flags --envoyfleet.namespace and --envoyfleet.name can be used to change the envoyfleet. | Flag | Description | Required? | |::|:--:|::| | `--kubeconfig` | absolute path to kube config | | | `--envoyfleet.name` | kusk gateway dashboard envoy fleet service name. (default: kusk-gateway-private-envoy-fleet) | | | `--envoyfleet.namespace` | kusk gateway dashboard envoy fleet service namespace. (default: kusk-system) | | | `--external-port` | external port to access dashboard at. (default: 8080) | | ``` $ kusk dashboard ``` Opens the Kusk Dashboard in the browser by exposing the default private envoy fleet on port 8080 ``` $ kusk dashboard --envoyfleet.namespace=other-namespace --envoyfleet.name=other-envoy-fleet ``` Specify other envoyfleet and namespace that is serving the dashboard ``` $ kusk dashboard --external-port=9090 ``` Expose dashboard on port 9090 ``` $ kusk dashboard --kubeconfig=/path/to/kube/config ``` Specify path to kube config. $HOME/.kube/config is used by default.
Project: Apache Thrift (Orchestration & Management / Remote Procedure Call)
File: pull_request_template.md

<!-- Explain the changes in the pull request below: --> <!-- We recommend you review the checklist/tips before submitting a pull request. --> ticket? (, not required for trivial changes) [ ] If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"? [ ] Did you squash your changes to a single commit? (not required, but preferred) [ ] Did you do your best to avoid breaking changes? If one was needed, did you label the Jira ticket with "Breaking-Change"? [ ] If your change does not involve any code, include `[skip ci]` anywhere in the commit message to free up build resources. <!-- The Contributing Guide at: https://github.com/apache/thrift/blob/master/CONTRIBUTING.md has more details and tips for committing properly. -->
Project: Envoy (Orchestration & Management / Service Proxy)
File: BACKPORTS.md

As documented in , the individual(s) on backports rotation are responsible for doing backports for security releases, and other qualifying backports. Backports rotation folks should make sure they have rights (ask one of the to give you access if you do not otherwise have it), and regularly triage issues, either removing the backports-review tag and adding backports-approved, or pushing back in comments for why the issue does not qualify based on For approved PRs, the person on rotation should backport them to supported binaries, based on the support window also in The individual can be checked out per normal github workflow, and reviews for backport PRs sent to the original PR author and/or reviewers for approval. See as an example backport, referencing the original PR See the for git commands to backport an example patch. Backports rotation assignee may or may not be the fix lead for a given security release. When the maintainer team kicks off a security release, the fix lead should add backports rotation to the release-specific slack channel for general coordination, and one of the should grant access to repo. As issues tagged are merged into main, the backports folks are responsible for backporting to the supported releases. In this case, fix lead is responsible for kicking off the actual release branches. For security backports best-practices include creating a patch per backport to make sure they individually pass CI, and then creating one rollup patch which is those patches combined, to make sure they merge cleanly.
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: mock-cmd.md

Spin up a local mocking server that generates responses from your content schema or returns your defined examples. Kusk uses to launch a mock server container. All you need to get started is your OpenAPI definition. Let's mock the following API using Kusk. ```yaml openapi: 3.0.0 info: title: todo-backend-api version: 0.0.2 paths: /todos: get: responses: '200': description: 'ToDos' content: application/json: schema: type: object properties: title: type: string description: Description of what to do completed: type: boolean order: type: integer format: int32 url: type: string format: uri required: title completed order url application/xml: example: title: "Mocked XML title" completed: true order: 13 url: "http://mockedURL.com" text/plain: example: | title: "Mocked Text title" completed: true order: 13 url: "http://mockedURL.com" ``` It has a single path with 3 content types. `application/json` specifies a response schema which Kusk will generate a generated response that matches `applications/xml` and `text/plain` specifies examples which Kusk will return as is. ```shell $ kusk mock -i todo-backend-api.yaml successfully parsed OpenAPI spec initializing mocking server server successfully initialized URL: http://localhost:8080 watching for file changes in todo-backend-api.yaml ``` The mock server is now running and will watch for any changes you make to fake todo-backend-api.yaml. Let's curl the endpoint for a JSON response ```shell $ curl -H "Accept: application/json" localhost:8080/todos | jq { "completed": true, "order": 507256954, "title": "Praesentium accusantium magni sequi saepe blanditiis. Officiis omnis sapiente laudantium quod. Vel dolorum voluptatibus sequi voluptatem voluptas nam.", "url": "http://sanfordconroy.name/elda.hills" } ``` The response returns matches the schema that we defined under the `application/json` content response. Let's now curl for `application/xml` and `text/plain` ```shell $ curl -H "Accept: application/xml" localhost:8080/todos <doc><completed>true</completed><order>13</order><title>Mocked XML title</title><url>http://mockedURL.com</url></doc> $ curl -H "Accept: text/plain" localhost:8080/todos title: "Mocked Text title" completed: true order: 13 url: "http://mockedURL.com" ``` Here the examples defined above are returned. Kusk mock prioritises examples over schema definitions. Let's change the name of route `/todos` to `/foo`. Note the file watcher doesn't pick up changes made in Vim - . Use any other text editor to do this. ```yaml openapi: 3.0.0 info: title: todo-backend-api version: 0.0.2 paths: /foo: ... ``` ```shell ... change detected in fake-api.yaml mock server restarted ``` When a change is detected, the server is restarted to serve the upto date api. Now we can curl the `/foo` endpoint as before. ``` $ curl -H "Accept: application/json" localhost:8080/foo $ curl -H "Accept: application/xml" localhost:8080/foo $ curl -H "Accept: text/plain" localhost:8080/foo ``` `ctrl+c`
Project: Serverless Devs (Orchestration & Management / Scheduling & Orchestration)
File: design_principles.md

title: General principles description: 'General principles' position: 6 category: 'User model' This specification provides serverless developers with a standardized and proper development process of serverless applications. Serverless developers can better manage lifecycles of Serverless Devs applications by using Serverless Devs. Serverless User Model (SUM) contains the development specifications for serverless applications and serverless package components. This specification helps developers easily manage and operate serverless applications.
Project: APISIX (Orchestration & Management / API Gateway)
File: Vision-and-Milestones.md

<!-- --> Apache APISIX is an open source API gateway designed to help developers connect any APIs securely and efficiently in any environment. Managing thousands or tens of thousands of APIs and microservices in a multi-cloud and hybrid cloud environment is not an easy task. There will be many challenges as authentication, observability, security, etc. Apache APISIX, a community-driven project, hopes to help everyone better manage and use APIs through the power of developers. Every developer's contribution will used by thousands of companies and served by billions of users. Apache APISIX has relatively complete features for north-south traffic, and will be iterated around the following directions in the next 6 months (if you have any ideas, feel free to create issue to discuss): More complete support for Gateway API on APISIX ingress controller Add support for service mesh User-friendly documentation More plugins for public cloud and SaaS services Java/Go plugins and Wasm production-ready Add dynamic debugging tools for Apache APISIX
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: g_stands_for.md

'g' stands for something different every gRPC release: 1.0 'g' stands for 1.1 'g' stands for 1.2 'g' stands for 1.3 'g' stands for 1.4 'g' stands for 1.6 'g' stands for 1.7 'g' stands for 1.8 'g' stands for 1.9 'g' stands for 1.10 'g' stands for 1.11 'g' stands for 1.12 'g' stands for 1.13 'g' stands for 1.14 'g' stands for 1.15 'g' stands for 1.16 'g' stands for 1.17 'g' stands for 1.18 'g' stands for 1.19 'g' stands for 1.20 'g' stands for 1.21 'g' stands for 1.22 'g' stands for 1.23 'g' stands for 1.24 'g' stands for 1.25 'g' stands for 1.26 'g' stands for 1.27 'g' stands for 1.28 'g' stands for 1.29 'g' stands for 1.30 'g' stands for 1.31 'g' stands for 1.32 'g' stands for 1.33 'g' stands for 1.34 'g' stands for 1.35 'g' stands for 1.36 'g' stands for 1.37 'g' stands for 1.38 'g' stands for 1.39 'g' stands for 1.40 'g' stands for 1.41 'g' stands for 1.42 'g' stands for 1.43 'g' stands for 1.44 'g' stands for 1.45 'g' stands for 1.46 'g' stands for 1.47 'g' stands for 1.48 'g' stands for 1.49 'g' stands for 1.50 'g' stands for 1.51 'g' stands for 1.52 'g' stands for 1.53 'g' stands for 1.54 'g' stands for 1.55 'g' stands for 1.56 'g' stands for 1.57 'g' stands for 1.58 'g' stands for 1.59 'g' stands for 1.60 'g' stands for 1.61 'g' stands for 1.62 'g' stands for 1.63 'g' stands for 1.64 'g' stands for 1.65 'g' stands for
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: bug_report_objc.md

name: Report a gRPC ObjC bug about: Create a report to help us improve labels: kind/bug, priority/P2, lang/ObjC assignees: dennycd <!-- 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 Issues specific to grpc-java, grpc-go, grpc-node, grpc-dart, grpc-web should be created in the repository they belong to (e.g. https://github.com/grpc/grpc-LANGUAGE/issues/new) --> Please provide either 1) A unit test for reproducing the bug or 2) Specific steps for us to follow to reproduce the bug. If theres not enough information to debug the problem, gRPC team may close the issue at their discretion. Youre welcome to re-open the issue once you have a reproduction. Make sure you include information that can help us debug (full error message, exception listing, stack trace, logs). See for how to diagnose problems better.
Project: Traefik (Orchestration & Management / API Gateway)
File: ipallowlist.md

title: "Traefik TCP Middlewares IPAllowList" description: "Learn how to use IPAllowList in TCP middleware for limiting clients to specific IPs in Traefik Proxy. Read the technical documentation." Limiting Clients to Specific IPs {: .subtitle } IPAllowList limits allowed requests based on the client IP. ```yaml tab="Docker & Swarm" labels: "traefik.tcp.middlewares.test-ipallowlist.ipallowlist.sourcerange=127.0.0.1/32, 192.168.1.7" ``` ```yaml tab="Kubernetes" apiVersion: traefik.io/v1alpha1 kind: MiddlewareTCP metadata: name: test-ipallowlist spec: ipAllowList: sourceRange: 127.0.0.1/32 192.168.1.7 ``` ```yaml tab="Consul Catalog" "traefik.tcp.middlewares.test-ipallowlist.ipallowlist.sourcerange=127.0.0.1/32, 192.168.1.7" ``` ```toml tab="File (TOML)" [tcp.middlewares] [tcp.middlewares.test-ipallowlist.ipAllowList] sourceRange = ["127.0.0.1/32", "192.168.1.7"] ``` ```yaml tab="File (YAML)" tcp: middlewares: test-ipallowlist: ipAllowList: sourceRange: "127.0.0.1/32" "192.168.1.7" ``` The `sourceRange` option sets the allowed IPs (or ranges of allowed IPs by using CIDR notation).
Project: WSO2 API Microgateway (Orchestration & Management / API Gateway)
File: SECURITY.md

| Version | Supported | | - | | | > 2.5.0 | :whitecheckmark: | WSO2 takes security issues very seriously. If you have any concerns regarding our product security or have uncovered a security vulnerability, we strongly encourage you to report that to our private and highly confidential security mailing list: security@wso2.com first, without disclosing them in any forums, sites or other groups - public or private. To protect the end-user security, these issues could be disclosed in other places only after WSO2 completes its . Warning : Please do not create GitHub issues for security vulnerabilities. page describes how to report a Security Vulnerability and includes a public key if you wish to send secure messages to security@wso2.com
Project: Fluid (Orchestration & Management / Scheduling & Orchestration)
File: architecture.md

The overall architecture of Fluid is as follows: <div align="center"> <img src="../../../static/concepts/architecture.png" title="perspective" height="60%" width="60%" alt=""> </div> There are two core concepts: Dataset and Runtime in Fluid. To support these two concepts, Fluid's architecture is split into a control plane and a data plane. Control Plane Dataset/Runtime Manager: Responsible for the scheduling and orchestration of datasets and their supporting runtimes in Kubernetes. This includes scheduling, migration, and elastic scaling of the runtime for datasets, as well as automated operations for dataset support, such as fine-grained data preheating, such as specifying preheating for a specific folder; controlling metadata backup and recovery to improve data access performance for scenarios with massive small files; and setting pinning policies for cached data to avoid performance fluctuations caused by data eviction. Application Manager: Responsible for the scheduling and operation of application Pods that use datasets, which is divided into two core components: the Scheduler and the Webhook. Scheduler: schedule application Pods that use datasets in the Kubernetes cluster. By incorporating cached information obtained from the Runtime, Pods that use datasets are preferentially scheduled to nodes that have data caching, without the need for users to specify caching nodes. Sidecar Webhook: For Kubernetes environments where the csi-plugin cannot be run, the Sidecar webhook automatically replaces the PVC with a FUSE sidecar and controls the startup order of containers in the Pod to ensure that the FUSE container starts first. Data Plane Runtime Plugin: As a highly extensible plugin, it can support various data access engines. Fluid achieves this by abstracting some common features, such as the use of cache media, quotas, directories, etc., making it extensible with different distributed cache engine implementation technologies. For example, the AlluxioRuntime uses a Master-Slave architecture, while the JuiceFSRuntime uses a Worker P2P architecture, both of which can be configured in the CRD of the Runtime. This plugin not only supports specific Runtimes like Alluxio and JuiceFS, but also supports a generic ThinRuntime, enabling users to access generic storage without the need for development. CSI Plugin: The storage client is started in a containerized manner, completely decoupled from the business container. Upgrading the CSI plugin will not affect the business container, and it also supports deploying multiple versions of the storage client in the same Kubernetes cluster. Running the client independently in a Pod also provides observability within the Kubernetes system. Additionally, resource quotas can be set for the client's computing resources.
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: search.md

title: Search Results layout: search <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -->