cwielenb/CNCF-Dataset huggingface dataset:
Project: Karmada (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: Open Cluster Management (Orchestration & Management / Scheduling & Orchestration)
File: CHANGELOG-v0.7.md

Upgrade Placement and PlacementDecision to v1beta1. ( ) Add SelectorType in ClusterSet. ( ) Add integration test. ( ) Add apiservice target ports ( ) Fix wrong deploy option for klusterlet. ( ) Fix webhook configuration to pointer. ( ) Fix defaulter for clusterset, clustermanager and klusterlet. ( ) Deprecate placement and placementdecision v1alpha1 ( ) Add hosted mode and deprecate detacded mode ( )
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: README.en.md

Four ways of data transmission when gRPC is used in Python. #### unary-unary In a single call, the client can only send request once, and the server can only respond once. `client.py: simple_method` `server.py: SimpleMethod` #### stream-unary In a single call, the client can transfer data to the server an arbitrary number of times, but the server can only return a response once. `client.py: clientstreamingmethod` `server.py: ClientStreamingMethod` #### unary-stream In a single call, the client can only transmit data to the server at one time, but the server can return the response many times. `client.py: serverstreamingmethod` `server.py: ServerStreamingMethod` #### stream-stream In a single call, both client and server can send and receive data to each other multiple times. `client.py: bidirectionalstreamingmethod` `server.py: BidirectionalStreamingMethod`
Project: BFE (Orchestration & Management / Service Proxy)
File: mod_prison.md

mod_prison limits the amount of requests a user can make in a given period of time based on defined rules. conf/modprison/modprison.conf | Config Item | Description | | -- | | | Basic.ProductRulePath | String<br>path of rule configuration | ```ini [Basic] ProductRulePath = mod_prison/prison.data ``` conf/mod_prison/prison.data | Config Item | Description | | -- | | | Version | String<br>Version of config file | | Config | Object<br>Prison rules for each product | | Config{k} | String<br>Product name | | Config{v} | Array<br>A ordered list of prison rules | | Config{v}[] | Object<br>A prison rule | | Config{v} | | Config{v}[].AccessSignConf | Object<br>Conf of access sign which is the basis for judgment of same access | | Config{v}[].AccessSignConf.UseSocketIP | Boolean<br>Whether using socket ip to generate access sign | | Config{v}[].AccessSignConf.UseClientIP | Boolean<br>Whether using client ip to generate access sign | | Config{v}[].AccessSignConf.UseConnectID | Boolean<br>Whether using connect id to generate access sign | | Config{v}[].AccessSignConf.UseUrl | Boolean<br>Whether using url to generate access sign | | Config{v}[].AccessSignConf.UseHost | Boolean<br>Whether using host to generate access sign | | Config{v}[].AccessSignConf.UsePath | Boolean<br>Whether using path to generate access sign | | Config{v}[].AccessSignConf.UseHeaders | Boolean<br>Whether using headers to generate access sign | | Config{v}[].AccessSignConf.UrlRegexp | String<br>Substrings in url matching UrlRegexp which are used for generating access sign | | Config{v}[].AccessSignConf.[]Qeury | Array<br>Qeury keys used for generating access sign | | Config{v}[].AccessSignConf.[]Header | Array<br>Header keys used for generating access sign | | Config{v}[].AccessSignConf.[]Cookie | Array<br>Cookie keys used for generating access sign | | Config{v}[].Action | Object<br>Prison action if visits exceed the limit | | Config{v}[].Action.Cmd | String<br>Name of prison action | | Config{v}[].Action.Params | Array<br>Parameters of prison action | | Config{v}[].CheckPeriod | Integer<br>Period of check time (second) | | Config{v}[].StayPeriod | Integer<br>Period of prison time if visits exceed the limit (second) | | Config{v}[].Threshold | Integer<br>Take action if exceeding threshold during specified CheckPeriod | | Config{v}[].AccessDictSize | Integer<br>Size of LRU cache for access records | | Config{v}[].PrisonDictSize | Integer<br>Size of LRU cache for prison records | | Action | Description | | -- | -- | | CLOSE | Close the connection | | FINISH | Return 403 response and close the connection | | PASS | Just forward request | | REQHEADERSET | Set request header | ```json { "Version": "20190101000000", "Config": { "example_product": [{ "Name": "example_prison", "Cond": "reqpathprefix_in(\"/prison\", false)", "accessSignConf": { "url": false, "path": false, "query": [], "header": [], "Cookie": [ "UID" ] }, "action": { "cmd": "CLOSE", "params": [] }, "checkPeriod": 10, "stayPeriod": 10, "threshold": 5, "accessDictSize": 1000, "prisonDictSize": 1000 }] } } ```
Project: Easegress (Orchestration & Management / API Gateway)
File: 6.3.egbuilder.md

`egbuilder` is a command-line tool that enables you to create, build, and run Easegress with custom plugins. The `egbuilder init` command helps initialize a custom plugin project, creating the necessary directories and files for users to get started. ``` egbuilder init --repo github.com/your/repo \ --filters=MyFilter1,MyFilter2 \ --controllers=MyController1,MyController2 ``` The example above will create following directories and files. ``` . .egbuilderrc controllers mycontroller1 mycontroller1.go mycontroller2 mycontroller2.go filters myfilter1 myfilter1.go myfilter2 myfilter2.go go.mod go.sum registry registry.go ``` The `.egbuilderrc` file is a configuration file that can be used by the `egbuilder add` and `egbuilder run` commands. The `registry/registry.go` file contains code generated to register custom filters and controllers with Easegress. The `controllers` and `filters` directories contain the necessary variables, structures, and methods to get started. The `egbuilder add` command allows you to add more custom filters and controllers to an existing custom plugin project. ``` egbuilder add --filters=MyFilter3,MyFilter4 \ --controllers=MyController3,MyController4 ``` The above example will add following directories and files. ``` . controllers ... mycontroller3 mycontroller3.go mycontroller4 mycontroller4.go filters ... myfilter3 myfilter3.go myfilter4 myfilter4.go ... ``` The `.egbuilderrc` and `registry/registry.go` files will be updated based on changes. The `egbuilder build` command is used to compile Easegress with custom plugins. ``` egbuilder build -f build.yaml ``` where `build.yaml` contains: ```yaml egVersion: v2.5.2 plugins: module: github.com/your/repo version: "" replacement: "." module: github.com/other/repo output: "./easegress-server" raceDetector: false skipBuild: false skipCleanup: false buildFlags: [] modFlags: [] compile: os: "" arch: "" arm: "" cgo: false ``` The `egbuilder run` command is used to run Easegress with custom plugins in current working directory. ```bash egbuilder run # run with default egbuilder run -f run.yaml # run with config ``` where `run.yaml` contains: ```yaml egVersion: v2.5.2 egServerArgs: [] raceDetector: false skipBuild: false skipCleanup: false buildFlags: [] modFlags: [] compile: os: "" arch: "" arm: "" cgo: false ``` So, `egbuilder run` can be seen as executing `egbuilder build` first, followed by running `./easegress-server`. `EGBUILDER_GO` sets the go command to use when more then one version of go is installed.
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: roadmap.md

title: Apache Mesos - Roadmap layout: documentation The provides a view of which tickets are targeted for upcoming releases. The provide a view into the larger projects planned to be worked on. The captures the big ticket items for the project. There is also an ad-hoc document that attempts to capture times and features for upcoming releases. If you have comments or suggestions, feel free to reach out to the Mesos dev list (dev@mesos.apache.org).
Project: Contour (Orchestration & Management / Service Proxy)
File: how-we-work.md

title: How We Work layout: how-we-work This page captures how we work on Contour. When you pick up an issue, assign it to yourself. When you stop working, unassign yourself. While you hold an issue, you are responsible for giving status reports on it; over communicate, dont let others speak for you, or worse, guess. Don't work on an issue assigned to someone else. If you think they're over committed or stuck, please ask. Don't assign an issue to someone else without talking to them directly. Hoarding issues is not saving for a rainy day, you can only work on one thing at a time, you should avoid holding more than one issue at a time. Log an issue or it didnt happen. When submitting a PR add the appropriate release milestone and also add the appropriate Github "release-note" label if this PR warrants getting called out in the next release. Everyone is responsible for code reviews. If someone asks you for a review, or they use GitHub for the same, you should aim to review it (timezones permitting) promptly. Your aim is to give feedback, not land the as soon as you are asked to review it. The smaller the change, the better the PR process works. Everything flows from this statement. GitHub review tools suck for extended debate, if you find youre taking past your reviewer, its a sign that more design is needed. Before you fix a bug, write a test to show you fixed it. Before you add a feature, write a test so someone else doesnt break your feature by accident. You are permitted to refactor as much as you like to achieve these goals. As Kent beck said, Github issues should be triaged and have their status recorded. Triaging issues and labeling them appropriately makes it easy for the issue submitter and other contributors to see what the state of an issue is at any time. The goal of triaging an issue is to make a decision about what should be done with it. The issue should be investigated enough to fully understand and document the problem and then decide whether the issue should be addressed by the project. It may not be necessary to decide how an issue should be addressed during triage, since that could involve substantial research and design. To be considered triaged, an issue must have the "lifecycle/accepted" label. If you are in the process of investigating an issue, assign it to yourself and apply the "lifecycle/investigating" label. In almost all cases, triaged issues should have kind and area labels. The priority and size labels are informative. Contributors should apply them at their discretion.
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: wait-for-ready.md

gRPC Wait for Ready Semantics ============================= If an RPC is issued but the channel is in `TRANSIENT_FAILURE` or `SHUTDOWN` states, the RPC is unable to be transmitted promptly. By default, gRPC implementations SHOULD fail such RPCs immediately. This is known as "fail fast," but usage of the term is historical. RPCs SHOULD NOT fail as a result of the channel being in other states (`CONNECTING`, `READY`, or `IDLE`). gRPC implementations MAY provide a per-RPC option to not fail RPCs as a result of the channel being in `TRANSIENT_FAILURE` state. Instead, the implementation queues the RPCs until the channel is `READY`. This is known as "wait for ready." The RPCs SHOULD still fail before `READY` if there are unrelated reasons, such as the channel is `SHUTDOWN` or the RPC's deadline is reached.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: standalone.md

Standalone only for quick experience for DolphinScheduler. If you are a newbie and want to experience DolphinScheduler functions, we recommend you install follow . If you want to experience more complete functions and schedule massive tasks, we recommend you install follow . If you want to deploy DolphinScheduler in production, we recommend you follow or . _Note:_ Standalone only recommends the usage of fewer than 20 workflows, because it uses in-memory H2 Database in default, ZooKeeper Testing Server, too many tasks may cause instability. When Standalone stops or restarts, in-memory H2 database will clear up. To use Standalone with external databases like mysql or postgresql, please see . JDKdownload (1.8+), install and configure environment variable `JAVAHOME` and append `bin` dir (included in `JAVAHOME`) to `PATH` variable. You can skip this step if it already exists in your environment. Binary package: download the DolphinScheduler binary package at . <!-- markdown-link-check-disable-line --> There is a standalone startup script in the binary compressed package, which can be quickly started after extraction. Switch to a user with sudo permission and run the script: ```shell tar -xvzf apache-dolphinscheduler-*-bin.tar.gz chmod -R 755 apache-dolphinscheduler-*-bin cd apache-dolphinscheduler-*-bin bash ./bin/dolphinscheduler-daemon.sh start standalone-server ``` Access address `http://localhost:12345/dolphinscheduler/ui` and login DolphinScheduler UI. The default username and password are admin/dolphinscheduler123 The script `./bin/dolphinscheduler-daemon.sh`can be used not only quickly start standalone, but also to stop the service operation. The following are all the commands: ```shell bash ./bin/dolphinscheduler-daemon.sh start standalone-server bash ./bin/dolphinscheduler-daemon.sh stop standalone-server bash ./bin/dolphinscheduler-daemon.sh status standalone-server ``` Note: Python gateway service is started along with the api-server, and if you do not want to start Python gateway service please disabled it by changing the yaml config `python-gateway.enabled : false` in api-server's configuration path `api-server/conf/application.yaml` Standalone server use H2 database as its metadata store, it is easy and users do not need to start database before they set up server. But if user want to store metabase in other database like MySQL or PostgreSQL, they have to change some configuration. Follow the instructions in `Standalone Switching Metadata Database Configuration` section to create and initialize database
Project: Contour (Orchestration & Management / Service Proxy)
File: slow-start.md

Slow start mode is a configuration setting that is used to gradually increase the amount of traffic targeted to a newly added upstream endpoint. By default, the amount of traffic will increase linearly for the duration of time window set by `window` field, starting from 10% of the target load balancing weight and increasing to 100% gradually. The easing function for the traffic increase can be adjusted by setting optional field `aggression`. A value above 1.0 results in a more aggressive increase initially, slowing down when nearing the end of the time window. Value below 1.0 results in slow initial increase, picking up speed when nearing the end of the time window. Optional field `minWeightPercent` can be set to change the minimum percent of target weight. It is used to avoid too small new weight, which may cause endpoint to receive no traffic in beginning of the slow start window. Slow start mode can be useful for example with JVM based applications, that might otherwise get overwhelmed during JIT warm-up period. Such applications may respond to requests slowly or return errors immediately after pod start or after container restarts. User impact of this behavior can be mitigated by using slow start configuration to gradually increase traffic to recently started service endpoints. The following example configures slow start mode for a service: ```yaml apiVersion: projectcontour.io/v1 kind: HTTPProxy metadata: name: slow-start spec: virtualhost: fqdn: www.example.com routes: services: name: java-app port: 80 slowStartPolicy: window: 3s aggression: "1.0" minWeightPercent: 10 ``` Slow start mode works only with `RoundRobin` and `WeightedLeastRequest` . For more details see .
Project: MetalLB (Orchestration & Management / Service Proxy)
File: maintainers.md

title: Maintainers weight: 1 MetalLB was created by Dave Anderson. We are thankful for his efforts to create MetalLB as a valuable contribution to the Kubernetes ecosystem. Ongoing MetalLB development and maintenance is led by a team of current maintainers. MetalLB maintainers are participants in the project with the ability to approve changes to the MetalLB code base. The current list of maintainers can be found in the [MetalLB CODEOWNERS file](https://github.com/metallb/metallb/blob/main/CODEOWNERS). An active maintainer should: Actively participate in reviewing pull requests and incoming issues. Note that there are no hard rules on what is "active enough" and this is left up to the judgement of the current group of maintainers. Actively participate in discussions about design and the future of the project. Take responsibility for backports to appropriate branches for PRs they approve and merge. Do their best to follow all code, testing, and design conventions as determined by consensus among active maintainers. Gracefully step down from their maintainership role when they are no longer planning to actively participate in the project. New maintainers are added by consensus among the current group of maintainers. This can be done via a private discussion via Slack or email. A majority of maintainers should support the addition of the new person, and no single maintainer should object to adding the new maintainer. When adding a new maintainer, we should: Add to CODEOWNERS in MetalLB relevant repos (e.g. metallb and metallb-operator) and to the MetalLB github org itself. Open a PR to adding the maintainer there. You can use as an example of what needs to be done. Create an account for CNCF service desk (TODO: check how to do this and document it here!). Grant permissions on quay.io (TODO: check how to do this and document it here!) and bot accounts. The new maintainer should subscribe to: The CNCF maintainers mailing list. For this, send an email to cncf-MetalLB-maintainers+subscribe@lists.cncf.io and link the merged PR that added you to the metallb CODEOWNERS. and their membership role should be marked as owner by current maintainers. It is normal for maintainers to come and go based on their other responsibilities. Inactive maintainers may be removed if there is no expectation of ongoing participation. If a former maintainer resumes participation, they should be given quick consideration for re-adding to the team. If there becomes a conflict among maintainers that may lead to removal, active maintainers should first work to resolve the conflict. If absolutely necessary, a maintainer may be removed by a majority vote of existing maintainers. Please see all the places that a maintainer was added, to remove them. Consider rotating any shared password if needed.
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.9.2.md

+++ title = "CoreDNS-1.9.2 Release" description = "CoreDNS-1.9.2 Release Notes." tags = ["Release", "1.9.2", "Notes"] release = "1.9.2" date = "2022-05-13T00:00:00+00:00" author = "coredns" +++ This is a release with many added features and security and bug fixes. The most notable one is the release of 3rd party security audit from Trail of Bits. Security issues discovered by this audit have all been fixed or covered. Antoine Tollenaere, Balazs Nagy, Chris O'Haver, dilyevsky, hansedong, Lorenz Brun, Marius Kimmina, nathannaveen, Ondej Benkovsk, Patrick W. Healy, Qasim Sarfraz, xuweiwei, Yong Tang core: add Trail of Bits to list of 3rd party security auditors (https://github.com/coredns/coredns/pull/5356) core: avoid usage of pseudo-random number (https://github.com/coredns/coredns/pull/5228) plugin/bufsize: don't add OPT RR to non-EDNS0 queries (https://github.com/coredns/coredns/pull/5368) plugin/cache: add refresh mode setting to serve_stale (https://github.com/coredns/coredns/pull/5131) plugin/cache: fix cache poisoning exploit (https://github.com/coredns/coredns/pull/5174) plugin/etcd: fix multi record TXT lookups (https://github.com/coredns/coredns/pull/5293) plugin/forward: configurable domain support for healthcheck (https://github.com/coredns/coredns/pull/5281) plugin/geoip: read source IP from EDNS0 subnet if provided (https://github.com/coredns/coredns/pull/5183) plugin/health: rework overloaded goroutine to support graceful shutdown (https://github.com/coredns/coredns/pull/5244) plugin/k8s_external: persist tc bit from lookup to client response (https://github.com/coredns/coredns/pull/4716) plugin/k8s_external: set authoritative bit in responses (https://github.com/coredns/coredns/pull/5284) plugin/kubernetes: fix k8s start up timeout ticker (https://github.com/coredns/coredns/pull/5361) plugin/route53: deprecate plaintext secret in Corefile for route53 plugin (https://github.com/coredns/coredns/pull/5228) plugin/route53: expand AWS config/credentials setup. (https://github.com/coredns/coredns/pull/5370) plugin/template: fix rcode option documentation (https://github.com/coredns/coredns/pull/5328)
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: seamless_migration_test.md

| Test Case | E2E Describe Text | Comments | |--||| | Verify migrate Deployment | Test migrate namespaced resource: Deployment | | | Verify migrate ClusterRole | Test migrate cluster resources: ClusterRole | | | Verify migrate Service (NodePort) | Test migrate namespaced resource: Service (NodePort) | |