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

Please do not create a Pull Request without creating an issue first. XXXXX XX XXXX Follow this checklist to help us incorporate your contribution quickly and easily: [ ] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue. [ ] Format the pull request title like `[ISSUE #123] Fix UnknownException when host config not exist`. Each commit in the pull request should have a meaningful subject line and body. [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. . [ ] Run `mvn -B clean package apache-rat:check findbugs:findbugs -Dmaven.test.skip=true` to make sure basic checks pass. Run `mvn clean install -DskipITs` to make sure unit-test pass. Run `mvn clean test-compile failsafe:integration-test` to make sure integration-test pass.
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: overridepolicy_test.md

| Test Case | E2E Describe Text | Comments | ||--|-| | Check if the OverridePolicy will update the deployment's labels | deployment labelsOverride testing | | | Check if the OverridePolicy will update the deployment's annotations | deployment annotationsOverrider testing | | | Check if the OverridePolicy will update the deployment's image value | deployment imageOverride testing | | | Check if the OverridePolicy will update the pod's image value | pod imageOverride testing | | | Check if the OverridePolicy will update the specific image value | deployment imageOverride testing | | | Test Case | E2E Describe Text | Comments | ||--|-| | Check if the OverridePolicy will update the specific image value when with nil resourceSelector | deployment imageOverride testing | | | Test Case | E2E Describe Text | Comments | ||--|-| | Check if the OverridePolicy will update all the image value of the deployment | deployment imageOverride testing | | | Check if the OverridePolicy will update all the image value of the pod | pod imageOverride testing | | | Check if the OverridePolicy will update the specific image value | deployment imageOverride testing | | | Test Case | E2E Describe Text | Comments | ||--|-| | Check if the OverridePolicy will update the deployment's image value when with nil resourceSelector | deployment imageOverride testing | | | Check if the OverridePolicy will update the deployment's image value when creating overridePolicy after develop and propagationPolicy have been created | deployment imageOverride testing | |
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.4.0.md

+++ title = "CoreDNS-1.4.0 Release" description = "CoreDNS-1.4.0 Release Notes." tags = ["Release", "1.4.0", "Notes"] release = "1.4.0" date = "2019-03-03T09:04:07+00:00" author = "coredns" +++ We are pleased to announce the of CoreDNS-1.4.0! Our first release after we became a graduated project in . Deprecation notice for the next release: will deprecate TIMEOUT* and recommends the use of RELOAD (). and will deprecate NO_RELOAD and recommends the use of RELOAD set to 0 (). will revert back to report process level health without plugin status. A new ready plugin will make sure plugins have at least completed their startup sequence. The will be moved to an external repository and as such be deprecated from the default set of plugin; use the as a replacement. The announced deprecations have been enacted. The (unused) gRPC watch functionally was removed from the server. Note we're actively working on two (probably related) bugs (, ) which should hopefully result in a fix and a new release fairly quickly. Random updates in documentation and fixes in tests and various plugins. fixes the logging now that kubernetes' client lib switched to klog from glog. fixes IPv4 addresses in IPV6 syntax. adds credential support and a fix for the reply when the `host` field is empty. has been made more efficient. drops out of order messages, this is solve occasionally FORMERRs people saw. Think we never had so many contributors for a single release. This is really nice to see. Thank you all: AdamDang, Anders Ingemann, Andrey Meshkov, Brian Bao, Carl-Magnus Bjrkell, Chris Aniszczyk, Chris O'Haver, Christophe de Carvalho, ckcd, Dan Kohn, Darshan Chaudhary, DO ANH TUAN, Guillaume Gelin, Guy Templeton, JoeWrightss, Kenjiro Nakayama, LongKB, Miek Gieben, mrasu, Nguyen Hai Truong, Nguyen Phuong An, Nguyen Quang Huy, Nguyen Van Duc, Nguyen Van Trung, Rob Maas, Ruslan Drozhdzh, Sandeep Rajan, Thomas Mangin, tuanvcw, Uladzimir Trehubenka, Xiao An, Xuanwo, Ye Ben, Yong Tang.
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_remove_route.md

title: "glooctl remove route" weight: 5 Remove a Route from a Virtual Service Routes match patterns on requests and indicate the type of action to take when a proxy receives a matching request. Requests can be broken down into their Match and Action components. The order of routes within a Virtual Service matters. The first route in the virtual service that matches a given request will be selected for routing. If no virtual service is specified for this command, glooctl add route will attempt to add it to a default virtualservice with domain '*'. if one does not exist, it will be created for you. Usage: `glooctl rm route [--name virtual-service-name] [--namespace namespace] [--index x]` ``` glooctl remove route [flags] ``` ``` -h, --help help for route -x, --index uint32 remove the route with this index in the virtual service route list -o, --output OutputType output format: (yaml, json, table, kube-yaml, wide) (default table) ``` ``` -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 -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") --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - remove configuration items from a top-level Gloo resource
Project: Traefik (Orchestration & Management / API Gateway)
File: advocating.md

title: "Traefik Advocation Documentation" description: "There are many ways to contribute to Traefik Proxy. Let us know if youre talking about Traefik, and we'll promote your enthusiasm!" Spread the Love & Tell Us About It {: .subtitle } Traefik Proxy was started by the community and for the community. You can contribute to the Traefik community in three main ways: Spread the word! Guides, videos, blog posts, how-to articles, and showing off your network design all help spread the word about Traefik Proxy and teach others in the community how to best implement it. It always sparks joy when users share how Traefik Proxy helps them solve their problems. If you are talking about Traefik Proxy, and we will promote your work and reward your enthusiasm! If you are giving a talk that includes or is about Traefik Proxy, and we will send you swag and stickers for your time at the conference. If you have written about Traefik or shared useful information you would like to promote, feel free to add links to the . Help community members! Everyone needs a place to share their cool innovations or get help with that pesky bug that only a different pair of eyes seems to be able to see. Join our where you can ask questions, help out other users, and share your neat configuration examples or snippets. Top contributors will be asked to join the Ambassador program and get unique swag to celebrate! Build cool solutions! Traefik Proxy would be so much better if only it had We love all the wonderful ideas that our users come up with, but we can only build so much. Luckily, as an open source community, our users can help by , enhancements, or bug fixes. We are a big community, so we do need to prioritize a bit. That is why we use the tag `contributor/wanted` to let you know which pull requests will make it to the front of the queue for design support and review. Feel free to grab one of these and run with it. Top contributors get unique swag to celebrate.
Project: Open Cluster Management (Orchestration & Management / Scheduling & Orchestration)
File: SECURITY.md

Join the [kubernetes-security-announce] group for security and vulnerability announcements. You can also subscribe to an RSS feed of the above using . Instructions for reporting a vulnerability can be found on the [Kubernetes Security and Disclosure Information] page. Information about supported Kubernetes versions can be found on the [Kubernetes version and version skew support policy] page on the Kubernetes website.
Project: Gloo (Orchestration & Management / API Gateway)
File: static_metadata.md

The contains a message that an an element of: This metadata is not required and the `resourceKind`, `resourceRef.name`, and `resourceRef.namespace` fields which compose the metadata are plain strings. While the objects used to create the Proxy Api resources are and should be generally irrelevant to the functionality of Gloo Edge, they do provide user facing value as sources of names and labels. When creating a resource, we use the static metadata to determine the value to use for the `service_name` field. A `StaticMetadataResource` is considered to be a Gateway when it has a `resourceKind` of `*v1.Gateway`. The value of that resource's `resourceRef.name` is then used as the `service.name`. If the metadata is not present, or in a different format, the `service_name` will be set to the following: Metadata is in deprecated format: "deprecated_metadata" Unknown metadata format: "unknown_metadata" Gateway metadata is not found: "undefined_gateway"
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: new-committer-oscar-westra-van-holthe-kind.md

title: "New committer: Oscar Westra van Holthe - Kind" linkTitle: "New committer: Oscar Westra van Holthe - Kind" date: 2023-08-09 <!-- 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. --> The Project Management Committee (PMC) for Apache Avro has invited Oscar Westra van Holthe - Kind to become a committer and we are pleased to announce that he has accepted. Oscar has done some really solid work on the IDL and JavaCC parts of the Java SDK. We trust his work and think it's exceptionally high quality. From the start, he has already doing much of the work of a committer, demonstrated by his continuous presence in commenting JIRA, reviewing PRs as well as encouraging and insightful words on the mailing list. As a bonus, in his spare time, Oscar also maintains the IntelliJ plugin for ! Thanks for all your hard work, and welcome!
Project: Eraser (Orchestration & Management / Scheduling & Orchestration)
File: custom-scanner.md

title: Custom Scanner To create a custom scanner for non-compliant images, use the following . In order to customize your scanner, start by creating a `NewImageProvider()`. The ImageProvider interface can be found can be found . The ImageProvider will allow you to retrieve the list of all non-running and non-excluded images from the collector container through the `ReceiveImages()` function. Process these images with your customized scanner and threshold, and use `SendImages()` to pass the images found non-compliant to the eraser container for removal. Finally, complete the scanning process by calling `Finish()`. When complete, provide your custom scanner image to Eraser in deployment.
Project: BFE (Orchestration & Management / Service Proxy)
File: MAINTAINERS.md

This file lists who are the maintainers of the BFE project. The responsibilities for maintainers are listed in the file. | Name | GitHub ID | Affiliation | | - | | -- | | | | Yingfei Networks | | | | Tencent | | Name | GitHub ID | Affiliation | | - | | -- | | | | Tencent | | Name | GitHub ID | Affiliation | | - | | -- | | | | Kuaishou | | | | Tencent | | | | ByteDance | | | | ByteDance | | | | ByteDance | | | | Baidu | | | | Yingfei Networks | | | | Yingfei Networks | | | | Yingfei Networks |
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: documentation-guide.md

title: Apache Mesos - Documentation Guide layout: documentation Documentation is an integral part of every good feature. It describes the intended usage and enables new users to start using and understanding the feature. We have three different kinds of documentation: User guides and non-code technical documentation are stored in markdown files in the `docs/` folder. These files get rendered for the . We will accept small documentation changes on . Larger documentation changes should go through the . Doxygen API documentation needs only to be applied to source code parts that constitute an interface for which we want to generate Mesos API documentation files. Implementation code that does not participate in this should still be enhanced by source code comments as appropriate, but these comments should not follow the doxygen style. Substantial libraries, components, and subcomponents of the Mesos system such as stout, libprocess, master, agent, containerizer, allocator, and others should have an overview page in markdown format that explains their purpose, overall structure, and general use. This can even be a complete developer guide. Regular source code documentation All other source code comments must follow the . We follow the on how to use words such as "must", "should", "can", and other requirement-related notions.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: subscribe.md

It is highly recommended to subscribe to the development mailing list to keep up-to-date with the community. In the process of using DolphinScheduler, if you have any questions or ideas, suggestions, you can participate in the DolphinScheduler community building through the Apache mailing list. Sending a subscription email is also very simple, the steps are as follows: Send an email to dev-subscribe@dolphinscheduler.apache.org with your own email address, subject and content are arbitrary. Receive confirmation email and reply. After completing step 1, you will receive a confirmation email from dev-help@dolphinscheduler.apache.org (if not received, please confirm whether the email is automatically classified as spam, promotion email, subscription email, etc.) . Then reply directly to the email, or click on the link in the email to reply quickly, the subject and content are arbitrary. Receive a welcome email. After completing the above steps, you will receive a welcome email with the subject WELCOME to dev@dolphinscheduler.apache.org, and you have successfully subscribed to the Apache DolphinScheduler mailing list. If you do not need to know what's going on with DolphinScheduler, you can unsubscribe from the mailing list. Unsubscribe from the mailing list steps are as follows: Send an email to dev-unsubscribe@dolphinscheduler.apache.org with your subscribed email address, subject and content are arbitrary. Receive confirmation email and reply. After completing step 1, you will receive a confirmation email from dev-help@dolphinscheduler.apache.org (if not received, please confirm whether the email is automatically classified as spam, promotion email, subscription email, etc.) . Then reply directly to the email, or click on the link in the email to reply quickly, the subject and content are arbitrary. Receive a goodbye email. After completing the above steps, you will receive a goodbye email with the subject GOODBYE from dev@dolphinscheduler.apache.org, and you have successfully unsubscribed to the Apache DolphinScheduler mailing list, and you will not receive emails from dev@dolphinscheduler.apache.org.
Project: Pipy (Orchestration & Management / Service Proxy)
File: discussion.md

name: "\U0001F914 Pipy Improvement Discussion" about: I want to start a new discussion about improving Pipy. labels: status:discussion What aspect of Pipy would you like to see improved? What are the reasons? Include practical examples to illustrate your points. Optionally add one (or more) proposals to improve the current situation.
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: kusk_install.md

Install kusk-gateway, envoy-fleet, api, and dashboard in a single command Install kusk-gateway, envoy-fleet, api, and dashboard in a single command. $ kusk cluster install Will install kusk-gateway, a public (for your APIS) and private (for the kusk dashboard and api) envoy-fleet, api, and dashboard in the kusk-system namespace using helm. $ kusk cluster install --name=my-release --namespace=my-namespace Will create a helm release named with --name in the namespace specified by --namespace. $ kusk cluster install --no-dashboard --no-api --no-envoy-fleet Will install kusk-gateway, but not the dashboard, api, or envoy-fleet. ``` kusk cluster install [flags] ``` ``` -h, --help help for install --name string installation name (default "kusk-gateway") --namespace string namespace to install in (default "kusk-system") --no-api don't install the api. Setting this flag implies --no-dashboard --no-dashboard don't the install dashboard --no-envoy-fleet don't install any envoy fleets ``` ``` --config string config file (default is $HOME/.kusk.yaml) ``` -
Project: Skipper (Orchestration & Management / Service Proxy)
File: ingress-backends.md

As described in , there is a problem that exists in Kubernetes, while terminating Pods. Terminating Pods could be graceful, but the nature of distributed environments will show failures, because not all components in the distributed system changed already their state. When a Pod terminates, the controller-manager has to update the `endpoints` of the Kubernetes `service`. Additionally Skipper has to get this endpoints list. Skipper polls the kube-apiserver every `-source-poll-timeout=<ms>`, which defaults to 3000. Reducing this interval or implementing watch will only reduce the timeframe, but not fix the underlying race condition. Mitigation strategies can be different and the next section document strategies for application developers to mitigate the problem. An application that is target of an ingress can circumvent HTTP code 504s Gateway Timeouts with these strategies: use use a SIGTERM handler to switch `readinessProbe` to unhealthy and exit later, or just wait for SIGKILL terminating the process. [Kubernetes Pod Lifecycle Hooks](https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/#define-poststart-and-prestop-handlers) in the Pod spec can have a `preStop` command which executes for example a binary. The following will execute the binary `sleep` with argument `20` to wait 20 seconds before terminating the containers within the Pod: ```yaml lifecycle: preStop: exec: command: ["sleep","20"] ``` 20 seconds should be enough to fade your Pod out of the endpoints list and Skipper's routing table. An application can implement a SIGTERM handler, that changes the `readinessProbe` target to unhealthy for the application instance. This will make sure it will be deleted from the endpoints list and from Skipper's routing table. Similar to [Pod Lifecycle Hooks](#pod-lifecycle-hooks) you could sleep 20 seconds and after that terminate your application or you just wait until SIGKILL will cleanup the instance after 60s. ```go go func() { var sigs chan os.Signal sigs = make(chan os.Signal, 1) signal.Notify(sigs, syscall.SIGTERM) for { select { case <-sigs: healthCheck = unhealthy time.Sleep(20*time.Second) os.Exit(0) } } }() ```
Project: Prefect (Orchestration & Management / Scheduling & Orchestration)
File: versioning.md

description: How Prefect versions its releases and compatibility. tags: versioning semver search: boost: 2 Versions are composed of three parts: MAJOR.MINOR.PATCH. For example, the version 2.5.0 has a major version of 2, a minor version of 5, and patch version of 0. Occasionally, we will add a suffix to the version such as `rc`, `a`, or `b`. These indicate pre-release versions that users can opt-into installing to test functionality before it is ready for release. Each release will increase one of the version numbers. If we increase a number other than the patch version, the versions to the right of it will be reset to zero. Prefect will increase the major version when significant and widespread changes are made to the core product. It is very unlikely that the major version will change without extensive warning. Prefect will increase the minor version when: Introducing a new concept that changes how Prefect can be used Changing an existing concept in a way that fundamentally alters how it is used Removing a deprecated feature Prefect will increase the patch version when: Making enhancements to existing features Fixing behavior in existing features Adding new functionality to existing concepts Updating dependencies A breaking change means that your code will need to change to use a new version of Prefect. We strive to avoid breaking changes in all releases. At times, Prefect will deprecate a feature. This means that a feature has been marked for removal in the future. When you use it, you may see warnings that it will be removed. A feature is deprecated when it will no longer be maintained. Frequently, a deprecated feature will have a new and improved alternative. Deprecated features will be retained for at least 3 minor version increases or 6 months, whichever is longer. We may retain deprecated features longer than this time period. Prefect will sometimes include changes to behavior to fix a bug. These changes are not categorized as breaking changes. When running a Prefect server, you are in charge of ensuring the version is compatible with those of the clients that are using the server. Prefect aims to maintain backwards compatibility with old clients for each server release. In contrast, sometimes new clients cannot be used with an old server. The new client may expect the server to support functionality that it does not yet include. For this reason, we recommend that all clients are the same version as the server or older. For example, a client on 2.1.0 can be used with a server on 2.5.0. A client on 2.5.0 cannot be used with a server on 2.1.0. Prefect Cloud targets compatibility with all versions of Prefect clients. If you encounter a compatibility issue, please .