cwielenb/CNCF-Dataset huggingface dataset:
Project: Service Mesh Performance (Orchestration & Management / Service Mesh)
File: PULL_REQUEST_TEMPLATE.md

Description This PR fixes # Notes for Reviewers [ ] Yes, I signed my commits. <!-- Thank you for contributing to Layer5 projects! Contributing Conventions: Include descriptive PR titles with [<component-name>] prepended. Build and test your changes before submitting a PR. Sign your commits By following the community's contribution conventions upfront, the review process will be accelerated and your PR merged more quickly. -->
Project: Knative (Orchestration & Management / Scheduling & Orchestration)
File: RELEASE.md

The `yaml` Project is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: pending_api_cleanups.md

There are times when we make changes that include a temporary shim for backward-compatibility (e.g., a macro or some other function to preserve the original API) to avoid having to bump the major version number in the next release. However, when we do eventually want to release a feature that does change the API in a non-backward-compatible way, we will wind up bumping the major version number anyway, at which point we can take the opportunity to clean up any pending backward-compatibility shims. This file lists all pending backward-compatibility changes that should be cleaned up the next time we are going to bump the major version number: remove `ServerBuilder::SetMaxMessageSize()` method from `include/grpc++/server_builder.h` (commit `6980362`) remove `ClientContext::setfailfast()` method from `include/grpc++/client_context.h` (commit `9477724`) remove directory `include/grpc++` and all headers in it (commit `eb06572`) make all `Request` and `Mark` methods in `grpc::Service` take a `size_t` argument for `index` rather than `int` (since that is only used as a vector index)
Project: SOFARPC (Orchestration & Management / Remote Procedure Call)
File: SECURITY.md

If you have apprehensions regarding SOFAStack's security or you discover vulnerability or potential threat, dont hesitate to get in touch with us by dropping a mail at sofastack@antgroup.com. In the mail, specify the description of the issue or potential threat. You are also urged to recommend the way to reproduce and replicate the issue. The SOFAStack community will get back to you after assessing and analysing the findings. PLEASE PAY ATTENTION to report the security issue on the security email before disclosing it on public domain. SOFARPC uses Hessian serialization by default. Hessian is a binary serialization protocol. For more information, please refer to Hessian's . Because of the implement of Hessian, by constructing a specific serialization stream, it may cause arbitrary code execution when doing deserialization. It is recommended that users configure blacklist to solve the problem. SOFARPC also provides a way to configure blacklists in `BlackListFileLoader`, you can override the blacklist configuration based on the code. The blacklist built into the project comes from internal practices and external contributions, and is for reference only and is not actively updated, we do not assume any legal responsibility for this.
Project: Gloo (Orchestration & Management / API Gateway)
File: consul.proto.sk.md

title: "consul.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Upstream Spec for Consul Upstreams consul Upstreams represent a set of one or more addressable pods for a consul Service the Gloo consul Upstream maps to a single service port. Because consul Services support multiple ports, Gloo requires that a different upstream be created for each port consul Upstreams are typically generated automatically by Gloo from the consul API ```yaml "serviceName": string "serviceTags": []string "subsetTags": []string "instanceTags": []string "instanceBlacklistTags": []string "serviceSpec": .options.gloo.solo.io.ServiceSpec "consistencyMode": .consul.options.gloo.solo.io.ConsulConsistencyModes "queryOptions": .consul.options.gloo.solo.io.QueryOptions "connectEnabled": bool "dataCenters": []string ``` | Field | Type | Description | | -- | - | -- | | `serviceName` | `string` | The name of the Consul Service. | | `serviceTags` | `[]string` | Deprecated: This field was renamed to subsettags. If subsettags is used, this field is ignored. Otherwise, the behavior is the same as subset_tags field below. | | `subsetTags` | `[]string` | Gloo will segment instances based off of these tags. This allows you to set routes that route to a subset of the instances of the service. | | `instanceTags` | `[]string` | The list of service tags Gloo should search for on a service instance before deciding whether or not to include the instance as part of this upstream. Empty list means that all service instances with the same service name will be included. When not empty, only service instances that match all of the tags (subset match) will be selected for this upstream. | | `instanceBlacklistTags` | `[]string` | The opposite of instanceTags, this is a list of service tags that gloo should ensure are not in a service instance before including it in an upstream. | | `serviceSpec` | | An optional Service Spec describing the service listening at this address. | | `consistencyMode` | | Sets the consistency mode. The default is DefaultMode. Note: Gloo handles staleness well (as it runs update loops ~ once/second) but makes many requests to get consul endpoints so users may want to opt into stale reads once the implications are understood. | | `queryOptions` | | QueryOptions are the query options to use for all Consul queries. | | `connectEnabled` | `bool` | Is this consul service connect enabled. | | `dataCenters` | `[]string` | The data centers in which the service instance represented by this upstream is registered. | <!-- Start of HubSpot Embed Code --> <script type="text/javascript" id="hs-script-loader" async defer src="//js.hs-scripts.com/5130874.js"></script> <!-- End of HubSpot Embed Code -->
Project: Gloo (Orchestration & Management / API Gateway)
File: cares_dns_resolver.proto.sk.md

title: "caresdnsresolver.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Configuration for c-ares DNS resolver. ```yaml "resolvers": []solo.io.envoy.config.core.v3.Address "dnsResolverOptions": .solo.io.config.core.v3.DnsResolverOptions ``` | Field | Type | Description | | -- | - | -- | | `resolvers` | | A list of dns resolver addresses. :ref:`useresolversasfallback<envoyv3apifieldextensions.network.dnsresolver.cares.v3.CaresDnsResolverConfig.useresolversas_fallback>` below dictates if the DNS client should override system defaults or only use the provided resolvers if the system defaults are not available, i.e., as a fallback. | | `dnsResolverOptions` | | Configuration of DNS resolver option flags which control the behavior of the DNS resolver. | <!-- Start of HubSpot Embed Code --> <script type="text/javascript" id="hs-script-loader" async defer src="//js.hs-scripts.com/5130874.js"></script> <!-- End of HubSpot Embed Code -->
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: demo.md

To prevent data loss by some miss-operation, it is recommended to back up data before initializing the workflow demo. The backup way according to your environment. Download the latest binary distribute package from and then put it in the different directory where current service running. And all below command is running in this directory. Start all services of dolphinscheduler according to your deployment method. If you deploy your dolphinscheduler according to , you can start all services by command `sh ./script/start-all.sh`. Initializing the workflow demo needs to store metabase in other database like MySQL or PostgreSQL, they have to change some configuration. Follow the instructions in `Standalone Switching Metadata Database Configuration` section to create and initialize database. ``` demo: tenant-code: default domain-name: localhost api-server-port: 5173 ``` Mentioned above, tenant-code is the default tenant, users can modify the user name according to their operating system, this replaces the manual tenant creation action, api-server-port is the port number of the service. Then execute the startup script that initializes the workflow demo service: `sh ./tools/bin/create-demo-processes.sh` to start the service. To create a demo, you can refer to
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: committing.md

title: Apache Mesos - Committing layout: documentation Only committers have the ability to commit your change, so make sure you work with one during code review to get your changes committed. If you are a committer, here are some guidelines for committing changes: Check the JIRA ticket: make sure there is no further discussion needed regarding the approach used in the patch. Follow the format of commit messages: we currently do not leverage any tooling to enforce the format of messages, so: Be clear and explicit in the commit message. Include the link to the review (this will be done automatically if using `support/post-reviews.py` for your own changes and `support/apply-review.sh` for committing changes from others). Be sure to clean up the commit message when pulling in changes from others. Use 72 character columns. Note that we don't always have a 50 character or less summary because that restriction tends to cause people to write poorly. Keep the 'Author' intact: `support/apply-review.sh` will handle this for you, but be careful when rebasing or ammending. Never ever commit a merge: always rebase instead, as appropriate. Likewise, never 'force push'. Don't break the build: we support , , Mac OS X and . However, not all configurations are being tested in Jenkins, so be aware of that. Also, pay attention to the Jenkins review bot if it flags a review as breaking the build. Note that if you do break the build, the fixes are often small and inconsequential so don't worry about going through a review cycle for that, just fix things (but don't take that as a license to "wait until the build fails to fix things").
Project: Gloo (Orchestration & Management / API Gateway)
File: backports.md

A backport is a change that is introduced on the main branch, and then applied to a previous version of Gloo Edge. For a backport to be appropriate it must fit the following criteria: The change must have a clear rationale for why it is needed on a previous version of Gloo Edge. The change must be a low-risk change, this typically means it is a bug fix or a non-breaking change. The proposed change is targeted to a . If the change is a feature request, you must have explicit approval from the product and engineering teams. This approval can also be solicited on the backport prs themselves Generally a backport for a feature should have been requested by at least one of these teams to be considered in the first place On the issue that tracks the desired functionality, apply a `release/1.N` label to indicate the version of Gloo Edge you wish the request to be supported on. For example, if there is a `release/1.14` label, that means the issue is targeted to be introduced first on the stable main branch, and then backported to Gloo Edge 1.14.x. First, create a PR to introduce the change on the main branch. Doing so ensures that changes are tested and reviewed before being applied to a previous version of Gloo Edge. Also, given that we use for our API definitions, introducing API changes to our main branch first ensures we will not have API compatibility issues when backporting. Once the change has been merged into the main branch, create a PR to backport the change to the desired release branch. The PR should be titled `[BRANCH NAME]: <PR title>` (ie `[1.14]: Original PR Title`). To create a backport branch we recommend the following: Use to apply changes to a previous version of Gloo Edge. Resolve any conflicts that have arisen due to drift between LTS branches If there is significant drift that causes the cherry-pick to be non-trivial, consider re-implementing the change from scratch rather than "backporting" Modify the changelog to be in the proper directory Validate that Proto fields have the same numbers as in main Title your pr to start with the major.minor version that you are backporting to (e.g. 1.13 for 1.13.x branch)
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: http.md

This node is used to perform http type tasks such as the common POST and GET request types, and also supports http request validation and other functions. Click `Project Management -> Project Name -> Workflow Definition`, and click the `Create Workflow` button to enter the DAG editing page. Drag the <img src="../../../../img/tasks/icons/http.png" width="15"/> from the toolbar to the drawing board. Please refer to `Default Task Parameters` section for default parameters. | Parameter | Description | |-|| | Request address | HTTP request URL. | | Request type | Supports GET, POST, HEAD, PUT, DELETE. | | Request parameters | Supports Parameter, Body, Headers. | | Verification conditions | Supports default response code, custom response code, content included, content not included. | | Verification content | When the verification condition selects a custom response code, the content contains, and the content does not contain, the verification content is required. | | Custom parameter | It is a user-defined parameter of http part, which will replace the content with `${variable}` in the script. | | Task Parameter | Description | |--|-| | response | VARCHAR, http request return result | Can use `${taskName.response}` to reference task output parameters in downstream tasks. For example, if the current task1 is a http task, the downstream task can use `${task1.response}` to reference the output parameters of task1. HTTP defines the different methods of interacting with the server, the most basic methods are GET, POST, PUT and DELETE. Here we use the http task node to demonstrate the use of POST to send a request to the system's login page to submit data. The main configuration parameters are as follows: URL: Address to access the target resource. Here is the system's login page. HTTP Parameters: userName: Username userPassword: User login password
Project: Gloo (Orchestration & Management / API Gateway)
File: ref.proto.sk.md

title: "ref.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> A way to reference resources across namespaces ```yaml "name": string "namespace": string ``` | Field | Type | Description | | -- | - | -- | | `name` | `string` | | | `namespace` | `string` | | <!-- Start of HubSpot Embed Code --> <script type="text/javascript" id="hs-script-loader" async defer src="//js.hs-scripts.com/5130874.js"></script> <!-- End of HubSpot Embed Code -->
Project: Nomad (Orchestration & Management / Scheduling & Orchestration)
File: golang.md

Nomad is intended to be built with a specific version of the Go toolchain for each release. Generally, each Y release of Nomad (where 0.9.5 means X=0, Y=9, Z=5) will update to the latest version of the Go toolchain available at the time. Nomad Z releases update to the latest Go Z release but do not change Go's Y version. | Nomad Version | Go Version | |:-:|:-:| | 1.2 | 1.17 | | 1.1 | 1.16 | | 1.0 | 1.15 | | 0.12 | 1.14 | | 0.11 | 1.14 | | 0.10 | 1.12 | | 0.9 | 1.11 | The script is used to update the Go version for all build tools. The will note when the Go version has changed in the Improvements section: ``` build: Updated to Go 1.12.13 [GH-6606] ```
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: concurrentqueue.md

There is no official release of this project as of Nov 1, 2017. There is a `v1.0.0-beta` pre-release, but we bundle the SHA at [7b69a8f] since there has been a bunch of bug fixes committed to `master`, including one of our own [420509b].
Project: OpenELB (Orchestration & Management / Service Proxy)
File: CHANGELOG.md

All notable changes to this project will be documented in this file. Fix the name of the program in the image. Change the `deploy/porter.yaml` image name to `kubesphere/porter:v0.4.1` Eip Address Management via CRD. Changes to the BgpConf/BgpPeer API to be compatible with the gobgp API and to support viewing status. Add param to config webhook port. Filter not ready nodes from nexthops. Supports automatic builds using GitHub actions Support layer 2 load-balancing Support loadBalancerIP in Service Support add neighbor dynamically Support config porter via CRD - add portforward for nonstandard bgp port <https://github.com/kubesphere/porterlb/pull/37> add doc about setting up in real router <https://github.com/kubesphere/porterlb/pull/36> more tests new Jenkinsfile <https://github.com/kubesphere/porterlb/pull/29> duplicated externalIPs in `kubectl get svc` <https://github.com/kubesphere/porterlb/pull/27> update docs auto detect main interface instead of using `eth0` <https://github.com/kubesphere/porterlb/pull/23> add e2e test <https://github.com/kubesphere/porterlb/pull/23> fix the reconcile logic which add route without waiting for all endpoints <https://github.com/kubesphere/porterlb/pull/24> Update readme
Project: Service Mesh Interface (SMI) (Orchestration & Management / Service Mesh)
File: GOVERNANCE.md

are responsible for activities around maintaining and updating the SMI specification. Final decisions on the spec reside with the project maintainers. Maintainers MUST remain active. If they are unresponsive for >3 months, they will be automatically removed unless a of the other project maintainers agrees to extend the period to be greater than 3 months. New maintainers can be added to the project by a vote of the existing maintainers. A potential maintainer may be nominated by an existing maintainer. A vote is conducted in private between the current maintainers over the course of a one week voting period. At the end of the week, votes are counted and a pull request is made on the repo adding the new maintainer to the file. A maintainer may step down by submitting an stating their intent. Changes to this governance document require a pull request with approval from a of the current maintainers.
Project: Gloo (Orchestration & Management / API Gateway)
File: gloo_linkerd.md

title: Gloo Edge and Linkerd weight: 3 If you're planning on injecting Linkerd into the Gloo Edge proxy pods, there is some configuration required. Linkerd discovers services based on the `:authority` or `Host` header. This allows Linkerd to understand what service a request is destined for without being dependent on DNS or IPs. Gloo Edge does not rewrite the incoming header (`example.com`) to the internal service name (`example.default.svc.cluster.local`) by default. In this example, when Linkerd receives the outgoing request it thinks the request is destined for `example.com` and not `example.default.svc.cluster.local`. This creates an infinite loop that can be pretty frustrating! Gloo Edge can be configured to automatically or manually modify the `Host` header to satisfy Linkerd's requirement. This uses `books` as an example, take a look at for instructions on how to run it. If you installed Gloo Edge using the Gateway method (`gloo install gateway`), then you'll need a VirtualService to be able to route traffic to your Books application. To use Gloo Edge with Linkerd, you can choose one of two options: As of Gloo Edge v0.13.20, Gloo Edge has native integration with Linkerd, so that the required Linkerd headers are added automatically. Assuming you installed gloo to the default location, you can enable the native integration like so: ```bash kubectl patch settings -n gloo-system default -p '{"spec":{"linkerd":true}}' --type=merge ``` Gloo Edge will now automatically add the `l5d-dst-override` header to every kubernetes upstream. Now simply add a route to the books app upstream: ```bash glooctl add route --path-prefix=/ --dest-name booksapp-webapp-7000 ``` As explained in the beginning of this document, you'll need to instruct Gloo Edge to add a header which will allow Linkerd to identify where to send traffic to. ```yaml apiVersion: gateway.solo.io/v1 kind: VirtualService metadata: creationTimestamp: "2019-04-18T13:39:49Z" generation: 7 name: books namespace: gloo-system resourceVersion: "8418" selfLink: /apis/gateway.solo.io/v1/namespaces/gloo-system/virtualservices/books uid: 6fb092ae-61df-11e9-a158-080027b5157f spec: virtualHost: domains: '*' routes: matchers: prefix: / routeAction: single: upstream: name: booksapp-webapp-7000 namespace: gloo-system options: headerManipulation: requestHeadersToAdd: header: key: l5d-dst-override value: webapp.booksapp.svc.cluster.local:7000 ``` The important stanza here is: ```yaml options: headerManipulation: requestHeadersToAdd: header: key: l5d-dst-override value: webapp.booksapp.svc.cluster.local:7000 ``` Using the content transformation engine built-in in Gloo Edge, you can instruct it to add the needed `l5d-dst-override` header which in the example above is pointing to the service's FDQN and port: `webapp.booksapp.svc.cluster.local:7000`
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.3.0-released.md

title: "Avro 1.3.0" linkTitle: "Avro 1.3.0" date: 2010-02-26 <!-- 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.3.0 has been released!
Project: Kubeflow (Orchestration & Management / Scheduling & Orchestration)
File: tf_serving.md

Authors: lunkai@google.com Status: 2018-07-10 Created is a high-performance serving system for ML models. It provides gRPC for prediction and model service. Starting in TF 1.8, TF Serving also provides a REST . In Kubeflow, we have a TF Serving . The provides an REST api, which is the same as TF Serving's built-in REST api. We initially implemented this because TF Serving only supported gRPC api (until TF 1.8). Going forward, we will still maintain and support this http proxy as it has the ability to provide additional features such as: exporting metrics, . request logging. See Users can choose between TF Serving's built-in http server or this http proxy. We build TF serving images for different TF versions, and for both cpu and gpu. For example, gcr.io/kubeflow-images-public/tensorflow-serving-1.6gpu:v20180604-0da89b8a. Check out gcr.io/kubeflow-images-public registry for other versions. Currently we can get rpc metrics (request count, error count, latencies) if we deploy . See . We are working on surfacing those metrics and other TF Serving specific metrics and integrating with Prometheus. See . Also, there will be liveness and health check. See . To use the TF Serving component, see document . is a platform for serving ML models. It's an open question how we should integrate TF Serving with Seldon to get nice features like routing and model management. : Support logging request and response to enable continuous training and skew detection : Model management feature : Examples showcasing CUJ : Autoscaling : Benchmark to understand performance, like autoscaling. : metrics Issues related to REST api: Improve current http proxy Use the new TF Serving REST api