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

+++ title = "CoreDNS-1.1.3 Release" description = "CoreDNS-1.1.3 Release Notes." tags = ["Release", "1.1.3", "Notes"] release = "1.1.3" date = "2018-05-24T09:43:29+01:00" author = "coredns" +++ We are pleased to announce the of CoreDNS-1.1.3! This release has fixes in the plugins, small core updates and experimental DNS over HTTPs support. We also announce the deprecation of a few things. Experimental DNS-over-HTTPS support was added in the server. Use `https://` as the server's scheme in the configuration. The `-log` flag actually doesn't do anything, so this is a deprecation notice that this flag will be removed in the next release. All in-tree plugins serve metrics with a `server` label. cache and dnssec* drop the capacity metrics add a panic counter: `corednspaniccount_total` supports A and AAAA record under the zone's apex. now handles `continue` in response rewrites. clean ups, esp when shutting it down. adds some optimization. adds option to `ignore` services without ready endpoints. Deprecation notice for the reverse* plugin. Deprecation notice for the `https_google` protocol in proxy*. The following people helped with getting this release done: Ahmet Alp Balkan, Anton Antonov, Cem Trker, Chris O'Haver, darkweaver87, Eugen Kleiner, Francois Tur, John Belamaric, Mario Kleinsasser, Miek Gieben, Ruslan Drozhdzh, Silver, Tobias Schmidt, Yong Tang. For documentation see our (in progress!) . For help and other resources, see our .
Project: Gloo (Orchestration & Management / API Gateway)
File: client_tls_service_annotations.md

title: Setting up Upstream TLS with Service Annotations menuTitle: TLS with Service Annotations weight: 30 description: Set up Gloo Edge to route to TLS-encrypted services using Kubernetes Service object annotations Gloo Edge can auto-discover SSL configuration for using annotations on the Kubernetes Service. This can be used as a convenient alternative to the {{% protobuf display="Upstream" name="gloo.solo.io.Upstream" %}} to configure Upstream or Client SSL. This document explains the options for configuring SSL using service annotations. For a step-by-step guide illustrating Upstream SSL in Gloo Edge, see To use a Kubernetes TLS secret for Upstream TLS, set the annotations of your service like so: {{< highlight yaml "hl_lines=4-5" >}} apiVersion: v1 kind: Service metadata: annotations: gloo.solo.io/sslService.secret: upstream-tls name: example-tls-server namespace: default spec: clusterIP: 10.7.244.103 ports: port: 8080 protocol: TCP targetPort: 8080 selector: app: example-tls-server type: ClusterIP {{< /highlight >}} {{% notice note %}} Note: The secret must live in the same namespace as the service. {{% /notice %}} To certs mounted to the proxy pod (named `gateway-proxy` by default) for Upstream TLS, set the annotations of your service like so: {{< highlight yaml "hl_lines=4-7" >}} apiVersion: v1 kind: Service metadata: annotations: gloo.solo.io/sslService.tlsCert: /tls.crt gloo.solo.io/sslService.tlsKey: /tls.key gloo.solo.io/sslService.rootCa: /ca.crt name: example-tls-server namespace: default spec: clusterIP: 10.7.244.103 ports: port: 8080 protocol: TCP targetPort: 8080 selector: app: example-tls-server type: ClusterIP {{< /highlight >}} {{% notice note %}} Note: The certificates must be mounted to the proxy pod (named `gateway-proxy` by default) with the paths specified in the annotations. {{% /notice %}} A service may have more than one port, where only a specific port is serving SSL. In this case, it's necessary to include the SSL port in the annotation value, like so: {{< highlight yaml "hl_lines=5-8" >}} apiVersion: v1 kind: Service metadata: annotations: gloo.solo.io/sslService.tlsCert: /443:tls.crt gloo.solo.io/sslService.tlsKey: /443:tls.key gloo.solo.io/sslService.rootCa: /443:ca.crt name: web namespace: default spec: clusterIP: 10.7.244.103 ports: port: 80 protocol: TCP targetPort: 80 port: 443 protocol: TCP targetPort: 443 selector: app: web type: ClusterIP {{< /highlight >}} {{% notice note %}} Note: You can also specify `<port>:<secret>` for the `gloo.solo.io/sslService.secret` annotation. {{% /notice %}}
Project: Nacos (Orchestration & Management / Coordination & Service Discovery)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: '' assignees: '' <!-- Here is for bug reports and feature requests ONLY! If you're looking for help, please check our mail listWeChat group and the Gitter room. Please try to use English to describe your issue, or at least provide a snippet of English translation. --> Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: Traefik Mesh (Orchestration & Management / Service Mesh)
File: compatibility.md

title: "Traefik Mesh Compatibility" description: "Traefik Mesh supports, similar to Kubernetes, at least the latest three minor versions of Kubernetes. Read the documentation to learn more." Traefik Mesh supports, , at least the latest three minor versions of Kubernetes, therefore currently: 1.21 1.22 1.23 General functionality cannot be guaranted for versions older than that. However, we expect it to work with Kubernetes down to 1.11 currently. Some of Traefik Mesh's features are only supported on certain Kubernetes versions. Please see the table below. | Features | K8s 1.21 | K8s 1.22 | K8s 1.23 | |--|-|-|-| | General functionality | | | | | Service Topology | | - | - | !!! warning "Service Topology" In Kubernetes `v1.22`, the experimental Service Topology feature was removed. Therefore, starting from Traefik Mesh `v1.4.5`, the support of this feature has been removed. Traefik Mesh is based on the latest version of the SMI specification: | API Group | API Version | |--|-| | access.smi-spec.io | | | specs.smi-spec.io | | | split.smi-spec.io | |
Project: hami (Orchestration & Management / Scheduling & Orchestration)
File: cambricon-mlu-support.md

We now support cambricon.com/mlu by implementing most device-sharing features as nvidia-GPU, including: *MLU sharing*: Each task can allocate a portion of MLU instead of a whole MLU card, thus MLU can be shared among multiple tasks. *Device Memory Control*: MLUs can be allocated with certain device memory size and guarantee it that it does not exceed the boundary. *Device Core Control*: MLUs can be allocated with certain compute cores and guarantee it that it does not exceed the boundary. *MLU Type Specification*: You can specify which type of MLU to use or to avoid for a certain task, by setting "cambricon.com/use-mlutype" or "cambricon.com/nouse-mlutype" annotations. neuware-mlu370-driver > 5.10 cntoolkit > 2.5.3 Install the chart using helm, See 'enabling vGPU support in kubernetes' section Tag MLU node with the following command ``` kubectl label node {mlu-node} mlu=on ``` Get cambricon-device-plugin from your device provider and specify the following parameters during deployment: `mode=dynamic-smlu`, `min-dsmlu-unit=256` These two parameters represent enabling the dynamic smlu function and setting the minimum allocable memory unit to 256 MB, respectively. You can refer to the document from device provider for more details Deploy the cambricon-device-plugin you just specified ``` kubectl apply -f cambricon-device-plugin-daemonset.yaml ``` Cambricon MLUs can now be requested by a container using the `cambricon.com/vmlu` ,`cambricon.com/mlu.smlu.vmemory` and `cambricon.com/mlu.smlu.vcore` resource type: ``` apiVersion: apps/v1 kind: Deployment metadata: name: binpack-1 labels: app: binpack-1 spec: replicas: 1 selector: matchLabels: app: binpack-1 template: metadata: labels: app: binpack-1 spec: containers: name: c-1 image: ubuntu:18.04 command: ["sleep"] args: ["100000"] resources: limits: cambricon.com/vmlu: "1" cambricon.com/mlu.smlu.vmemory: "20" cambricon.com/mlu.smlu.vcore: "10" ``` Mlu-sharing in init container is not supported, pods with "combricon.com/mlumem" in init container will never be scheduled. `cambricon.com/mlu.smlu.vmemory`, `cambricon.com/mlu.smlu.vcore` only work when `cambricon.com/vmlu=1`, otherwise, whole MLUs are allocated when `cambricon.com/vmlu>1` regardless of `cambricon.com/mlu.smlu.vmemory` and `cambricon.com/mlu.smlu.vcore`.
Project: KrakenD (Orchestration & Management / API Gateway)
File: CONTRIBUTING.md

Thank you for your interest in contributing to Lura, there are several ways you can contribute and make this project more awesome, please see below: If you believe you have found an issue with the code please do not hesitate to file an issue in . When filing the issue please describe the problem with the maximum level of detail and the steps to reproduce the problem, including information about your environment. You can also open an issue requesting for help or doing a question and it's also a good way of contributing since other users might be in a similar position. Please note we have a code of conduct, please follow it in all your interactions with the project. When contributing to this repository, it is generally a good idea to discuss the change with the owners before investing a lot of time coding. The process could be: Open an issue explaining the improvment or fix you want to add Code it in your fork Submit a referencing the issue Your work will then be reviewed as soon as possible (suggestions about some changes, improvements or alternatives may be given). Don't forget to add tests, make sure that they all pass! Once the repository is forked, you should track the upstream (original) one using the following command: git remote add upstream https://github.com/luraproject/lura.git Then you should create your own branch: git checkout -b <prefix>/<micro-title>-<issue-number> Once your changes are done (`git commit -am '<descriptive-message>'`), get the upstream changes: git checkout master git pull --rebase origin master git pull --rebase upstream master git checkout <your-branch> git rebase master Finally, publish your changes: git push -f origin <your-branch> You should be now ready to make a pull request.
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.3.3-released.md

title: "Avro 1.3.3" linkTitle: "Avro 1.3.3" date: 2010-07-07 <!-- 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.3 has been released!
Project: KEDA (Orchestration & Management / Scheduling & Orchestration)
File: README.md

This package is a fork of the go-yaml library and is intended solely for consumption by kubernetes projects. In this fork, we plan to support only critical changes required for kubernetes, such as small bug fixes and regressions. Larger, general-purpose feature requests should be made in the upstream go-yaml library, and we will reject such changes in this fork unless we are pulling them from upstream. This fork is based on v2.4.0: https://github.com/go-yaml/yaml/releases/tag/v2.4.0 Introduction The yaml package enables Go programs to comfortably encode and decode YAML values. It was developed within as part of the project, and is based on a pure Go port of the well-known C library to parse and generate YAML data quickly and reliably. Compatibility The yaml package supports most of YAML 1.1 and 1.2, including support for anchors, tags, map merging, etc. Multi-document unmarshalling is not yet implemented, and base-60 floats from YAML 1.1 are purposefully not supported since they're a poor design and are gone in YAML 1.2. Installation and usage The import path for the package is gopkg.in/yaml.v2. To install it, run: go get gopkg.in/yaml.v2 API documentation -- If opened in a browser, the import path itself leads to the API documentation: API stability The package API for yaml v2 will remain stable as described in . License The yaml package is licensed under the Apache License 2.0. Please see the LICENSE file for details. Example ```Go package main import ( "fmt" "log" "gopkg.in/yaml.v2" ) var data = ` a: Easy! b: c: 2 d: [3, 4] ` // Note: struct fields must be public in order for unmarshal to // correctly populate the data. type T struct { A string B struct { RenamedC int `yaml:"c"` D []int `yaml:",flow"` } } func main() { t := T{} err := yaml.Unmarshal([]byte(data), &t) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" t:\n%v\n\n", t) d, err := yaml.Marshal(&t) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" t dump:\n%s\n\n", string(d)) m := make(map[interface{}]interface{}) err = yaml.Unmarshal([]byte(data), &m) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" m:\n%v\n\n", m) d, err = yaml.Marshal(&m) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" m dump:\n%s\n\n", string(d)) } ``` This example will generate the following output: ``` t: {Easy! {2 [3 4]}} t dump: a: Easy! b: c: 2 d: [3, 4] m: map[a:Easy! b:map[c:2 d:[3 4]]] m dump: a: Easy! b: c: 2 d: 3 4 ``` fmt.Printf("err: %v\n", err) return } fmt.Println(string(j2)) /* Output: {"age":30,"name":"John"} */ } ``` mp:\n%s\n\n", string(d)) m := make(map[interface{}]interface{}) err = yaml.Unmarshal([]byte(data), &m) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" m:\n%v\n\n", m) d, err = yaml.Marshal(&m) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" m dump:\n%s\n\n", string(d)) } ``` This example will generate the following output: ``` t: {Easy! {2 [3 4]}} t dump: a: Easy! b: c: 2 d: [3, 4] m: map[a:Easy! b:map[c:2 d:[3 4]]] m dump: a: Easy! b: c: 2 d: 3 4 ```
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: kubernetes.md

K8S task type used to execute a batch task. In this task, the worker submits the task by using a k8s client. Click `Project Management -> Project Name -> Workflow Definition`, and click the `Create Workflow` button to enter the DAG editing page. Drag from the toolbar <img src="../../../../img/tasks/icons/kubernetes.png" width="15"/> to the canvas. Please refer to `Default Task Parameters` section for default parameters. | Parameter | Description | |-|| | Namespace | The namespace for running k8s task. | | Min CPU | Minimum CPU requirement for running k8s task. | | Min Memory | Minimum memory requirement for running k8s task. | | Image | The registry url for image. | | Image Pull Policy | The image pull policy for image. | | Command | The container execution command (yaml-style array), for example: ["printenv"] | | Args | The args of execution command (yaml-style array), for example: ["HOSTNAME", "KUBERNETES_PORT"] | | Custom label | The customized labels for k8s Job. | | Node selector | The label selectors for running k8s pod. Different value in value set should be separated by comma, for example: `value1,value2`. You can refer to https://kubernetes.io/docs/reference/kubernetes-api/common-definitions/node-selector-requirement/ for configuration of different operators. | | Custom parameter | It is a local user-defined parameter for K8S task, these params will pass to container as environment variables. | If you are using the K8S task type in a production environment, the K8S cluster environment is required. Configure the required content according to the parameter descriptions above. Task name contains only lowercase alphanumeric characters or '-'
Project: Kubernetes (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: Traefik Mesh (Orchestration & Management / Service Mesh)
File: submitting-pull-requests.md

title: "Submitting Pull Requests for Traefik Mesh" description: "This documentation article describes the process of submitting a pull request for Traefik Mesh." So you've decided to improve Traefik Mesh? Thank You! Now the last step is to submit your Pull Request in a way that makes sure it gets the attention it deserves. Let's go through the classic pitfalls to make sure everything is right. The title must be short and descriptive. (~60 characters) Follow the as much as possible. Explain the conditions which led you to write this PR: give us context. The context should lead to something, an idea or a problem that youre facing. Remain clear and concise. Take time to polish the format of your message so we'll enjoy reading it and working on it. Help the readers focus on what matters, and help them understand the structure of your message (see the ). Make it small. Each PR should be linked to an issue. One feature per PR. PRs should be standalone (they should not depend on an upcoming PR). Write useful descriptions and titles. Avoid re-formatting code that is not on the path of your PR. Commits should be split properly (in order to guide reviewers through the code). Make sure the . Make sure . Add tests. Address review comments in terms of additional commits (don't amend/squash existing ones unless the PR is trivial).
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-007.md

+++ date = "2017-05-03T19:26:11Z" description = "CoreDNS-007 Release Notes." release = "007" tags = ["Release", "007", "Notes"] title = "CoreDNS-007 Release" author = "coredns" +++ CoreDNS-007 has been ! CoreDNS is a DNS server that chains plugins, where each plugin implements a DNS feature. CoreDNS is accepted as an inception project by the ! Which means a lot to us. See on why we wanted/did this. Because of this we moved repos: <https://github.com/coredns> is the main overarching repo. There is an automatic redirect in place from the old repo. And... We have a new logo! We're also discussion a website redesign for <https://coredns.io> and this blog. Back to the release. `ServeDNS` is extended to take a context. This allows (for instance) tracing to start at an earlier entrypoint. gRPC and TLS are made first class citizens. See [the zone specification](https://github.com/coredns/coredns/blob/master/README.md#zone-specification) on how to use it. TL;DR using `grpc://` makes the server talk gRPC. The `tls` directive is used to specify TLS certificates. Zipkin tracing can be enabled for all plugin. rewrite* now allows you to add or modify EDNS0 local or NSID options. The framework is in place to add additional EDNS0 types in the future. etcd* when no upstreams are defined won't default to using 8.8.8.8, 8.8.4.4; it just does not resolve external names in that case. erratic* now can also delay queries and send queries with Truncated set. metrics* will happily start as many (different) listeners as you want (if you really need that). startup and shutdown* allow for command to be run during startup or shutdown. These directly use the code from Caddy, see . kubernetes* now implements a `fallthrough` option to pass queries that would result in NXDOMAIN to the next plugin, even if the query is in the cluster domain. This enables custom DNS entries in the cluster domain (as long as they do not overlap with a normal Kubernetes record). To facilitate this the plugin ordering is also altered to put kubernetes in the chain before other backends. cache* will no longer cache RRSIGs that will expire while cached. The following people helped with getting this release done: Chris Aniszczyk, Chris O'Haver, Christoph Grn, Dominic, John Belamaric, Jonathan Boulle, Michael, Michael S. Fischer, Miek Gieben, Yong Tang, Yue Ko. If you want to help, please check out one of the and start coding! For documentation and help, see our .
Project: Easegress (Orchestration & Management / API Gateway)
File: README.md

Helm charts for installing Easegress ingress controller on Kubernetes ```shell kubectl create ns ingress-easegress ``` ```shell helm install ingress-easegress -n ingress-easegress ./helm-charts/ingress-controller helm install ingress-easegress -n ingress-easegress ./helm-charts/ingress-controller \ --set service.nodePort=4080 \ --set image.tag=v1.4.0 \ --set ingressClass.name=test-eg \ --set controller.name=test-eg \ --set 'controller.namespaces={ingress-easegress, default}' ``` You can reference for creating Kubernetes Ingress rules. ```shell helm uninstall ingress-easegress -n ingress-easegress ``` The following table lists the configurable parameters of the Ingress Controller Helm installation. | Key | Type | Default | Description | |--|||-| | service.nodePort | int | `30080` | nodePort for Easegress Ingress Controller. | | replicas | int | `1` | number of Easegress Ingress Controllers | | log.path | string | `/opt/easegress/log` | log path inside container | By default, k8s use range 30000-32767 for NodePort. Make sure you choose right port number.
Project: etcd (Orchestration & Management / Coordination & Service Discovery)
File: logging.md

etcd uses the library for logging application output categorized into levels. A log message's level is determined according to these conventions: Debug: Everything is still fine, but even common operations may be logged, and less helpful but more quantity of notices. Usually not used in production. Examples: Send a normal message to a remote peer Write a log entry to disk Info: Normal, working log information, everything is fine, but helpful notices for auditing or common operations. Should rather not be logged more frequently than once per a few seconds in a normal server's operation. Examples: Startup configuration Start to do a snapshot Warning: (Hopefully) Temporary conditions that may cause errors, but may work fine. A replica disappearing (that may reconnect) is a warning. Examples: Failure to send a raft message to a remote peer Failure to receive heartbeat message within the configured election timeout Error: Data has been lost, a request has failed for a bad reason, or a required resource has been lost. Examples: Failure to allocate disk space for WAL Panic: Unrecoverable or unexpected error situation that requires stopping execution. Examples: Failure to create the database Fatal: Unrecoverable or unexpected error situation that requires immediate exit. Mostly used in the test. Examples: Failure to find the data directory Failure to run a test function