cwielenb/CNCF-Dataset huggingface dataset:
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: README.md

whoami - returns your resolver's local IP address, port and transport. The whoami plugin is not really that useful, but can be used for having a simple (fast) endpoint to test clients against. When whoami returns a response it will have your client's IP address in the additional section as either an A or AAAA record. The reply always has an empty answer section. The port and transport are included in the additional section as a SRV record, transport can be "tcp" or "udp". ~~~ txt ._<transport>.qname. 0 IN SRV 0 0 <port> . ~~~ The whoami plugin will respond to every A or AAAA query, regardless of the query name. If CoreDNS can't find a Corefile on startup this is the default plugin that gets loaded. As such it can be used to check that CoreDNS is responding to queries. Other than that this plugin is of limited use in production. ~~~ txt whoami ~~~ Start a server on the default port and load the whoami plugin. ~~~ corefile example.org { whoami } ~~~ When queried for "example.org A", CoreDNS will respond with: ~~~ txt ;; QUESTION SECTION: ;example.org. IN A ;; ADDITIONAL SECTION: example.org. 0 IN A 10.240.0.1 _udp.example.org. 0 IN SRV 0 0 40212 ~~~ on how this plugin is built, or .
Project: BFE (Orchestration & Management / Service Proxy)
File: block.md

Suppose our service has been attacked from a specific IP, or a specific API (such as issuing a voucher) has been maliciously called; we want to block specified traffic, such as: block attack traffic comes from some fixed IP2.2.2.2 block attack traffic targeted at some specific PATH/bonus Modify example configurations (conf/) as the following steps: Step 1. Modify conf/bfe.conf and enable mod_block ```ini Modules = modblock #enable modblock ``` Step 2. Modify conf/modblock/modblock.conf and configure path of global ip blocklist and block rules ```ini [basic] ProductRulePath = modblock/blockrules.data IPBlocklistPath = modblock/ipblocklist.data ``` Step 3. Configure global blocklist (conf/modblock/ipblocklist.data) Config ip address list, such as 2.2.2.2 ```ini 2.2.2.2 ``` Step 4. Configure block rules (conf/modblock/blockrules.data) ```json { "Version": "init version", "Config": { "example_product": [{ "action": { "cmd": "CLOSE", "params": [] }, "name": "block bonus", "cond": "reqpathin(\"/bonus\", false)" }] } } ``` Step 5. Verify configured rules ```bash curl -v -H "host: example.org" "http://127.1:8080/bonus" ``` The connection will be closed by bfe immediately.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: e2e-guide.md

The main purpose of E2E test is to verify the integration and data integrity of the system, and its components, by simulating real user scenarios. This makes it possible to extend the scope of testing and ensure the health and stability of the system. To a certain extent, the test workload and costs are reduced. In simple terms, E2E testing is about treating a program as a black box and simulating the access behaviour of a real system from the user's point of view to see if the input to the test (user behaviour/simulated data) gives the expected results. Therefore, the community decided to add E2E automated testing to DolphinScheduler. The current community E2E test has not yet reached full coverage, so this document has been written with the aim of guiding more partners to get involved. The E2E test pages are currently divided into four pages: Project Management, Resource Center, DataSource, and Security Center. Contributors can find the task by going to GitHub, searching for , and then searching for `e2e test cases` in the . As shown below. In each issue, we list the content to be tested and the expected results, which can be seen in the Description. Once you are on the current page, you can select the issue you are interested in, for example, to participate in the Security Center test, just leave a comment under the corresponding issue about the case you want to test. Task status: If the test has been completed, it is considered finished and as a contributor you need to find the outstanding tests. number: Test case serial number. function module: Functional modules to be tested, a functional module containing multiple test cases. test point: Specific examples of what needs to be tested. For example button click actions on pages, page jump functions. priority: The priority of the test case, which is recommended to find a high priority. service: The service that needs to be started during the test process. test steps: The test steps to be performed for each test case. expected results: The expected test results. actual results: The actual results. remarks: The precautions needed during the test process. After taking up the corresponding task, the next step is to get to the crux of writing the code. Many partners may not be familiar with E2E test codes, so you can refer to this page: . Participation in the open source community can take many forms, including issue, pull request and translation. To participate in the E2E testing process, contributors are first required to understand the simple process of submitting a pull request, see: .
Project: Traefik (Orchestration & Management / API Gateway)
File: maintainers.md

title: "Traefik Maintainers Documentation" description: "Traefik Proxy is an open source software with a thriving community of contributors and maintainers. Read the list of maintainers on this page." Emile Vauge Manuel Zapf Ludovic Fernandez Julien Salleyron Nicolas Mengin Michal Matur Grald Cros Jean-Baptiste Doumenjou Mathieu Lonjaret Romain Tribott Kevin Pollet Harold Ozouf Tom Moulard Landry Benguigui Simon Delicata Baptiste Mayelle People who have had an incredibly positive impact on the project, and are now focusing on other projects. Vincent Demeester Ed Robinson Daniel Tomcej Timo Reimann Marco Jantke Please read the .
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.6.3.md

+++ title = "CoreDNS-1.6.3 Release" description = "CoreDNS-1.6.3 Release Notes." tags = ["Release", "1.6.3", "Notes"] release = "1.6.3" date = 2019-08-31T07:30:47+00:00 author = "coredns" +++ The CoreDNS team has released . In this release we have moved the federation plugin to , but it is still fully functional in this version. In version 1.7.0 we expect to deprecate it. Further more a slew a spelling corrections, and other minor improvements and polish. And two new plugins: clouddns and sign. to enable serving zone data from GCP Cloud DNS. that (DNSSEC) signs your zonefiles (in its most basic form). various update, plug a memory leak when doing zone transfers, among other things. We've removed the time stamping from `pkg/log` as timestamps are also added by the logging aggregators, like `journald` or inside Kubernetes. And a small ASCII art logo is now printed when CoreDNS starts up. AllenZMC, Chris Aniszczyk, Chris O'Haver, Cricket Liu, Guangming Wang, Julien Garcia Gonzalez, li mengyang, Miek Gieben, Muhammad Falak R Wani, Palash Nigam, Sakura, wwgfhf, xieyanker, Xigang Wang, Yevgeny Pats, Yong Tang, zhangguoyan, . fuzzing: Add Continuous Fuzzing Integration to Fuzzit (https://github.com/coredns/coredns/pull/3093) pkg/log: remove timestamp (https://github.com/coredns/coredns/pull/3218) plugin/clouddns: Add Google Cloud DNS plugin (https://github.com/coredns/coredns/pull/3011) plugin/federation: Move federation plugin to github.com/coredns/federation (https://github.com/coredns/coredns/pull/3139) plugin/file: close reader for reload (https://github.com/coredns/coredns/pull/3196) plugin/file: less notify logging spam (https://github.com/coredns/coredns/pull/3212) plugin/file: respond correctly to IXFR message (https://github.com/coredns/coredns/pull/3177) plugin/file: rework outgoing axfr (https://github.com/coredns/coredns/pull/3227) plugin/{health,ready}: return standardized text for ready and health endpoint (https://github.com/coredns/coredns/pull/3195) plugin/k8s_external handle NS records (https://github.com/coredns/coredns/pull/3160) plugin/kubernetes: handle NS records (https://github.com/coredns/coredns/pull/3160) startup: add logo (https://github.com/coredns/coredns/pull/3230)
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.9.0.md

+++ title = "CoreDNS-1.9.0 Release" description = "CoreDNS-1.9.0 Release Notes." tags = ["Release", "1.9.0", "Notes"] release = "1.9.0" date = "2022-02-01T00:00:00+00:00" author = "coredns" +++ This is a release with bug fixes and some new features added. Starting with 1.9.0 the minimal required go version will be 1.17. Wildcard queries are no longer supported by the kubernetes plugin. Chris O'Haver, Ondej Benkovsk, Tomas Hulata, Yong Tang, xuweiwei plugin/kubernetes: remove wildcard query functionality (https://github.com/coredns/coredns/pull/5019) Health-checks should respect force_tcp (https://github.com/coredns/coredns/pull/5109) plugin/prometheus: Write rcode properly to the metrics (https://github.com/coredns/coredns/pull/5126) plugin/template: Persist truncated state to client if CNAME lookup response is truncated (https://github.com/coredns/coredns/pull/4713)
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.10.1.md

+++ title = "CoreDNS-1.10.1 Release" description = "CoreDNS-1.10.1 Release Notes." tags = ["Release", "1.10.1", "Notes"] release = "1.10.0" date = "2023-01-20T00:00:00+00:00" author = "coredns" +++ This release fixes some bugs, and adds some new features including: Corrected architecture labels in multi-arch image manifest A new plugin timeouts* that allows configuration of server listener timeout durations acl* can drop queries as an action template* supports creating responses with extended DNS errors New weighted policy in loadbalance* Option to serve original record TTLs from cache* Arthur Outhenin-Chalandre, Ben Kaplan, Chris O'Haver, Gabor Dozsa, Grant Spence, Kumiko as a Service, LAMRobinson, Miciah Dashiel Butler Masters, Ondej Benkovsk, Rich, Stephen Kitt, Yash Singh, Yong Tang, rsclarke, sanyo0714 plugin/timeouts - Allow ability to configure listening server timeouts (https://github.com/coredns/coredns/pull/5784) plugin/acl: adding ability to drop queries (https://github.com/coredns/coredns/pull/5722) plugin/template : add support for extended DNS errors (https://github.com/coredns/coredns/pull/5659) plugin/kubernetes: error NXDOMAIN for TXT lookups (https://github.com/coredns/coredns/pull/5737) plugin/kubernetes: dont match external services when endpoint is specified (https://github.com/coredns/coredns/pull/5734) plugin/k8s_external: Fix rcode for headless services (https://github.com/coredns/coredns/pull/5657) plugin/edns: remove truncating of question section on bad EDNS version (https://github.com/coredns/coredns/pull/5787) plugin/dnstap: Fix behavior when multiple dnstap plugins specified (https://github.com/coredns/coredns/pull/5773) plugin/cache: cache now uses source query DNSSEC option for upstream refresh (https://github.com/coredns/coredns/pull/5671) Workaround for incorrect architecture (https://github.com/coredns/coredns/pull/5691) plugin/loadbalance: Add weighted policy (https://github.com/coredns/coredns/pull/5662) plugin/cache: Add keepttl option (https://github.com/coredns/coredns/pull/5879) plugin/forward: Fix dnstap for forwarded request/response (https://github.com/coredns/coredns/pull/5890)
Project: Tyk (Orchestration & Management / API Gateway)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: enhancement assignees: Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: sla-plugin.md

When users apply jobs to volcano, they may need adding some particular constraints to job, for example, longest Pending time aiming to prevent job from starving. And these constraints can be regarded as Service Level Agreement (SLA) which are agreed between volcano and user. So sla plugin is provided to receive and realize SLA settings for both individual job and whole cluster. In sla plugin, arguments `sla-waiting-time` is provided to realize job resource reservation: `sla-waiting-time` is maximum time one job should stay `Pending` or `inqueue` status and not be allocated. When `sla-waiting-time` is over, `sla` plugin sets the job to be `inqueue` in `enqueue` action immediately. Then `sla` plugin locks idle resources pre-allocated to pods of this job in `allocate` action, even if the job has not been `Ready` yet. In this way, `sla` plugin realizes large job election and resource reservation, thus replaces `elect` & `reserve` action in v1.1.0. Arguments `sla-waiting-time` can be set for one job, and for all jobs in cluster. For one job, user can set them in job annotations in following format: ```yaml apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: annotations: sla-waiting-time: 1h2m3s ``` For all jobs, user can set `sla-waiting-time` field in `sla` plugin arguments via `volcano-scheduler-configmap` in following format: ```yaml actions: "enqueue, allocate, backfill" tiers: plugins: name: priority name: gang name: sla arguments: sla-waiting-time: 1h2m3s ``` `sla` plugin return 3 callback functions: `JobEnqueueableFn`, `JobPipelinedFn`, and `JobOrderFn`: `JobEnqueueableFn` returns `Permit` when job waiting time in `Pending` status is longer than `sla-waiting-time`, and job will go through `enqueue` action and be `inqueue` instantly, regardless of other plugins returning `Reject` or `Abstain` to reject this job from being `inqueue`. `JobPipelinedFn` returns `Permit` when job waiting time in `inqueue` status is longer than `sla-waiting-time`, and job will be `Pipelined` status instantly, regardless of other plugins returning `Reject` or `Abstain` to reject this job from being `Pipelined`. In this way `allocate` action reserves resources for pods of the job even if the job is not Ready yet. `JobOrderFn` adjusts the order of this job in waiting queues of `enqueue` & `allocate` action. The more close to `sla-waiting-time` that job waiting time is, the higher scored of this job in `JobOrderFn` of `sla` plugin, so that job would have larger probability to be front int priority queue, which means that it can touch more idle resources and have higher priority to be `inqueue` and allocated. the execution flow chart of `sla` plugin is shown as below: By now we only need 1 argument `sla-waiting-time`, so I add it into annotations for simplicity and invocation, but when `sla` plugin is extended with more arguments, a better way to invoke this plugin may be job plugin like `svc` and `ssh`.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: contribute.md

First of all, thank you very much for choosing and using DolphinScheduler, and welcome to join the DolphinScheduler family! We encourage any form of participation in the community that will eventually become Committer or PPMC Such as: Problems will be encountered via github on the form feedback out. Answer the issue questions that others are asking. Help improve the documentation. Help your project add test cases. Add comments to the code. Submit a PR that fixes the bug or Feature. Publish application case practice, scheduling process analysis, or technical articles related to scheduling. Help promote DolphinScheduler, participate in technical conferences or meetup, sharing and more. Welcome to the contributing team and join open source starting with submitting your first PR. For example, add code comments or find "easy to fix" tags or some very simple issue (misspellings, etc.) and so on, first familiarize yourself with the submission process through the first simple PR. Note: Contributions are not limited to PR Only, but contribute to the development of the project. I'm sure you'll benefit from open source by participating in DolphinScheduler! Refer to the Refer to the , , If you want to implement a Feature or fix a Bug. Please refer to the following: All bugs and the features are recommended and managed using the GitHub issues(https://github.com/apache/dolphinscheduler/issues). If you want to develop a Feature, first reply to the Issue associated with that feature, indicating that you are currently working on it. And set yourself a "deadline" when to Submit the Feature, and add it in the reply comment. It's a good idea to find a mentor (or an instructor) in the core contributors who gives immediate feedback on design and functional implementation. You should create a new branch to start your work, to get the name of the branch refer to the . For example, if you want to complete the feature and submit Issue 111, your branch name should be feature-111. The feature name can be determined after discussion with the instructor. When you're done, send a Pull Request to dolphinscheduler, please refer to the If you want to submit a Pull Request to complete a Feature or fix a Bug, it is recommended that you start with the `good first issue`, `easy-to-fix` issues, complete a small function to submit, do not change too many files at a time, changing too many files will also put a lot of pressure on Reviewers, it is recommended to submit them through multiple Pull Requests, not all at once.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: priority.md

DolphinScheduler has three parameter types: : parameters defined at the project management page. : parameters defined at the workflow define page. : parameters defined at the workflow launch page. : parameters passed by upstream task nodes. : parameters belong to its node, which is the parameters defined by the user in [Custom Parameters]. The user can define part of the parameters when creating workflow definitions. As there are multiple sources of the parameter value, it will raise parameter priority issues when the parameter name is the same. The priority of DolphinScheduler parameters from high to low is: `Startup Parameter > Local Parameter > Parameter Context > Global Parameter > Project-level Parameter`. In the case of upstream tasks can pass parameters to the downstream, there may be multiple tasks upstream that pass the same parameter name: Downstream nodes prefer to use parameters with non-empty values If there are multiple parameters with non-empty values, select the value from the upstream task with the earliest completion time The following are examples showing task parameters priority problems: 1: Use shell nodes to explain the first case. The [useParam] node can use the parameters which are set in the [createParam] node. The [useParam] node cannot obtain the parameters from the [noUseParam] node due to there is no dependency between them. Other task node types have the same usage rules with the Shell example here. The [createParam] node can use parameters directly. In addition, the node creates two parameters named "key" and "key1", and "key1" has the same name as the one passed by the upstream node and assign value "12". However, due to the priority rules, the value assignment will assign "12" and the value from the upstream node is discarded. 2: Use SQL nodes to explain another case. The following shows the definition of the [use_create] node: "status" is own parameter of the node set by the current node. However, the user also sets the "status" parameter (global parameter) when saving the process definition and assign its value to -1. Then the value of status will be 2, with higher priority when the SQL executes. The global parameter value is discarded. The "ID" here is the parameter set by the upstream node. The user sets the parameters of the same parameter name "ID" for the [createparam1] node and [createparam2] node. And the [use_create] node uses the value of [createParam1] which is finished first.
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_create_secret_encryptionkey.md

title: "glooctl create secret encryptionkey" weight: 5 Create an encryption key secret with the given name Create an encryption key secret with the given name. The format of the secret data is: <key>The encryption key will be stored is the secret data under the key `key`. ``` glooctl create secret encryptionkey [flags] ``` ``` -h, --help help for encryptionkey --key string key for encryption ``` ``` -c, --config string set the path to the glooctl config file (default "<home_directory>/.gloo/glooctl-config.yaml") --consul-address string address of the Consul server. Use with --use-consul (default "127.0.0.1:8500") --consul-allow-stale-reads Allows reading using Consul's stale consistency mode. --consul-datacenter string Datacenter to use. If not provided, the default agent datacenter is used. Use with --use-consul --consul-root-key string key prefix for for Consul key-value storage. (default "gloo") --consul-scheme string URI scheme for the Consul server. Use with --use-consul (default "http") --consul-token string Token is used to provide a per-request ACL token which overrides the agent's default token. Use with --use-consul --dry-run print kubernetes-formatted yaml rather than creating or updating a resource -i, --interactive use interactive mode --kube-context string kube context to use when interacting with kubernetes --kubeconfig string kubeconfig to use, if not standard one --name string name of the resource to read or write -n, --namespace string namespace for reading or writing resources (default "gloo-system") -o, --output OutputType output format: (yaml, json, table, kube-yaml, wide) (default table) --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) --use-vault use Vault Key-Value storage as the backend for reading and writing secrets --vault-address string address of the Vault server. This should be a complete URL such as "http://vault.example.com". Use with --use-vault (default "https://127.0.0.1:8200") --vault-ca-cert string CACert is the path to a PEM-encoded CA cert file to use to verify the Vault server SSL certificate.Use with --use-vault --vault-ca-path string CAPath is the path to a directory of PEM-encoded CA cert files to verify the Vault server SSL certificate.Use with --use-vault --vault-client-cert string ClientCert is the path to the certificate for Vault communication.Use with --use-vault --vault-client-key string ClientKey is the path to the private key for Vault communication.Use with --use-vault --vault-path-prefix string The Secrets Engine to which Vault should route traffic. (default "secret") --vault-root-key string key prefix for Vault key-value storage inside a storage engine. (default "gloo") --vault-tls-insecure Insecure enables or disables SSL verification.Use with --use-vault --vault-tls-server-name string TLSServerName, if set, is used to set the SNI host when connecting via TLS.Use with --use-vault --vault-token string The root token to authenticate with a Vault server. Use with --use-vault ``` - Create a secret
Project: Knative (Orchestration & Management / Scheduling & Orchestration)
File: pull-request-template.md

Fixes # <!-- Please include the 'why' behind your changes if no issue exists --> Release Note <!-- Enter your extended release note in the below block. If the PR requires additional action from users switching to the new release, include the string "action required". If no release note is required, write "NONE". --> ```release-note ```