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

+++ title = "CoreDNS-1.0.2 Release" description = "CoreDNS-1.0.2 Release Notes." tags = ["Release", "1.0.2", "Notes"] draft = false release = "1.0.2" date = "2017-12-31T09:06:29+00:00" author = "coredns" +++ We are pleased to announce the of CoreDNS-1.0.2! This release can be summarized as "help external plugin developers" as most changes are geared towards exposing CoreDNS functionality to make this as easy as possible. Is also a fairly small release. Expose the directives list, so that external plugins can be easily added without mucking with CoreDNS code, see the for details. Fix crash when there are no handlers that can actually serve queries, i.e. a Corefile with only debug and pprof for instance. has a New function to help external plugin developers. plugin now checks all plugins for a `health.Healther` implementation and will export health for those plugins that do. Again helps external plugin developers. gained regular expression and substring-matching support. The following people helped with getting this release done: Brad Beam, Francois Tur, Frederic Hemberger, James Hartig, Max Schmitt, Miek Gieben, Paul Greenberg, Yong Tang. If you want to help, please check out one of the and start coding! For documentation and help, see our .
Project: Gloo (Orchestration & Management / API Gateway)
File: subset.proto.sk.md

title: "subset.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> ```yaml "values": map<string, string> ``` | Field | Type | Description | | -- | - | -- | | `values` | `map<string, string>` | | <!-- Start of HubSpot Embed Code --> <script type="text/javascript" id="hs-script-loader" async defer src="//js.hs-scripts.com/5130874.js"></script> <!-- End of HubSpot Embed Code -->
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: reporting_bugs.md

If any part of the Volcano project has bugs or documentation mistakes, please let us know by opening an issue. We treat bugs and mistakes very seriously and believe no issue is too small. Before creating a bug report, please check that an issue reporting the same problem does not already exist. To make the bug report accurate and easy to understand, please try to create bug reports that are: Specific. Include as much details as possible: which version, what environment, what configuration, etc. If the bug is related to running the volcano component, please attach the component log (the starting log with component configuration is especially important). Reproducible. Include the steps to reproduce the problem. We understand some issues might be hard to reproduce, please includes the steps that might lead to the problem. Isolated. Please try to isolate and reproduce the bug with minimum dependencies. It would significantly slow down the speed to fix a bug if too many dependencies are involved in a bug report. Unique. Do not duplicate existing bug report. Scoped. One bug per report. Do not follow up with another bug inside one report. We might ask for further information to locate a bug. A duplicated bug report will be closed.
Project: Sentinel (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, 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 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 <sentinel@linux.alibaba.com>. 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
Project: Armada (Orchestration & Management / Scheduling & Orchestration)
File: README.md

](https://godoc.org/github.com/processout/grpc-go-pool) This package aims to provide an easy to use and lightweight GRPC connection pool. Please note that the goal isn't to replicate the client-side load-balancing feature of the official grpc package: the goal is rather to have multiple connections established to one endpoint (which can be server-side load-balanced).
Project: Contour (Orchestration & Management / Service Proxy)
File: sds-design.md

Status: Approved This document outlines what changes are needed on Contour to support SDS. [0] Implement SDS server as a gRPS service Support contour cli for SDS Support auth.SdsSecretConfig configuration on Listener & Cluster under auth.CommonTlsContext Currently, contour supports fetching TLS cert/keys from k8s secrets and populates the values for DownstreamTlsContext in LDS & UpstreamTlsContext in CDS. Now that Envoy 1.8 and later releases support Secret Discovery Service (SDS) to fetch secrets remotely, we want to add support in Contour to parse SDS secret config and stream secrets using SDS GRPc service. Please refer to [1] to understand more on how SDS works on Envoy. Create GRPC server for SDS Create SecretCache to be used by Contour Internally to identify any changes. Support contour cli for SDS Create new resource SDS of `Cache` Interface type which implements the SDS v2 gRPS API. Create new xdsHandler of secret type. Register & Implement FetchSecrets() & StreamSecrets(). In /internal/contour create secret.go with SecretCache struct Implement Register(), Update() and notify() Create secretVisitor and implement visit() and visitSecrets() to produce a map with v2.secrets In order to facilitate debugging and to find out exactly the data that is being sent to Envoy, will add support to contour cli sub command. This cmd shd be used stream changes to the SDS api endpoint to the terminal. `kubectl -n projectcontour exec $CONTOUR_POD -c contour contour cli sds`
Project: OpenELB (Orchestration & Management / Service Proxy)
File: roadmap.md

OpenELB Roadmap lists the features and Bugfix for each milestone. | Edition | Schedule | ||| | Release v0.7.0 | TBD | | Release v0.6.0 | Jul, 2022 | | Release v0.5.0| May, 2022 | | Release v0.4.4 | Feb, 2022 | | Release v0.4.3 | Jan, 2022 | | Release v0.4.2| Jul, 2021 | | Release v0.4.1| Mar, 2021 | | Release v0.4.0| Mar, 2021 | | Release v0.3.1| Aug, 2020 | | Release v0.3.0| Aug, 2020 | | Release v0.1.0| Mar, 2019 | | Release v0.0.1| Feb, 2019 | [ ] Achieve the LoadBalancer for kube-apiserver [ ] Support for more routing protocols; Be compatible with the popular CNI [ ] Support VIP Group and more VIPs [ ] Support for IPv6 [ ] Support for BGP policies [ ] Provide the Prometheus metrics for monitoring [ ] Provide the OpenELB Web UI for managing EIP and IP pool ) ) ) [x] Support layer 2 load-balancing [x] Support loadBalancerIP in Service [x] Support add neighbor dynamically [x] Support config porter via CRD [x] add portforward for nonstandard bgp port [x] add doc about setting up in real router [x] more tests [x] Release Porter v0.0.1
Project: Kuma (Orchestration & Management / Service Mesh)
File: fault-injection.md

Fault Injection is a useful feature that allows to test resiliency of the service. Envoy provides full-featured support of Fault Injection so we intended to implement same functionality in Kuma. ```yaml type: FaultInjection mesh: default name: fi-1 sources: match: service: frontend region: aws version: 3 destinations: match: service: backend version: 5 conf: delay: percentage: 35.5 # from 0.0 to 100.0 value: 50ms abort: percentage: 87.5 httpStatus: 500 responseBandwidth: # responseratelimit in envoy percentage: 87.5 limit: 500kbps # bps, mbps ``` There are two possible places to configure Envoy proxy: outbound listener of source inbound listener of destination Probably will be much easier to implement Fault Injections for external services in the future. Limitations: unable to differentiate destinations somehow besides service's name. Potentially could be resolved the same way like `TrafficRoute`, but this is undesirable because we have to generate cluster for every destination combination which leads to complexity of reading and aggregating of metrics. Also this is performance hit on having such combinations in envoy configs, they become bigger. More preferable way to implement Fault Injection. But problem with traffic differentiation still has to be solved. The idea is to implement matching by HTTP Headers. Envoy Fault Injection filter allows to specify regex for headers and be applied only for matched ones. Kuma can reserve header `x-kuma-match` and configure source proxy to set it on every request. We can consider the format for that header, but probably the simplest one is URL-style: `service=frontend&version=0.1`. _Why don't just have separate header for each tag?_ Alternatively we could reserve header pattern like `x-kuma-tag-TAGNAME` and store each tag separately. But in that case we need envoy to have ability to remove headers with specified prefix (or with regex). There is no such functionality yet._ On the destination side proxy we will configure regex for matching: ``` (?=.version=0\.1.)(?=.service=frontend.) ``` So it will match: `service=frontend&version=0.1` `version=0.1&service=frontend` `service=frontend&version=0.1&tag=customtag` ... In other words all key-values pairs that necessarily contain provided version and service. Also on destination side we will configure HTTP filter that removes specified headers. So application will see the request as it was sent by source. _Note: envoy will replace header if some malicious application tries to specify it by itself pretending to be identified like another service. So that feature requres to have mTLS enabled._ At that point we decided to move forward with implementation of the second option - Fault Injection on the destination inbound. That gives us more flexibility for traffic management with less efforts. As soon as External Services support will be added to Kuma for L7 traffic, we will come back to Fault Injections and to that proposal.
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: propagationpolicy_test.md

| Test Case | E2E Describe Text | Comments | |-|-|| | Test the propagationPolicy for deployment | deployment propagation testing | | | Test the propagationPolicy for service | service propagation testing | | | Test the propagationPolicy for pod | pod propagation testing | | | Test the propagationPolicy for namespace scope custom resource | namespaceScoped cr propagation testing | | | Test the propagationPolicy for job | job propagation testing | | | Test the propagationPolicy for role | role propagation testing | | | Test the propagationPolicy for roleBinding | roleBinding propagation testing | | | Test Case | E2E Describe Text | Comments | ||-|| | priorityMatchName/priorityMatchLabel/priorityMatchAll testing | check whether the deployment uses the highest priority propagationPolicy (priorityMatchName/priorityMatchLabel/priorityMatchAll) | | | Test Case | E2E Describe Text | Comments | |-||--| | Test the high explicit/low priority/implicit priority propagation for deployment | high explicit/low priority/implicit priority PropagationPolicy propagation testing | | | Test the same explicit priority propagation for deployment | same explicit priority PropagationPolicy propagation testing | | | Test Case | E2E Describe Text | Comments | |--||--| | Test add resourceSelector of the propagationPolicy for the deployment | add resourceSelectors item | | | Test update resourceSelector of the propagationPolicy for the deployment | update resourceSelectors item | | | Test update propagateDeps of the propagationPolicy for the deployment | update policy propagateDeps | | | Test update placement of the propagationPolicy for the deployment | update policy placement | | | Test delete propagationpolicy for deployment | delete the propagationPolicy and check whether labels and annotations are deleted correctly | | | Test modify the old propagationPolicy to unbind and create a new one | modify the old propagationPolicy to unbind and create a new one | | | Test delete the old propagationPolicy to unbind and create a new one | delete the old propagationPolicy to unbind and create a new one | |
Project: BFE (Orchestration & Management / Service Proxy)
File: ip.md

Description: Judge if source IP of session is in [startip, endip] Parameter | Parameter | Description | | | - | | start_ip | String<br>start ip address | | end_ip | String<br>end ip address | Example ```go sessiprange("10.0.0.1", "10.0.0.10") ``` Description: Judge if VIP of session is in [startip, endip] Parameter | Parameter | Description | | | - | | start_ip | String<br>start ip address | | end_ip | String<br>end ip address | Example ```go sesviprange("10.0.0.1", "10.0.0.10") ```
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_upgrade.md

title: "glooctl upgrade" weight: 5 upgrade glooctl binary ``` glooctl upgrade [flags] ``` ``` -h, --help help for upgrade --path string Desired path for your upgraded glooctl binary. Defaults to the location of your currently executing binary. --release string Which glooctl release to download. Specify a release tag corresponding to the desired version of glooctl,"experimental" to use the version currently under development, or a major+minor release like v1.10.x to get the most recent patch version. (default "latest") ``` ``` -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) ``` - CLI for Gloo
Project: BFE (Orchestration & Management / Service Proxy)
File: mod_auth_jwt.md

modauthjwt implements JWT(). conf/modauthjwt/modauthjwt.conf | Config Item | Description | | -- | | | Basic.DataPath | String<br>Path of rule configuration | | Log.OpenDebug | Boolean<br>Debug flag of module | ```ini [Basic] DataPath = modauthjwt/authjwtrule.data ``` conf/modauthjwt/authjwtrule.data | Config Item | Description | | -- | | | Version | String<br>Version of config file | | Config | Struct<br>JWT rules for each product | | Config{k} | String<br>Product name | | Config{v} | Object<br>A ordered list of rules | | Config{v}[] | Object<br>A rule | | Config{v} | | Config{v}[].KeyFile | String<br>Path of JWK configuration | | Config{v}[].Realm | String<br>Realm, ie. protection space<br>Default "Restricted" | Description about JWK configuration Key file must follow the format described by the Generate key: ``` echo -n jwtexample | base64 | tr '+/' '-' | tr -d '=' ``` key file configuration example ```json [ { "k": "and0X2V4YW1wbGU", "kty": "oct", "kid": "0001" } ] ``` ```json { "Version": "20190101000000", "Config": { "example_product": [ { "Cond": "reqhostin(\"www.example.org\")", "KeyFile": "modauthjwt/key_file", "Realm": "Restricted" } ] } } ```
Project: Higress (Orchestration & Management / API Gateway)
File: FEATURE_REQUEST.md

name: Feature Request about: Suggest an idea for Higress title: '' labels: '' assignees: '' Is your feature request related to a problem? Please describe in details A clear and concise description of what you want to happen. You can explain more about input of the feature, and output of it. Add any other context or screenshots about the feature request here.
Project: Gloo (Orchestration & Management / API Gateway)
File: aws_ec2.proto.sk.md

title: "aws_ec2.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Upstream Spec for AWS Lambda Upstreams AWS Upstreams represent a collection of Lambda Functions for a particular AWS Account (IAM Role or User account) in a particular region ```yaml "region": string "secretRef": .core.solo.io.ResourceRef "roleArn": string "filters": []aws_ec2.options.gloo.solo.io.TagFilter "publicIp": bool "port": int ``` | Field | Type | Description | | -- | - | -- | | `region` | `string` | The AWS Region where the desired EC2 instances exist. | | `secretRef` | | Optional, if not set, Gloo will try to use the default AWS secret specified by environment variables. If a secret is not provided, the environment must specify both the AWS access key and secret. The environment variables used to indicate the AWS account can be: - for the access key: "AWSACCESSKEYID" or "AWSACCESSKEY" - for the secret: "AWSSECRETACCESSKEY" or "AWSSECRETKEY" If set, a to an AWS Secret AWS Secrets can be created with `glooctl secret create aws ...` If the secret is created manually, it must conform to the following structure: ``` accesskey: <aws access key> secretkey: <aws secret key> ``` Gloo will create an EC2 API client with this credential. You may choose to use a credential with limited access in conjunction with a list of Roles, specified by their Amazon Resource Number (ARN). | | `roleArn` | `string` | Optional, Amazon Resource Number (ARN) referring to IAM Role that should be assumed when the Upstream queries for eligible EC2 instances. If provided, Gloo will create an EC2 API client with the provided role. If not provided, Gloo will not assume a role. | | `filters` | | List of tag filters for selecting instances An instance must match all the filters in order to be selected Filter keys are not case-sensitive. | | `publicIp` | `bool` | If set, will use the EC2 public IP address. Defaults to the private IP address. | | `port` | `int` | If set, will use this port on EC2 instances. Defaults to 0. | ```yaml "key": string "kvPair": .aws_ec2.options.gloo.solo.io.TagFilter.KvPair ``` | Field | Type | Description | | -- | - | -- | | `key` | `string` | if set, only instances that have a tag with this key will be matched keys are not case-sensitive, as with AWS Condition Keys. Only one of `key` or `kvPair` can be set. | | `kvPair` | | if set, only instances that have a tag with this key and value. Only one of `kvPair` or `key` can be set. | ```yaml "key": string "value": string ``` | Field | Type | Description | | -- | - | -- | | `key` | `string` | keys are not case-sensitive, as with AWS Condition Keys. | | `value` | `string` | values are case-sensitive. | <!-- 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: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.7.3-released.md

title: "Avro 1.7.3" linkTitle: "Avro 1.7.3" date: 2012-12-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.7.3 has been released!