cwielenb/CNCF-Dataset huggingface dataset:
Project: Eraser (Orchestration & Management / Scheduling & Orchestration)
File: exclusion.md

title: Exclusion Eraser can exclude registries (example, `docker.io/library/*`) and also specific images with a tag (example, `docker.io/library/ubuntu:18.04`) or digest (example, `sha256:80f31da1ac7b312ba29d65080fd...`) from its removal process. To exclude any images or registries from the removal, create configmap(s) with the label `eraser.sh/exclude.list=true` in the eraser-system namespace with a JSON file holding the excluded images. ```bash $ cat > sample.json <<"EOF" { "excluded": [ "docker.io/library/*", "ghcr.io/eraser-dev/test:latest" ] } EOF $ kubectl create configmap excluded --from-file=sample.json --namespace=eraser-system $ kubectl label configmap excluded eraser.sh/exclude.list=true -n eraser-system ``` Exempting nodes from cleanup was added in v1.0.0. When deploying Eraser, you can specify whether there is a list of nodes you would like to `include` or `exclude` from the cleanup process using the configmap. For more information, see the section on .
Project: 3Scale (Orchestration & Management / API Gateway)
File: liquid_conditions.md

You can use Liquid to configure conditions applicable across multiple policies to <insert_purpose> of conditions that can be used across multiple policies Condition passes if the 'Backend' header is sent and it's staging ``` "condition":{ "operations":[ { "left":" {% if headers['Backend'] %}{{ headers['Backend'] }}{%else%}Notpresent{%endif%}", "left_type":"liquid", "op":"==", "right":"staging" } ] } ``` If you want to test when the `Backend` header is not present, the condition is as follows: ``` "condition":{ "operations":[ { "left":" {% if headers['Backend'] %}IsPresent{%else%}Notpresent{%endif%}", "left_type":"liquid", "op":"==", "right":"Notpresent" } ] } ``` Numeric operations require additional steps. By default, all the values on liquid are strings, so you need to get any integer before do any operation. Use `minus` or `plus` filters along with `0` (zero), and apply the following configuration: ``` "condition":{ "operations":[ { "left": "{% assign val = headers['version'] | minus:0 %} {%if val < 20 %}PASS{%else%}DENIED{%endif%}", "left_type":"liquid", "op":"==", "right":"PASS" } ] } ``` @TODO: something like a int filter should be added. @TODO: default filter should be added too.
Project: BFE (Orchestration & Management / Service Proxy)
File: mod_cors.md

mod_cors support Cross-Origin Resource Sharing conf/modcors/modcors.conf | Config Item | Description | | -- | | | Basic.DataPath | String<br>Path of rule configuration | | Log.OpenDebug | Boolean<br>Debug flag of module | ```ini [Basic] DataPath = modcors/corsrule.data [Log] OpenDebug = false ``` conf/modcors/corsrule.data | Config Item | Description | | -- | -- | | Version | String<br>Version of the config file | | Config | Object<br>Trace rules for each product | | Config[k] | String<br>Product name | | Config[v] | Object<br>A list of cors rules | | Config | Object<br>A cors rule | | Config | | Config.AccessControlAllowOrigins | List<br> Indicates whether the response can be shared with requesting code from the given origin; for requests without credentials, the "*" wildcard, to tell browsers to allow any origin to access the resource. "%origin" specifies the origin from the request header "Origin" | | Config.AccessControlAllowCredentials| Boolean<br> Indicates whether or not the response to the request can be exposed.| | Config.AccessControlExposeHeaders | Boolean<br> Specifies the response headers that browsers are allowed to access. | | Config.AccessControlAllowMethods | List<br> Specifies the method or methods allowed when accessing the resource. This is used in response to a preflight request.| | Config.AccessControlAllowHeaders | List<br> Indicates which HTTP headers can be used when making the actual request. This is used in response to a preflight request.| | Config.AccessControlMaxAge | Int<br>Indicates how long the results of a preflight request can be cached. This is used in response to a preflight request.| ```json { "Version": "cors_rule.data.version", "Config": { "example_product": [ { "Cond": "reqhostin(\"example.org\")", "AccessControlAllowOrigins": ["%origin"], "AccessControlAllowCredentials": true, "AccessControlExposeHeaders": ["X-Custom-Header"], "AccessControlAllowMethods": ["HEAD","GET","POST","PUT","DELETE","OPTIONS","PATCH"], "AccessControlAllowHeaders": ["X-Custom-Header"], "AccessControlMaxAge": -1 } ] } } ```
Project: Kubernetes (Orchestration & Management / Scheduling & Orchestration)
File: usage_guidelines.md

These guidelines provide you with guidance for using the Kubernetes logo. All artwork is made available under the Linux Foundation trademark usage . This text from those guidelines, and the correct and incorrect usage examples, are particularly helpful: Certain marks of The Linux Foundation have been created to enable you to communicate compatibility or interoperability of software or products. In addition to the requirement that any use of a mark to make an assertion of compatibility must, of course, be accurate, the use of these marks must avoid confusion regarding The Linux Foundations association with the product. The use of the mark cannot imply that The Linux Foundation or its projects are sponsoring or endorsing the product. Additionally, permission is granted to modify the Kubernetes mark for non-commercial uses such as t-shirts and stickers. The Kubernetes logo is available in 2 formats (PNG & SVG), 3 layouts -- horizontal (also known as landscape format), stacked (which is closer to square), and icon (which does not include the name and is square), and 5 colors (color/black/white/all-blue/white-text) -- so over 20 versions -- in the CNCF repo.
Project: WSO2 API Microgateway (Orchestration & Management / API Gateway)
File: pull_request_template.md

<!-- Short description of the issue you are going to solve with this PR. --> <!-- Link github issues that are going to be solved with this PR. Format should be: Fixes #123 --> Fixes # Unit tests added: Yes/No Integration tests added: Yes/No <!-- Specify the environments you used to test this PR. OS, DB, JDK version, etc... --> Not Tested [ ] Assigned 'Type' label [ ] Assigned the project [ ] Validated respective github issues [ ] Assigned milestone to the github issue(s)
Project: Consul (Orchestration & Management / Service Mesh)
File: feature_request.md

name: Feature Request about: If you have something you think Consul could improve or add support for. <! Please search the existing issues for relevant feature requests, and use the reaction feature (https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to add upvotes to pre-existing requests. > <! Please provide a written overview of the feature and why this feature solves challenges that you are facing today. > <! Please describe the use case for this feature (i.e. Service Mesh, Service Discovery, KV, API Gateway) and also deployment environments you are looking to see this addressed in (K8s, VMs, Nomad, ECS, Lambda). -->
Project: Traefik (Orchestration & Management / API Gateway)
File: SECURITY.md

You can join our security mailing list to be aware of the latest announcements from our security team. You can subscribe sending a mail to security+subscribe@traefik.io or on . Reported vulnerabilities can be found on . We usually release 3/4 new versions (e.g. 1.1.0, 1.2.0, 1.3.0) per year. Release Candidates are available before the release (e.g. 1.1.0-rc1, 1.1.0-rc2, 1.1.0-rc3, 1.1.0-rc4, before 1.1.0). Bug-fixes (e.g. 1.1.1, 1.1.2, 1.2.1, 1.2.3) are released as needed (no additional features are delivered in those versions, bug-fixes only). Each version is supported until the next one is released (e.g. 1.1.x will be supported until 1.2.0 is out). We use . | Version | Supported | |--|--| | `2.2.x` | :whitecheckmark: | | `< 2.2.x` | :x: | | `1.7.x` | :whitecheckmark: | | `< 1.7.x` | :x: | We want to keep Traefik safe for everyone. If you've discovered a security vulnerability in Traefik, we appreciate your help in disclosing it to us in a responsible manner, by creating a .
Project: Gloo (Orchestration & Management / API Gateway)
File: tap.proto.sk.md

title: "tap.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> ```yaml "staticConfig": .tap.options.gloo.solo.io.StaticConfig ``` | Field | Type | Description | | -- | - | -- | | `staticConfig` | | | ```yaml "outputConfig": .tap.options.gloo.solo.io.OutputConfig ``` | Field | Type | Description | | -- | - | -- | | `outputConfig` | | | ```yaml "sinks": []tap.options.gloo.solo.io.Sink ``` | Field | Type | Description | | -- | - | -- | | `sinks` | | Sinks to which tap data should be output. Currently, only a single sink is supported. TODO is there a validate rule that we can use to enforce a length of 1?. | ```yaml "grpcService": .tap.options.gloo.solo.io.GrpcService ``` | Field | Type | Description | | -- | - | -- | | `grpcService` | | Write tap data out to a GRPC service .solo.io.envoy.config.core.v3.GrpcService grpc_service = 1;. | A tap sink over a GRPC service ```yaml "tapServer": .core.solo.io.ResourceRef ``` | Field | Type | Description | | -- | - | -- | | `tapServer` | | | <!-- 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: Gloo (Orchestration & Management / API Gateway)
File: aws-tests.md

See for more details about e2e tests in general These steps can only be taken if you are a Gloo Edge maintainer You will need to do the following to run the locally: Obtain an AWS IAM User account that is part of the Solo.io organization Create an AWS access key Under IAM > Users in the AWS console, select the User from step 1 Under Summary click "Create access key" to create an access key Save the Access key ID and the associated secret key to be used later Install AWS CLI v2 You can check whether you have AWS CLI installed by running `aws --version` Installation guides for various operating systems can be found Configure AWS credentials on your machine You can do this by running `aws configure` You will be asked to provide your Access Key ID and Secret Key from step 2, as well as the default region name and default output format It is critical that you set the default region to `us-east-1` This will create a credentials file at `~/.aws/credentials` on Linux or macOS, or at `C:\Users\USERNAME\.aws\credentials` on Windows. Copy the credentials file to a location in the `gloo` directory, for example at `/test/e2e/awscredentials/credentials` and set the `AWSSHAREDCREDENTIALSFILE` var to that location, relative to `/test/e2e` The tests read this file in order to interact with lambdas that have been created in the Solo.io organization Set the `AWS_PROFILE` env var to the name of the IAM User
Project: Skipper (Orchestration & Management / Service Proxy)
File: index.md

This is the documentation page of . Skipper is an HTTP router and reverse proxy for service composition. It's designed to handle large amounts of dynamically configured HTTP route definitions (>800000 routes) with detailed lookup conditions, and flexible augmentation of the request flow with filters. It can be used out of the box or extended with custom lookup, filter logic and configuration sources. Skipper identifies routes based on the requests' properties, such as path, method, host and headers using the . It allows the modification of the requests and responses with that are independently configured for each route. Skipper can be used to run as a Kubernetes Ingress controller. Details with examples of Skipper's capabilities and an overview can be found in the [ingress-controller deployment docs](kubernetes/ingress-controller.md).
Project: KEDA (Orchestration & Management / Scheduling & Orchestration)
File: VERSIONING.md

We follow the , and use the corresponding tooling. For the purposes of the aforementioned guidelines, controller-runtime counts as a "library project", but otherwise follows the guidelines exactly. For release branches, we generally tend to support backporting one (1) major release (`release-{X-1}` or `release-0.{Y-1}`), but may go back further if the need arises and is very pressing (e.g. security updates). Note the . Particularly: We DO guarantee Kubernetes REST API compatibility -- if a given version of controller-runtime stops working with what should be a supported version of Kubernetes, this is almost certainly a bug. We DO NOT guarantee any particular compatibility matrix between kubernetes library dependencies (client-go, apimachinery, etc); Such compatibility is infeasible due to the way those libraries are versioned.
Project: Gloo (Orchestration & Management / API Gateway)
File: pull_request_template.md

Please include a high level summary of the changes. This bug fixes ... \ This new feature can be used to ... Fill out any of the following sections that are relevant and remove the others Added x field to y resource ... Fix error in `Foo()` function Add `Bar()` function ... Adjusted schedule for x job ... Added guide about feature x to public docs Updated README to account for y behavior ... Users ran into this bug doing ... \ Users needed this feature to ... See slack conversation We chose to do things this way because ... I manually verified behavior by ... Be sure to verify intended behavior by ... Please proofread comments on ... This is a complex PR and may require a huddle to discuss ... [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] I have added tests that prove my fix is effective or that my feature works <! Include a concise, user-facing changelog (for details, see https://github.com/solo-io/go-utils/tree/main/changelogutils) referencing the issue that is resolved Include `resolvesIssue: false` unless the issue does not require a release to be resolved; only a subset of non-user-facing issues can be considered resolved without release Run codegen via `make -B install-go-tools generated-code` Follow guidelines laid out in the Gloo Edge If not ready for review, open a draft PR or apply the `work in progress` label -->
Project: Envoy (Orchestration & Management / Service Proxy)
File: WASM.md

WebAssembly tests are built using [Proxy-Wasm C++ SDK] and [Proxy-Wasm Rust SDK], as such, they bring their own set of dependencies. In order to update Cargo dependencies, please make sure that Rust and Cargo are installed, and run this tool: ``` bash tools/update_crates.sh ``` which will regenerate Bazel rules in `bazel/external/cargo/`.
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: CODECOVERAGE.md

<!-- /* 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. */ --> The following instructions should be followed in order to create a code coverage report locally. Open a command prompt Install ReportGenerator globally\ a. Run the following command line: `dotnet tool install --global dotnet-reportgenerator-globaltool --version 5.1.4 --add-source https://www.nuget.org/packages/`\ b. The latest version can be found at Navigate to the test project `avro\lang\csharp\src\apache\test` Run the following test command `dotnet test --results-directory ./TestResults --collect:"XPlat Code Coverage"` Generate the report with the following command `ReportGenerator "-reports:./TestResults/*/coverage.cobertura.xml" "-targetdir:./Coverage/" -reporttypes:HTML` Open Report under `avro\lang\csharp\src\apache\test\Coverage\index.html`
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.25.2.md

We are delighted to present version v1.25.2 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. Bumps to v1.26.7. This ensures better compatibility with Kubernetes v1.27 clusters. See for more context on why this change is required. Many thanks to @chrism417 for bringing this to our attention. For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.25.2 is tested against Kubernetes 1.25 through 1.27. 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: Gloo (Orchestration & Management / API Gateway)
File: osa_provided.md

Name|Version|License || |v3.2.1|MIT License |v0.0.0-20180928190340-9d1f4485533b|Apache License 2.0 |v2.4.3+incompatible|MIT License |v4.3.3|MIT License |v1.34.9|Apache License 2.0 |v0.2.0|Apache License 2.0 |v0.0.0-20230607035331-e9ce68804cb4|Apache License 2.0 |v0.0.0-20190331194516-514510793eaa|MIT License |v1.29.0-patch1|Apache License 2.0 |v1.0.2|Apache License 2.0 |v3.2.5+incompatible|MIT License |v1.7.0|BSD 3-clause "New" or "Revised" License |v1.0.1-0.20190212211648-25d852aebe32|MIT License |v1.2.4|Apache License 2.0 |v0.19.4|Apache License 2.0 |v0.19.6|Apache License 2.0 |v0.22.4|Apache License 2.0 |v0.21.0|Apache License 2.0 |v1.4.0|Apache License 2.0 |v1.3.2|BSD 3-clause "New" or "Revised" License |v1.5.3|BSD 3-clause "New" or "Revised" License |v17.0.0+incompatible|BSD 3-clause "New" or "Revised" License |v32.0.0|BSD 3-clause "New" or "Revised" License |v1.3.1|BSD 3-clause "New" or "Revised" License |v1.8.0|BSD 3-clause "New" or "Revised" License |v1.3.0|Apache License 2.0 |v0.0.0-20180809195222-d55458df857c|MIT License |v0.3.16|BSD 3-clause "New" or "Revised" License |v0.0.0-20160112193335-8152e7eb6ccf|UNKNOWN |v1.15.3|Apache License 2.0 |v1.4.0|MIT License |v0.0.5|MIT License |v2.17.0|MIT License |v1.30.0|MIT License |v0.0.0-20180916011732-0a3d74bf9ce4|BSD 2-clause "Simplified" License |v0.9.1|BSD 2-clause "Simplified" License |v0.3.22|BSD 3-clause "New" or "Revised" License |v0.5.4|MIT License |v0.0.0-20210820204958-38443d06ebe0|MIT License |v1.1.0|MIT License |v1.9.2|Apache License 2.0 |v1.8.0|Apache License 2.0 |v1.0.5|BSD 3-clause "New" or "Revised" License |v1.8.1|MIT License |v1.8.4|MIT License |v0.24.0|Apache License 2.0 |v1.2.1|MIT License |v1.11.0|MIT License |v1.26.0|MIT License |v0.18.0|BSD 3-clause "New" or "Revised" License |v0.0.0-20231006140011-7918f672742d|BSD 3-clause "New" or "Revised" License |v0.6.0|BSD 3-clause "New" or "Revised" License |v0.17.0|BSD 3-clause "New" or "Revised" License |v0.0.0-20230822172742-b8732ec3820d|Apache License 2.0 |v0.0.0-20230822172742-b8732ec3820d|Apache License 2.0 |v1.59.0|Apache License 2.0 |v1.32.0|BSD 3-clause "New" or "Revised" License |v1.8.7|MIT License |v3.14.2|Apache License 2.0 |v0.28.3|Apache License 2.0 |v0.28.3|Apache License 2.0 |v0.28.3|Apache License 2.0 |v0.28.3|Apache License 2.0 |v0.28.3|Apache License 2.0 |v0.28.3|Apache License 2.0 |v0.28.3|Apache License 2.0 |v0.0.0-20230726121419-3b25d923346b|Apache License 2.0 |v0.0.0-20211210083629-bace06e98aee|Apache License 2.0 |v0.0.0-20211206113427-18589ac7627e|Apache License 2.0 |v0.16.3|Apache License 2.0 |v1.0.1-0.20231102234148-3b5969669194|Apache License 2.0 |v1.4.0|MIT License |latest|MIT License |latest|MIT License |latest|Apache License 2.0 |latest|Apache License 2.0 |latest|MIT License
Project: Apache Thrift (Orchestration & Management / Remote Procedure Call)
File: os_x.md

The following command install all the required tools and libraries to build and install the Apache Thrift compiler on a OS X based system. Download the boost library from untar compile with ./bootstrap.sh sudo ./b2 threading=multi address-model=64 variant=release stage install Download , untar and compile with ./configure --prefix=/usr/local make sudo make install Download the latest version of , untar and compile with ./configure --prefix=/usr/local/ --with-boost=/usr/local --with-libevent=/usr/local For more information on the requirements see: For more information on building and installing Thrift see:
Project: Clusterpedia (Orchestration & Management / Scheduling & Orchestration)
File: CONTRIBUTING.md

Welcome to Kubernetes. We are excited about the prospect of you joining our ! The Kubernetes community abides by the CNCF . Here is an excerpt: As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. We have full documentation on how to get started contributing here: <! If your repo has certain guidelines for contribution, put them here ahead of the general k8s resources --> Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests - Main contributor documentation, or you can just jump directly to the - Common resources for existing developers - We have a diverse set of mentorship programs available that are always looking for volunteers! <! Custom Information - if you're copying this template for the first time you can add custom content here, for example: - Replace `kubernetes-users` with your slack channel string, this will send users directly to your channel. -->
Project: BFE (Orchestration & Management / Service Proxy)
File: name_conf.data.md

name_conf.data records the mapping between service name and service instances. | Config Item | Description | | -- | | | Version | String<br>Version of config file | | Config | Struct<br>Mapping between service name and instances | | Config{k} | String<br>Service name | | Config{v} | Struct<br>A list of instances | | Config{v}[].Host | String<br>Instance address | | Config{v}[].Port | Integer<br>Instance port | | Config{v}[].Weight | Integer<br>Instance weight | ```json { "Version": "20190101000000", "Config": { "example.redis.cluster": [ { "Host": "192.168.1.1", "Port": 6439, "Weight": 10 } ] } } ```
Project: BFE (Orchestration & Management / Service Proxy)
File: mod_key_log.md

modkeylog writes tls key logs in NSS key log format so that external programs(eg. wireshark) can decrypt TLS connections for trouble shooting. For more information about NSS key log format, see: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/KeyLogFormat conf/modkeylog/modkeylog.conf | Config Item | Description | | -- | | | Log.LogFile | String<br>Set file path of log for saving to a single file without rotation | | Log.LogPrefix | String<br>Filename prefix for log | | Log.LogDir | String<br>Directory of log files | | Log.RotateWhen | String<br>Interval to rotate log file | | Log.BackupCount | Integer<br>Max number of rotated log files | ```ini [Log] LogPrefix = key LogDir = ../log RotateWhen = H BackupCount = 3 ``` ```ini [Log] LogFile = /dev/stdout ```