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

Condition is a conditional node, that determines which downstream task should run based on the condition of the upstream task. Currently, the Conditions support multiple upstream tasks, but only two downstream tasks. When the number of upstream tasks exceeds one, achieve complex upstream dependencies by through `and` and `or` operators. 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/conditions.png" width="20"/> task node to canvas. Please refer to `Default Task Parameters` section for default parameters. | Parameter | Description | ||| | Downstream tasks selection | Depending on the status of the predecessor task, you can jump to the corresponding branch, currently two branches are supported: success, failure <ul><li>Success: When the upstream task runs successfully, run the success branch.</li><li>Failure: When the upstream task runs failed, run the failure branch.</li></ul></li></ul> | | Upstream condition selection | Can select one or more upstream tasks for conditions.<ul><li>Add an upstream dependency: the first parameter is to choose a specified task name, and the second parameter is to choose the upstream task status to trigger conditions.</li><li>Select upstream task relationship: use `and` and `or` operators to handle the complex relationship of upstream when there are multiple upstream tasks for conditions.</li></ul></li></ul> | : Conditions task mainly executes the corresponding branch based on the execution status (success, failure) of the upstream nodes. The task node mainly executes the corresponding branch based on the value of the and the result of user written expression. This sample demonstrates the operation of the Condition task by using the task. Go to the workflow definition page, and then create the following task nodes: Node_A: Shell task, prints out "hello world", its main function is the upstream branch of Condition, and triggers the corresponding branch node according to whether its execution is successful or not. Condition: The Conditions task executes the corresponding branch according to the execution status of the upstream task. NodeSuccess: Shell task, print out "success", NodeA executes the successful branch. NodeFalse: Shell task, print out "false", NodeA executes the failed branch. After you finish creating the workflow, you can run the workflow online. You can view the execution status of each task on the workflow instance page. As shown below: In the above figure, the task status marked with a green check mark is the successfully executed task node. The Conditions task supports multiple upstream tasks, but only two downstream tasks. The Conditions task and the workflow that contain it do not support copy operations. The predecessor task of Conditions cannot connect to its branch nodes, which will cause logical confusion and does not conform to DAG scheduling. The situation shown below is wrong.
Project: APISIX (Orchestration & Management / API Gateway)
File: rate-limiting.md

title: Rate Limiting slug: /getting-started/rate-limiting <head> <link rel="canonical" href="https://docs.api7.ai/apisix/getting-started/rate-limiting" /> </head> The Getting Started tutorials are contributed by . APISIX is a unified control point, managing the ingress and egress of APIs and microservices traffic. In addition to the legitimate client requests, these requests may also include unwanted traffic generated by web crawlers as well as cyber attacks, such as DDoS. APISIX offers rate limiting capabilities to protect APIs and microservices by limiting the number of requests sent to upstream services in a given period of time. The count of requests is done efficiently in memory with low latency and high performance. <br /> <div style={{textAlign: 'center'}}> <img src="https://static.apiseven.com/uploads/2023/02/20/l9G9Kq41_rate-limiting.png" alt="Routes Diagram" /> </div> <br /> In this tutorial, you will enable the `limit-count` plugin to set a rate limiting constraint on the incoming traffic. Complete the step to install APISIX first. Complete the step. The following route `getting-started-ip` is inherited from . You only need to use the `PATCH` method to add the `limit-count` plugin to the route: ```shell curl -i "http://127.0.0.1:9180/apisix/admin/routes/getting-started-ip" -X PATCH -d ' { "plugins": { "limit-count": { "count": 2, "time_window": 10, "rejected_code": 503 } } }' ``` You will receive an `HTTP/1.1 201 Created` response if the plugin was added successfully. The above configuration limits the incoming requests to a maximum of 2 requests within 10 seconds. Let's generate 100 simultaneous requests to see the rate limiting plugin in effect. ```shell count=$(seq 100 | xargs -I {} curl "http://127.0.0.1:9080/ip" -I -sL | grep "503" | wc -l); echo \"200\": $((100 - $count)), \"503\": $count ``` The results are as expected: out of the 100 requests, 2 requests were sent successfully (status code `200`) while the others were rejected (status code `503`). ```text "200": 2, "503": 98 ``` Disable rate limiting by setting the `_meta.disable` parameter to `true`: ```shell curl -i "http://127.0.0.1:9180/apisix/admin/routes/getting-started-ip" -X PATCH -d ' { "plugins": { "limit-count": { "_meta": { "disable": true } } } }' ``` Let's generate 100 requests again to validate if it is disabled: ```shell count=$(seq 100 | xargs -i curl "http://127.0.0.1:9080/ip" -I -sL | grep "503" | wc -l); echo \"200\": $((100 - $count)), \"503\": $count ``` The results below show that all of the requests were sent successfully: ```text "200": 100, "503": 0 ``` You can use the APISIX variables to configure fined matching rules of rate limiting, such as `$host` and `$uri`. In addition, APISIX also supports rate limiting at the cluster level using Redis. Congratulations! You have learned how to configure rate limiting and completed the Getting Started tutorials. You can continue to explore other documentations to customize APISIX and meet your production needs.
Project: Serverless Devs (Orchestration & Management / Scheduling & Orchestration)
File: overview_and_terminology.md

title: Overview and terms description: 'Overview and terms' position: 3 category: 'User model' SUM is an application model and provides specification for serverless developers. Serverless Devs can identify the applications developed by using the specification. You can use components that are provided by Serverless Registry to implement related features. A serverless developer model is proposed in the Serverless Application specification. serverless application can be identified by the Serverless Devs. A YAML file is required to describe the resources and behaviors of the application, and the YAML file must conform to the Serverless Application specification. In the current version, SUM defines the following content: Serverless application specifications Serverless package component usage specifications
Project: Knative (Orchestration & Management / Scheduling & Orchestration)
File: issue-template.md

<!-- Pro-tip: You can leave this block commented, and it still works! Select the appropriate areas for your issue: /area API /area autoscale /area build /area monitoring /area networking /area test-and-release Classify what kind of issue this is: /kind question /kind bug /kind cleanup /kind doc /kind feature /kind good-first-issue /kind process /kind spec /kind proposal -->
Project: MetalLB (Orchestration & Management / Service Proxy)
File: siteparam.en.md

+++ description = "Get value of site params" title = "SiteParam" +++ The `siteparam` shortcode prints values of site params. While the examples are using shortcodes with named parameter you are free to use positional aswell or call this shortcode from your own partials. {{< tabs groupid="shortcode-parameter">}} {{% tab title="shortcode" %}} ````go {{%/ siteparam name="editURL" /%}} ```` {{% /tab %}} {{% tab title="shortcode (positional)" %}} ````go {{%/ siteparam "editURL" /%}} ```` {{% /tab %}} {{% tab title="partial" %}} ````go {{ partial "shortcodes/siteparam.html" (dict "page" . "name" "editURL" )}} ```` {{% /tab %}} {{< /tabs >}} | Name | Position | Default | Notes | |-|-||-| | name | 1 | &lt;empty&gt; | The name of the site param to be displayed. | ```go `editURL` value: {{%/ siteparam name="editURL" /%}} ``` `editURL` value: {{% siteparam name="editURL" %}} To use formatted parameter, add this in your `hugo.toml`: {{< multiconfig file=hugo >}} [markup.goldmark.renderer] unsafe = true {{< /multiconfig >}} Now values containing Markdown will be formatted correctly. {{< multiconfig file=hugo >}} [params] [params.siteparam.test] text = "A nested parameter <b>with</b> formatting" {{< /multiconfig >}} ```go Formatted parameter: {{%/ siteparam name="siteparam.test.text" /%}} ``` Formatted parameter: {{% siteparam name="siteparam.test.text" %}}
Project: Traefik (Orchestration & Management / API Gateway)
File: inflightconn.md

Limiting the Number of Simultaneous connections. {: .subtitle } To proactively prevent services from being overwhelmed with high load, the number of allowed simultaneous connections by IP can be limited. ```yaml tab="Docker & Swarm" labels: "traefik.tcp.middlewares.test-inflightconn.inflightconn.amount=10" ``` ```yaml tab="Kubernetes" apiVersion: traefik.io/v1alpha1 kind: MiddlewareTCP metadata: name: test-inflightconn spec: inFlightConn: amount: 10 ``` ```yaml tab="Consul Catalog" "traefik.tcp.middlewares.test-inflightconn.inflightconn.amount=10" ``` ```yaml tab="File (YAML)" tcp: middlewares: test-inflightconn: inFlightConn: amount: 10 ``` ```toml tab="File (TOML)" [tcp.middlewares] [tcp.middlewares.test-inflightconn.inFlightConn] amount = 10 ``` The `amount` option defines the maximum amount of allowed simultaneous connections. The middleware closes the connection if there are already `amount` connections opened.
Project: Gloo (Orchestration & Management / API Gateway)
File: e2e-tests.md

These end-to-end tests do not require Kubernetes, and persist configuration in memory. - - This is the most common and preferred type of end-to-end test, since it is the quickest to set up and easiest to debug. Additionally, Gloo Edge may be run using various backing stores; these tests provide a single space to validate the translation of Gloo resources into Envoy resources, independently of where Gloo Edge is deployed. These test do not rely on Kubernetes, so if there is any Kubernetes behavior that needs to be tested, write a instead. The tests are located in the folder In-memory end-to-end tests: Run the Run either using a binary or docker container Apply Gloo resources using Execute requests against the Envoy proxy and confirm the expected response. This validates that the Gloo resources have been picked up by the controllers, were been translated correctly into Envoy configuration, the configuration was sent to the Envoy proxy, and the proxy behaves appropriately. We have an which outlines how in-memory e2e tests work. It also provides some examples for basic testing operations. If you are writing a new e2e test, we recommend that you review the example test first. This was introduced in a which includes other useful details about e2e test considerations. These tests are run by in Google Cloud as part of our CI pipeline. If a test fails, you can retry it using the build-bot . If you do this, please make sure to include a link to the failed logs for debugging purposes. See the for more details about running these tests.
Project: Gloo (Orchestration & Management / API Gateway)
File: setup_postman_echo.md

This guide assumes that you installed the following components: Gloo Edge in the `gloo-system` namespace in your cluster The `glooctl` command line utility The command line utility to format JSON strings You also need an upstream service to serve as the target for the requests that you send to test the Gloo Edge configurations in this tutorial. You can use the publicly available service. Postman Echo exposes a set of endpoints that are very useful for inspecting both the requests sent upstream and the resulting responses. For more information about this service, see the . Create a static upstream to represent the postman-echo.com remote service. ```yaml apiVersion: gloo.solo.io/v1 kind: Upstream metadata: name: postman-echo namespace: gloo-system spec: static: hosts: addr: postman-echo.com port: 80 ```
Project: Gloo (Orchestration & Management / API Gateway)
File: zipkin.proto.sk.md

title: "zipkin.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Configuration for the Zipkin tracer. [#extension: envoy.tracers.zipkin] [#next-free-field: 6] ```yaml "collectorUpstreamRef": .core.solo.io.ResourceRef "clusterName": string "collectorEndpoint": string "traceId128Bit": .google.protobuf.BoolValue "sharedSpanContext": .google.protobuf.BoolValue "collectorEndpointVersion": .solo.io.envoy.config.trace.v3.ZipkinConfig.CollectorEndpointVersion ``` | Field | Type | Description | | -- | - | -- | | `collectorUpstreamRef` | | The upstream that hosts the Zipkin collectors. Only one of `collectorUpstreamRef` or `clusterName` can be set. | | `clusterName` | `string` | The name of the cluster that hosts the Zipkin collectors. Note that the Zipkin cluster must be defined in the :ref:`Bootstrap static cluster resources <envoyapifield_config.bootstrap.v3.Bootstrap.StaticResources.clusters>`. Only one of `clusterName` or `collectorUpstreamRef` can be set. | | `collectorEndpoint` | `string` | The API endpoint of the Zipkin service where the spans will be sent. When using a standard Zipkin installation, the API endpoint is typically /api/v1/spans, which is the default value. | | `traceId128Bit` | | Determines whether a 128bit trace id will be used when creating a new trace instance. The default value is false, which will result in a 64 bit trace id being used. | | `sharedSpanContext` | | Determines whether client and server spans will share the same span context. The default value is true. | | `collectorEndpointVersion` | | Determines the selected collector endpoint version. By default, the ``HTTPJSONV1`` will be used. | Available Zipkin collector endpoint versions. | Name | Description | | -- | -- | | `DEPRECATEDANDUNAVAILABLEDONOTUSE` | Zipkin API v1, JSON over HTTP. [#comment: The default implementation of Zipkin client before this field is added was only v1 and the way user configure this was by not explicitly specifying the version. Consequently, before this is added, the corresponding Zipkin collector expected to receive v1 payload. Hence the motivation of adding HTTPJSON_V1 as the default is to avoid a breaking change when user upgrading Envoy with this change. Furthermore, we also immediately deprecate this field, since in Zipkin realm this v1 version is considered to be not preferable anymore.] | | `HTTP_JSON` | Zipkin API v2, JSON over HTTP. | | `HTTP_PROTO` | Zipkin API v2, protobuf over HTTP. | <!-- 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: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: scheduling_test.md

| Test Case | E2E Describe Text | Comments | ||--|--| | Test schedule the Deployment with label and group constraints | Deployment propagation with label and group constraints testing | | | Test schedule the CRD with label and group constraints | Crd with specified label and group constraints propagation testing | | | Test schedule the Job with label and group constraints | Job propagation with label and group constraints testing | | | Test Case | E2E Describe Text | Comments | |-||-| | Test ReplicaScheduling when ReplicaSchedulingType value is Duplicated | replicas duplicated testing | | | Test ReplicaScheduling when ReplicaSchedulingType value is Duplicated, trigger rescheduling when replicas have changed | replicas duplicated testing when rescheduling | | | Test ReplicaScheduling when ReplicaSchedulingType value is Divided, ReplicaDivisionPreference value is Weighted, WeightPreference is nil | replicas divided and weighted testing | | | Test ReplicaScheduling when ReplicaSchedulingType value is Divided, ReplicaDivisionPreference value is Weighted, WeightPreference is nil, trigger rescheduling when replicas have changed | replicas divided and weighted testing when rescheduling | | | Test ReplicaScheduling when ReplicaSchedulingType value is Divided, ReplicaDivisionPreference value is Weighted, WeightPreference isn't nil | replicas divided and weighted testing | | | Test ReplicaScheduling when ReplicaSchedulingType value is Divided, ReplicaDivisionPreference value is Weighted, WeightPreference isn't nil, trigger rescheduling when replicas have changed | replicas divided and weighted testing when rescheduling | | | Test Case | E2E Describe Text | Comments | ||-|-| | Test Job's parallelism are divided equally on member clusters | Job replicas divided and weighted testing | |
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.22.3.md

We are delighted to present version v1.22.3 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. A big thank you to everyone who contributed to the release. Updates Go to 1.19.4, see . (#4925, @skriss) For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.22.3 is tested against Kubernetes 1.22 through 1.24. If you're using Contour and want to add your organization to our adopters list, please visit this . If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this .
Project: Service Mesh Interface (SMI) (Orchestration & Management / Service Mesh)
File: integration-service-mesh-hub.md

The Service Mesh Hub is an example integration of the SMI Specification. Service Mesh Hub is a mesh agnostic dashboard to install and operate meshes. A read only version of the Service Mesh Hub can be found on Service Mesh Hub does: Built-in installers for different meshes Automatically discovers existing meshes, their configurations, running services / extensions and registers them to the Hub to manage Install and manage meshes and mesh extensions Extensions Tab has ecosystem tools for service mesh environments. Users can also build their own extensions Demos Tab has demo apps for trying out mesh use cases Install Service Mesh Hub on any Kubernetes cluster with the command: ```bash kubectl apply -f https://raw.githubusercontent.com/solo-io/service-mesh-hub/master/install/service-mesh-hub.yaml ``` This will install the hub into the `sm-marketplace` namespace. Once the pods are running, you can open the hub by port forwarding: ```bash kubectl port-forward -n sm-marketplace deploy/smm-apiserver 8080 ``` Then navigate your browser to `localhost:8080` Go to Extensions Tab, select SMI and install that extension onto an existing mesh or install a mesh to add SMI. * #Service-Mesh-Hub Slack channel for related discussion
Project: Gloo (Orchestration & Management / API Gateway)
File: _index.md

title: Open Source Attribution weight: 7 description: Open Source Attribution and Licenses 3rd Party open source software which is provided by solo.io in connection with Gloo Edge {{< readfile file="static/content/osa_provided.md" markdown="true" >}} Free Software under GNU General Public License, and Mozilla Public License Software that are utilized by Gloo Edge {{< readfile file="static/content/osa_included.md" markdown="true" >}}
Project: Consul (Orchestration & Management / Service Mesh)
File: faq.md

This section addresses some frequently asked questions about Consul's architecture. When you query Consul for information about a service, such as via the , the agent will always make an internal RPC request to a Consul server that will query the consistent state store. Even though an agent might learn that another agent is down via gossip, that won't be reflected in service discovery until the current Raft leader server perceives that through gossip and updates the catalog using Raft. You can see an example of where these layers are plumbed together here - https://github.com/hashicorp/consul/blob/v1.0.5/agent/consul/leader.go#L559-L602. Consul's make a best-effort attempt to wait for new information, but they may return the same results as the initial query under some circumstances. First, queries are limited to 10 minutes max, so if they time out they will return. Second, due to Consul's prefix-based internal immutable radix tree indexing, there may be modifications to higher-level nodes in the radix tree that cause spurious wakeups. In particular, waiting on things that do not exist is not very efficient, but not very expensive for Consul to serve, so we opted to keep the code complexity low and not try to optimize for that case. You can see the common handler that implements the blocking query logic here - https://github.com/hashicorp/consul/blob/v1.0.5/agent/consul/rpc.go#L361-L439. For more on the immutable radix tree implementation, see https://github.com/hashicorp/go-immutable-radix/ and https://github.com/hashicorp/go-memdb, and the general support for "watches". No. These are always fetched via an internal RPC request to a Consul server. The agent doesn't do any caching, and if you want to be able to fetch these values even if there's no cluster leader, then you can use a more relaxed . You can see an example where the `/v1/kv/<key>` HTTP endpoint on the agent makes an internal RPC call here - https://github.com/hashicorp/consul/blob/v1.0.5/agent/kvs_endpoint.go#L56-L90. We strongly recommend running the Consul agent on each node in a cluster. Even the key/value store benefits from having agents on each node. For example, when you lock a key it's done through a , which has a lifetime that's by default tied to the health of the agent as determined by Consul's gossip-based distributed failure detector. If the agent dies, the session will be released automatically, allowing some other process to quickly see that and obtain the lock without having to wait for an open-ended TTL to expire. If you are using Consul's service discovery features, the local agent runs the health checks for each service registered on that node and only needs to send edge-triggered updates to the Consul servers (because gossip will determine if the agent itself dies). Most attempts to avoid running an agent on each node will face solving issues that are already solved by Consul's design if the agent is deployed as intended. For cases where you really cannot run an agent alongside a service, such as for monitoring an , there's a companion project called the that may help.