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

Use `Hive Cli Task` to create a `Hive Cli` type task and execute hive SQL from scripts or files. The workers run `hive -e` to execute hive sql from scripts or `hive -f` to execute from files in `Resource Center`. In DolphinScheduler, we have both `Hive CLI Task` and `SQL Task With Hive Datasource` for different scenarios. You could choose between these two based on your needs. The `Hive CLI` task plugin connects directly to `HDFS` and the `Hive Metastore` for hive task executions, which requires your workers to have access to those services, such as related `Hive` libs, `Hive` and `HDFS` configuration files. However, `Hive CLI Task` provides better stability for scheduling in production. `SQL Task With Hive Datasource` does not require access to `Hive` libs, `Hive` and `HDFS` configuration files and supports `Kerberos` for authentication. However, you may encounter `HiveServer2` failures if your hive sql task scheduling puts significant pressure on it. Click `Project Management-Project Name-Workflow Definition`, and click the `Create Workflow` button to enter the DAG editing page. Drag <img src="../../../../img/tasks/icons/hivecli.png" width="15"/> from the toolbar to the canvas. Please refer to `Default Task Parameters` section for default parameters. | Parameter | Description | ||| | Hive Cli Task Execution Type | The type of hive cli task execution, choose either `FROMSCRIPT` or `FROMFILE`. | | Hive SQL Script | If you choose `FROM_SCRIPT` for `Hive Cli Task Execution Type`, you need to fill in your SQL script. | | Hive Cli Options | Extra options for hive cli, such as `--verbose` to check execution result. | | Resources | If you choose `FROM_FILE` for `Hive Cli Task Execution Type`, you need to select your SQL file. | This example below illustrates how to create a `Hive CLI` task node and execute hive SQL from script: This example below illustrates how to create a `Hive CLI` task node and execute hive SQL from file:
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: task-order.md

When a workload is presented to kube-batch in the form of jobs or tasks, kube-batch prioritizes those job/tasks, so job/task with high priority is handled first. In this doc, we will look into how Tasks within job are prioritized. Task priority in kube-batch is done by using either of following data Task's Priority given in TaskSpec(i.e. PodSpec as defined in the YAML) Task's Creation time Task's UID If priority plugin in kube-batch is loaded, then priority is decided using task's priority that will be provided in TaskSpec. Else it checks for creationTime of tasks. Depending on which task has been created first, that task will be given high priority. If creationTime is also same, then UID is compared and then priority is decided.
Project: Fluid (Orchestration & Management / Scheduling & Orchestration)
File: RELEASING.md

A Gomega release is a tagged sha and a GitHub release. To cut a release: Ensure CHANGELOG.md is up to date. Use ```bash LAST_VERSION=$(git tag --sort=version:refname | tail -n1) CHANGES=$(git log --pretty=format:'- %s [%h]' HEAD...$LAST_VERSION) echo -e "## NEXT\n\n$CHANGES\n\n### Features\n\n### Fixes\n\n### Maintenance\n\n$(cat CHANGELOG.md)" > CHANGELOG.md ``` to update the changelog Categorize the changes into Breaking Changes (requires a major version) New Features (minor version) Fixes (fix version) Maintenance (which in general should not be mentioned in `CHANGELOG.md` as they have no user impact) Update GOMEGAVERSION in `gomegadsl.go` Commit, push, and release: ``` git commit -m "vM.m.p" git push gh release create "vM.m.p" git fetch --tags origin master ```
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: enterprise-webexteams.md

If you need to use `Webex Teams` to alert, create an alert instance in the alert instance management, and choose the WebexTeams plugin. You can pick private alert or room group chat alert. The following is the `WebexTeams` configuration example: | Parameter | Description | |--|-| | botAccessToken | The access token of robot. | | roomID | The ID of the room that receives message (only support one room ID). | | toPersonId | The person ID of the recipient when sending a private 1:1 message. | | toPersonEmail | The email address of the recipient when sending a private 1:1 message. | | atSomeoneInRoom | If the message destination is room, the emails of the person being @, use `,` (eng commas) to separate multiple emails. | | destination | The destination of the message (one message only support one destination). | Create a bot visit to `Create a New APP` and select `Create a Bot`, fill in the bot information and acquire `bot username` and `bot ID` for further usage. Create a root visit to create a new room, fill in the room name and acquire `id`(room ID) and `creatorId` for further usage. Invite bot to the room by invite bot Email (bot username). In this way, you can send private message to a person by `User Email` or `UserId` in a private conversation. Fill in the `To Person Id` or `To Person Email`(recommended) and `Bot Access Token` and select `Destination` `personEmail` or `personId`. The `user Email` is user register Email. The `userId` we can acquire it from the `creatorId` of creating a new group chat room API. In this way, you can send group room message to a room by `Room ID`. Fill in the `Room Id` and `Bot Access Token` and select `Destination` `roomId`. The `Room ID` we can acquire it from the `id` of creating a new group chat room API.
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.9.1-released.md

title: "Avro 1.9.1" linkTitle: "Avro 1.9.1" date: 2019-09-02 <!-- 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. --> Apache Avro 1.9.1 has been released!
Project: APISIX (Orchestration & Management / API Gateway)
File: basic-auth.md

title: basic-auth keywords: Apache APISIX API Gateway Plugin Basic Auth basic-auth description: This document contains information about the Apache APISIX basic-auth Plugin. <!-- --> The `basic-auth` Plugin is used to add to a Route or a Service. This works well with a . Consumers of the API can then add their key to the header to authenticate their requests. For Consumer: | Name | Type | Required | Description | |-|--|-|| | username | string | True | Unique username for a Consumer. If multiple Consumers use the same `username`, a request matching exception is raised. | | password | string | True | Password of the user. This field supports saving the value in Secret Manager using the resource. | NOTE: `encrypt_fields = {"password"}` is also defined in the schema, which means that the field will be stored encrypted in etcd. See . For Route: | Name | Type | Required | Default | Description | |||-||| | hide_credentials | boolean | False | false | Set to true will not pass the authorization request headers to the Upstream. | To enable the Plugin, you have to create a Consumer object with the authentication configuration: :::note You can fetch the `admin_key` from `config.yaml` and save to an environment variable with the following command: ```bash adminkey=$(yq '.deployment.admin.adminkey[0].key' conf/config.yaml | sed 's/"//g') ``` ::: ```shell curl http://127.0.0.1:9180/apisix/admin/consumers -H "X-API-KEY: $admin_key" -X PUT -d ' { "username": "foo", "plugins": { "basic-auth": { "username": "foo", "password": "bar" } } }' ``` You can also use the to complete the operation through a web UI. <!-- --> Once you have created a Consumer object, you can then configure a Route or a Service to authenticate requests: ```shell curl http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "methods": ["GET"], "uri": "/hello", "plugins": { "basic-auth": {} }, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } }' ``` After you have configured the Plugin as mentioned above, you can make a request to the Route as shown below: ```shell curl -i -ufoo:bar http://127.0.0.1:9080/hello ``` ``` HTTP/1.1 200 OK ... hello, world ``` If the request is not authorized, an error will be thrown: ```shell HTTP/1.1 401 Unauthorized ... {"message":"Missing authorization in request"} ``` And if the user or password is not valid: ```shell HTTP/1.1 401 Unauthorized ... {"message":"Invalid user authorization"} ``` To remove the `jwt-auth` Plugin, you can delete the corresponding JSON configuration from the Plugin configuration. APISIX will automatically reload and you do not have to restart for this to take effect. ```shell curl http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "methods": ["GET"], "uri": "/hello", "plugins": {}, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } }' ```
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: SECURITY.md

Join the [kubernetes-security-announce] group for security and vulnerability announcements. You can also subscribe to an RSS feed of the above using . Instructions for reporting a vulnerability can be found on the [Kubernetes Security and Disclosure Information] page. Information about supported Kubernetes versions can be found on the [Kubernetes version and version skew support policy] page on the Kubernetes website.
Project: Kubeflow (Orchestration & Management / Scheduling & Orchestration)
File: images.md

<!-- START doctoc generated TOC please keep comment here to allow auto update --> <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> Table of Contents generated with - <!-- END doctoc generated TOC please keep comment here to allow auto update --> This page contains information about how Kubeflow builds and maintains docker images. Our prow jobs can be used to build docker images on every pre/postsubmit. We currently do this by using docker in docker to run docker build. Our test jobs can use gcr.io/kubeflow-ci to publish the images. This registry is not public. Our releases also publish images using Argo workflows; for more info see . We currently use the registry gcr.io/kubeflow-images-public. There are open issues to Publish images to Dockerhub as well Create registry gcr.io/kubeflow-images
Project: Envoy (Orchestration & Management / Service Proxy)
File: gh-cve-template.md

This template is for public disclosure of CVE details on Envoy's GitHub. It should be filed with the public release of a security patch version, and will be linked to in the announcement sent to envoy-security-announce@googlegroups.com. The title of this issue should be the CVE identifier and it should have the `security` label applied. Brief description used when filing CVE. ($CVSSSCORE, $SEVERITY) Envoy x.y.z and before. List affected internal components and features. How would an attacker use this? Individual and optional organization. If there is proof-of-concept or example, provide a concrete example. Deep dive into the defect. This should be detailed enough to maintain a record for posterity while being clear and concise. Are there configuration or CLI options that can be used to mitigate? How can exploitation of this bug be detected in existing and future Envoy versions? E.g. access logs. CVE: $CVEURL Any other public information.
Project: BFE (Orchestration & Management / Service Proxy)
File: mod_tcp_keepalive.md

modtcpkeepalive is used to set strategy of sending keepalive message in tcp connection. In some situation, like smart watch, the device is sensitive to power consumption, it may be necessary to close the TCP-KeepAlive heartbeat message or increase the interval of sending TCP-KeepAlive heartbeat message. modtcpkeepalive can help to handle situation like this. conf/modtcpkeepalive/modtcpkeepalive.conf | Config Item | Description | | -- | | | Basic.DataPath | String<br>Path of product rule configuration | | Log.OpenDebug | Boolean<br>Open debug mode or not | ```ini [Basic] DataPath = ../data/modtcpkeepalive/tcp_keepalive.data [Log] OpenDebug = false ``` | Config Item | Description | | -- | | | Version | String<br>Version of config file | | Config | Object<br>Rules for each product | | Config{k} | String<br>Product name | | Config{v} | Array<br>A list of rules | | Config{v}[] | Object<br>A specific rule | | Config{v}[].VipConf | Array<br>The list of virtual IPs to set the keepalive message strategy | | Config{v}[].KeepAliveParam | Object<br>The specific keepalive message strategy| | Config{v}[].KeepaliveParam.Disable | Bool<br>Disable sending keepalive message or not, default false | | Config{v}[].KeepaliveParam.KeepIdle | Int<br>Period to send heartbeat message since there is no data transport in tcp connection | | Config{v}[].KeepaliveParam.KeepIntvl | Int<br>Period to send heartbeat message again when last message is not applied | | Config{v}[].KeepaliveParam.KeepCnt | Int<br>Counter to resend heartbeat message when last message is not applied | ```json { "Config": { "product1": [ { "VipConf": ["10.1.1.1", "10.1.1.2"], "KeepAliveParam": { "KeepIdle": 70, "KeepIntvl": 15, "KeepCnt": 9 } }, { "VipConf": ["10.1.1.3"], "KeepAliveParam": { "Disable": true } } ], "product2": [ { "VipConf": ["10.2.1.1"], "KeepAliveParam": { "KeepIdle": 20, "KeepIntvl": 15 } } ] }, "Version": "2021-06-25 14:31:05" } ``` | Metric | Description | | - | - | | CONNTOSET | Counter for connection which hit rule, to set or disable keeplaive | | CONNSETKEEP_IDLE | Counter for connection set keepalive idle | | CONNSETKEEPIDLEERROR | Counter for connection set keepalive idle error | | CONNSETKEEP_INTVL | Counter for connection set keepalive interval | | CONNSETKEEPINTVLERROR | Counter for connection set keepalive interval error | | CONNSETKEEP_CNT | Counter for connection set keepalive retry count | | CONNSETKEEPCNTERROR | Counter for connection set keepalive retry count error | | CONNDISABLEKEEP_ALIVE | Counter for connection disable keepalive message | | CONNDISABLEKEEPALIVEERROR | Counter for connection disable keepalive error | | CONNCOVERTTOTCPCONN_ERROR | Counter for connection convert to TCPConn error |
Project: Service Mesh Performance (Orchestration & Management / Service Mesh)
File: methodology.md

layout: page title: Test Methodology permalink: dashboard/methodology redirect_from: dashboard/methodology/ language: en display-title: "true" list: exclude Meshery is the canonical implementation of the Service Mesh Performance specification. You can choose from multiple load generators and use a highly configurable set of load profiles with variable tunable facets to run a performance test. Meshery packages all these features into an easy-to-use GitHub Action. The is available in the GitHub Marketplace. You can create your own performance profiles to run repeatable tests with Meshery via: Configurable Benchmarking Test: Users can provide their own configuration, choose different service meshes and load generators. Scheduled Benchmarking Test: The matrix of different service meshes, load generators and configurations will be run periodically. CNCF Community Infrastructure Lab resources is contributed and managed by , a leading bare metal cloud, as part of its commitment to the cloud native and open source communities. We have extended the to run benchmark tests with in CNCF Community Infrastructure Lab, which greatly improved the flexibility and credibility of performance bencharmk tests. <a href="/pages/dashboard/methodology/smp-action-sequence-diagram.jpg"><img src="/pages/dashboard/methodology/smp-action-sequence-diagram.jpg" width="100%" /></a> The results from the tests are updated on the Performance Management dashboard in Meshery. To learn more about interpreting the test results, check out this guide. You can always checkout the to dive-deep into these features.
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2017-12-01-mesos-1-2-3-released.md

layout: post title: Apache Mesos 1.2.3 Released permalink: /blog/mesos-1-2-3-released/ published: true post_author: display_name: Adam B tags: Release The latest (and final) Mesos 1.2.x release, 1.2.3, is now available for . This release includes important bug fixes on top of 1.2.2. It is recommended to use this version if you are considering using Mesos 1.2. More specifically, this release includes the following bug fixes: - Docker executor hangs forever if `docker stop` fails. - Launching two tasks with the same Docker image simultaneously may cause a staging dir never cleaned up. - Compile error with recent glibc. - Build failure with glibc 2.12. - Mesos slave stucks. - Docker image with universal containerizer does not work if WORKDIR is missing in the rootfs. - Mesos Agent Sends TASK_KILL status update to Master, and still launches task. - Framework might not receive status update when a just launched task is killed immediately. - Launching a nested container with namespace/pid isolation, with glibc < 2.25, may deadlock the LinuxLauncher and MesosContainerizer. - Agent may drop pending kill task status updates. - Agent may process a kill task and still launch the task. - Scheduler hang when registration fails. - Ordering dependency between 'linux/capabilities' and 'docker/runtime' isolator. - Abnormal termination of default executor can cause MesosContainerizer::destroy to fail. - OOM due to LibeventSSLSocket send incorrectly returning 0 after shutdown. - Handle `/proc/self/ns/pidforchildren` when parsing available namespace. - Handle cgroups v2 hierarchy when parsing /proc/self/cgroups. - The command/default/docker executor can incorrectly send a TASK_FINISHED update even when the task is killed. - Stout fails to compile with libc >= 2.26. - Killing TASK_GROUP fail to kill some tasks. - The default executor does not propagate missing task exit status correctly. - Masters can lose track of tasks' executor IDs. Full release notes are available in the release Rolling upgrades from a Mesos 1.2.2 cluster to Mesos 1.2.3 are straightforward. Please refer to the for detailed information on upgrading to Mesos 1.2.3 from 1.1.x or 1.0.x. NOTE: Since Mesos 1.2.1, the master does not allow 0.x agents to register. Please try out this release and let us know what you think. If you run into any issues, let us know on the . Thanks to the 12 contributors who made 1.2.3 possible: Adam B, Alexander Rukletsov, Andrei Budnik, Benjamin Hindman, Benjamin Mahler, Gaston Kleiman, Gilbert Song, James Peach, Jie Yu, Kapil Arya, Neil Conway, and Qian Zhang.
Project: TARS (Orchestration & Management / Remote Procedure Call)
File: PULL_REQUEST_TEMPLATE.md

IMPORTANT: Please do not create a Pull Request without creating an issue first. Any change needs to be discussed before proceeding. Failure to do so may result in the rejection of the pull request. Please provide enough information so that others can review your pull request: <!-- You can skip this if you're fixing a typo or adding an app to the Showcase. --> Explain the details for making this change. What existing problem does the pull request solve? <!-- Example: When "Adding a function to do X", explain why it is necessary to have a way to do X. --> Test plan (required) Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI. <!-- Make sure tests pass on both Travis and Circle CI. --> Code formatting <!-- See the simple style guide. --> Closing issues Put `closes #XXXX` in your comment to auto-close the issue that your PR fixes (if such).
Project: Consul (Orchestration & Management / Service Mesh)
File: windows-test.md

This file is the entrypoint to understand how to execute Envoy integration tests on Windows as well as to understand the differences between Linux tests and Windows tests. Below you can find a list of relevant documentation that has been written while working on supporting the Envoy integration tests on Windows. : On this file you will find why the testing architecture on Windows differs from Linux's. : Here you will find how to build the images required for executing the tests. : This file lists, among other things everything we needed to change/adapt for the existing tests to run in Windows containers. Before running the integration tests, you must pre-build the core images that the tests require to be ran on the Windows environment. Make sure to check out the `BUILD-IMAGES` file for this purpose. During the execution of the integration tests, several images are built based-on the pre-built core images. To get more information about these and how to run them independently, please check out the `docker.windows` file . To run all the integration tests, you need to execute next command ```shell go test -v -timeout=30s -tags integration ./test/integration/connect/envoy -run="TestEnvoy" -win=true ``` To run a single test case, the name should be specified. For instance, to run the `case-badauthz` test, you need to execute next command ```shell go test -v -timeout=30m -tags integration ./test/integration/connect/envoy -run="TestEnvoy/case-badauthz" -win=true ``` :warning: Note that the flag `-win=true` must be specified as shown in the above commands. This flag is very important because the same allows to indicate that the tests will be executed on the Windows environment. When executing the Envoy integration tests the End of Line Sequence of every related file and or script will be automatically changed from LF to CRLF.
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2014-07-21-mesos-0-19-1-released.md

layout: post title: Apache Mesos 0.19.1 Released permalink: /blog/mesos-0-19-1-released/ published: true post_author: display_name: Ben Mahler twitter: bmahler tags: Release The latest Mesos release, 0.19.1 is now available for . This release fixes a bug in the Java and Python APIs in which the garbage collection of a MesosSchedulerDriver object leads to a framework unregistration. More details can be found in , the from Whitney Sorenson, and the from Benjamin Hindman. This release has the following bug fixes: - Mesos Fetcher doesn't support URLs that have 30X redirects. - Scheduler process is not explicitly terminated in the destructor of MesosSchedulerDriver. - A container destruction in the middle of a launch leads to CHECK failure. - No longer able to spin up Mesos master in local mode. - MesosSchedulerDriver should never, ever, call 'stop'. - Master does not create work directory when missing. Upgrading to 0.19.1 can be done seamlessly on a 0.19.0 cluster. If upgrading from 0.18.x, please refer to the documentation. Thanks to all the contributors for 0.19.1: Tom Arnfeld, Ian Downes, Benjamin Hindman, Benjamin Mahler, Vinod Kone, Whitney Sorenson.
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.26.3.md

We are delighted to present version v1.26.3 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. Updates Envoy to v1.27.4. See the release notes for v1.27.4 . Updates Go to v1.20.14. See the release notes for v1.20.14 . For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.26.3 is tested against Kubernetes 1.26 through 1.28. 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 .