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

<h1 align="center"> <p align="center">Katalyst-core</p> </h1> English | Katalyst aims to provide a universal solution to improve resource utilization and reduce overall costs in the cloud. The main features include: QoS-based Resource Model: Katalyst provides a pre-defined QoS model along with multiple enhancements to meet the QoS requirements of various workloads; Elastic Resource Management: Katalyst provides both horizontal and vertical scaling implementations, along with an extensible mechanism for out-of-tree algorithms; Topology-aware Scheduling and Allocation: Katalyst extends the capabilities of the native scheduler and kubelet to be aware of the NUMA and device topology when scheduling Pods and allocating resources to them, thereby improving the performance of workloads; Fine-grained Resource Isolation: Katalyst provides real-time and fine-grained resource over-commitment, allocation and isolation strategies for each QoS through auto-tuned workload profiling. Katalyst contains three main projects: : API definitions for the Katalyst project, including CRDs, protocols, the QoS model, and more; : Katalyst core implementations; : Helm charts for all projects in KubeWharf; A more detailed introduction will be presented in the future. <div align="center"> <picture> <img src="docs/imgs/katalyst-overview.jpg" width=80% title="Katalyst Overview" loading="eager" /> </picture> </div> Katalyst runs on a KubeWharf enhanced kubernetes cluster. Please refer to for detailed deployment instructions. Please refer to for detailed helm charts. Since KubeWharf enhanced kubernetes is developed based on specific versions of upstream Kubernetes and maintains API compatibility with corresponding Kubernetes versions, if you wish to run other components (e.g. operators), please note its compatibility with the corresponding Kubernetes API version. Katalyst provides several example yaml to demonstrate the common use cases. For more information, please refer to . We currently have a tentative bi-weekly meeting to discuss proposals, review milestones, do Q&As and so forth. Bi-weekly, Thursday at 19:30 UTC+8 If you have any questions or wish to contribute, you are welcome to communicate via GitHub issues or pull requests. Alternatively, you may reach out to us via <img src="/docs/imgs/lark-qrcode.png" width="200"> If you are willing to be a contributor of the Katalyst project, please refer to our document for details. Katalyst is under the Apache 2.0 license. See the file for details. Certain implementations in Katalyst rely on the existing code from Kubernetes and the credits go to the original Kubernetes authors.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: README.md

This module is the jdbc registry plugin module, this plugin will use jdbc as the registry center. Will use the database configuration same as DolphinScheduler in api'yaml default. Initialize the database table If you use Mysql you can directly execute the sql script `src/main/resources/mysqlregistryinit.sql`. If you use Postgresql you can directly execute the sql script `src/main/resources/postgresqlregistryinit.sql`. Change the config You need to set the registry properties in master/worker/api's application.yml ```yaml registry: type: jdbc ``` After do this two steps, you can start your DolphinScheduler cluster, your cluster will use mysql as registry center to store server metadata. NOTE: You need to add `mysql-connector-java.jar` into DS classpath if you use mysql database, since this plugin will not bundle this driver in distribution. You can get the detail about <a href="https://dolphinscheduler.apache.org/en-us/docs/3.1.2/guide/installation/pseudo-cluster">Initialize the Database</a>. ```yaml registry: type: jdbc term-refresh-interval: 2s term-expire-times: 3 ``` You need to set the registry properties in master/worker/api's application.yml ```yaml registry: type: jdbc term-refresh-interval: 2s term-expire-times: 3 hikari-config: jdbc-url: jdbc:mysql://127.0.0.1:3306/dolphinscheduler username: root password: root maximum-pool-size: 5 connection-timeout: 9000 idle-timeout: 600000 ``` ```yaml registry: type: jdbc term-refresh-interval: 2s term-expire-times: 3 hikari-config: jdbc-url: jdbc:postgresql://localhost:5432/dolphinscheduler username: root password: root maximum-pool-size: 5 connection-timeout: 9000 idle-timeout: 600000 ```
Project: Tengine (Orchestration & Management / Service Proxy)
File: ngx_http_upstream_dynamic.md

Name ==== ngxhttpupstreamdynamicmodule Description =========== This module provides the functionality to resolve domain names into IP addresses in an upstream at run-time. Examples ======== upstream backend { dynamicresolve fallback=stale failtimeout=30s; server a.com; server b.com; } server { ... proxy_pass http://backend; } Directives ========== dynamic_resolve Syntax: dynamic_resolve [fallback=stale|next|shutdown] [fail_timeout=time] Default: - Context: upstream Enable dynamic DNS resolving functionality in an upstream. The 'fallback' parameter specifies what action to take if a domain name can not be resolved into an IP address: stale, use the original IP addresses resolved when tengine starts. next, go to next availiable server in the upstream. shutdown, finalize current request. The 'fail_timeout' parameter specifies how long time tengine considers the DNS server as unavailiable if a DNS query fails for a server in the upstream. In this period of time, all requests comming will follow what 'fallback' specifies.
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: new-project-logo.md

title: "New Project Logo" linkTitle: "New Project Logo" date: 2023-11-21 <!-- 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 Apache Avro project has a new project logo! The old logo was derived from the logo of a (now defunct) aircraft manufacturer in Great Britain. This posed a risk, as the Apache foundation would not contest legal action (even if extremely unlikely). But thanks to Emma Kellam, we now have a new logo! She has made several logo designs, and after some debate and several votes (it was a close call!), we can announce the new logo: <p style="height: 10rem"> {{< project_logo >}} </p> The new logo is an homage to the previous logo, which is also triangular and uses blue colours. The paper airplane embodies keywords like 'fast', 'small' and 'efficient'. The blobby tail left behind by the airplane makes the icon unique and embodies 'flow' and 'transformation'. All in all a very nice logo for Apache Avro, which embodies the same keywords. Thanks for all your hard work Emma, and welcome!
Project: Koordinator (Orchestration & Management / Scheduling & Orchestration)
File: bug-report.md

name: Bug Report about: Create a report to help us improve title: "[BUG]" labels: kind/bug <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--> What happened: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: App version: Kubernetes version (use `kubectl version`): Install details (e.g. helm install args): Node environment (for koordlet/runtime-proxy issue): Containerd/Docker version: OS version: Kernal version: Cgroup driver: cgroupfs/systemd Others:
Project: APISIX (Orchestration & Management / API Gateway)
File: websocket-authentication.md

title: WebSocket Authentication keywords: API Gateway Apache APISIX WebSocket Authentication description: This article is a guide on how to configure authentication for WebSocket connections. <!-- --> Apache APISIX supports traffic, but the WebSocket protocol doesn't handle authentication. This article guides you on how to configure authentication for WebSocket connections using Apache APISIX. To establish a WebSocket connection, the client sends a WebSocket handshake request, for which the server returns a WebSocket handshake response as shown below: ```text title="Client request" GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 Origin: http://example.com ``` ```text title="Server response" HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= Sec-WebSocket-Protocol: chat ``` The handshake workflow is shown below: APISIX supports several authentication methods like , , and . While establishing connections from the client to server in the handshake phase, APISIX first checks its authentication information before choosing to forward the request or deny it. Before you move on, make sure you have: A WebSocket server as the Upstream. This article uses : `wss://ws.postman-echo.com/raw`. APISIX 3.0 installed. First we will create a Route to the Upstream echo service. Since the Upstream uses wss protocol, the scheme is set to `https`. We should also set `enable_websocket` to `true`. In this tutorial, we will use the Plugin. This would work similarly for other authentication methods: ```shell curl --location --request PUT 'http://127.0.0.1:9180/apisix/admin/routes/1' \ --header 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' \ --header 'Content-Type: application/json' \ --data-raw '{ "uri": "/*", "methods": ["GET"], "enable_websocket": true, "upstream": { "type": "roundrobin", "nodes": { "ws.postman-echo.com:443": 1 }, "scheme": "https" }, "plugins": { "key-auth": {} } }' ``` We will now create a and add a key `thisisthe_key`. A user would now need to use this key configured in the Consumer object to access the API. ```sh curl --location --request PUT 'http://127.0.0.1:9180/apisix/admin/consumers/jack' \ --header 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' \ --header 'Content-Type: application/json' \ --data-raw '{ "username": "jack", "plugins": { "key-auth": { "key": "thisisthe_key" } } }' ``` Now, if you try to connect `ws://127.0.0.1:9080/raw` without the `apikey` header or an incorrect key, APISIX will return a `401 Unauthorized`. To authenticate, you can add the header `apikey` with the value `thisisthe_key`:
Project: Fluid (Orchestration & Management / Scheduling & Orchestration)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at oss-conduct@uber.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at .
Project: Gloo (Orchestration & Management / API Gateway)
File: annotations.proto.sk.md

title: "annotations.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Copyright (c) 2015, Google Inc. Licensed 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 http://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. <!-- 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: gRPC (Orchestration & Management / Remote Procedure Call)
File: fork_support.md

In Python, multithreading is ineffective at concurrency for CPU bound tasks due to the GIL (global interpreter lock). Extension modules can release the GIL in CPU bound tasks, but that isn't an option in pure Python. Users use libraries such as multiprocessing, subprocess, concurrent.futures.ProcessPoolExecutor, etc, to work around the GIL. These modules call `fork()` underneath the hood. Various issues have been reported when using these modules with gRPC Python. gRPC Python wraps gRPC core, which uses multithreading for performance, and hence doesn't support `fork()`. Historically, we didn't support forking in gRPC, but some users seemed to be doing fine until their code started to break on version 1.6. This was likely caused by the addition of background c-threads and a background Python thread. gRPC Python applications can enable client-side forking when two environment variables are given: ``` export GRPCENABLEFORK_SUPPORT=true export GRPCPOLLSTRATEGY=poll ``` The fork-support effort only works with "epoll1" and "poll" polling strategy. There is no active development to extend fork-support's coverage. For more details about poll strategy setting, see https://github.com/grpc/grpc/blob/master/doc/environment_variables.md. Complexities mentioned in the background section are inevitable for "pre-fork" usage, where the application creates gRPC Python objects (e.g., client channel) before invoking `fork()`. However, if the application only instantiate gRPC Python objects after calling `fork()`, then `fork()` will work normally, since there is no C extension binding at this point. This idea is demonstrated by the [multiprocessing example](https://github.com/grpc/grpc/tree/master/examples/python/multiprocessing).
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.0.0-released.md

title: "Avro 1.0.0" linkTitle: "Avro 1.0.0" date: 2010-07-15 <!-- 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 first release of Avro is now available. To download, it, use the "Download" link below.
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2015-09-30-announcing-mesoscon-eu-2015-hackathon.md

layout: post title: "Announcing the #MesosCon Europe Hackathon" permalink: /blog/announcing-mesoscon-eu-2015-hackathon/ published: true post_author: display_name: Casey Bisson twitter: misterbisson tags: MesosCon We are proud to announce the first ever hackathon on Friday, October 9th, 2015. This event is an opportunity to contribute to the project, learn from other members of the community, and build some fantastic hacks. The hackathon is being sponsored by , and, though not required, participants are invited to use Joyent's cloud during the hack day. Joyent is offering each participant substantial service credits in their cloud to kickstart work and continue hacking after the event. We are challenging participants to hack on Mesos in two categories: Community need: These are issues logged in the Mesos issue tracker that have received a large amount of activity (comments, votes, etc), and address some of the larger problems or pain points for the community. Suggested projects include new features, bugs, or documentation. Peoples choice: These contributions will be voted on by your peers, and our guidance is intentionally open-ended so teams will run wild with their ideas. Were excited to see what you come up with. Additionally, Joyent is offering a container-native bonus award to one hack in each of the above categories that best leverages Joyent's Triton bare metal container infrastructure. Joyent's judges may award the container-native bonus at their discretion. Coding may not begin until the hackathon officially begins, although we encourage you to plan and scheme ahead of time! Sourcecode from the hackathon must be fully available on Github, Bitbucket, or a public source repo in order to be successfully submitted. Code must additionally be licensed in a manner compatible with Mesos' licensing. Submitted applications must run. Teams may have a maximum of four contributors. A team may only win one category. Submissions must be related to Mesos in some way. These rules are subject to change. Please hack the code, not the rules: if you think you're doing something that's against the rules or that gives you an unfair advantage, you probably shouldn't do it. 9:00 - Hacking begins at conference center 13:00 - Lunch arrives 17:00 - Coding stops, refreshments are served 17:15 - Re-explain the voting rules 17:20 - Presentations start - Each team gets 5 minutes to pitch what they built and show it off 18:00 - Voting occurs 18:15 - Winners announced The hackathon is open to all attendees. Please indicate your interest in the hackathon while registering for the conference or update your registration to reflect it.
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: CONTRIBUTING.md

Welcome to Kubernetes. We are excited about the prospect of you joining our ! The Kubernetes community abides by the CNCF . Here is an excerpt: As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. We have full documentation on how to get started contributing here: <! If your repo has certain guidelines for contribution, put them here ahead of the general k8s resources --> Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests - Main contributor documentation, or you can just jump directly to the - Common resources for existing developers - We have a diverse set of mentorship programs available that are always looking for volunteers! <! Custom Information - if you're copying this template for the first time you can add custom content here, for example: - Replace `kubernetes-users` with your slack channel string, this will send users directly to your channel. -->
Project: Docker Swarm (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 ```