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

Found here: https://github.com/Tencent/rapidjson rapidjson has an MIT license but includes a binary that has the JSON license which cannot be included in Apache products: https://www.apache.org/legal/resolved.html#json Therefore we must strip content from the release. Be sure to strip the release in order to comply with the licensing requirements noted above, as well as to lower the size impact on the mesos git repository: ``` $ curl --location https://github.com/Tencent/rapidjson/archive/v1.1.0.tar.gz -o rapidjson-1.1.0.tar.gz $ mkdir tmp $ tar -zxvf rapidjson-1.1.0.tar.gz --directory=tmp $ mkdir rapidjson-1.1.0 $ mv tmp/rapidjson-1.1.0/license.txt rapidjson-1.1.0 $ mv tmp/rapidjson-1.1.0/include rapidjson-1.1.0 $ tar -zcvf rapidjson-1.1.0.tar.gz rapidjson-1.1.0 $ openssl sha -sha256 3rdparty/rapidjson-1.1.0.tar.gz ```
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_cluster_deregister.md

title: "glooctl cluster deregister" weight: 5 Deregister a cluster to the Gloo Federation control plane Deregister a cluster from the Gloo Federation control plane. Deregistered clusters can no longer be targeted for discovery and configuration. This will not delete the cluster or the managing namespace, but it will delete the service account, cluster role, and cluster role binding created on the remote cluster during the cluster registration process. ``` glooctl cluster deregister [flags] ``` ``` --cluster-name string name of the cluster to deregister --federation-namespace string namespace of the Gloo Federation control plane (default "gloo-system") -h, --help help for deregister --remote-context string name of the kubeconfig context to use for deregistration --remote-kubeconfig string path to the kubeconfig from which the deregistered cluster will be accessed --remote-namespace string namespace in the target cluster where artifacts should be deleted (default "gloo-system") ``` ``` -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 --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - Cluster commands
Project: MetalLB (Orchestration & Management / Service Proxy)
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 dave@natulte.net. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and 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 https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: kusk_dashboard.md

Access the kusk dashboard Access the kusk dashboard. kusk dashboard will start a port-forward session on port 8080 to the envoyfleet serving the dashboard and will open the dashboard in the browser. By default this is kusk-gateway-private-envoy-fleet.kusk-system. The flags --envoyfleet.namespace and --envoyfleet.name can be used to change the envoyfleet. ``` kusk dashboard [flags] ``` ``` $ kusk dashboard Opens the kusk gateway dashboard in the browser by exposing the default private envoy fleet on port 8080 $ kusk dashboard --envoyfleet.namespace=other-namespace --envoyfleet.name=other-envoy-fleet Specify other envoyfleet and namespace that is serving the dashboard $ kusk dashboard --external-port=9090 Expose dashboard on port 9090 ``` ``` --envoyfleet.name string kusk gateway dashboard envoy fleet service name (default "kusk-gateway-private-envoy-fleet") --envoyfleet.namespace string kusk gateway dashboard envoy fleet namespace (default "kusk-system") --external-port int external port to access dashboard at (default 8080) -h, --help help for dashboard ``` ``` --config string config file (default is $HOME/.kusk.yaml) ``` -
Project: Contour (Orchestration & Management / Service Proxy)
File: external-names.md

Status: Accepted This document looks to allow Contour to process Kubernetes service types `ExternalName` so that traffic can be proxied to dns hosts rather than only pod endpoints. Allow for Contour to proxy traffic via Envoy to external dns endpoints Utilize built-in Kubernetes object types (i.e. ExternalName service) `externalIPs` will not be used, users who want to proxy to custom IP's should build their own service/endpoint object Utilize a new CRD or ConfigMap style mapping Only support HTTP at the moment, TCP will be addressed in a further design doc Contour currently watches Kubernetes services and endpoints, streaming them to via Envoy xDS CDS & EDS endpoints. Kubernetes pods are identified by their presence in the Endpoint document and streamed to Envoy via EDS. Requests to envoy are routed directly to Kubernetes pods (i.e. endpoints). This proposal looks to add a second way to identify the members of a Envoy clustr object, using a DNS entry to supply the cluster members rather than EDS. Contour will need to watch for and process Kubernetes service types of `ExternalName` (https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.13/#servicespec-v1-core). When configuring a Route, Contour will use the contents of the `spec.externalName` of the service as well as the port from the `spec.ports` section of the Kubernetes service. If ports are not supplied for the Kubernetes service, then the IngressRoute status will be set accordingly with an error message. Allowing for TLS proxying and validation should still be applied as it exists already so users can proxy to a TLS upstream as well as validate the certificate+subject alt name of the upstream service. The `TCPService` struct in `internal/dag/dag.go` will have a new `externalName string` field added. When services are added in `internal/dag/builder.go`, if `svc.Spec.Type == v1.ServiceTypeExternalName` then the value of `svc.Spec.ExternalName` will be set to the TCPService struct's `externalName`. Since the service does not have any Kubernetes Endpoints, we cannot rely on having an EDS cluster to reference from the CDS cluster. For this type of service (i.e. `ExternalName`) when creating the cluster in `internal/envoy/cluster.go`, instead of setting a `EdsClusterConfig`, we'll configure a `LoadAssignment` which should allow us to specify the endpoint defined in `externalName` dynamically. Potentially, we could avoid using a Service of type `ExternalName` by simply just extending the `IngressRoute` CRD as proposed here: https://github.com/projectcontour/contour/issues/825#issue-386869426 The downside to this approach is it couldn't be used with Ingress resources. Potentially someone could use an `ExternalName` service to reference services in another namespace by setting the `externalName` (ex: `other-service.namespace-other.svc.cluster.local`). This scenario exists in a cluster regardless if Contour is deployed or not, other security restrictions should be applied if users want to avoid this from happening.
Project: Kuma (Orchestration & Management / Service Mesh)
File: SECURITY.md

<!-- Synced from kumahq/.github update lifecycle action (and remove this comment) to stop syncing --> We use Github's Security advisories for reporting security vulnerabilities. You can open a private report in the . To learn more about this reporting checkout the . Security vulnerabilities will be disclosed via release notes, issues and Github advisories with severity score higher than will have an advisory published.
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: preempt-action.md

In scheduler there are 4 actions such as `allocate`, `preempt`, `reclaim`, `backfill` and with the help of plugins like `conformance`, `drf`, `gang`, `nodeorder` and more plugins. All these plugins provides behavioural characteristics how scheduler make scheduling decisions. As discussed in Introduction, preempt is one of the actions in kube-batch scheduler. Preempt action comes into play when a high priority task comes and there is no resource requested by that task is available in the cluster, then few of the tasks should be evicted so that new task will get resource to run. In preempt action, multiple plugin function are getting used like TaskOrderFn(Plugin: Priority), JobOrderFn(Plugin: Priority, DRF, Gang), NodeOrderFn(Plugin: NodeOrder), PredicateFn(Plugin: Predicates), PreemptableFn(Plugin: Conformance, Gang, DRF). Compares taskPriority set in PodSpec and returns the decision of comparison between two priorities. Compares jobPriority set in Spec(using PriorityClass) and returns the decision of comparison between two priorities. The job having the lowest share will have higher priority. The job which is not yet ready(i.e. minAvailable number of task is not yet in Bound, Binding, Running, Allocated, Succeeded, Pipelined state) will have high priority. NodeOrderFn returns the score of a particular node for a specific task by running through sets of priorities. PredicateFn returns whether a task can be bounded to a node or not by running through set of predicates. Checks whether a task can be preempted or not, which returns set of tasks that can be preempted so that new task can be deployed. In conformance plugin, it checks whether a task is critical or running in kube-system namespace, so that it can be avoided while computing set of tasks that can be preempted. It checks whether by evicting a task, it affects gang scheduling in kube-batch. It checks whether by evicting particular task, total number of tasks running for a job is going to be less than the minAvailable requirement for gang scheduling requirement. The preemptor can only preempt other tasks only if the share of the preemptor is less than the share of the preemptee after recalculating the resource allocation of the premptor and preemptee.
Project: BFE (Orchestration & Management / Service Proxy)
File: release_regulation.md

BFE development follows git-flow branching model and . BFE development follows , but makes some minor differences for github. For the official bfe repository, developers should follow . 'master' branch is the stable branch. Latest commit of the 'master' branch is unit-tested and regression-tested. 'develop' branch is the development branch. Every commit of the 'develop' branch is unit-tested, but not regression-tested. 'release/vX.Y.Z' branch is the temporary branch created for release. The code on this branch is undergoing regression testing. For the forked bfe repository, developers don't need to strictly abide the git-flow(http://nvie.com/posts/a-successful-git-branching-model/). Each branch of the forked repository is equivalent to feature branch. Specific Suggestions are as follows: Developers synchronize 'develop' branches of the forked repository with that of the official repository. Developers create 'feature' branch from 'develop' branch of the forked repository. After completion of 'feature' branch development, developers submit 'Pull Request' to the official repository for code review. During the review process, developers may continue to modify and submit code in their feature branches. In addition, the 'bugfix' branch is also maintained in the developer's forked repository. Different from the feature branch, developers should submit 'Pull Request' from the 'bugfix' branch to 'master', 'develop' and possibly 'release/vX.Y.Z' branches of the official repository respectively. Follow the following procedures to release a new version: Create a new branch from the 'develop' branch with the name 'release/vX.Y.Z'. For example, `release/v0.10.0` Tag the version of the new branch with 'X.Y.Z-rc.N' (N is patch number). The first tag is'0.10.0-rc.1', the second tag is '0.10.0-rc.2', and so on. For the submission of this version, do the following: Modify version information in 'VERSION' file. Test the functional correctness of the version. If it fails, fixing all the bugs in the 'release/vX.Y.Z' branch, and return to the second step with patch number added by 1. Complete the writing of . Merge the 'release/vX.Y.Z' branch into the master branch, and delete the 'release/vX.Y.Z' branch. Merge 'master' branches into the 'develop' branch. Tag the latest commit of the master branch with 'vX.Y.Z' Note: Once a release branch has been created, it is generally not allowed to merge 'release/vX.Y.Z' from the 'develop' branch. This ensures that the 'release/vX.Y.Z' branch is frozen, making it easy for QA to test. When the 'release/vX.Y.Z' branch exists, merge the 'bugfix' branch into the 'master', 'develop' and 'release/vX.Y.Z' branches at the same time, if there are bugfix behaviors.
Project: kcp (Orchestration & Management / Scheduling & Orchestration)
File: inspecting-e2e-metrics.md

description: > Inspecting Prometheus metrics of e2e runs. kcp internally exposes the same metrics as kube api-server. These are being gathered during e2e runs if the `PROMETHEUS_URL` variable is set. Here, any e2e spawned kcp server will publish a scraping configuration to prometheus for the given Prometheus URL environment variable. For e2e tests, the above environment variable is respected by the following test servers: when a shared kcp server is spawned using `SharedKcpServer` or `PrivateKcpServer` in the `kcp.test.e2e.framework` package. `cmd/sharded-test-server` `cmd/test-server/kcp` To inspect metrics from GitHub e2e test runs, download the metrics from the GitHub summary page: And execute Prometheus locally to inspect metrics: ```shell $ mkdir -p metrics && unzip -p e2e-sharded-metrics.zip | tar xvzf - -C metrics $ prometheus --storage.tsdb.path=metrics --config.file /dev/null ``` To inspect e2e metrics from prow runs, just copy-paste the prow link from the pull request: And paste it into : Once the Prometheus pod is ready, the provisioned link can be called to inspect gathered metrics. Alternatively, download the prometheus tarball from the gcsweb frontend locally and start a Prometheus instance as described above. To collect metrics locally, a convenience script is available to download and execute a Prometheus instance. Calling `... ./hack/run-in-prometheus make ...` will download, start, collect metrics, and stop Prometheus during the test run. Example: ```shell $ WHAT=./test/e2e/virtual/apiexport TEST_ARGS="-v -run TestAPIExportAuthorizers" ./hack/run-with-prometheus.sh make test-e2e ``` A local Prometheus can then be started to inspect gathered metrics: ```shell $ ./hack/tools/prometheus --storage.tsdb.path=.prometheus_data --config.file /dev/null ```
Project: Fluid (Orchestration & Management / Scheduling & Orchestration)
File: license.md

MIT License Copyright (c) 2022 Smarty Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. NOTE: Various optional and subordinate components carry their own licensing requirements and restrictions. Use of those components is subject to the terms and conditions outlined the respective license of each component.
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.5.0-released.md

title: "Avro 1.5.0" linkTitle: "Avro 1.5.0" date: 2011-03-11 <!-- 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.5.0 has been released!
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.6.5.md

+++ title = "CoreDNS-1.6.5 Release" description = "CoreDNS-1.6.5 Release Notes." tags = ["Release", "1.6.5", "Notes"] release = "1.6.5" date = 2019-11-06T10:00:00+00:00 author = "coredns" +++ The CoreDNS team has released . A fairly small release that polishes various plugins and fixes a bunch of bugs. A new plugin that encapsulates the zone transfer knowledge and code in one place. This makes it easier to add this functionality to new plugins. Plugins that already implement zone transfers are expected to move to it in the 1.7.0 release. don't block on returning sockets; instead timeout and drop the socket on the floor, this makes each go-routine guarantee to exit. adds metrics to measure kubernetes control plane latency, see documentation for details. fixes a panic when comparing domains names. Chris O'Haver, Erfan Besharat, Hauke Lffler, Ingo Gottwald, janluk, Miek Gieben, Uladzimir Trehubenka, Yong Tang, yuxiaobo96. core: Make request.Request smaller (https://github.com/coredns/coredns/pull/3351) pkg/log: Add Clear to stop debug logging (https://github.com/coredns/coredns/pull/3372) plugin/cache: move goroutine closure to separate function to save memory (https://github.com/coredns/coredns/pull/3353) plugin/clouddns: remove initialization from init (https://github.com/coredns/coredns/pull/3349) plugin/erratic: doc and zone transfer (https://github.com/coredns/coredns/pull/3340) plugin/file: fix panic in miekg/dns.CompareDomainName() (https://github.com/coredns/coredns/pull/3337) plugin/forward: make Yield not block (https://github.com/coredns/coredns/pull/3336) plugin/forward: Move map to array (https://github.com/coredns/coredns/pull/3339) plugin/kubernetes: Measure and expose DNS programming latency from Kubernetes plugin. (https://github.com/coredns/coredns/pull/3171) plugin/route53: Remove amazon initialization from init (https://github.com/coredns/coredns/pull/3348) plugin/transfer: Zone transfer plugin (https://github.com/coredns/coredns/pull/3223) plugins: Add MustNormalize (https://github.com/coredns/coredns/pull/3385)