cwielenb/CNCF-Dataset huggingface dataset:
Project: Apache bRPC (Orchestration & Management / Remote Procedure Call)
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 dev@brpc.apache.org. The project team will review and investigate all complaints, and will respond in a way that it deems 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
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.7.6-released.md

title: "Avro 1.7.6" linkTitle: "Avro 1.7.6" date: 2014-01-22 <!-- 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.7.6 has been released!
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: clusterpropagationpolicy_test.md

| Test Case | E2E Describe Text | Comments | |-|-|| | Test the propagation policy for CRD | crd propagation testing | | | Test the propagation policy for clusterRole | clusterRole propagation testing | | | Test the propagation policy for clusterRoleBinding | clusterRoleBinding propagation testing | | | Test Case | E2E Describe Text | Comments | |-||--| | Test add resourceSelector of the propagation policy for the deployment | add resourceSelectors item(namespace scope) | | | Test update resourceSelector of the propagation policy for the deployment | update resourceSelectors item(namespace scope) | | | Test add resourceSelector of the propagation policy for the clusterRole | add resourceSelectors item(cluster scope) | | | Test update resourceSelector of the propagation policy for the clusterRole | update resourceSelectors item(cluster scope) | | | Test update propagateDeps of the propagation policy for deployment | update policy propagateDeps(namespace scope) | | | Test update placement of the propagation policy for deployment | update policy placement(namespace scope) | | | Test update placement of the propagation policy for clusterRole | update policy placement(cluster scope) | | | Test Case | E2E Describe Text | Comments | |-|-|| | Test the high explicit/low priority/implicit priority propagation for deployment | high explicit/low priority/implicit priority ClusterPropagationPolicy propagation testing | | | Test the same explicit priority propagation for deployment | same explicit priority ClusterPropagationPolicy propagation testing | | | Test Case | E2E Describe Text | Comments | |--|--|| | Test delete clusterpropagationpolicy for deployment | delete ClusterPropagationPolicy and check whether labels and annotations are deleted correctly(namespace scope) | | | Test delete clusterpropagationpolicy for CRD | delete ClusterPropagationPolicy and check whether labels and annotations are deleted correctly(cluster scope) | | May need add the test case when the . May need add the test case for the same implicit priority propagation. May need add the test case for delete the clusterPropagationPolicy.
Project: etcd (Orchestration & Management / Coordination & Service Discovery)
File: roadmap.md

etcd uses GitHub milestones to track all tasks in each major or minor release. The `roadmap.md` file only records the most important tasks for each release. The list is based on the current maintainer capacity that may shift over time. Proposed milestones are what we think we can deliver with the people we have. If we have more support on the important stuff, we could pick up more items from the backlog. Note that etcd will continue to mainly focus on technical debt over the next few major or minor releases. Each item has an assigned priority. Refer to . For a full list of tasks in `v3.6.0`, please see . | Title | Priority | Status | Note | |--|-|-|--| | | priority/important-soon | In progress | etcd will support downgrade starting from 3.6.0. But it will also support offline downgrade from 3.5 to 3.4. | | | priority/important-soon | In progress | This task will be covered in both 3.6 and 3.7. | | | priority/important-soon | Not started | etcd 3.6.0 will depends on raft 3.6.0 | | | priority/important-soon | Not started | etcd 3.6.0 will depends on bbolt 1.4.0 | | | priority/important-longterm | In progress | It provides clearer APIs, and can also work around the stalled writes issue | | | priority/important-longterm | Completed | It isn't guaranteed to be resolved in 3.6, and might be postponed to 3.7 depending on the effort and risk. | | | priority/important-longterm | Completed | It isn't guaranteed to be resolved in 3.6, and might be postponed to 3.7 depending on the effort and risk. | | | priority/important-longterm | Completed | It's important to diagnose bbolt issues | | | priority/important-longterm | Completed | Surgery commands are important for fixing corrupted db files | | | priority/backlog | Not started | This task will be covered in both 3.6 and 3.7. | For a full list of tasks in `v3.7.0`, please see . | Title | Priority | Note | |-|-|--| | | P0 | Finish the remaining tasks 3.7. | | | P1 | to be investigated & discussed | | | P1 | It should improve the performance | | | P2 | It may get rid of etcd's defragmentation. Both bbolt and etcd need to be changed. | | | P2 | Finish the remaining tasks 3.7. | | Title | Priority | Note | |-|-|| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Project: Dubbo (Orchestration & Management / Remote Procedure Call)
File: SECURITY.md

Below is a table that shows versions that we accept security fixes. | Version | Supported | || | | 3.3.x | :whitecheckmark: | | 3.2.x | :whitecheckmark: | | 3.1.x | :whitecheckmark: | | 3.0.x | :x: | | 2.7.x | :x: | | 2.6.x | :x: | | 2.5.x | :x: | The Apache Software Foundation takes a rigorous standpoint in annihilating the security issues in its software projects. Apache Dubbo is highly sensitive and forthcoming to issues pertaining to its features and functionality. If you have apprehensions regarding Dubbo's security or you discover vulnerability or potential threat, dont hesitate to get in touch with the Apache Dubbo Security Team by dropping a mail at security@dubbo.apache.org. In the email, specify the description of the issue or potential threat. You are also urged to recommend the way to reproduce and replicate the issue. The Dubbo 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. An overview of the vulnerability handling process is: The reporter reports the vulnerability privately to Apache. The appropriate project's security team works privately with the reporter to resolve the vulnerability. A new release of the Apache product concerned is made that includes the fix. The vulnerability is publicly announced. A more detailed description of the process can be found .
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.23.6.md

We are delighted to present version v1.23.6 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. Update to Envoy v1.24.10. See the for more information about the content of the release including details on the addressed CVEs. Update to Go v1.19.11. See the for more information. For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.23.6 is tested against Kubernetes 1.23 through 1.25. If you're using Contour and want to add your organization to our adopters list, please visit this . If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this .
Project: Flomesh Service Mesh (FSM) (Orchestration & Management / Service Mesh)
File: wasm.md

FSM includes a to Envoy. It extends Envoy's statistics to enable and is built using the . Building the WASM module requires only Docker as a pre-requisite and is invoked as part of `make docker-build-fsm-controller`. Each proxy is configured by xDS to add HTTP headers prefixed with `fsm-` with the metadata required for the to each request and response, like workload name, namespace, etc. Because of the , response headers to add are configured by the router filter via RDS while request headers to add are configured via a Lua extension so that both sets of headers are made available to the WASM extension. Each proxy only knows about its own metadata, so metadata about the downstream proxy is read from request headers while metadata about the upstream proxy is read from response headers. Request durations represent the time between when stream context is created and ended/reset on the downstream proxy.
Project: hami (Orchestration & Management / Scheduling & Orchestration)
File: hygon-dcu-support.md

We now support hygon.com/dcu by implementing most device-sharing features as nvidia-GPU, including: *DCU sharing*: Each task can allocate a portion of DCU instead of a whole DCU card, thus DCU can be shared among multiple tasks. *Device Memory Control*: DCUs can be allocated with certain device memory size on certain type(i.e Z100) and have made it that it does not exceed the boundary. *Device compute core limitation*: DCUs can be allocated with certain percentage of device core(i.e hygon.com/dcucores:60 indicate this container uses 60% compute cores of this device) *DCU Type Specification*: You can specify which type of DCU to use or to avoid for a certain task, by setting "hygon.com/use-dcutype" or "hygon.com/nouse-dcutype" annotations. dtk driver with virtualization enabled(i.e dtk-22.10.1-vdcu), try the following command to see if your driver has virtualization ability ``` hdmcli -show-device-info ``` If this command can't be found, then you should contact your device provider to aquire a vdcu version of dtk driver. The absolute path of dtk driver on each dcu node must be the same(i.e placed in /root/dtk-driver) Install the chart using helm, See 'enabling vGPU support in kubernetes' section , please be note that, you should set your dtk driver directory using --set devicePlugin.hygondriver={your dtk driver path on each nodes}, for example: ``` helm install vgpu vgpu-charts/vgpu --set devicePlugin.hygondriver="/root/dcu-driver/dtk-22.10.1-vdcu" --set scheduler.kubeScheduler.imageTag={your k8s server version} -n kube-system ``` Tag DCU node with the following command ``` kubectl label node {dcu-node} dcu=on ``` Hygon DCUs can now be requested by a container using the `hygon.com/dcunum` , `hygon.com/dcumem` and `hygon.com/dcucores` resource type: ``` apiVersion: v1 kind: Pod metadata: name: alexnet-tf-gpu-pod-mem labels: purpose: demo-tf-amdgpu spec: containers: name: alexnet-tf-gpu-container image: pytorch:resnet50 workingDir: /root command: ["sleep","infinity"] resources: limits: hygon.com/dcunum: 1 # requesting a GPU hygon.com/dcumem: 2000 # each dcu require 2000 MiB device memory hygon.com/dcucores: 60 # each dcu use 60% of total compute cores ``` You need to enable vDCU inside container in order to use it. ``` source /opt/hygondriver/env.sh ``` check if you have successfully enabled vDCU by using following command ``` hdmcli -show-device-info ``` If you have an output like this, then you have successfully enabled vDCU inside container. ``` Device 0: Actual Device: 0 Compute units: 60 Global memory: 2097152000 bytes ``` Launch your DCU tasks like you usually do DCU-sharing in init container is not supported, pods with "hygon.com/dcumem" in init container will never be scheduled. Only one vdcu can be aquired per container. If you want to mount multiple dcu devices, then you shouldn't set `hygon.com/dcumem` or `hygon.com/dcucores`
Project: Emissary-Ingress (Orchestration & Management / API Gateway)
File: OWNERS.md

This page lists all active maintainers. This can be used for routing PRs, questions, etc. to the right place. Kuat Yessenov () (kuat@google.com) Yangmin Zhu () (ymzhu@google.com) Snow Pettersen () (snowp@lyft.com) Alec Holmes () (alec.holmes@greymatter.io) James Peach () (jpeach@apache.org) Sunjay Bhatia ()(sunjayb@vmware.com) Valerian Roche ()(valerian.roche@datadoghq.com) Ryan Northey () (ryan@synca.io)
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: MAINTAINERS.md

This page lists all active maintainers of this repository. If you were a maintainer and would like to add your name to the Emeritus list, please send us a PR. See for governance guidelines and how to become a maintainer. See for general contribution guidelines. <!-- go/keep-sorted start case=no --> , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Skyscanner Ltd , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC <!-- go/keep-sorted end --> <!-- go/keep-sorted start case=no --> , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Linux Foundation , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Dropbox, Inc. , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , LinkedIn , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC <!-- go/keep-sorted end -->
Project: 3Scale (Orchestration & Management / API Gateway)
File: prometheus-metrics.md

| Metric | Description | Type | Labels | Policy | |||--|-|--| | apicast_status | Number of response status send by APIcast to client | counter | status | Default | | nginxhttpconnections | Number of HTTP connections | gauge | state(accepted,active,handled,reading,total,waiting,writing) | Default | | nginxerrorlog | APIcast errors | counter | level(debug,info,notice,warn,error,crit,alert,emerg) | Default | | openrestyshdictcapacity | Capacity of the dictionaries shared between workers | gauge | dict(one for every dictionary) | Default | | openrestyshdictfree_space | Free space of the dictionaries shared between workers | gauge | dict(one for every dictionary) | Default | | nginxmetricerrors_total | Number of errors of the Lua library that manages the metrics | counter | - | Default | | totalresponsetimeseconds | Time needed to sent a response to the client (in seconds) | histogram | serviceid, servicesystemname | Default | | upstreamresponsetimeseconds | Response times from upstream servers (in seconds) | histogram | serviceid, servicesystemname | Default | | upstreamstatus | HTTP status from upstream servers | counter | status, serviceid, servicesystemname | Default | | worker_process | Number of times that a worker process has been started. | counter | - | Default | | threescalebackendcalls | Authorize and report requests to the 3scale backend (Apisonator) | counter | endpoint(authrep, auth, report), status(2xx, 4xx, 5xx) | APIcast | | batchingpolicyauthscachehits | Hits in the auths cache of the 3scale batching policy | counter | - | 3scale Batcher | | batchingpolicyauthscachemisses | Misses in the auths cache of the 3scale batching policy | counter | - | 3scale Batcher | | content_caching | Number of requests that go through content caching policy. | counter | status(MISS, BYPASS, EXPIRED, STALE, UPDATING, REVALIDATED, HIT) | Content Caching |
Project: Gloo (Orchestration & Management / API Gateway)
File: proxy_protocol.proto.sk.md

title: "proxy_protocol.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> ```yaml "rules": []proxy_protocol.options.gloo.solo.io.ProxyProtocol.Rule "allowRequestsWithoutProxyProtocol": bool ``` | Field | Type | Description | | -- | - | -- | | `rules` | | The list of rules to apply to requests. | | `allowRequestsWithoutProxyProtocol` | `bool` | Allow requests through that don't use proxy protocol. Defaults to false. .. attention:: The true setting is only honored in Gloo Edge Enterprise. This breaks conformance with the specification. Only enable if ALL traffic to the listener comes from a trusted source. For more information on the security implications of this feature, see https://www.haproxy.org/download/2.1/doc/proxy-protocol.txt. | ```yaml "metadataNamespace": string "key": string ``` | Field | Type | Description | | -- | - | -- | | `metadataNamespace` | `string` | The namespace if this is empty, the filter's namespace will be used. | | `key` | `string` | The key to use within the namespace. | A Rule defines what metadata to apply when a header is present or missing. ```yaml "tlvType": int "onTlvPresent": .proxy_protocol.options.gloo.solo.io.ProxyProtocol.KeyValuePair ``` | Field | Type | Description | | -- | - | -- | | `tlvType` | `int` | The type that triggers the rule - required TLV type is defined as uint8t in proxy protocol. See `the spec <https://www.haproxy.org/download/2.1/doc/proxy-protocol.txt>` for details. | | `onTlvPresent` | | If the TLV type is present, apply this metadata KeyValuePair. | <!-- 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: Capsule (Orchestration & Management / Scheduling & Orchestration)
File: lens.md

With Capsule extension for , a cluster administrator can easily manage from a single pane of glass all resources of a Kubernetes cluster, including all the Tenants created through the Capsule Operator. Capsule extension for Lens provides these capabilities: List all tenants See tenant details and change through the embedded Lens editor Check Resources Quota and Budget at both the tenant and namespace level Please, see the for details about the installation of the Capsule Lens Extension.
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.20.1.md

We are delighted to present version v1.20.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. A big thank you to everyone who contributed to the release. Fixed a bug where upstream TLS SNI (`HTTProxy.spec.routes.requestHeadersPolicy` `Host` key) and protocol fields might not take effect when e.g. two `HTTPProxies` were otherwise equal but differed only on those fields. (#4350, @tsaarni) Update github.com/prometheus/client_golang to v1.11.1 to address CVE-2022-21698. (#4361, @tsaarni) Updates Envoy to v1.21.1. See the for details. (#4365, @skriss) Added documentation for HTTPProxy request redirection. (#4367, @sunjayBhatia) For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.20.1 is tested against Kubernetes 1.21 through 1.23. If you're using Contour and want to add your organization to our adopters list, please visit this . If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this .
Project: Service Mesh Performance (Orchestration & Management / Service Mesh)
File: feature_request.md

name: General Feature Request about: Suggest an enhancement to Meshery. title: '' labels: 'kind/enhancement' assignees: '' <!-- A brief description of what the problem is. (e.g. I need to be able to...) --> <!-- A brief description of the enhancement. --> <!-- [Optional] Specifics on the approach to fulfilling the feature request. --> <!-- [Optional] Stipulations of functional behavior or non-functional items that must be in-place in order for the issue to be closed. --> <!-- [Optional] Any visual diagrams of the desired user interface. --> - Meshery documentation and Wireframes and in Figma Questions: and
Project: Gloo (Orchestration & Management / API Gateway)
File: envoy_glooe_solo_io.project.sk.md

title: "envoyglooesolo_io.project" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> API Version: `envoy.glooe.solo.io.v1` <!-- 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: KrakenD (Orchestration & Management / API Gateway)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: '' assignees: '' 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.