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

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at info@stackstorm.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: ADOPTERS.md

uses CoreDNS in production, implementing a global DNS service allowing access to our ISP edge and regional locations. uses CoreDNS in its Active Trust Cloud SaaS service, as well as for Kubernetes cluster DNS. uses CoreDNS for Kubernetes cluster DNS. uses CoreDNS for Kubernetes cluster DNS. uses CoreDNS to handle geographic DNS requests for our public-facing microservices. uses CoreDNS for service discovery of its GPU machine learning cloud with TensorFlow and Kubernetes. uses CoreDNS in production at MIT for DNS. uses CoreDNS to look up company identifiers across multiple shards/regions/zones uses CoreDNS as internal cache+proxy in Kubernetes clusters to handle hundreds of thousands DNS service discovery requests per second. uses CoreDNS in production combination with Consul and Kubernetes Clusters. uses CoreDNS as Kubernetes' DNS Server, in production with tuned Kubernetes plugin options uses CoreDNS as Kubernetes' DNS Server, in production and lab with default configuration uses CoreDNS in multiple Kubernetes clusters, with Federation plugin. expect to go into production soon. uses CoreDNS with Kubernetes in production with default configuration. uses CoreDNS with Kubernetes in production on very large cluster (over 250 nodes) uses CoreDNS in Kubernetes using default configuration, in its Lab. Expect to be in production soon. uses CoreDNS as Kubernetes' DNS Server, in production. uses CoreDNS along with Kubernetes in production, with a tuned configuration. uses CoreDNS within Kubernetes in production, with standard configuration. uses CoreDNS with a tuned configuration for Kubernetes, as production. uses CoreDNS as Kubernetes' DNS Server, in production. uses CoreDNS with default configuration for Kubernetes in its production environment. uses CoreDNS on its numerous Kubernetes' clusters, using refined configurations. Address both Lab and Production environment uses CoreDNS with default configuration for Kubernetes for its Lab and its Production. uses CoreDNS in Lab and Production, using default configuration for Kubernetes. uses CoreDNS in and, therefore, in production public AdGuard DNS servers. uses CoreDNS within Kubernetes in production with the configuration tuned to use the Autopath plugin. uses CoreDNS within Kubernetes in production, with standard configuration. uses CoreDNS in Kubernetes using default configuration, in its Lab. Expected to be in production soon. uses CoreDNS in multiple Kubernetes clusters, with Forward plugin. uses CoreDNS in production across all its Kubernetes clusters. uses CoreDNS within Kubernetes in production, with standard configuration. uses CoreDNS as an integral part of Kubernetes Global Balancer project - . uses CoreDNS on all of our Kubernetes clusters across GCP, AWS, and bare-metal. uses CoreDNS on K8s in its highly-loaded internal infrastructure. uses CoreDNS on K8s in its plusserver Kubernetes Engine.
Project: Knative (Orchestration & Management / Scheduling & Orchestration)
File: COMMUNITY_CONTACTS.md

Every week we dedicate one individual (the community contact) to watch for user issues and either answer them or redirect the questions to other who can. The community contact's duty (subject to change) is as followed: Remove yourself from `@serving-help` usergroup and add the next contact using this . If you don't have permission, ask in the Slack channel `#steering-toc-questions`. Email the next contacts, cc'ing `knative-dev@` with a short summaries of the user questions encountered and links to them. Send updates to this process. See Check the for flakiness to pick a test and focus on fixing it during your week. Once you pick the test flake, assign the corresponding bug filed by flakiness test reporter to yourself so that others won't pick the same test to fix. Check the mailing list. Check Slack channel and for unanswered questions. Any questions that relates to usability please instruct user to and to join the channel to capture user feedback. . Quick links: - -- YOU NEED TO UPDATE THE DATE IN THE QUERY Check Docs for unanswered questions. Answer relevant Participation is voluntary and based on good faith. We are only expected to participate during our local office hour. We seed this rotation with all approvers from all the Serving workgroups, excluding productivity. If you are no longer active in Knative, or if you are contributing on personal capacity and do not have time to contribute in the rotation, feel free to send a PR to remove yourself. See . The format is: ``` RFC3339-date | username ``` You can see the current oncall at https://knative.party/ (which reads the machine-readable file).
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: cgroups-devices.md

title: Apache Mesos - Cgroups 'devices' Subsystem Support in Mesos Containerizer layout: documentation The `cgroups/devices` isolator allows operators to provide device isolation for containers launched by Mesos Containerizer. It uses the cgroups to track and enforce open and mknod restrictions on device files. To enable the `cgroups/devices` isolator, append `cgroups/devices` to the `--isolation` flag when starting the Mesos agent. The following devices are, by default, whitelisted for each container, if you turn on this isolator. Each whitelist entry has 4 fields. `type` is `a` (all), `c` (char), or `b` (block). 'all' means it applies to all types and all major and minor numbers. Major and minor are either an integer or `*` for all. Access is a composition of `r` (), `w` (), and `m` (). `c :* m`: Make new character devices using . `b :* m`: Make new block devices using . `c 5:1 rwm`: Read/write `/dev/console` `c 4:0 rwm`: Read/write `/dev/tty0` `c 4:1 rwm`: Read/write `/dev/tty1` `c 136: rwm`: Read/write `/dev/pts/*` `c 5:2 rwm`: Read/write `/dev/ptmx` `c 10:200 rwm`: Read/write `/dev/net/tun` `c 1:3 rwm`: Read/write `/dev/null` `c 1:5 rwm`: Read/write `/dev/zero` `c 1:7 rwm`: Read/write `/dev/full` `c 5:0 rwm`: Read/write `/dev/tty` `c 1:9 rwm`: Read/write `/dev/urandom` `c 1:8 rwm`: Read/write `/dev/random` Note that the cgroups device whitelist control is based on device numbers. This is orthogonal to populating `/dev`, which is typically done by udev or devtmpfs. Capability `CAP_MKNOD` is always required to perform irrespective of whether the device is whitelisted or not. The operator can configure the agent to add additional whitelisted devices using the `--allowed_devices` flag on the agent. The flag takes a JSON object (or the path to a file that contains the JSON object). For example: ```json { "allowed_devices": [ { "device": { "path": "/path/to/device" }, "access": { "read": true, "write": false, "mknod": false } } ] } ```
Project: hami (Orchestration & Management / Scheduling & Orchestration)
File: issue_template.md

The template below is mostly useful for bug reports and support questions. Feel free to remove anything which doesn't apply to you and add more information where it makes sense. Common error checking: [ ] The output of `nvidia-smi -a` on your host [ ] Your docker or containerd configuration file (e.g: `/etc/docker/daemon.json`) [ ] The vgpu-device-plugin container logs [ ] The vgpu-scheduler container logs [ ] The kubelet logs on the node (e.g: `sudo journalctl -r -u kubelet`) Additional information that might help better understand your environment and reproduce the bug: [ ] Docker version from `docker version` [ ] Docker command, image and tag used [ ] Kernel version from `uname -a` [ ] Any relevant kernel output lines from `dmesg`
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: feature_request_php.md

name: Request a gRPC PHP feature about: Suggest an idea for this project labels: kind/enhancement, priority/P2, lang/php assignees: stanley-cheung <!-- PLEASE DO NOT POST A QUESTION HERE. This form is for bug reports and feature requests ONLY! For general questions and troubleshooting, please ask/look for answers at StackOverflow, with "grpc" tag: https://stackoverflow.com/questions/tagged/grpc For questions that specifically need to be answered by gRPC team members, please ask/look for answers at grpc.io mailing list: https://groups.google.com/forum/#!forum/grpc-io Issues specific to grpc-java, grpc-go, grpc-node, grpc-dart, grpc-web should be created in the repository they belong to (e.g. https://github.com/grpc/grpc-LANGUAGE/issues/new) --> A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] A clear and concise description of what you want to happen. A clear and concise description of any alternative solutions or features you've considered. Add any other context about the feature request here.
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2015-12-16-mesos-0-26-0-released.md

layout: post title: Apache Mesos 0.26.0 Released permalink: /blog/mesos-0-26-0-released/ published: true post_author: display_name: Till Toenshoff twitter: ttoenshoff tags: Release The latest Mesos release, 0.26.0, is now available for . 103+ bugfixes and improvements made it into this release. For full release notes with all features and bug fixes, please refer to the . Rolling upgrades from a Mesos 0.25.0 cluster to Mesos 0.26.0 are straightforward. There are just some minor, backwards compatible deprecations. Please refer to the for detailed information on upgrading to Mesos 0.26. We encourage you to try out this release and let us know what you think. If you run into any issues, please let us know on the . Thanks to the 45 contributors who made 0.26.0 possible: Adam B, Alex Clemmer, Alexander Rojas, Alexander Rukletsov, Anand Mazumdar, Andrey Dyatlov, Artem Harutyunyan, Avinash sridharan, Benjamin Bannier, Benjamin Hindman, Benjamin Mahler, Bernd Mathiske, Bhuvan Arumugam, Chengwei Yang, Chi Zhang, Connor Doyle, Dave Lester, Elsmore, Felix Abecassis, Gastn Kleiman, Gilbert Song, Greg Mann, Guangya Liu, haosdent huang, Isabel Jimenez, James Peach, Jian Qiu, Jie Yu, Joerg Schad, Jojy Varghese, Jonathon Rossi, Joris Van Remoortere, Joseph Wu, Kapil Arya, Klaus Ma, Marco Massenzio, Michael Park, Neil Conway, Rossi, Spike Curtis, Till Toenshoff, Timothy Chen, Tomasz Janiszewski, Vinod Kone, Yong Qiao Wang
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.8.1.md

+++ title = "CoreDNS-1.8.1 Release" description = "CoreDNS-1.8.1 Release Notes." tags = ["Release", "1.8.1", "Notes"] release = "1.8.1" date = 2021-01-20T07:00:00+00:00 author = "coredns" +++ The CoreDNS team has released . This release fixes a bunch of bugs, and adds a (very) simple new plugin called to answer "local" queries. Bunch of work in the plugin to add support for new upstream features. If using the plugin for a Kubernetes cluster >= 1.19, CoreDNS must be granted `list` and `watch` access to `endpointslices`. Blake Ryan, Bob, Chotiwat Chawannakul, Chris O'Haver, Guangwen Feng, Gunadhya, Jiang Biao, Johnny Bergstrm, luanphantiki, Matt Kulka, mgugger, Miek Gieben, Serge, sschepens, Yong Tang, ZouYu. plugin/{clouddns,azure,route53}: Use cancelable contexts for cloud provider plugin refreshes (https://github.com/coredns/coredns/pull/4226) plugin/azure: Iterate over all RecordSetListResultPage Pages (https://github.com/coredns/coredns/pull/4351) core: custom DoH request validation (https://github.com/coredns/coredns/pull/4329) pkg/tls: remove InsecureSkipVerify=true flag (https://github.com/coredns/coredns/pull/4265) plugin/azure: return FQDN as MNAME in SOA record (https://github.com/coredns/coredns/pull/4286) plugin/cache Prevent race from prefetching (https://github.com/coredns/coredns/pull/4368) plugin/dnssec: Change hash key input (https://github.com/coredns/coredns/pull/4372) plugin/dnstap: remove config struct (https://github.com/coredns/coredns/pull/4258) plugin/dnstap: remove custom encoder (https://github.com/coredns/coredns/pull/4242) plugin/file: Use NXDOMAIN response if CNAME target is NXDOMAIN (https://github.com/coredns/coredns/pull/4303) plugin/file: document wrong behavior in lookup fox Apex (https://github.com/coredns/coredns/pull/4376) plugin/file: guard against cname loops (https://github.com/coredns/coredns/pull/4387) plugin/forward: respond with REFUSED when max_concurrent is exceeded (https://github.com/coredns/coredns/pull/4326) plugin/forward: HC every 0.5 seconds, do not do exponential backoff (https://github.com/coredns/coredns/pull/4371) plugin/health: Fix health check endpoint (https://github.com/coredns/coredns/pull/4231) plugin/kubernetes: Add support for dual stack ClusterIP Services (https://github.com/coredns/coredns/pull/4339) plugin/kubernetes: Fix dns programming duration metric (https://github.com/coredns/coredns/pull/4255) plugin/kubernetes: Fix NPE issue (https://github.com/coredns/coredns/pull/4338) plugin/kubernetes: Watch EndpointSlices (https://github.com/coredns/coredns/pull/4209) plugin/local: add local plugin (https://github.com/coredns/coredns/pull/4262) plugin/trace: Fix zipkin json_v2 (https://github.com/coredns/coredns/pull/4180) plugin/transfer: Fix go-routine leak (https://github.com/coredns/coredns/pull/4380)
Project: Crossplane (Orchestration & Management / Scheduling & Orchestration)
File: ROADMAP.md

The public roadmap for Crossplane is published as a GitHub project board. Issues added to the roadmap have been triaged and identified as valuable to the community, and therefore a priority for the project that we expect to invest in. Milestones assigned to any issues in the roadmap are intended to give a sense of overall priority and the expected order of delivery. They should be considered approximate estimations and are not a strict commitment to a specific delivery timeline. [Crossplane Roadmap]
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2017-08-11-mesos-1-2-2-released.md

layout: post title: Apache Mesos 1.2.2 Released permalink: /blog/mesos-1-2-2-released/ published: true post_author: display_name: Alexander Rojas tags: Release The latest Mesos 1.2.x release, 1.2.2, is now available for . This release includes important bug fixes and improvements on top of 1.2.1. It is recommended to use this version if you are considering using Mesos 1.2. More specifically, this release includes the following: - The filesystem/linux isolator does not set the permissions of the host_path. - Need to fix resource check in long-lived framework. - `WAITNESTEDCONTAINER` sometimes returns 404. - Allow "old" executors with half-open connections to be preserved during agent upgrade / restart. - Fix interference of external Boost installations when using some unbundled dependencies. - Libprocess can crash on malformed request paths for libprocess messages. - The agent can crash when an unknown executor tries to register. - Mesos fails to exec a custom executor when no shell is used. - Java HTTP adapter crashes JVM when leading master disconnects. - Persistent volume might not be mounted if there is a sandbox volume whose source is the same as the target of the persistent volume. - Agent failed to recover due to mount namespace leakage in Docker 1.12/1.13. - `LIBPROCESS_IP` isn't passed on to the fetcher. - Sandbox_path volume does not have ownership set correctly. - Add an agent flag for executor re-registration timeout. Full release notes are available in the release Rolling upgrades from a Mesos 1.2.1 cluster to Mesos 1.2.2 are straightforward. Please refer to the for detailed information on upgrading to Mesos 1.2.2 from 1.1.x or 1.0.x. NOTE: Since Mesos 1.2.1, the master does not allow 0.x agents to register. Please try out this release and let us know what you think. If you run into any issues, let us know on the . Thanks to the 11 contributors who made 1.2.2 possible: Aaron Wood, Adam B, Alexander Rukletsov, Benjamin Bannier, Benjamin Mahler, Chun-Hung Hsiao, Gastn Kleiman, Gilbert Song, Greg Mann, Jie Yu and Michael Park.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: local.md

Parameters configured on the task definition page, the scope of this parameter is inside this task only. But if you configure according to , it could pass to downstream tasks. If you want to use parameter in single task, see . If you want to use set parameter in task and use them in downstream tasks: For simple use without using custom parameter, see . Using custom parameter, see . Using bash variable, see . Usage of local parameters is: at the task define page, click the '+' beside the 'Custom Parameters' and fill in the key and value to save. This example shows how to use local parameters to print the current date. Create a Shell task and write a script with the content `echo ${dt}`. Click custom parameter in the configuration bar, and the configuration is as follows: Parameters: dt: indicates the parameter name. IN: IN indicates that local parameters can only be used on the current node, and OUT indicates that local parameters can be transmitted to the downstream. DATE: indicates the DATE of the data type. $[YYYY-MM-DD] : indicates a built-in parameter derived from a user-defined format. Save the workflow and run it. View log of Shell task. Note: The local parameter can be used in the workflow of the current task node. If it is set to OUT, it can be passed to the downstream workflow. Please refer to: . If you want to simple export parameters and then use them in downstream tasks, you could use `setValue` in your task. And you can manage your parameters into one single task. You can use syntax `echo '${setValue(set_val=123)}'`(do not forget the single quote) in Shell task and add new `OUT` custom parameter to export it. You can get this value in downstream task using syntax `echo '${set_val}'`. If you want to export parameters with custom parameter instead of constants value, and then use them in downstream tasks, you could use `setValue` in your task, which easier to maintain by change "custom parameter" block when you want to change its value. You can use syntax `echo "#{setValue(setvalparam=${val})}"`(do not forget the double quote, if you are using any variable with `setValue`) in Shell task and add new `IN` custom parameter for input variable `val` and `OUT` custom parameter for exporting parameter `setvalparam`. You could get this value in downstream task using syntax `echo '${setvalparam}'`. If you want to export parameters with bash variable instead of constants value, and then use them in downstream tasks, you could use `setValue` in your task, which more flexible such as you can get variable for exists local or HTTP resource. You can use syntax like ```shell lines_num=$(wget https://raw.githubusercontent.com/apache/dolphinscheduler/dev/README.md -q -O - | wc -l | xargs) echo "#{setValue(setvalvar=${lines_num})}" ``` in Shell task(do not forget the double quote, if you are using any variable with `setValue`) and add `OUT` custom parameter for exporting parameter `setvalvar` . You could get this value in downstream task using syntax `echo '${setvalvar}'`.