cwielenb/CNCF-Dataset huggingface dataset:
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: downgrades.md

title: Apache Mesos - Downgrade Compatibility layout: documentation This document serves as a guide for users who wish to downgrade from an existing Mesos cluster to a previous version. This usually happens when rolling back from problematic upgrades. Mesos provides compatibility between any 1.x and 1.y versions of masters/agents as long as new features are not used. Since Mesos 1.8, we introduced a check for minimum capabilities on the master. If a backwards incompatible feature is used, a corresponding minimum capability entry will be persisted to the registry. If an old master (that does not possess the capability) tries to recover from the registry (e.g. when rolling back), an error message will be printed containing the missing capabilities. This document lists the detailed information regarding these minimum capabilities and remediation for downgrade errors. <table class="table table-striped"> <thead> <tr><th>Capability</th><th>Description</th> </thead> <tr> <td> <code>AGENT_DRAINING</code> </td> <td> This capability is required when any agent is marked for draining or deactivated. These states were added in Mesos 1.9 and are triggered by using the <code>DRAIN_AGENT</code> or <code>DEACTIVATE_AGENT</code> operator APIs. <br/> To remove this minimum capability requirement: <ol> <li> Stop the master downgrade and return to the more recent version. </li> <li> Find all agents that are marked for draining or deactivated. This can be done by using the <code>GET_AGENTS</code> operator API and checking the <code>deactivated</code> boolean field of each agent. All draining agents will also be deactivated. </li> <li> Use the <code>REACTIVATE_AGENT</code> operator API for each deactivated agent. </li> </ol> </td> </tr> <tr> <td> <code>QUOTA_V2</code> </td> <td> This capability is required when quota is configured in Mesos 1.9 or higher. When that happens, the newly configured quota will be persisted in the <code>quota_configs</code> field in the registry which requires this capability to decode. <br/> To remove this minimum capability requirement: <ol> <li> Stop the master downgrade and return to the more recent version. </li> <li> Use the <code>/registrar(id)/registry</code> endpoint to read the registry content and identify roles listed under the <code>quota_configs</code> field. </li> <li> Reset those roles' quota back to default (no guarantees and no limits). This will remove the roles from the <code>quota_configs</code> field. Once <code>quota_configs</code> becomes empty, the capability requirement will be removed. </li> </ol> </td> </tr> </table>
Project: OpenNebula (Orchestration & Management / Scheduling & Orchestration)
File: bug_report.md

name: Bug report about: Create a report to help us improve labels: 'Type: Bug' /!\ To report a security issue please follow this procedure: [https://github.com/OpenNebula/one/wiki/Vulnerability-Management-Process] Description A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior. Expected behavior A clear and concise description of what you expected to happen. Details Affected Component: [e.g. Sunstone, Scheduler, or Storage] Hypervisor: [e.g. KVM] Version: [e.g. 5.4.12 or development] Additional context Add any other context about the problem here. <!--////////////////////////////////////////////--> <!-- THIS SECTION IS FOR THE DEVELOPMENT TEAM --> <!-- BOTH FOR BUGS AND ENHANCEMENT REQUESTS --> <!-- PROGRESS WILL BE REFLECTED HERE --> <!--////////////////////////////////////////////--> [ ] Code committed [ ] Testing - QA [ ] Documentation (Release notes - resolved issues, compatibility, known issues)
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: cleanup_request.md

name: Request a cleanup about: Suggest a cleanup in our repository labels: kind/internal cleanup, priority/P2, untriaged <!-- 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) -->
Project: Service Mesh Performance (Orchestration & Management / Service Mesh)
File: README.md

Before contributing, please review the . The following steps will guide you on how to set up your development environment, fork and clone the repository, run the site locally, and finally commit, sign-off, and push any changes made for review. The Service-Mesh-Performance Docs site is built using Jekyll - a simple static site generator! You can learn more about Jekyll and setting up your development environment in the .* First , then install Jekyll and Bundler. Fork and then clone the ```bash $ git clone https://github.com/YOUR-USERNAME/service-mesh-performance ``` Change to the docs directory ```bash $ cd docs ``` Install any Ruby dependencies ```bash $ bundle install ``` Serve the code locally ```bash $ make site ``` Note: From the Makefile, this command is running `$ bundle exec jekyll serve --drafts --livereload` After making changes, don't forget to commit with the sign-off flag (-s)! ```bash $ commit -s -m my commit message w/signoff ``` Once all changes have been committed, push the changes. ```bash $ git push origin <branch-name> ``` Then on Github, navigate to the and create a pull request from your recently pushed changes! See the for additional reference.
Project: Contour (Orchestration & Management / Service Proxy)
File: design-document-tmpl.md

Status: {Draft,Reviewing,Accepted,Declined} Note: The preferred style for design documents is one sentence per line. Do not wrap lines. This aids in review of the document as changes to a line are not obscured by the reflowing those changes caused and has a side effect of avoiding debate about one or two space after a period. Note: The name of the file should follow the name pattern `<short meaningful words joined by '-'>_design.md`, e.g: `listener-design.md`. One to two sentences that describes the goal of this proposal and the problem being solved by the proposed change. The reader should be able to tell by the title, and the opening paragraph, if this document is relevant to them. One to two paragraphs of exposition to set the context for this proposal. A short list of things which will be accomplished by implementing this proposal. Two things is ok. Three is pushing it. More than three goals suggests that the proposal's scope is too large. A short list of items which are: a. out of scope b. follow on items which are deliberately excluded from this proposal. One to two paragraphs that describe the high level changes that will be made to implement this proposal. A detailed design describing how the changes to the product should be made. The names of types, fields, interfaces, and methods should be agreed on here, not debated in code review. The same applies to changes in CRDs, YAML examples, and so on. Ideally the changes should be made in sequence so that the work required to implement this design can be done incrementally, possibly in parallel. If there are alternative high level or detailed designs that were not pursued they should be called out here with a brief explanation of why they were not pursued. If this proposal has an impact to the security of the product, its users, or data stored or transmitted via the product, they must be addressed here. A discussion of any compatibility issues that need to be considered A description of the implementation, timelines, and any resources that have agreed to contribute. A discussion of issues relating to this proposal for which the author does not know the solution. This section may be omitted if there are none.
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: bug_report.md

name: Bug report about: Create a report to help us improve Kusk Gateway title: '' labels: kind/bug assignees: '' Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: Run '...' Specify '...' See error Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add log output to help explain your problem. Desktop (please complete the following information): Kubernetes version Kube Gateway Version Additional context Add any other context about the problem here.
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: linux-seccomp.md

title: Apache Mesos - Linux Seccomp Isolator in Mesos Containerizer layout: documentation This document describes the `linux/seccomp` isolator. This isolator adds support for installing for containers launched using the . Seccomp filter reduces the attack surface of the Linux kernel by providing a mechanism for filtering of certain system calls. Seccomp requires Linux kernel 3.5 or newer. Seccomp filter is defined by a Seccomp profile which must be compatible with the Docker Seccomp profile format. An example of the Seccomp profile can be found in . Note: Mesos containerizer uses `pivot_root` system call, so it must be specified in the Seccomp profile. Usually, the Docker Seccomp profile contains `chroot` syscall, so the `pivot_root` syscall must be added to the same array `"names": ["chroot","pivot_root"]`. The Linux Seccomp isolator is loaded when `linux/seccomp` is present in the agent's `--isolation` flag. This isolator requires root privileges to install a Seccomp filter because a Seccomp filter can't be installed for a non-privileged user without setting `nonewprivs` bit which leads to side effects. The `--seccompconfigdir` flag specifies the path to the directory containing Seccomp profiles. The `--seccompprofilename` flag specifies the default Seccomp profile which is applied by default for all Mesos containers. This profile name must be relative to the `--seccompconfigdir`. If this flag is omitted, then the default Seccomp profile is not defined and therefore not applied by default. A possible agent startup invocation could be ```{.console} sudo mesos-agent --master=<master ip> --ip=<agent ip> --work_dir=/var/lib/mesos --isolation=linux/seccomp[,other isolation flags] --seccompconfigdir=/etc/mesos/seccomp --seccompprofilename=default.json ``` In order for a Mesos task to override the agent's default Seccomp profile, it should declare the required profile in the `LinuxInfo` field of its `ContainerInfo`. E.g., if the agent is launched with the default Seccomp profile enabled, a framework can disable Seccomp for a particular task by setting an `unconfined` field in the corresponding `SeccompInfo`.
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.6.3-released.md

title: "Avro 1.6.3" linkTitle: "Avro 1.6.3" date: 2012-03-19 <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> Apache Avro 1.6.3 has been released!
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: organization-configuration-notification-template.md

Customize the notifications displayed in the bell in the navigation bar. You can change the title and the content. Customize the notifications sent by email. You can change the subject and the body of the message. NOTE: For a template to include, you can only override the body. You can use Freemarker template engine to add specific information to your templates: Examples: `${user.name}` `${api.metadata['foo-bar']}` For all notifications, you can use these parameters: | API | Application | Group | |-||| | name | name | name | | description | description | - | | version | type | - | | role | status | - | | metadata (Map) | role | - | | deployedAt (Date) | - | - | | createdAt (Date) | createdAt (Date) | createdAt (Date) | | updatedAt (Date) | updatedAt (Date) | updatedAt (Date) | | Plan | Owner/User | Subscription | |--|-|| | name | name | status | | description | description | request | | order | order | reason | | publishedAt (Date) | displayName | processedAt (Date) | | closedAt (Date) | email | startingAt (Date) | | - | - | endingAt (Date) | | createdAt (Date) | - | closedAt (Date) | | updatedAt (Date) | - | subscribedAt (Date) |
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-api-resources.md

Resources are link to the API lifecycle. They are initialized when the API is starting and released when API is stopped. Resources are used via the API policies to enhance API behavior. Different resource types are available: Cache Used to store re-usable data to avoid subsequent calls. OAuth 2.0 Used to introspect an access_token via an external OAuth 2.0 authorization server. The (+) button let you create a new resource.
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_edit_route_ratelimit.md

title: "glooctl edit route ratelimit" weight: 5 Configure rate-limits (Enterprise) Configure rate-limits for requests that match this route. This is a Gloo Enterprise feature. ``` -h, --help help for ratelimit ``` ``` -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 -x, --index uint32 edit the route with this index in the virtual service route list -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) --resource-version string the resource version of the resource we are editing. if not empty, resource will only be changed if the resource version matches --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - - Add rate-limits (Enterprise)
Project: KEDA (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 oss-conduct@uber.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: coredns-1.1.0.md

+++ title = "CoreDNS-1.1.0 Release" description = "CoreDNS-1.1.0 Release Notes." tags = ["Release", "1.1.0", "Notes"] draft = false release = "1.1.0" date = "2018-03-12T09:33:29+00:00" author = "coredns" enabled = "default" +++ We are pleased to announce the of CoreDNS-1.1.0! CoreDNS has been promoted to the level in the ! This has been made possible by the work done by contributors, users and adopters. Thank you all! Bump the version to 1.1.0, as we deprecate two plugins (shutdown and startup). In CoreDNS 1.0.6 the plugin was extended to allow binding to multiple interfaces. This release adds the ability serve the same zone on different interfaces (we used to block this for no good reason). I.e. this now works: ``` . { bind 127.0.0.1 } . { bind 127.0.0.2 } ``` The plugins shutdown and startup* where marked deprecated in 1.0.6. This release removes them. You should use instead. A new plugin was added: reload*, which watches for changes in your Corefile and then automatically will reload the process. This is not yet bullet proof, some plugins can fail to setup during a reload. See the discussion in . A number of plugins can only be used once in a server block, but didn't make this explicit. I.e. would silently overwrite earlier config. The following plugins now return an error when used multiple times in a single Server Block*: cache, dnssec, errors, forward, hosts, nsid, metrics, kubernetes, pprof, reload, root. adds support for a Datadog endpoint. Some changes went into , make it easier to use from other plugins. Small change in the plugin, the log default will now also log the client's port number and IPv6 addresses are printed with brackets: `[::1]`. The following people helped with getting this release done: Chris O'Haver, Francois Tur, John Belamaric, Miek Gieben, nogoegst, Ricardo Katz, Tobias Schmidt, Uladzimir Trehubenka, varyoo, Yamil Asusta, Yong Tang. For documentation see our (in progress!) . For help and other resources, see our .
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: bug_report_python.md

name: Report a gRPC Python bug about: Create a report to help us improve labels: kind/bug, priority/P2, lang/Python assignees: gnossen XuanWang-Amos <!-- 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) --> Please provide either 1) A unit test for reproducing the bug or 2) Specific steps for us to follow to reproduce the bug. If theres not enough information to debug the problem, gRPC team may close the issue at their discretion. Youre welcome to re-open the issue once you have a reproduction. Make sure you include information that can help us debug (full error message, exception listing, stack trace, logs). See for how to diagnose problems better.