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

| Datasource | Description | |-|--| | Datasource | Select Oracle. | | Datasource Name | Enter the name of the datasource. | | Description | Enter a description of the datasource. | | IP/Host Name | Enter the Oracle service IP. | | Port | Enter the Oracle service port. | | Username | Set the username for Oracle connection. | | Password | Set the password for Oracle connection. | | Database Name | Enter the ServiceName or SID of the Oracle connection. | | ServiceName or SID | Choose ServiceName or SID according to your entry in Database Name column. | | jdbc connect parameters | Parameter settings for Oracle connection, in JSON format. For example, you can use {"schema": "abc"} to specify database abc for using. | Yes, could use this datasource by default.
Project: OpenFunction (Orchestration & Management / Scheduling & Orchestration)
File: quickstart.md

This document walks you through how to get started with building OpenFunction in your local environment. If you are interested in developing controller-manager, see and . OpenFunction is based on . Both of them are written in . If you don't have a Go development environment, please first. | Kubernetes | requires Go | | - | -- | | 1.18+ | go>=1.12 | Tips: Ensure your GOPATH and PATH have been configured in accordance with the Go environment instructions. It's recommended to install when using MacOS for development. OpenFunction components are often deployed as containers in Kubernetes. If you need to rebuild the OpenFunction components in the Kubernetes cluster, you'll need to in advance. OpenFunction uses to manage dependencies. You can build ```openfunction``` image for your local environment by modifying ``cmd/Dockerfile``. After uploading the image to your personal image repository, change the image url corresponding to the ```openfunction``` container in the workload (Deployment) openfunction-controller-manager and switch it to your personal image repository. ```shell kubectl edit deployments.apps -n openfunction openfunction-controller-manager ``` Kubernetes will then automatically apply your controllers.
Project: Knative (Orchestration & Management / Scheduling & Orchestration)
File: roadmap-2018.md

The purpose of the API Core group is to implement the control plane API for the Knative Serving project. This includes the API governance process as well as implementation and supporting documentation. This roadmap is what we hope to accomplish in 2018. In 2018, we will largely focus on curating and implementing the Knative Serving resource specification. Process. It must be clear to contributors how to drive changes to the Knative Serving API. Schema. matches . Semantics. The of Knative Serving API interactions match , and are well covered by . <!-- TODO(mattmoor): Should this cover Infrastructure as well? --> Define the process by which changes to the API are proposed, approved, and implemented. Define our conventions to which API changes should adhere for consistency with the Knative Serving API. Complete our implementation of the initial API specification. Track changes to our API specification (according to our process) over time, including the versioning of API resources. Triage drift of our implementation from the API specification. <!-- TODO(mattmoor): Should this include something about webhook validation? --> Implement our desired semantics as outlined in our . Fail gracefully and clearly as outlined in our docs. <!-- TODO(mattmoor): https://github.com/knative/serving/issues/459 --> Ensure continued conformance of our implementation with the API specification over time by ensuring semantics are well covered by our conformance testing. <!-- TODO(mattmoor): https://github.com/knative/serving/issues/234 --> <!-- TODO(mattmoor): https://github.com/knative/serving/issues/492 --> Operator Extensions. Guidelines for how operators can/should customize an Knative Serving installation (e.g. runtime contract) are captured in documentation. <!-- ## What We Are Not Doing -->
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: postgresql.md

| Datasource | Description | |-|| | Datasource | Select POSTGRESQL. | | Datasource name | Enter the name of the DataSource. | | Description | Enter a description of the DataSource. | | IP/Host Name | Enter the PostgreSQL service IP. | | Port | Enter the PostgreSQL service port. | | Username | Set the username for PostgreSQL connection. | | Password | Set the password for PostgreSQL connection. | | Database name | Enter the database name of the PostgreSQL connection. | | Jdbc connection parameters | Parameter settings for PostgreSQL connection, in JSON format. | Yes, could use this datasource by default.
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: reclaim-design.md

Reclaim runs in each session and the workflow of the session is explained below with the help of diagram. In every session, local copies of objects(queues, queueMap, preemptorsMap, preemptorTasks) are created. Range over all Jobs If Job's Queue is not found, move on to next job If found, add queue to queueMap and queues local object. Check for Job's Pending tasks, If no pending tasks, move on to next job If Job has pending tasks, update local objects. Check whether queues object is empty If queues object is not empty Pop out queue from queues object If queue is overused, move on to next queue from queues object If queue is not overused, check for for jobs which has pending tasks within that queue and select preemptor task Range over all nodes and run predicateFn for preemptor task If predicates are not satisfied, move on to next node If all the predicates are satisfied Range over all tasks running that node but from different queue other than preemptor task's queue and find all reclaimees tasks Send preemptor task and set of reclaimees task to ReclaimableFn which has been loaded by following plugins such as conformance, gang and proportion ReclaimableFn returns all possible victim tasks that can be evicted If number or victim tasks is zero or resource requirement of preemptor task is greater than total resource of all victim tasks, then move on to next node If resouce requirement of preemptor task is satisfied, then evict tasks from victim tasks one by one until preemptor task can be pipelined Run this until queues object is empty
Project: hami (Orchestration & Management / Scheduling & Orchestration)
File: tasklist.md

``` resources: requests: mthreads.com/gpu: ${num} mthreads.com/vcuda-core: ${core} mthreads.com/vcuda-memory: ${mem} limits: mthreads.com/gpu: ${num} mthreads.com/vcuda-core: ${core} mthreads.com/vcuda-memory: ${mem} ``` ``` resources: requests: birentech.com/gpu: ${num} birentech.com/vcuda-core: ${core} birentech.com/vcuda-memory: ${mem} limits: birentech.com/gpu: ${num} birentech.com/vcuda-core: ${core} birentech.com/vcuda-memory: ${mem} ``` ``` resources: requests: iluvatar.ai/gpu: ${num} iluvatar.ai/vcuda-core: ${core} iluvatar.ai/vcuda-memory: ${mem} limits: iluvatar.ai/gpu: ${num} iluvatar.ai/vcuda-core: ${core} iluvatar.ai/vcuda-memory: ${mem} ``` ``` resources: requests: ascend.com/npu: ${num} ascend.com/npu-core: ${core} ascend.com/npu-mem: ${mem} limits: ascend.com/npu: ${num} ascend.com/npu-core: ${core} ascend.com/npu-mem: ${mem} ``` Description: ResourceQuota is frequently used in kubernetes namespace. Since the number of virtual devices doesn't mean anything, we need to support the limitation in deviceMemory. For example, the following resourceQuota ``` cat <<EOF > compute-resources.yaml apiVersion: v1 kind: ResourceQuota metadata: name: compute-resources spec: hard: requests.cpu: "1" requests.memory: 1Gi limits.cpu: "2" limits.memory: 2Gi requests.nvidia.com/gpu-memory: 30000 EOF ``` with the following command ``` kubectl create -f ./compute-resources.yaml--namespace=myspace ``` will limit the maxinum device memory allocated to namespace 'myspace' to 30G Description: HAMi needs to support multiple schedule policies, to provide meets the need in complex senarios, a pod can select a schedule policy in annotations field. The effect of each schedule policy is shown in the table below | Schedule Policy | Effect | | -- | - | | best-fit | the fewer device memory remains, the higher score | | idle-first | idle GPU has higher score | | numa-first | for multiple GPU allocations, GPUs on the same numa have higher score | For example, if a pod want to select a 'best-fit' schedule policy, it can specify .metadata.annotations as the code below: ``` apiVersion: v1 kind: Pod metadata: name: gpu-pod annotations: nvidia.com/schedule-policy: "best-fit" spec: containers: name: ubuntu-container image: ubuntu:18.04 command:["bash""-c""sleep 86400"] resources: limits: nvidia.com/gpu: 2 # requesting 2 VGPUs ```
Project: Kubeflow (Orchestration & Management / Scheduling & Orchestration)
File: developer_guide.md

You can use skaffold to build the docker image for the controller by running Kaniko on your cluster and then deploy it. To use skaffold you will need to modify skaffold.yaml to work with a Kubernetes cluster you have access to Modify skaffold.yaml Set gcsBucket to a GCS Bucket you have access to and will use to make the build context available to the Kaniko pod For other setups refer to the for information on making the context available to your cluster builds. Set image* to a GCR image that you can push to Modify cluster.pullSecretName to be the name of a secret containing a GCP Service account that has permissions to push to the GCR repository where the image will be stored Change the value of GOOGLE_APPLICATION_CREDENTIALS* to point to the filename that is used by the pull secret for your GCP service account. Change namespace* to the namespace in which you want to run Kaniko Run the build ``` skaffold build -v info ```
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: getting-started.html.md

title: Apache Mesos | Getting Started breadcrumb: Getting Started layout: gettingstartedsection <h1>Getting Started</h1> <p>For a great introduction to building and running a distributed system with Apache Mesos, watch Benjamin Hindman's <a href="https://www.youtube.com/watch?v=hTcZGODnyf0">talk on YouTube</a>. If anything could be considered <i>required reading</i>, it would be the official white paper: <a href="https://people.eecs.berkeley.edu/~alig/papers/mesos.pdf">Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center</a>.</p> <div class="row-fluid"> <h2 name="binary-packages">How to use Binary Packages</h2> Find out how to download <a href="/documentation/latest/binary-packages">binary packages</a> and run Mesos on supported platforms. <h2 name="building">How To Build</h2> <p>See the <a href="/documentation/latest/building">building documentation</a> to learn how to build Mesos from source on various platforms.</p> <h2 name="contribute">Contribute</h2> <p>Read the <a href="/documentation/latest/beginner-contribution">beginner contribution guide</a> for a first-time introduction to the process of contributing to Mesos. For the standard day-to-day workflow for advanced Mesos contributors, read our <a href="/documentation/latest/advanced-contribution">advanced contribution guide</a>. The latter guide also includes information on our core libraries, <a href="https://github.com/apache/mesos/blob/master/3rdparty/stout/README.md">stout</a> and <a href="https://github.com/apache/mesos/blob/master/3rdparty/libprocess/README.md">libprocess</a>, with which new developers should get familiar.</p> <h2 name="community">Community</h2> <p>Refer to the <a href="/community">community page</a> for our mailing lists, Slack, IRC, and JIRA issue tracker.</p> </div>
Project: Gloo (Orchestration & Management / API Gateway)
File: resource.proto.sk.md

title: "resource.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> xDS resource wrapper. This encapsulates a xDS resource when appearing in an xDS transport discovery response or when accessed as a filesystem object. ```yaml "name": .xds.core.v3.ResourceName "version": string "resource": .google.protobuf.Any ``` | Field | Type | Description | | -- | - | -- | | `name` | | Resource name. This may be omitted for filesystem resources. | | `version` | `string` | The resource's logical version. It is illegal to have the same named xDS resource name at a given version with different resource payloads. | | `resource` | | The resource payload, including type URL. | <!-- 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: Tengine (Orchestration & Management / Service Proxy)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: '' assignees: '' <!-- Is your feature request related to a problem? Please describe in details --> <!--A clear and concise description of what you want to happen. For a computer fan, you can explain more about input of the feature, and output of it.--> <!-- Add any other context or screenshots about the feature request here.-->
Project: Kuma (Orchestration & Management / Service Mesh)
File: rate-limit.md

Today the only way to support Rate Limiting using Kuma create a ProxyTemplate. Current proposal introduces a new policy Rate Limit. Provide a way to configure local rate limit both for and . ```yaml type: RateLimit name: rt-1 mesh: default sources: match: kuma.io/service: web destinations: match: kuma.io/service: backend conf: tcp: connections: 100 # how many connections are allowed per 'period' period: 1s http: requests: 100 # how many requests are allowed per 'period' period: 1s status: 401 headers: key: x-local-rate-limit value: 'true' append: false ``` Configuration of the rate-limiter happens on the `source` side. Such kind of the rate-limiting allows user to limit the number of the outgoing requests. If you put 100 RPS between `web` and `backend` that does NOT mean `backend` will be limited by 100 request per second. It means every instance of `web` won't be making more than 100 request per second (i.e. if you have 10 instances of `web` then `backend` will be handling 1000 request per second). ```yaml type: RateLimit name: rt-1 mesh: default sources: match: kuma.io/service: web destinations: match: kuma.io/service: backend conf: tcp: connections: 100 # how many connections are allowed per 'period' period: 1s http: requests: 100 # how many requests are allowed per 'period' period: 1s status: 401 headers: key: x-local-rate-limit value: 'true' append: false ``` Same as , but rate-limiter is configured on the `destination` side. This allows user to protect `backend` from being DDoS'ed. If you put 100 RPS between `web` and `backend` in this case it's guaranteed that every instance of the `backend` service won't receive more than 100 requests per second. Downsides: should work only with mTLS for 2 reasons: In order to support `sources` selector for TCP we have to encode information about the service into SNI (we already do it for Zone Ingress) Security. If you set quotas 10 RPS for `web` and 1000 RPS for `offers` then `web` service should not be able to impersonate `offers` and bypass quotas. ```yaml type: RateLimit name: rt-1 mesh: default selectors: match: kuma.io/service: backend # apply on backend for any traffic conf: tcp: connections: 100 # how many connections are allowed per 'period' period: 1s ``` This design allows user to protect `backend` from being DDoS'ed, but doesn't have an option to select by `source` service. In other words, no way to configure quotas per `service` like in
Project: Contour (Orchestration & Management / Service Proxy)
File: contributing-docs.md

title: Contributing Technical Documentation layout: page The purpose of the Working Group is to build up a self-sustaining community around documentation for Contour. We have an initial need to rework the existing documentation based on the recommendations outlined in the , and a continuous need for documentation being added/edited/removed for releases going forward. This group is open to contributors of all levels, the only requirement is being interested in helping with docs! Whenever youre available to join, come say hi using either method: Join the every 1st and 3rd Thursday at 1-2pm ET / 10am-11pm PT and introduce yourself On the , join the channel and introduce yourself When you introduce yourself, let us know: Why you are interested in participating in the working group and what you hope to get out of your time contributing to the Contour docs Your prior experience level with our docs toolchain (Git and GitHub, Markdown, Hugo, HTML) and where you need some help Which operating system youre using (for help with setting up your environment) We can help you help find an open issue to work on or answer any questions you have about writing Contour docs. If you notice something about the docs you'd like to improve, please file an issue and bring it up with the working group. We'd love to hear your ideas. Make sure you have the following installed: A GitHub login A good editor Now you can start editing content: Start by the repo Within the `contour/site` directory, you will find the entire website Within the `contour/site/content` directory you will find our docs, our resources, guides and so forth The `docs` directory is divided into `main` which is the latest development docs, and `1.X.Z` where you will find the latest released versioned docs For new content for future versions, it should be created in `main` For edits to older versioned docs, first make the edits to that specific version (spelling errors, broken links etc) and then verify if those changes should also be incorporated in the `main` directory for the latest development docs Please see the in the section "Contribution workflow" for more detailed information on how to commit your changes and submit a pull request. When you join the working group and get assigned an issue, we'd ask that you try to open a pull requests with your fixes within a few days. If you are unable to finish your assigned issue, please submit a pull request with the content that you were able to create and update the Github issue with the latest information of your progress. This way your work goes to use, you get credit for your a contributions, and we can work with other team members to continue making progress on the issue :)
Project: Traefik (Orchestration & Management / API Gateway)
File: data-collection.md

title: "Traefik Data Collection Documentation" description: "To learn more about how Traefik is being used and improve it, we collect anonymous usage statistics from running instances. Read the technical documentation." Understanding How Traefik is Being Used {: .subtitle } Understanding how you use Traefik is very important to us: it helps us improve the solution in many different ways. For this very reason, the sendAnonymousUsage option is mandatory: we want you to take time to consider whether or not you wish to share anonymous data with us, so we can benefit from your experience and use cases. !!! example "Enabling Data Collection" ```yaml tab="File (YAML)" global: sendAnonymousUsage: true ``` ```toml tab="File (TOML)" [global] sendAnonymousUsage = true ``` ```bash tab="CLI" --global.sendAnonymousUsage ``` This feature comes from this . In order to help us learn more about how Traefik is being used and improve it, we collect anonymous usage statistics from running instances. Those data help us prioritize our developments and focus on what's important for our users (for example, which provider is popular, and which is not). Once a day (the first call begins 10 minutes after the start of Traefik), we collect: the Traefik version number a hash of the configuration an anonymized version of the static configuration (token, username, password, URL, IP, domain, email, etc., are removed). !!! info We do not collect the dynamic configuration information (routers & services). We do not collect this data to run advertising programs. We do not sell this data to third-parties. ```yaml tab="Original configuration" entryPoints: web: address: ":80" api: {} providers: docker: endpoint: "tcp://10.10.10.10:2375" exposedByDefault: true tls: ca: dockerCA cert: dockerCert key: dockerKey insecureSkipVerify: true ``` ```yaml tab="Resulting Obfuscated Configuration" entryPoints: web: address: ":80" api: {} providers: docker: endpoint: "xxxx" exposedByDefault: true tls: ca: xxxx cert: xxxx key: xxxx insecureSkipVerify: true ``` If you want to dig into more details, here is the source code of the collecting system: By default, we anonymize all configuration fields, except fields tagged with `export=true`.
Project: OpenFunction (Orchestration & Management / Scheduling & Orchestration)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: bug assignees: '' Description A clear and concise description of what the bug is. Environmental Tell us what your cluster environment is like, e.g. Operating System Information kubernetes version OpenFunction version Versions of dependent components (e.g. dapr, keda, shipwright, knative) Expected behavior Tell us what should happen. Actual behavior Tell us what happens instead. Provide a log message if relevant. To Reproduce Steps to reproduce the behavior: '..' '...' '....' See error Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here.
Project: Traefik (Orchestration & Management / API Gateway)
File: releases.md

Below is a non-exhaustive list of versions and their maintenance status: | Version | Release Date | Active Support | Security Support | ||--|--|| | 2.11 | Feb 12, 2024 | Yes | Yes | | 2.10 | Apr 24, 2023 | Ended Feb 12, 2024 | No | | 2.9 | Oct 03, 2022 | Ended Apr 24, 2023 | No | | 2.8 | Jun 29, 2022 | Ended Oct 03, 2022 | No | | 2.7 | May 24, 2022 | Ended Jun 29, 2022 | No | | 2.6 | Jan 24, 2022 | Ended May 24, 2022 | No | | 2.5 | Aug 17, 2021 | Ended Jan 24, 2022 | No | | 2.4 | Jan 19, 2021 | Ended Aug 17, 2021 | No | | 2.3 | Sep 23, 2020 | Ended Jan 19, 2021 | No | | 2.2 | Mar 25, 2020 | Ended Sep 23, 2020 | No | | 2.1 | Dec 11, 2019 | Ended Mar 25, 2020 | No | | 2.0 | Sep 16, 2019 | Ended Dec 11, 2019 | No | | 1.7 | Sep 24, 2018 | Ended Dec 31, 2021 | Contact Support | ??? example "Active Support / Security Support" Active support: receives any bug fixes. Security support: receives only critical bug and security fixes. This page is maintained and updated periodically to reflect our roadmap and any decisions affecting the end of support for Traefik Proxy. Please refer to our migration guides for specific instructions on upgrading between versions, an example is the . !!! important "All target dates for end of support or feature removal announcements may be subject to change." The Traefik Proxy project follows the scheme and maintains a separate branch for each minor version. The main branch always represents the next upcoming minor or major version. And these are our guiding rules for version support: Only the latest `minor` will be on active support at any given time The last `minor` after releasing a new `major` will be supported for 1 year following the `major` release Previous rules are subject to change and in such cases an announcement will be made publicly, is an example extending v1.x branch support.