cwielenb/CNCF-Dataset huggingface dataset:
Project: Envoy (Orchestration & Management / Service Proxy)
File: listener.md

Envoy uses the following procedure for creating sockets and assigning them to workers. When a listener is created, a socket is pre-created for every worker on the main thread. This allows most errors to be caught early on in the listener creation process (e.g., bad socket option, unable to bind, etc.). If using reuse_port, a unique socket is created for every worker. If not using reuse_port, a unique socket is created for worker 0, and then that socket is duplicated for all other workers. In the case of a listener update in which the address/socket is to be shared (i.e., a named listener that has configuration settings changed but listens on the same address will share sockets with the draining listener), all sockets are duplicated regardless of whether using reuse_port or not. This keeps the logic equivalent, and also makes sure that when using reuse_port no TCP connections are dropped during the drain process (in the race condition between assigning a queue and closing the listening socket on the old listener). In the case of hot restart, all sockets are requested by worker index. If the old process has a match, the socket is duplicated and sent to the new process. Thus, hot restart and a listener update effectively share the same update process. This is so that no connections are dropped when using reuse_port. A consequence of every listener having dedicated sockets (whether duplicated or not) is that a listener can close() its sockets when removed without concern for other listeners. For more information, see `ListenSocketFactoryImpl` and its use within `ListenerImpl` and `ListenerManagerImpl`.
Project: Azure Service Fabric (Orchestration & Management / Scheduling & Orchestration)
File: cluster_deployer_test.md

You will need to setup Docker as instructed here for or see below for the Linux instructions. You can't run the local cluster and the Docker daemon concurrently. If you followed the [instructions] (installpackagesanddeploycluster.md) to setup a local cluster, then in order to use use this test you will need to stop the local cluster and start the Docker daemon. ``` sudo systemctl stop servicefabric sudo systemctl start docker ``` Edit the Daemon configuration (normally `/etc/docker/daemon.json`) ```json { "ipv6": true, "fixed-cidr-v6": "fd00::/64" } ``` Expose a tcp listener for your Docker daemon. For Ubuntu edit `/etc/systemd/system/docker.service.d/docker.conf` ``` [Service] ExecStart= ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2376 ``` Reload Docker. On Ubuntu ``` sudo systemctl daemon-reload sudo systemctl restart docker ``` Build Service Fabric ``` $ ./runbuild.sh ``` Run the test ``` $ cd out/build.prod/ClusterDeployerTest/ $ ./runtest.sh ``` This test first builds a Docker image (service-cluster-run-ubuntu) locally, this image contains the necessary packages to run Service Fabric. The test then runs Docker, mounting the FabricDrop folder in your output directory. Then a is downloaded and built inside the container. The application is installed, and if the http endpoint can be hit then the test passes.
Project: Serverless Devs (Orchestration & Management / Scheduling & Orchestration)
File: clean.md

title: Clean Command description: 'Clean Command' position: 3 category: 'Commands' The `s clean` command is designated to clear the cache and associated functionalities within Serverless Devs. With this command, you're able to cleanse the environment, eliminate unused dependencies, and remove relevant cached data. - To access help information, execute `s clean -h`: ```shell script $ s clean -h Usage: s clean [options] Clean up the cache related functions of serverless devs. You can clean up the environment, unused dependent packages and related cache contents through this command. Example: $ s clean --component fc api $ s clean --all Tips: Get all installed component: s component Document: https://serverless.help/t/s/clean Options: --all Clean up the environment --logs Clean logs --cache [dirName] Delete the <dirName> file in the cache --component [componentName] Remove component (like: fc, fc@0.0.1) -h, --help Display help for command ``` Navigate through the command's options with ease, each tailored for a specific aspect of the clean-up process: | Parameter | Abbreviation | Required | Description | |--|--|--|--| | all | | Optional | Initiates a comprehensive environment clean-up | | logs | | Optional | Targets log files for cleaning | | cache | | Optional | Specifies and removes a <dirName> within the cache | | component | | Optional | Deletes a particular component (e.g., fc, fc@0.0.1) | To purge a specific component, employ the `--component` flag alongside the name of the component: ```shell script $ s clean --component fc api [s_cli] Component [fc api] has been cleaned up successfully. ``` For cache removal, utilize the `--cache` option as demonstrated below: ```shell script $ s clean --cache [s_cli] Cache cleaned up successfully. ``` Log file clean-up can be achieved through the `--logs` parameter: ```shell script $ s clean --logs [s_cli] Logs cleaned up successfully. ``` For an all-encompassing clean-up, the `--all` parameter is at your disposal: ```shell script $ s clean --all [s_cli] Component cleaned up successfully. [s_cli] Cache cleaned up successfully. [s_cli] Logs cleaned up successfully. [s_cli] The environment of Serverless Devs has been cleaned up successfully. ``` Please note the following protocols when executing a component-specific clean-up: The system will first assess if there are any corresponding components within the current Registry cache and proceed to clear them. Following that, the system will purge the ultimate Registry cache, the Github Registry, eradicating any components that match the criteria.
Project: OpenSergo (Orchestration & Management / Service Mesh)
File: fault-tolerance.md

domain: fault-tolerance version: v1alpha1 `FaultToleranceRule` YAML sample: ```yaml apiVersion: fault-tolerance.opensergo.io/v1alpha1 kind: RateLimitStrategy metadata: name: rate-limit-foo spec: metricType: RequestAmount limitMode: Global threshold: 10 statDuration: "1s" apiVersion: fault-tolerance.opensergo.io/v1alpha1 kind: HttpRequestFallbackAction metadata: name: fallback-foo spec: behavior: ReturnProvidedResponse behaviorDesc: responseStatusCode: 429 responseContentBody: "Blocked by Sentinel" responseAdditionalHeaders: key: X-Sentinel-Limit value: "foo" apiVersion: fault-tolerance.opensergo.io/v1alpha1 kind: FaultToleranceRule metadata: name: my-rule namespace: prod labels: app: my-app spec: selector: app: my-app targets: targetResourceName: '/foo' strategies: name: rate-limit-foo fallbackAction: fallback-foo ```
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: starrocks.md

| Datasource | Description | |-|--| | Datasource | Select StarRocks. | | Datasource name | Enter the name of the DataSource. | | Description | Enter a description of the DataSource. | | IP/Host Name | Enter the StarRocks service IP. | | Port | Enter the StarRocks service port. | | Username | Set the username for StarRocks connection. | | Password | Set the password for StarRocks connection. | | Database name | Enter the database name of the StarRocks connection. | | Jdbc connection parameters | Parameter settings for StarRocks connection, in JSON format. | No, you need to import Mysql jdbc driver first, read section example in `DataSource Center` section to import Mysql JDBC Driver.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: openmldb.md

is an excellent open source machine learning database, providing a full-stack FeatureOps solution for production. OpenMLDB task plugin used to execute tasks on OpenMLDB cluster. 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/openmldb.png" width="15"/> task node to canvas. Please refer to `Default Task Parameters` section for default parameters. | Parameter | Description | |-|--| | zookeeper | OpenMLDB cluster zookeeper address, e.g. 127.0.0.1:2181. | | zookeeper path | OpenMLDB cluster zookeeper path, e.g. /openmldb. | | Execute Mode | Determine the init mode, offline or online. You can switch it in sql statement. | | SQL statement | SQL statement. | | Custom parameters | It is the user-defined parameters of Python, which will replace the content with \${variable} in the script. | We use `LOAD DATA` to load data into OpenMLDB cluster. We select `offline` here, so it will load to offline storage. We use `SELECT INTO` to do feature extraction. We select `offline` here, so it will run sql on offline engine. You should create an OpenMLDB cluster first. If in production env, please check . You can follow to a quick start. The OpenMLDB task will use OpenMLDB Python SDK to connect OpenMLDB cluster. So you should have the Python env. We will use `python3` by default. You can set `PYTHON_LAUNCHER` to use your custom python env. Make sure you have installed OpenMLDB Python SDK in the host where the worker server running, using `pip install openmldb`.
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: cgroups-net-cls.md

title: Apache Mesos - Cgroups 'net_cls' Subsystem Support in Mesos Containerizer layout: documentation The `cgroups/net_cls` isolator allows operators to provide network performance isolation and network segmentation for containers within a Mesos cluster. To enable the `cgroups/net_cls` isolator, append `cgroups/net_cls` to the `--isolation` flag when starting the agent. As the name suggests, the isolator enables the `net_cls` subsystem for Linux cgroups and assigns a `net_cls` cgroup to each container launched by the Mesos Containerizer. The objective of the `net_cls` subsystem is to allow the kernel to tag packets originating from a container with a 32-bit handle. These handles can be used by kernel modules such as `qdisc` (for traffic engineering) and `net-filter` (for firewall) to enforce network performance and security policies specified by the operators. The policies, based on the `net_cls` handles, can be specified by the operators through user-space tools such as and . The 32-bit handle associated with a `net_cls` cgroup can be specified by writing the handle to the `net_cls.classid` file, present within the `net_cls` cgroup. The 32-bit handle is of the form `0xAAAABBBB`, and consists of a 16-bit primary handle 0xAAAA and a 16-bit secondary handle 0xBBBB. You can read more about the use cases for the primary and secondary handles in the [Linux kernel documentation for netcls](https://www.kernel.org/doc/Documentation/cgroup-v1/netcls.txt). By default, the `cgroups/net_cls` isolator does not manage the `net_cls` handles, and assumes the operator is going to manage/assign these handles. To enable the management of `net_cls` handles by the `cgroups/net_cls` isolator you need to specify a 16-bit primary handle, of the form 0xAAAA, using the `--cgroupsnetclsprimaryhandle` flag at agent startup. Once a primary handle has been specified for an agent, for each container the `cgroups/net_cls` isolator allocates a 16-bit secondary handle. It then assigns the 32-bit combination of the primary and secondary handle to the `net_cls` cgroup associated with the container by writing to `netcls.classid`. The `cgroups/netcls` isolator exposes the assigned `net_cls` handle to operators by exposing the handle as part of the `ContainerStatus` &mdash;associated with any task running within the container&mdash; in the agent's endpoint.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: clickhouse.md

| Datasource | Description | |-|| | Datasource | Select CLICKHOUSE. | | Datasource Name | Enter the name of the datasource. | | Description | Enter a description of the datasource. | | IP/Host Name | Enter the CLICKHOUSE service IP. | | Port | Enter the CLICKHOUSE service port. | | Username | Set the username for CLICKHOUSE connection. | | Password | Set the password for CLICKHOUSE connection. | | Database Name | Enter the database name of the CLICKHOUSE connection. | | jdbc connect parameters | Parameter settings for CLICKHOUSE connection, in JSON format. | Yes, could use this datasource by default.
Project: OpenELB (Orchestration & Management / Service Proxy)
File: feature_request.md

name: Feature request about: Suggest a new feature or enhancement title: "" labels: kind/feature assignees: "" <!-- If you have a general conceptual idea please ! We try and keep our issue tracker to focus on specific changes. --> Is your feature request related to a problem? Please describe. <!-- A clear and concise description of what the problem is. eg: I'm always frustrated when ... --> Describe the solution you'd like <!-- A clear and concise description of what you want to happen. --> Describe alternatives you've considered <!-- A clear and concise description of any alternative solutions or features you've considered. --> Additional context <!-- Add any other context or screenshots about the feature request here. -->
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: task-definition.md

Task definition allows to modify or operate tasks at the task level rather than modifying them in the workflow definition. We already have workflow level task editor in which you can click the specific workflow and then edit its task definition. It is depressing when you want to edit the task definition but do not remember which workflow it belongs to. So we decide to add `Task Definition` view under `Task` menu. In this view, you can create, query, update, delete task definition by click the related button in `operation` column. The most exciting thing is you could query task by task name in the wildcard, and it is useful when you only remember the task name but forget which workflow it belongs to. It is also supported query by the task name alone with `Task Type` or `Workflow Name` Stream task definitions are created in the workflow definition, and can be modified and executed. Click the execute button, check the execution parameters and click Confirm to submit the stream task.
Project: Traefik (Orchestration & Management / API Gateway)
File: PULL_REQUEST_TEMPLATE.md

<!-- PLEASE READ THIS MESSAGE. Documentation fixes or enhancements: for Traefik v2: use branch v2.11 for Traefik v3: use branch v3.0 Bug fixes: for Traefik v2: use branch v2.11 for Traefik v3: use branch v3.0 Enhancements: for Traefik v2: we only accept bug fixes for Traefik v3: use branch v3.0 HOW TO WRITE A GOOD PULL REQUEST? https://doc.traefik.io/traefik/contributing/submitting-pull-requests/ --> <!-- A brief description of the change being made with this pull request. --> <!-- What inspired you to submit this pull request? --> [ ] Added/updated tests [ ] Added/updated documentation <!-- Anything else we should know when reviewing? -->
Project: MOSN (Orchestration & Management / Service Proxy)
File: PULL_REQUEST_TEMPLATE.md

Your PR should present related issues you want to solve. You should show your solutions about the issues in your PR, including the overall solutions, details and the changes. At this time, Chinese is allowed to describe these. Unit Test is needed if the code is changed, your unit test should cover boundary cases, corner cases, and some exceptional cases. And you need to show the UT result. If your code involves the processing of every request, you should give the Benchmark Result. Make sure `Goimports` has run Show `Golint` result
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: new-committer-martin-grigorov.md

title: "New committer: Martin Grigorov" linkTitle: "New committer: Martin Grigorov" date: 2022-01-04 <!-- 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. --> The Project Management Committee (PMC) for Apache Avro has invited Martin Grigorov to become a committer and we are pleased to announce that he has accepted. Over the last few months, he has been active, reliable and easy to work with on PRs and on the mailing list. His work is of high quality, and he has a breadth of experience in many of the SDK languages. I'm especially keen to point out the work he's been doing on the website! Being a committer enables easier contribution to the project since there is no need to go via the patch submission process. This should enable better productivity. It's great to have you as part of the team, Martin!
Project: MetalLB (Orchestration & Management / Service Proxy)
File: network-addons.md

title: Network Addon Compatibility Generally speaking, MetalLB doesn't care which network addon you choose to run in your cluster, as long as it provides the standard behaviors that Kubernetes expects from network addons. The following is a list of network addons that have been tested with MetalLB, for your reference. The list is presented in alphabetical order, we express no preference for one addon over another. Addons that are not on this list probably work, we just haven't tested them. Please if you have information on network addons that aren't listed! | Network addon | Compatible | ||-| | Antrea | Yes (Tested on version ) | | Calico | Mostly (see ) | | Canal | Yes | | Cilium | Yes | | Flannel | Yes | | Kube-ovn | Yes | | Kube-router | Mostly (see ) | | Weave Net | Mostly (see ) |
Project: Consul (Orchestration & Management / Service Mesh)
File: pull_request_template.md

<!-- Please describe why you're making this change, in plain English. --> <!-- In the case of bugs, describe how to replicate If any manual tests were done, document the steps and the conditions to replicate Call out any important/ relevant unit tests, e2e tests or integration tests you have added or are adding --> <!-- Include any links here that might be helpful for people reviewing your PR (Tickets, GH issues, API docs, external benchmarks, tools docs, etc). If there are none, feel free to delete this section. Please be mindful not to leak any customer or confidential information. HashiCorp employees may want to use our internal URL shortener to obfuscate links. --> [ ] updated test coverage [ ] external facing docs updated [ ] appropriate backport labels added [ ] not a security concern
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-configuration-tenants.md

Multi-tenancy let you manage APIs across multiple business entities, such as countries, areas, data centers, etc... Tenants maximize resource sharing for a single API deployment. For example: You have a cluster of 2 gateway instances, one in ASIA region and another in EUROPE region. You have an API with 2 endpoints, one in ASIA region and another in EUROPE region. To minimize cost, you can set a europe tenant to the EUROPE Gateway instance and the EUROPE API's endpoint and the same thing applies for the ASIA region with an asia tenant. You can create a new shard tag by clicking on the New tenant input and press SAVE button. A tenant's ID will be automatically created. To make the association between API endpoints and Gateway instances, you must choose this tenant in the API endpoints configuration page and copy/paste the tenant's ID to the `gravitee.yml` file of the gateway instance: ```yaml ```
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: cli.md

title: Apache Mesos - CLI layout: documentation The new Mesos Command Line Interface provides one executable Python 3 script to run all default commands and additional custom plugins. Two of the subcommands available allow you to debug running containers: `mesos task exec`, to run a command in a running task's container. `mesos task attach`, to attach your local terminal to a running task and stream its input/output. For now, the Mesos CLI is still under development and not built as part of a standard Mesos distribution. However, the CLI can be built using and . If necessary, check the options described in the linked pages to set Python 3 before starting a build. The result of this build will be a `mesos` binary that can be executed. Using the CLI without building Mesos is also possible. To do so, activate the CLI virtual environment by following the steps described below: ``` $ cd src/python/cli_new/ $ PYTHON=python3 ./bootstrap $ source activate $ mesos ``` Calling `mesos` will then run the CLI and calling `mesos-cli-tests` will run the integration tests. The CLI uses a configuration file to know where the masters of the cluster are as well as list any plugins that should be used in addition to the default ones provided. The configuation file, located by default at `~/.mesos/config.toml`, looks like this: ``` plugins = [ "</absolute/path/to/plugin-1/directory>", "</absolute/path/to/plugin-2/directory>" ] [master] address = "10.10.0.30:5050" ```
Project: BFE (Orchestration & Management / Service Proxy)
File: time.md

Description: Judge if current time is in [starttime, endtime] Parameters | Parameter | Description | | | - | | start_time | String<br>start time | | end_time | String<br> end time | Time formatyyyymmddhhmmssZZ is time zonedetail information is shown in Section "Time Zone Detail" Example ```go bfetimerange("20190204203000H", "20190204204500H") ``` Description: Judge if current time is periodly(period) in [starttime, endtime] Parameters | Parameter | Description | | | - | | start_time | String<br>start time | | end_time | String<br> end time | | period | String<br> period, default Day | Time format: hhmmssZZ is time zonedetail information is shown in "Appendix B: Time Zone Detail" Example ```go bfeperiodictime_range("203000H", "204500H", "") ``` In order to test time condition primitive, X-Bfe-Debug-Time can be added in header of request to mock system time | Time zone name | Letter | Offset | Description | | :-- | : | :-- | : | | Alfa Time Zone | A | | | | Bravo Time Zone | B | | | | Charlie Time Zone | C | | | | Delta Time Zone | D | | | | Echo Time Zone | E | | | | Foxtrot Time Zone | F | | | | Golf Time Zone | G | | | | Hotel Time Zone | H | | Beijing Time | | India Time Zone | I | | | | Kilo Time Zone | K | | | | Lima Time Zone | L | | | | Mike Time Zone | M | | | | November Time Zone | N | | | | Oscar Time Zone | O | | | | Papa Time Zone | P | | | | Quebec Time Zone | Q | | | | Romeo Time Zone | R | | | | Sierra Time Zone | S | | | | Tango Time Zone | T | | | | Uniform Time Zone | U | | | | Victor Time Zone | V | | | | Whiskey Time Zone | W | | | | X-ray Time Zone | X | | | | Yankee Time Zone | Y | | | | Zulu Time Zone | Z | | Greenwich Mean Time |