cwielenb/CNCF-Dataset huggingface dataset:
Project: Serverless Devs (Orchestration & Management / Scheduling & Orchestration)
File: registry_model.md

title: Registry model description: 'Registry model' position: 4 category: 'Registry model' This topic describes the build mode of Serverless Registry Model (SRM). Serverless Registry obtains and stores the following package information. | Data name | Type | Description | | -- | | | | Name | String | The name of the package. | | Type | String | Component/Application | | Version | String | Package version, which conforms to the following format: Major.Minor.Patch. | | PublishTime | Number | Timestamp of publication. Unit: second. | | VersionBody | String | Description of the version. | In addition to the preceding basic specification, Serverless Registry providers and organizations can store more data based on business requirements, including package contributor IDs, which can be used for authentication and package status. The following figure shows the process on how package developers and serverless developers publish and use packages. As shown in the preceding figure, package developers must provide packages to Serverless Registry based on the . Serverless developers must download and use packages by using Serverless Devs. The following items describe the key specification of this process: Serverless Registry only accepts the ZIP files of components and applications that are contributed by package developers. The code and other content included in the ZIP packages conform to . You must follow the following specification to query the package versions and download the packages, including applications and components. that are published on Serverless Registry: Query all versions: MethodGET URI{package-name}/releases Response ``` { "tag_name": "1.1.13", "created_at": "2021-01-04T07:41:23Z", "zipball_url": "https://api.github.com/repos/Serverless-Devs/Serverless-Devs/zipball/1.1.13", "body": "- English: \r\n - Fix the bug that the temporary key acquisition fails under boundary conditions" } ``` Query the latest version: MethodGET URI{package-name}/releases/latest Response ``` { "tag_name": "1.1.13", "created_at": "2021-01-04T07:41:23Z", "zipball_url": "https://api.github.com/repos/Serverless-Devs/Serverless-Devs/zipball/1.1.13", "body": "- English: \r\n - Fix the bug that the temporary key acquisition fails under boundary conditions" } ``` Download a package: MethodGET URI{package-name}/zipball/{version} Responsecomponent compression packages In addition to the preceding basic specification, Serverless Registry providers and organizations can provide capabilities to update and delete packages and to change permissions
Project: Kong (Orchestration & Management / API Gateway)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to make 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 support@konghq.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and 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: Knative (Orchestration & Management / Scheduling & Orchestration)
File: bug-report.md

name: Bug report about: Report a bug in knative/serving title: '' labels: kind/bug assignees: '' <!-- If you need to report a security issue with Knative, send an email to knative-security@googlegroups.com. --> <!-- Remove the '> ' to select /area API /area autoscale /area build /area monitoring /area networking /area test-and-release Other classifications: /kind good-first-issue /kind process /kind spec --> <!-- Delete all but your choice --> 0.9.x 0.10.x 0.11.x Output of `git describe --dirty` <!-- Briefly describe what you expect to happen --> <!-- Briefly describe what is actually happening --> <!-- How can a maintainer reproduce this issue (be detailed) -->
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.4.1-released.md

title: "Avro 1.4.1" linkTitle: "Avro 1.4.1" date: 2010-10-13 <!-- 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.4.1 has been released!
Project: Slime (Orchestration & Management / Service Mesh)
File: CONTRIBUTING_GUILDLINES.md

Thank you for your interest in the slime program. Please take some time to learn about participation and communication in the slime program. First, please review the file, and we will adhere to the principles therein. In general, we encourage you to make communication as simple and easy as possible, so we will try to minimize the number of constraints, and the following is more of a process for informing and advising each other so that we can get the information we want easily. For more formal and definite communication content, such as bug reports, feature suggestions, etc., we recommend using . For others, such as usage issues, feature questions, etc., a more flexible communication method is recommended, see . For the issue method, we have preset several types and created different content format templates, please fill them according to the format, so that others can understand the main points of the content faster. If you are interested in participating in the slime project, you can find appropriate content in , and participation in the issue discussion is also a good form. If you wish to participate in the development, you can look for a feature with or label and judge whether it is suitable for you according to the description therein. If you decide to take over, you can reply below the issue, and our maintainers will determine it as soon as possible to avoid duplication of work. Of course, if there is already clear content, you can directly follow the process below to submit a PR. first, do on the slime project do some initialization work in the local repository add slime remote ```sh git remote add upstream git@github.com:slime-io/slime.git ``` rebase slime remote ```sh git checkout master git pull --rebase upstream master ``` create a new branch, suggest an ideographic name, such as `feature-xxx`, `fix-xxx` ```sh git checkout -b feature-xx ``` Complete the corresponding code changes, commit, and push to your remote repository ```sh git push -f origin feature-xx ``` Click `New pull request` on the `Pull requests` page of your own remote repository (e.g. `github.com/xxx/slime/pull`). Select the head repository branch as the development branch such as `feature-xx`, then click `Create pull request`, fill in the appropriate title and description content and click `Create pull request` again. You can refer to the sample PR: https://github.com/slime-io/slime/pull/179 We will arrange a reviewer as soon as possible after the contributor submits the PR. During the review process, there may be some feedback comments or requests for changes, so please check the system notifications and emails. The reviewer will approve the PR after making the corresponding changes until the differences disappear and agreement is reached, and then the maintainer with permission will carry out the merge operation. The process is as follows. contributor -> PR feedback/request change <- reviewer contributor -> change(recommit, repush) feedback/request change <- reviewer ... approve <- reviewer merge <- maintainer
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2014-06-11-mesoscon-2014-program-announced.md

layout: post title: "#MesosCon Program Announced, Now Including Hackathon" permalink: /blog/mesoscon-2014-program-announced/ published: true post_author: display_name: Dave Lester twitter: davelester tags: Announcement, MesosCon Today were excited to announce the for 2014, the first ever conference dedicated to the Mesos ecosystem. It will take place in Chicago August 21-22, 2014, and be co-located with 2014. MesosCon welcomes attendees who are advanced users, along with those that are new to the project. There will be time to socialize, share and learn from adopters to core committers. The first day will begin with an introductory Mesos 101 workshop and keynote presentations from Mesos PMC lead Benjamin Hindman (Twitter) and John Wilkes (Google). Day one will include single track talks featuring: Mesos : including , , , and a stream processing framework developed by Netflix. An operations perspective on Mesos: including talks on the challenges of running an elastic cluster, and using with Mesos. Presentations from companies who use Mesos in production: including eBay, HubSpot, and Airbnb. These presenters will also participate in a panel discussion. The final day will include a Mesos hackathon, generously sponsored by Atlassian. In advance of the hackathon, the community will seed ideas for specific features and projects to work on the . and filling up quickly so register today. MesosCon is sponsored by Atlassian, eBay, Mesosphere, and Twitter. Interested companies can contact us regarding . For the latest updates on #MesosCon, we invite you to follow on Twitter.
Project: BFE (Orchestration & Management / Service Proxy)
File: mod_block.md

mod_block blocks incoming connections/requests based on defined rules. conf/modblock/modblock.conf | Config Item | Description | | -- | -- | | Basic.ProductRulePath | Path of product rule configuration | | Basic.IPBlocklistPath | Path of ip blocklist file | ```ini [Basic] ProductRulePath = modblock/blockrules.data IPBlocklistPath = modblock/ipblocklist.data ``` Format of IPBlocklistPath file ``` 192.168.1.253 192.168.1.254 192.168.1.250 ``` conf/modblock/blockrules.data | Config Item | Description | | -- | | | Version | String<br>Version of config file | | Config | Struct<br>Block rules for each product | | Config{k} | String<br>Product name | | Config{v} | Object<br>A list of rules | | Config{v}[] | Object<br>A block rule | | Config{v} | | Config{v}[].Name | String<br>Name of rule | | Config{v}[].Action | Object<br>Action of rule | | Config{v}[].Action.Cmd | String<br>Name of action | | Config{v}[].Action.Params | Object<br>A list of action parameters | | Config{v}[].Action.Params[] | String<br>A action parameter | | Action | Description | | | -- | | CLOSE | Close the connection | | ALLOW | Accept the request | ```json { "Version": "20190101000000", "Config": { "global": [ { "action": { "cmd": "ALLOW", "params": [] }, "cond": "reqhostin(\"n.example.org\") && reqpathprefixin(\"/index/\", false) && reqquerykeyin(\"space\")", "name": "example whiterule" } ], "example_product": [ { "action": { "cmd": "CLOSE", "params": [] }, "name": "example rule", "cond": "reqpathin(\"/limit\", false)" } ] } } ``` | Metric | Description | | - | | | CONN_ACCEPT | Counter for connection accepted | | CONN_REFUSE | Counter for connection refused | | CONN_TOTAL | Counter for all connnetion checked | | REQ_ACCEPT | Counter for request accepted | | REQ_REFUSE | Counter for request refused | | REQ_TOTAL | Counter for all request in | | REQTOCHECK | Counter for request to check | | WRONG_COMMAND | Counter for request with condition satisfied, but wrong command |
Project: Hango (Orchestration & Management / API Gateway)
File: Readme.md

We use helm to install gateway on kubernetes. If you do not have a kubernetes, you can start with 1.22 > Kubernetes Version >=1.17 Go to github hango-gateway's to download the latest version: , then decompress the zip file to a local directory Go to the "hango-gateway/install" directory. The directory structure tree is as follows ```xml install install common crds helm init-hango install.sh check.sh uninstall.sh ``` You will see three scripts for install (install.sh), check status (check.sh), and uninstall (uninstall.sh) respectively. You can directly execute the command Note: Make sure you have sufficient permissions before executing the script ```shell sh install.sh ``` After the script is executed, run the following command to verify the running status of the Hango gateway ```shell sh check.sh ``` The normal running status is as follows. If the container is not ready now, wait for a while and check it again ```shell ========= pods in namespace[hango-system] show below ========= NAME READY STATUS RESTARTS AGE gateway-proxy-55887cb579-mv9xh 1/1 Running 0 87s hango-api-plane-6c4554cfc4-ndnx5 1/1 Running 0 101s hango-portal-597bb489d6-45b2r 1/1 Running 0 101s hango-ui-75458cc7dc-b4x6b 1/1 Running 0 101s istio-e2e-app-85bb49bf75-t7slt 1/1 Running 0 101s hango-istiod-697b5c4456-67l92 1/1 Running 0 95s slime-75fcb44f68-w9x4x 1/1 Running 0 94s ``` Please configure K8S resources of Hango gateway by referring to the script content Go to "hango-gateway/install" directory Run the script to uninstall hango gateway Note: Make sure you have sufficient permissions before executing the script ```shell sh uninstall.sh ``` After the script is executed, run the following command to check the running status of the Hango gateway ```shell sh check.sh ``` After the uninstallation is complete, the namespaces and all containers under them will be deleted. If k8s resources still exist, you can try uninstall.sh script again or manually delete the resources ```shell ========= pods in namespace[hango-system] show below ========= No resources found in hango-system namespace. ``` Planing... Planing...
Project: Katalyst (Orchestration & Management / Scheduling & Orchestration)
File: wip-20220706-dynamic-configuration.md

title: Katalyst Reporter Manager authors: "luomingmeng" reviewers: "waynepeking348" "csfldf" "Aiden-cn" "sun-yuliang" creation-date: 2022-07-06 last-updated: 2023-02-23 status: provisional atalyst Dynamic Configuration i.e. `KatalystCustomConfig` (`KCC` for short) is a general framework to enable each daemon component to dynamically adjust its working status without restarting or re-deploying. The detailed proposal contents for Katalyst SysAdvisor is ongoing and will be released in the next quarter. <!-- toc --> - - - - <!-- /toc -->
Project: KubeStellar (Orchestration & Management / Scheduling & Orchestration)
File: turbonomic.md

Medium - <br/> <p align=center> <div id="spinner1"> <img width="140" height="140" src="../../../images/spinner.gif" class="centerImage"> </div> <iframe class="centerImage" id="embed1" width="0" height="0" src="https://www.youtube.com/embed/B3jZTnu1LDo?controls=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen style="visibility:hidden;" onload= "document.getElementById('spinner1').style.display='none';document.getElementById('embed1').style.visibility='visible';document.getElementById('embed1').width='720';document.getElementById('embed1').height='400';"></iframe> </p> As we can see from the blog and the demo, Turbonomic talks to KubeStellar via GitOps. The scheduling decisions are passed from Turbonomic to KubeStellar in two steps: Turbo -> GitHub repository. GitHub repository -> KubeStellar. For the 1st step (Turbonomic -> GitHub repository), a controller named "" creates PRs against the GitHub repository, where the PRs contains changes to scheduling decisions. There's also which intercepts Turbonomic actions and creates CRs for the above change reconciler. For the 2nd step (GitHub repository-> KubeStellar), we can use Argo CD. The detailed procedure to integrate Argo CD with KubeStellar is documented . As we can see from the blog and the demo, Turbonomic collects data from edge clusters. This is made possible by installing into each of the edge clusters. <p align=center> <div id="spinner2"> <img width="140" height="140" src="../../../images/spinner.gif" class="centerImage"> </div> <iframe class="centerImage" id="embed2" src="https://www.linkedin.com/embed/feed/update/urn:li:share:7066466334334668800" scrolling=no height="0" width="0" frameborder="0" allowfullscreen="" title="Embedded post" style="visibility:hidden;" onload= "document.getElementById('spinner2').style.display='none';document.getElementById('embed2').style.visibility='visible';document.getElementById('embed2').width='740';document.getElementById('embed2').height='400';"></iframe> </p> <style type="text/css"> .centerImage { display: block; margin: auto; } </style>
Project: Kuma (Orchestration & Management / Service Mesh)
File: 006-additional-retry-logic.md

Status: accepted Technical Story: https://github.com/kumahq/kuma/issues/4494 We currently set some defaults for the retryOn field for HTTP in our Retry policy. Some users may need additional flexibility so we should plumb through some extra fields from Envoy. User request (additional flexibility) ProxyTemplate Adding fields to Retry policy Chosen option: 2 because we want to provide a lower friction experience to add these fields. The change the policy would add a `retryOn` field to expose additional configuration options beyond our defaults. ```yaml spec: conf: http: backOff: baseInterval: 0.025s maxInterval: 0.250s numRetries: 5 perTryTimeout: 16s retryOn: all_5xx gateway_error ``` This addition would not change existing behavior in the case that the `http.retriableStatusCodes` field is not specified. This addition would change the existing behavior in the case that the `http.retriableStatusCodes` field is specified. Previously specifying this field would set the `retryOn` field to a default of `"connect-failure,refused-stream,retriable-status-codes"`. Following this change we will add only `retriable-status-codes` (as specifying them doesn't make sense otherwise), and leave the additional conditions to be specified by the user (which would be possible now) if desired. Due to this field being an enum, we cannot use `5xx` as a field name, so must prefix it (`all_5xx` above) then post 'convert' to the Envoy-native field name. We already use `retriablestatuscodes` as a field to specify which codes should be retried, however that is also one of the enum options in `retryOn`. We also need to have a different field name here and post-process back to the Envoy-native field name. Improve flexibility for configuring Retry policies. Additional complexity of policy?
Project: wasmCloud (Orchestration & Management / Scheduling & Orchestration)
File: 0008-embedded.md

This decision record covers our decision to not create our own fully supported wasmCloud host runtime for embedded devices that do not run on one of our already support targets (e.g. `arm` or `aarch64` etc). One of the main value propositions of the wasmCloud lattice is that it can connect actors and capability providers running anywhere. If that's true, then we must consider what it would take to run providers and actors on tiny embedded devices like asset trackers, sensor equipment, telemetry gathering devices, weather stations, maker boards, and the like. There are a few options that we considered: Create our own official first-party distribution for all supported devices Do not create a first-party distribution for embedded devices Provide guidance to capability provider developers on how to act as an "MQTT bridge" to remote embedded devices. We chose the last option, provide guidance to capability provider developers on how to act as an "MQTT bridge" to remote embedded devices. This will be resolved through a separate PR to our documentation site. In , we discuss all of the pros and cons of the various options. In short, it would be impractical and far too time and resource consuming for us to create releases and custom libraries for each combination of hardware and chipsets. Instead, offering the option of the "IoT proxy provider" seems like the best approach that keeps us focused on the cloud native runtime that allows actors to "run anywhere."
Project: Gloo (Orchestration & Management / API Gateway)
File: grpc_web.proto.sk.md

title: "grpc_web.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> GrpcWeb support is enabled be default. Use this extension to disable it. ```yaml "disable": bool ``` | Field | Type | Description | | -- | - | -- | | `disable` | `bool` | Disable grpc web support. | <!-- 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 -->