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

+++ date = "2017-02-22T21:26:11Z" description = "CoreDNS-006 Release Notes." tags = ["Release", "006", "Notes"] release = "006" title = "CoreDNS-006 Release" author = "coredns" +++ CoreDNS-006 has been ! CoreDNS is a DNS server that chains plugins, where each plugin implements a DNS feature. Move CoreDNS to <https://github.com/coredns/coredns> together with several other repos. This will be the new home for CoreDNS development. Fixed: Fix hot-reloading. This would fail with `[ERROR] SIGUSR1: listen tcp :53: bind: address already in use`. Allow removal of core plugin, see comments in . reverse* plugin: allows CoreDNS to respond dynamically to an PTR request and the related A/AAAA request. proxy* a new `protocol`: `grpc`: speak DNS over gRPC. Server side impl. resides [in this out of tree plugin](https://github.com/coredns/grpc). file* additional section processing for MX and SRV queries. prometheus* fix hot reloading trace* various improvements The following people helped with getting this release done: John Belamaric, Miek Gieben, Richard Hillmann, Yong Tang, If you want to help, please check out one of the and start coding! For documentation and help, see our .
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: README.md

When adapting to K8S V1.25, Volcano introduces the volumebinding package from K8S for self-maintenance. It is expected that the current package will be deleted from Volcano when adapting to K8S V1.29. Volcano encounters forward compatibility issues when adapting to K8S V1.25. Volcano can run properly in K8S V1.25, but cannot run in earlier K8S versions (for example, v1.23, v1.21). The error information is `reflector.go:424] k8s.io/client-go/informers/factory.go:134: failed to list *v1.CSIStorageCapacity: the server could not find the requested resource`. The `volumeBinder.csiStorageCapacityLister` in the `k8s.io/kubernetes/pkg/scheduler/framework/plugins/volumebinding` package uses the `k8s.io/client-go/listers/storage/v1beta1` interface in V1.23, and is updated to the `k8s.io/client-go/listers/storage/v1` interface in V1.25. (csiStorageCapacity is officially released v1 in v1.24) In addition, the EnableCSIStorageCapacity feature switch is removed. The volumeBinder structure is statically defined. If the external plug-in imports the volumebinding package and uses the volumeBinder structure, forward compatibility issues may occur, for example, `v1.CSIStorageCapacity` is not defined. Volcano references the volumebinding package of the K8S during scheduling for PVC binding. Therefore, after the K8S V1.25 is upgraded, the V1.23 and V1.21 versions cannot run properly. The `k8s.io/kubernetes/pkg/scheduler/framework/plugins/volumebinding` package is introduced to Volcano for self-maintenance. The `volumeBinder.csiStorageCapacityLister` version is changed back to `k8s.io/client-go/listers/storage/v1beta1` to implement compatibility processing of K8S v1.25, v1.23, and v1.21. Solution 1: After the Volcano adapts to K8S V1.27, the `volumeBinder.csiStorageCapacityLister` interface version is upgraded from V1beta1 to V1, the self-maintained volumebinding package is deleted, and the volumebinding package in K8S is referenced again. After the upgrade, however, Only K8S V1.27 and V1.25 are compatible. Earlier versions, such as V1.23, are not compatible. Solution 2: Add an abstract layer to volumeBinder in the volumebinding package and change the static version dependency to dynamic definition to ensure compatibility between v1beta1 and v1 interfaces.
Project: Katalyst (Orchestration & Management / Scheduling & Orchestration)
File: wip-20220615-sys-advisor.md

title: Katalyst Reporter Manager authors: "sun-yuliang" reviewers: "waynepeking348" "csfldf" "Aiden-cn" "pendoragon" creation-date: 2022-06-15 last-updated: 2023-02-23 status: provisional SysAdvisor is the core node-level resource recommendation module, and it uses statistical-based, indicator-based, and ml-based algorithms for different scenarios. The detailed proposal contents for Katalyst SysAdvisor is ongoing and will be released in the next quarter. <!-- toc --> - - - - <!-- /toc -->
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: CONTRIBUTING_STEPS.md

Note: This document is not meant for Google employees. To contribute to the gRPC codebase, you need the following: An [Knowledge of how to fork a repository, clone a repository, merge, rebase, resolve, push, pull, fetch etc.](https://docs.github.com/en/get-started/using-git/about-git) Knowledge of the language being used, which can be C++, Python, Ruby, Objective-C, PHP, or C#. The GitHub repository for the C-based gRPC (C++, Python, Ruby, Objective-C, PHP, C#) is at https://github.com/grpc/grpc. If you want to contribute to the gRPC code base, you need to make a fork of the repository. Create your from https://github.com/grpc/grpc. on your local machine. In your cloned repository, create a new branch from `master`. Then prepare a commit for the files that you want to contribute. Commit to this branch. Push the commit to your fork on GitHub. Take care that your commits are aligned with these . After pushing your commit, visit https://github.com/grpc/grpc . If the forking, branch creation, commit and push have been successful, you will see the following message: Take care to allow edits by maintainers. If there is a specific issue with your pull request, the maintainer can help if needed. This access to help will reduce the turnaround time for your submission. Create a pull request. Once the pull request is ready, you must wait for a reviewer to be assigned to your pull request. If you see Not Covered in the EasyCLA screen, as shown in the following image, click on the mentioned link to start the authorization process. You will see a series of screens: Select *Authorize LF-Engineering: Select your contributor type: Select SIGN CLA: Some time after you've digitally signed the document, the EasyCLA will appear as Covered. After a few hours, you will notice a new "assignee" assigned to the pull request. After a reviewer is assigned to you, they will help with the next steps, which are as follows: You complete the code review and address the comments. Your reviewer may add a few labels as needed. Once you have approval from the reviewer, check if the tests are running. After the tests are complete, look at the status of all the tests. If everything is green, everything is good. But usually some failures exist. If there are failures, select each failure. The selection will take you to a page that has error details. Try to fix the issue. For pull requests that are non-trivial, there is a thorough code review process. You can read more about the process and requirements . After you fix the code review, you will finally get an approval. After getting approval, you can submit the pull request. You cannot do submission or merge of a pull request through Github. After you have approval from a reviewer, a Google employee will trigger the submission process. When the submission happens: A commit with your changes, along with a few additional formatting changes, will be committed to the `grpc/master` branch. The pull request you originally created will be closed.
Project: Service Mesh Interface (SMI) (Orchestration & Management / Service Mesh)
File: README.md

Summer of Code ===================== Organization Admins If you need help with anything Summer of code related, you can file an issue or contact one of the admins below: Michelle Noorali (\): Thomas Rampelberg (\): Communication Please reach out to us on the in the #general channel. Project Ideas Istio Adapter Description: Converting from the SMI APIs to Istio specific configuration is a critical part of supporting every service mesh that has been released. There has been some work done on this already, but more needs to be done. The work involves setting up CI, writing end to end tests, updating the adapter and APIs to work with the latest version of Istio and documenting the contribution process for the project. Recommended Skills: Golang, Kubernetes Mentor(s): Michelle Noorali (@michellenoorali) Issues: , , Consul Connect Metrics Description: The metrics for SMI are implemented in a [single project](https://github.com/deislabs/smi-metrics). Currently, support for Linkerd and Istio has been implemented. This project will be to implement support for Consul Connect. The work will include implementing the adapter, building a helm chart to distribute and writing tests to validate the functionality. Recommended Skills: Golang Mentor(s): Tarun Pothulapati (@tarunpothulapati), Nic Jackson (@sheriffjackson) Issues: HPA Support -- Description: It is valuable to scale workloads on metrics other than cpu/memory. To do this today, you must use the custom metrics API and the prometheus adapter. With the SMI metrics API it should be possible to get HPA working with that API. This project should integrate HPA and SMI metrics to allow for scaling on rps as well as latency. The work includes demonstrating how to do this, documenting it, adding as an end to end test and producing a demo tha shows off to end users how it all works. Recommended Skills: Golang, Kubernetes Mentor(s): Thomas Rampelberg (@grampelberg) Issues: Conformance Tool -- Description: Ensure that a service mesh is properly configured and that its behavior conforms to official SMI specifications. Conformance consists of both capabilities and compliance status as outlined in the design specification. Use Meshery as the underlying technology to support SMI validation. Recommended Skills: Golang, Kubernetes Mentor(s): Lee Calcote (@lcalcote), Sagar Utekar (@named_uttu) Issues: Design Spec:
Project: Hango (Orchestration & Management / API Gateway)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, 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 within all project spaces, and it also applies when an individual is representing the project or its community in public spaces. 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 [INSERT EMAIL ADDRESS]. 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 For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq
Project: Pipy (Orchestration & Management / Service Proxy)
File: quic-statm.md

QUIC Statistics Manager ======================= The statistics manager keeps track of RTT statistics for use by the QUIC implementation. It provides the following interface: Instantiation The QUIC statistics manager is instantiated as follows: ```c typedef struct osslstatmst { ... } OSSL_STATM; int osslstatminit(OSSL_STATM *statm); void osslstatmdestroy(OSSL_STATM *statm); ``` The structure is defined in headers, so it may be initialised without needing its own memory allocation. However, other code should not examine the fields of `OSSL_STATM` directly. Get RTT Info The current RTT info is retrieved using the function `osslstatmgetrttinfo`, which fills an `OSSLRTTINFO` structure: ```c typedef struct osslrttinfo_st { / As defined in RFC 9002. / OSSLTIME smoothedrtt, latestrtt, rttvariance, min_rtt, maxackdelay; } OSSLRTTINFO; void osslstatmgetrttinfo(OSSLSTATM *statm, OSSLRTTINFO *rttinfo); ``` Update RTT New RTT samples are provided using the `osslstatmupdate_rtt` function: `ack_delay`. This is the ACK Delay value; see RFC 9000. `overridelatestrtt` provides a new latest RTT sample. If it is `OSSLTIMEZERO`, the existing Latest RTT value is used when updating the RTT. The maximum ACK delay configured using `osslstatmsetmaxack_delay` is not enforced automatically on the `ack_delay` argument as the circumstances where this should be enforced are context sensitive. It is the caller's responsibility to retrieve the value and enforce the maximum ACK delay if appropriate. ```c void osslstatmupdatertt(OSSLSTATM *statm, OSSLTIME ackdelay, OSSLTIME overridelatest_rtt); ``` Set Max. Ack Delay Sets the maximum ACK delay field reported by `OSSLRTTINFO`. ```c void osslstatmsetmaxackdelay(OSSLSTATM *statm, OSSLTIME maxack_delay); ```
Project: Open Service Mesh (Orchestration & Management / Service Mesh)
File: bug_report.md

name: Bug report about: Report a bug encountered while operating OSM title: '' labels: bug assignees: '' <!-- This issue tracker is a best-effort forum for users and customers to report bugs. Be sure to not include any sensitive information. Sensitive information should NOT be included in this issue. --> Bug description: Affected area (please mark with X where applicable): Install [ ] SMI Traffic Access Policy [ ] SMI Traffic Specs Policy [ ] SMI Traffic Split Policy [ ] Permissive Traffic Policy [ ] Ingress [ ] Egress [ ] Envoy Control Plane [ ] CLI Tool [ ] Metrics [ ] Certificate Management [ ] Sidecar Injection [ ] Logging [ ] Debugging [ ] Tests [ ] Demo [ ] CI System [ ] Expected behavior: Steps to reproduce the bug (as precisely as possible): How was OSM installed?: Anything else we need to know?: Bug report archive: <!-- Generate and upload bug report archive for the given app namespaces, deployments, and pods. Use `osm support bug-report --app-namespaces <ns1>,<ns2> --app-deployments <ns1>/<dep1>,<ns2>/<dep2> --app-pods <ns1>/<pod1>` --> Environment: OSM version (use `osm version`): Kubernetes version (use `kubectl version`): Size of cluster (number of worker nodes in the cluster): Others:
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_get_ratelimitconfig.md

title: "glooctl get ratelimitconfig" weight: 5 read a ratelimitconfig or list ratelimitconfigs in a namespace usage: glooctl get ratelimitconfig [NAME] [--namespace=namespace] [-o FORMAT] ``` glooctl get ratelimitconfig [flags] ``` ``` -h, --help help for ratelimitconfig ``` ``` -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") -o, --output OutputType output format: (yaml, json, table, kube-yaml, wide) (default table) --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - Display one or a list of Gloo resources
Project: Serverless Devs (Orchestration & Management / Scheduling & Orchestration)
File: extend.md

title: Yaml inheritance description: 'Yaml inheritance' position: 9 category: 'Overview' Through the keyword `extend`, the problem of multiple Yaml configuration redundancy is solved. For example, when using Serverless Devs to deploy a application, the pre-release environment and the official environment will be except for is inconsistent. Other configurations are exactly the same. Yaml configuration is as follows ``` code s.yaml s.prod.yaml s.pre.yaml ``` ``` edition: 1.0.0 access: "default" services: fc-deploy-test: component: fc props: region: cn-hangzhou service: name: fc-service nasConfig: Auto description: "Serverless Devs Service" function: name: hello-function description: "Serverless Devs Function" codeUri: "./" runtime: nodejs12 timeout: 60 ``` ``` extend: s.yaml services: fc-deploy-test: props: service: name: fc-service-pre tracingConfig: Disable ``` ``` extend: s.yaml services: fc-deploy-test: props: service: name: fc-service-pro tracingConfig: Enable ``` Displays the declaration `extend` keyword, to gain the ability to inherit By specifying the yaml configuration `s deploy -t s.pro.yaml` takes effect ``` edition: 1.0.0 access: "default" services: fc-deploy-test: component: fc props: region: cn-hangzhou service: name: fc-service-pro tracingConfig: Enable nasConfig: Auto description: "Serverless Devs Service" function: name: hello-function description: "Serverless Devs Function" codeUri: "./" runtime: nodejs12 timeout: 60 ``` Configuration merging uses the module for deep copying. However, considering that the configuration level of `yaml` is relatively deep, such as the above [example] (#/typical scenario), we need to override the `service name` in the pre-release environment, which needs to be written strictly according to the hierarchical relationship, which is relatively cumbersome. ``` services: fc-deploy-test: props: service: name: fc-service-pro tracingConfig: Enable ``` When data is merged, it is directly overwritten, not merged ``` const a = { arr: [1, 2], }; const b = { arr: [3], }; extend(true, a, b); // => { arr: [ 3 ] } ``` Yaml inheritance is generally used for environment division. For example, the pre-release environment is `s.pre.yaml`, and the online environment is `s.pro.yaml`. When deploying, specify the corresponding deployment template `s deploy -t s.pro.yaml` `Configuration. Below are some common environment variable values and their corresponding descriptions. | Key | Describe | | | | | local | local development environment | | dev/daily/development | daily development environment | | pre/prepub | pre-production environment | | prod/production | Production Environment | | test/unittest | unit test environment |
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_create_upstreamgroup.md

title: "glooctl create upstreamgroup" weight: 5 Create an Upstream Group Upstream groups represent groups of upstreams. An UpstreamGroup addresses an issue of how do you have multiple routes or virtual services referencing the same multiple weighted destinations where you want to change the weighting consistently for all calling routes. This is a common need for Canary deployments where you want all calling routes to forward traffic consistently across the two service versions. ``` glooctl create upstreamgroup [flags] ``` ``` -h, --help help for upstreamgroup --weighted-upstreams strings comma-separated list of weighted upstream key=value entries (namespace.upstreamName=weight) ``` ``` -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 --dry-run print kubernetes-formatted yaml rather than creating or updating a resource -i, --interactive use interactive mode --kube-context string kube context to use when interacting with kubernetes --kubeconfig string kubeconfig to use, if not standard one --name string name of the resource to read or write -n, --namespace string namespace for reading or writing resources (default "gloo-system") -o, --output OutputType output format: (yaml, json, table, kube-yaml, wide) (default table) --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - Create a Gloo resource
Project: kratos (Orchestration & Management / Remote Procedure Call)
File: ROADMAP.md

This document defines the roadmap for Kratos development. [x] Config [x] Local Files [x] K8s ConfigMap [x] Consul [x] Etcd [x] Nacos [x] Registry [x] Consul [x] Etcd [x] K8s [x] Nacos [x] Encoding [x] JSON [x] Protobuf [x] Transport [x] HTTP [x] gRPC [x] Middleware [x] Logging [x] metrics [x] recovery [x] gRPC status [x] transport tracing [x] Validator [x] Authentication [x] Ratelimit [x] CircuitBreaker [x] Metrics [x] Prometheus [x] DataDog [x] Tracing [x] HTTP [x] TLS [x] Client [x] Service Registrar [ ] javascript/typescript clients [x] gRPC [x] TLS [x] Uarry Handler [x] Streaming Handler [ ] Cache [ ] go-redis [x] Event [x] Pub/Sub [x] Kafka [ ] Nats [x] Database [x] Ent [ ] Gorm [ ] Kratos API [ ] Auth [ ] Config [ ] Registry [ ] Events [ ] Kratos Runtime [ ] Secrets [ ] Service-to-Service [ ] Publish and Subscribe [ ] Observability [ ] Controllable [ ] Kratos UI [ ] Auth [ ] Config [ ] Services [ ] Endpoints [ ] Ratelimit [ ] CircuitBreaker [ ] FaultInjection [ ] TrafficPolicy [x] Kratos [x] HTTP Generator [ ] API YAML [x] Errors Generator