cwielenb/CNCF-Dataset huggingface dataset:
Project: KubeStellar (Orchestration & Management / Scheduling & Orchestration)
File: kyverno.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/tcpequs5pVM?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> <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:7072623853629263875" scrolling=no height="0" width="0" frameborder="0" allowfullscreen="" title="Kyverno and KubeStellar" 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> to create this document <style type="text/css"> .centerImage { display: block; margin: auto; } </style>
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl-config.md

title: Glooctl Config File weight: 60 description: Persistent configuration for `glooctl` When you use `glooctl`, it tries to read a configuration file located at `$HOME/.gloo/glooctl-config.yaml`. You can override the location of this file by setting the `--config` value (or alias `-f`) when you run a `glooctl` command. If the file does not exist, `glooctl` tries to write it. You can set the following top-level values. `checkTimeoutSeconds: int`. The maximum length of time to wait, in seconds, before giving up on an entire `glooctl check` call. A value of zero means no timeout. (default 0s)
Project: KubeStellar (Orchestration & Management / Scheduling & Orchestration)
File: release-testing.md

The following testing process should be applied to every new KubeStellar release in order to validate it, this include both regular releases and release candidates. All the tests should be done while the KubeStellar code is still under code-freeze and new code shouldn't be merged into the main branch until all tests are passed and the release is officially declared as ready. In case the release tests fail (even one of them), the release should be declared as unstable and a fix through a new release candidate should be worked on ASAP. The KubeStellar code-freeze should be lifted only after all tests are passed and a the release was completed. To reduce the exposure of instable releases the update of the KubeStellar site should be done only once all release tests passed successfully. The following section describe the tests that must be executed for each release. Our release tests consists of: Automatic tests running on Ubuntu X86 (see below) Manually initiated tests running on OCP (TODO: add specific version and machine details) Due to the lack of OCP based automatic testing, these tests will be performed only once a release candidate passed all other tests and is a candidate to become a regular release. Note: We plan to automate all release tests in the future KubeStellar CICD automatically runs a set of e2e tests on each new release. Currently these tests include 2 main test types bash based e2e tests and ginkgo based e2e tests. The bash test basically tests the scenario of . The ginkgo test cover the , and several other tests that are listed in the test . Note, however, that the content of the releases tests may be changed in the future. We will refer to those tests as the e2e release tests. The automatic tests are running on github hosted runners of type Ubuntu latest (currently 22.04) X86 64 bit Note: When a new release is created please verify that the automatic tests indeed executed and passed. As many of the KubeStellar customers are using OCP, the release tests should be executed on an OCP cluster as well. Currently these tests should be initiated manually on a dedicated OCP cluster that is reserved for the release testing process. TODO: The details on how to setup and run the test {: style="height:100px;width:100px"} KubeStellar is also used on other platforms such as ARM64, MacOS, etc.. Currently these platforms are not part of the routine release testing, however the KubeStellar team will try its best to help and solve issues detected on other platforms as well. Users should go through the regular procedure of opening issues against the KubeStellar .
Project: Eraser (Orchestration & Management / Scheduling & Orchestration)
File: introduction.md

title: Introduction slug: / When deploying to Kubernetes, it's common for pipelines to build and push images to a cluster, but it's much less common for these images to be cleaned up. This can lead to accumulating bloat on the disk, and a host of non-compliant images lingering on the nodes. The current garbage collection process deletes images based on a percentage of load, but this process does not consider the vulnerability state of the images. Eraser aims to provide a simple way to determine the state of an image, and delete it if it meets the specified criteria.
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: reclaim-action.md

In kube-batch there are 4 actions such as allocate, preempt, reclaim, backfill and with the help of plugins like conformance, drf, gang, nodeorder and more plugins. All these plugins provides behavioural characteristics how scheduler make scheduling decisions. Reclaim is one of the actions in kube-batch scheduler. Reclaim action comes into play when a new queue is created, and new job comes under that queue but there is no resource / less resource in cluster because of change of deserved share for previous present queues. When a new queue is created, resource is divided among queues depending on its respective weight ratio. Consider two queues is already present and entire cluster resource is used by both the queues. When third queue is created, deserved share of previous two queues is reduced since resource should be given to third queue as well. So jobs/tasks which is under old queues will not be evicted until, new jobs/tasks comes to new queue(Third Queue). At that point of time, resource for third queue(i.e. New Queue) should be reclaimed(i.e. few tasks/jobs should be evicted) from previous two queues, so that new job in third queue can be created. Reclaim is basically evicting tasks from other queues so that present queue can make use of it's entire deserved share for creating tasks. In Reclaim Action, there are multiple plugin functions that are getting used like, TaskOrderFn(Plugin: Priority), JobOrderFn(Plugin: Priority, DRF, Gang), NodeOrderFn(Plugin: NodeOrder), PredicateFn(Plugin: Predicates), ReclaimableFn(Plugin: Conformance, Gang, Proportion). Compares taskPriority set in PodSpec and returns the decision of comparison between two priorities. Compares jobPriority set in Spec(using PriorityClass) and returns the decision of comparison between two priorities. The job having the lowest share will have higher priority. The job which is not yet ready(i.e. minAvailable number of task is not yet in Bound, Binding, Running, Allocated, Succeeded, Pipelined state) will have high priority. NodeOrderFn returns the score of a particular node for a specific task by running through sets of priorities. PredicateFn returns whether a task can be bounded to a node or not by running through set of predicates. Checks whether a task can be evicted or not, which returns set of tasks that can be evicted so that new task can be created in new queue. In conformance plugin, it checks whether a task is critical or running in kube-system namespace, so that it can be avoided while computing set of tasks that can be preempted. It checks whether by evicting a task, it affects gang scheduling in kube-batch. It checks whether by evicting particular task, total number of tasks running for a job is going to be less than the minAvailable requirement for gang scheduling requirement. It checks whether by evicting a task, that task's queue has allocated resource less than the deserved share. If so, that task is added as a victim task that can be evicted so that resource can be reclaimed.
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-application.md

Set general information about your application such as its name, its type (mobile/web) and description. You can also give access to your application to registered groups. If relevant, you can set the domain used by your application (for instance `https://my-app.com`). It will help API publishers to properly configure access controls. TIP: You can set multiple domains separated by commas.
Project: Kubernetes (Orchestration & Management / Scheduling & Orchestration)
File: CONDUCT.md

Cobra will follow a steady release cadence. Non breaking changes will be released as minor versions quarterly. Patch bug releases are at the discretion of the maintainers. Users can expect security patch fixes to be released within relatively short order of a CVE becoming known. For more information on security patch fixes see the CVE section below. Releases will follow . Users tracking the Master branch should expect unpredictable breaking changes as the project continues to move forward. For stability, it is highly recommended to use a release. We will maintain two major releases in a moving window. The N-1 release will only receive bug fixes and security updates and will be dropped once N+1 is released. Deprecation of Go versions or dependent packages will only occur in major releases. To reduce the change of this taking users by surprise, any large deprecation will be preceded by an announcement in the and an Issue on Github. Maintainers will make every effort to release security patches in the case of a medium to high severity CVE directly impacting the library. The speed in which these patches reach a release is up to the discretion of the maintainers. A low severity CVE may be a lower priority than a high severity one. Cobra maintainers will use GitHub issues and the as the primary means of communication with the community. This is to foster open communication with all users and contributors. Breaking changes are generally allowed in the master branch, as this is the branch used to develop the next release of Cobra. There may be times, however, when master is closed for breaking changes. This is likely to happen as we near the release of a new version. Breaking changes are not allowed in release branches, as these represent minor versions that have already been released. These version have consumers who expect the APIs, behaviors, etc, to remain stable during the lifetime of the patch stream for the minor release. Examples of breaking changes include: Removing or renaming exported constant, variable, type, or function. Updating the version of critical libraries such as `spf13/pflag`, `spf13/viper` etc... Some version updates may be acceptable for picking up bug fixes, but maintainers must exercise caution when reviewing. There may, at times, need to be exceptions where breaking changes are allowed in release branches. These are at the discretion of the project's maintainers, and must be carefully considered before merging. Maintainers will ensure the Cobra test suite utilizes the current supported versions of Golang. Changes to this document and the contents therein are at the discretion of the maintainers. None of the contents of this document are legally binding in any way to the maintainers or the users.
Project: Envoy (Orchestration & Management / Service Proxy)
File: thrift_state_machine.md

Thrift Decoder State Machine ============================ Decoding Thrift messages can be visualized as a series of state transitions. Each state corresponds to the invocation of a function on the `ThriftProxy::Protocol` interface. Not pictured in the state diagram is the transient `WaitForData` state which implies that insufficient data was available to process a state and that the state machine should be resumed when more data is available. The `Value` states in the diagram are represented by multiple states in the actual state machine (`FieldValue`, `ListValue`, `MapKey`, `MapValue`, and `SetValue`). The various value states encode the transition from, for example, a list value (`ListValue`) to the `ListEnd` state. The state machine tracks "frames" which allow the state machine to record information about nested lists, maps, sets, and structures. Thrift allows these data types to be nested in arbitrary combinations and the frame records the state to return to at the end of each type. For lists, maps, and sets the frame also records the number of remaining elements.
Project: Fluid (Orchestration & Management / Scheduling & Orchestration)
File: VERSIONING.md

We follow the , and use the corresponding tooling. For the purposes of the aforementioned guidelines, controller-runtime counts as a "library project", but otherwise follows the guidelines exactly. For release branches, we generally tend to support backporting one (1) major release (`release-{X-1}` or `release-0.{Y-1}`), but may go back further if the need arises and is very pressing (e.g. security updates). Note the . Particularly: We DO guarantee Kubernetes REST API compability -- if a given version of controller-runtime stops working with what should be a supported version of Kubernetes, this is almost certainly a bug. We DO NOT guarantee any particular compability matrix between kubernetes library dependencies (client-go, apimachinery, etc); Such compability is infeasible due to the way those libraries are versioned.
Project: Fluid (Orchestration & Management / Scheduling & Orchestration)
File: MAINTAINERS.md

This page lists all active maintainers of this repository. If you were a maintainer and would like to add your name to the Emeritus list, please send us a PR. See for governance guidelines and how to become a maintainer. See for general contribution guidelines. , Datadog, Inc. , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC
Project: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: phoenix-live-dashboard.md

id: phoenix-live-dashboard title: Phoenix LiveDashboard sidebar_label: Phoenix LiveDashboard provides real-time performance monitoring and debugging tools. It's accessible at `:4010/dashboard`. All metrics are created via the same Prometheus metrics as those in the . Phoenix LiveDashboard is a much simpler and quicker overview over the RIG (or any Elixir app). It provides metrics in real-time fashion, but only from the point when you open a given metric (it doesn't use any database). In addition it offers some Erlang/Elixir specific statistics/information which you won't find in the .
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: dms.md

helps you migrate databases to AWS quickly and securely. The source database remains fully operational during the migration, minimizing downtime to applications that rely on the database. The AWS Database Migration Service can migrate your data to and from the most widely used commercial and open-source databases. DMS task plugin can help users to create and start DMS tasks in DolphinScheduler more conveniently. Contains two features: Create DMS task and start DMS task Restart DMS task We can create DMS task and start DMS task in two ways: Use interface Use JSON data DolphinScheduler will track the status of the DMS task and set the status to successfully completed when the DMS task is completed. Except for the CDC task without end time. So, if the `migrationType` is `cdc` or `full-load-and-cdc`, `cdcStopPosition` not be set, DolphinScheduler will set the status to successfully after the DMS task starts successfully. 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/dms.png" width="15"/> from the toolbar to the canvas. The task plugin picture is as follows Create and start DMS task by interface Restart DMS task by interface Create and start DMS task by JSON data Restart DMS task by JSON data Please refer to `Default Task Parameters` section for default parameters. isRestartTaskWhether to restart the task. If it is true, the task will be restarted. If it is false, the task will be created and started. isJsonFormatWhether to use JSON data to create and start the task. If it is true, the task will be created and started by JSON data. If it is false, the task will be created and started by interface. jsonDataJson data for creating and starting the task. Only when `isJsonFormat` is true, this parameter is valid. Parameters of creating and starting the task by interface migrationTypeThe type of migration. The value can be full-load, cdc, full-load-and-cdc. replicationTaskIdentifierThe name of the task. replicationInstanceArnThe ARN of the replication instance. sourceEndpointArnThe ARN of the source endpoint. targetEndpointArnThe ARN of the target endpoint. tableMappingsThe mapping of the table. Parameters of restarting the task by interface replicationTaskArnThe ARN of the task. Some AWS configuration is required, modify a field in file `common.properties` ```yaml resource.aws.access.key.id=<YOUR AWS ACCESS KEY> resource.aws.secret.access.key=<YOUR AWS SECRET KEY> resource.aws.region=<AWS REGION> ```
Project: KubeAdmiral (Orchestration & Management / Scheduling & Orchestration)
File: README.md

English | KubeAdmiral is a multi-cluster management system for Kubernetes, developed from . Kubernetes Federation v2 allows users to manage Kubernetes resources across multiple clusters through the use of federated types such as FederatedDeployment, FederatedReplicaSet, FederatedSecret, etc. KubeAdmiral extends the Kubernetes Federation v2 API, providing compatibility with the Kubernetes native API and more powerful resource management capabilities. KubeAdmiral also adds new features such as: A new scheduling framework with a rich set of scheduling plugins. Override policies. Automatic propagation of dependencies with follower scheduling. Status aggregation of member cluster resources. Scalability, stability and user experience enhancements KubeAdmiral supports Kubernetes versions from 1.16 up to 1.24. Using lower or higher Kubernetes versions may cause compatibility issues. For setup please refer to . If you are willing to be a contributor for the KubeAdmiral project, please refer to our document for details. 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 our . KubeAdmiral is under the Apache 2.0 license. See the LICENSE file for details. KubeAdmiral is a continuation of Kubernetes Federation v2, and certain features in KubeAdmiral rely on existing code from Kubernetes &mdash; all credits go to the original Kubernetes authors. We also refer to for some of our architecture and API design, all relevant credits go to the Karmada Authors.
Project: APISIX (Orchestration & Management / API Gateway)
File: global-rule.md

title: Global Rules keywords: API Gateway Apache APISIX Global Rules description: This article describes how to use global rules. <!-- --> A configuration can be bound directly to a , a or a . But what if we want a Plugin to work on all requests? This is where we register a global Plugin with Global Rule. Compared with the plugin configuration in Route, Service, Plugin Config, and Consumer, the plugin in the Global Rules is always executed first. The example below shows how you can use the `limit-count` Plugin on all requests: :::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 -X PUT \ http://{apisixlistenaddress}/apisix/admin/global_rules/1 \ -H 'Content-Type: application/json' \ -H "X-API-KEY: $admin_key" \ -d '{ "plugins": { "limit-count": { "time_window": 60, "policy": "local", "count": 2, "key": "remote_addr", "rejected_code": 503 } } }' ``` You can also list all the Global rules by making this request with the Admin API: ```shell curl http://{apisixlistenaddress}/apisix/admin/globalrules -H "X-API-KEY: $adminkey" ```
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: submit-code.md

First from the remote repository https://github.com/apache/dolphinscheduler.git* fork a copy of the code into your own repository There are currently three branches in the remote repository: master normal delivery branch After the stable release, merge the code from the stable branch into the master. dev daily development branch Every day dev development branch, newly submitted code can pull request to this branch. Clone your repository to your local `git clone https://github.com/apache/dolphinscheduler.git` Add remote repository address, named upstream `git remote add upstream https://github.com/apache/dolphinscheduler.git` View repository `git remote -v` At this time, there will be two repositories: origin (your own repository) and upstream (remote repository) Get/Update remote repository code `git fetch upstream` Synchronize remote repository code to local repository ``` git checkout origin/dev git merge --no-ff upstream/dev ``` If remote branch has a new branch such as `dev-1.0`, you need to synchronize this branch to the local repository ``` git checkout -b dev-1.0 upstream/dev-1.0 git push --set-upstream origin dev-1.0 ``` Create new branch ``` git checkout -b xxx origin/dev ``` Make sure that the branch `xxx` is building successfully on the latest code of the official dev branch After modifying the code locally in the new branch, submit it to your own repository: `git commit -m 'commit content'` `git push origin xxx --set-upstream` Submit changes to the remote repository On the github page, click "New pull request". Select the modified local branch and the branch you want to merge with the past, click "Create pull request". Then the community Committers will do CodeReview, and then he will discuss some details (including design, implementation, performance, etc.) with you. When everyone on the team is satisfied with this modification, the commit will be merged into the dev branch Finally, congratulations, you have become an official contributor to dolphinscheduler!