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

Releases ======== v1.11.0 (2023-03-28) ==================== `Errors` now supports any error that implements multiple-error interface. Add `Every` function to allow checking if all errors in the chain satisfies `errors.Is` against the target error. v1.10.0 (2023-03-08) ==================== Comply with Go 1.20's multiple-error interface. Drop Go 1.18 support. Per the support policy, only Go 1.19 and 1.20 are supported now. Drop all non-test external dependencies. v1.9.0 (2022-12-12) =================== Add `AppendFunc` that allow passsing functions to similar to `AppendInvoke`. Bump up yaml.v3 dependency to 3.0.1. v1.8.0 (2022-02-28) =================== `Combine`: perform zero allocations when there are no errors. v1.7.0 (2021-05-06) =================== Add `AppendInvoke` to append into errors from `defer` blocks. v1.6.0 (2020-09-14) =================== Actually drop library dependency on development-time tooling. v1.5.0 (2020-02-24) =================== Drop library dependency on development-time tooling. v1.4.0 (2019-11-04) =================== Add `AppendInto` function to more ergonomically build errors inside a loop. v1.3.0 (2019-10-29) =================== Switch to Go modules. v1.2.0 (2019-09-26) =================== Support extracting and matching against wrapped errors with `errors.As` and `errors.Is`. v1.1.0 (2017-06-30) =================== Added an `Errors(error) []error` function to extract the underlying list of errors for a multierr error. v1.0.0 (2017-05-31) =================== No changes since v0.2.0. This release is committing to making no breaking changes to the current API in the 1.X series. v0.2.0 (2017-04-11) =================== Repeatedly appending to the same error is now faster due to fewer allocations. v0.1.0 (2017-31-03) =================== Initial release
Project: BFE (Orchestration & Management / Service Proxy)
File: api.md

BFE provides a set of management APIs for metrics exposing, configurations reloading, debugging and profiling etc. It should not publicly exposing the APIs, keeping them restricted to internal networks. Set management port in BFE core configuration file(conf/bfe.conf) ``` [Server] MonitorPort = 8421 ``` All the following endpoints must be accessed with a `GET` HTTP request. | Path | Description | | - | | | /monitor | Lists all the monitor categories. See | | /monitor/{name} | Returns the metrics information of the monitor category specified by `name`. | | /reload | Lists all the reload entries. See | | /reload/{name} | Reloads the configuration specified by `name`. | | /debug/pprof/ | See the Go documentation.| | /debug/cmdline | See the Go documentation. | | /debug/profile | See the Go documentation. | | /debug/symbol | See the Go documentation. | | /debug/trace | See the Go documentation. |
Project: Kuma (Orchestration & Management / Service Mesh)
File: README.md

Kuma Control Plane inside Docker Compose ==================== `docker-compose` ```bash make build/example/docker-compose -C ../../../.. ``` ```bash make deploy/example/docker-compose -C ../../../.. ``` ```bash make wait/example/docker-compose -C ../../../.. make curl/example/docker-compose -C ../../../.. ``` ```bash make verify/example/docker-compose -C ../../../.. ``` ```bash make stats/example/docker-compose -C ../../../.. ``` E.g., ``` envoyclusterupstreamrqtotal{envoyclustername="pass_through"} 11 envoyclusterupstreamrqtotal{envoyclustername="ads_cluster"} 1 envoyclusterupstreamrqtotal{envoyclustername="localhost_8080"} 11 ``` where `envoyclusterupstreamrqtotal{envoyclustername="localhost_8080"}` is a number of `inbound` requests `envoyclusterupstreamrqtotal{envoyclustername="pass_through"}` is a number of `outbound` requests ```bash make verify/traffic-routing/docker-compose/without-mtls -C ../../../.. ``` ```bash make verify/traffic-routing/docker-compose/with-mtls -C ../../../.. ``` ```bash make undeploy/example/docker-compose -C ../../../.. ```
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_uninstall.md

title: "glooctl uninstall" weight: 5 uninstall gloo ``` glooctl uninstall [flags] ``` ``` --all Deletes all gloo resources, including the namespace, crds, and cluster role --delete-crds Delete all gloo crds (all custom gloo objects will be deleted) --delete-namespace Delete the namespace (all objects written to this namespace will be deleted) -h, --help help for uninstall -n, --namespace string namespace in which Gloo is installed (default "gloo-system") --release-name string helm release name (default "gloo") -v, --verbose If true, output from kubectl commands will print to stdout/stderr ``` ``` -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: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: 0003-for-config-prefer-prefix-over-nesting-and-don-t-hide-defaults-in-code.md

Date: 18/08/2017 Superceded by There no agreed-upon way of handling application configuration. There are two issues this ADR aims to address. In `config.exs`, configuration keys can be nested by using a Keyword as value. Unfortunately, there is no built-in support for this nesting. For example: ``` Application.fetchenv!(:rig, :requiredkey) ``` will show a nice error, while ``` Application.fetchenv!(:rig, :requiredkey)[:required_subkey] ``` will simply return nil in case `:requiredkey` is present but `:requiredsubkey` is not. Some default values are defined where they are needed in the code, which is a problem once a key is used more than once. Also, defaults are no easily inspectable. We prefer not to nest configuration keys; instead, we prefix them where it makes sense. For example, instead of `config :rig, :kafka, clientid: :rigbrodclient` we write `config :rig, kafkaclientid: :rigbrodclient`. This allows us to leverage the built-in methods (e.g., `Application.fetchenv!`), which produce sensible error messages in case required values are not defined. We always set default values in config.exs (in turn this means that we prefer `Application.fetchenv!` over `Application.getenv`). This way, it is easy to reason about default values, and using a default value in more than one place is not an issue. We streamline the way configuration is done for the different parts of the application, which makes the configuration easier to read and reason about.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: trino.md

| Datasource | Description | |-|-| | Datasource | Select Trino. | | Datasource Name | Enter the name of the datasource. | | Description | Enter a description of the datasource. | | IP/Host Name | Enter the Trino service IP. | | Port | Enter the Trino service port. | | Username | Set the username for Trino connection. | | Password | Set the password for Trino connection. | | Database Name | Enter the database name of the Trino connection. | | jdbc connect parameters | Parameter settings for Trino connection, in JSON format. | | Datasource Definition | Define whether the data source is a test data source or an online data source | Yes, could use this datasource by default.
Project: Apache Thrift (Orchestration & Management / Remote Procedure Call)
File: committers.md

Make sure that there is an issue for the patch(s) you are about to commit in our Check out the latest version of the source code git clone https://github.com/apache/thrift.git thrift Apply the patch curl https://issues.apache.org/jira/... |git apply --ignore-space-change or curl https://github.com/<GitHub User>/thrift/commit/<Commit ID>.patch |git apply --ignore-space-change Inspect the applied patch to ensure that all are met Run the necessary unit tests and cross-language test cases to verify the patch Commit the patch git --config user.name "Your Name" git --config user.email "YourApacheID@apache.org" git add -A git commit The commit message should be in the format: THRIFT-####:<Jira description> Client: <component> Patch: <Name of person contributing the patch> Description of what was fixed or addressed. If this is a github pull request then add the below comment to automatically close the GitHub request, where #NNNN is the PR number: This closes #NNNN Double check the patch committed and that nothing was missed then push the patch git status git show HEAD git push origin master Resolve the Jira issue and set the following for the changelog Component the patch is for fixVersion to the current version on master
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: linux-devices.md

title: Apache Mesos - Linux Devices Isolator in Mesos Containerizer layout: documentation While the `cgroups/devices` isolator allows operators to control container access to host devices, the container might still need additional privileges to create a device node to actually use the device. The `linux/devices` isolator ensures that containers that are granted access to host devices are populated with the correct set of device nodes. Access to host devices is granted by using the flag on the agent. To enable the `linux/devices` isolator, append `linux/devices` to the flag when starting the Mesos agent. Device access is configured at container granularity. For example, this means that if the flag specifies read access for a device, then every process in the container will be able to read from the specified device. The `linux/devices` isolator does not require the entry to grant `mknod` access, since it creates device nodes from outside the container.
Project: Gloo (Orchestration & Management / API Gateway)
File: proxyprotocol.proto.sk.md

title: "proxyprotocol.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> ```yaml "rules": []envoy.config.listener.proxy_protocol.v3.CustomProxyProtocol.Rule "allowRequestsWithoutProxyProtocol": bool "passThroughTlvs": .solo.io.envoy.config.core.v3.ProxyProtocolPassThroughTLVs ``` | 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:: 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. | | `passThroughTlvs` | | This config controls which TLVs can be passed to filter state if it is Proxy Protocol V2 header. If there is no setting for this field, no TLVs will be passed through. .. note:: If this is configured, you likely also want to set :ref:`core.v3.ProxyProtocolConfig.passthroughtlvs <envoyv3apifieldconfig.core.v3.ProxyProtocolConfig.passthroughtlvs>`, which controls pass-through for the upstream. | ```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": .envoy.config.listener.proxy_protocol.v3.CustomProxyProtocol.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: Hango (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.
Project: Contour (Orchestration & Management / Service Proxy)
File: structured-logs.md

title: How to enable structured JSON logging This document describes how to configure structured logging for Envoy via Contour. Contour allows you to choose from a set of JSON fields that will be expanded into Envoy templates and sent to Envoy. There is a default set of fields if you enable JSON logging, and you may customize which fields you log. The list of available fields are discoverable in the following objects: are fields that have built in mappings to commonly used envoy operators. are the names of simple envoy operators that don't require arguments, they are case-insensitive when configured. are the names of complex envoy operators that require arguments. The default list of fields is available at . To enable the feature you have two options: Add `--accesslog-format=json` to your Contour startup line. Add `accesslog-format: json` to your configuration file. Without any further customization, the will be used. To customize the logged fields, add a `json-fields` list of strings to your config file. If the `json-fields` key is not specified, the will be configured. To use a value from or , simply include the name of the value in the list of strings. The JSONFields are case-sensitive, but envoySimpleOperators are not. To use or to use alternative field names, specify strings as key/value pairs like `"fieldName=%OPERATOR(...)%"`. Unknown field names in non key/value fields will result in validation errors, as will unknown Envoy operators in key/value fields. Note that the `DYNAMICMETADATA` and `FILTERSTATE` Envoy logging operators are not supported at this time due to the complexity of their validation. See the to see this used in context. Here is a sample config: ```yaml accesslog-format: json json-fields: "@timestamp" "authority" "bytes_received" "bytes_sent" "customer_id=%REQ(X-CUSTOMER-ID)%" "downstreamlocaladdress" "downstreamremoteaddress" "duration" "method" "path" "protocol" "request_id" "requestedservername" "response_code" "response_flags" "ubertraceid" "upstream_cluster" "upstream_host" "upstreamlocaladdress" "upstreamservicetime" "user_agent" "xforwardedfor" ```
Project: OpenFunction (Orchestration & Management / Scheduling & Orchestration)
File: 20220919-dapr-proxy.md

Currently, OpenFunction injects the dapr sidecar into each Function pod, which leads to following problems Function pod startup time is affected by the dapr sidecar, in my environment the startup time of the dapr sidecar is around 7 seconds. The `sidecar` mode is an blocking issue when we want to use the Function Pool to optimize the cold start speed of the Function. The `sidecar` mode means more resource overhead, which is more asymmetric for simple Functions. So, OpenFunction should support `dapr-proxy` mode. Function Pod startup time is no longer affected by the dapr sidecar. Resolve blocking issue for OpenFunction's cold start optimization. Reduce the resource overhead of Function. Once a Function CR with `openfunction.io/dapr-service-mode: "standalone"` and `openfunction.io/enable-dapr: "true"` in the `spec.serving.annotations` field is created, the function controller will: Create Dapr Proxy Deployment with annotation `dapr.io/enabled: "true"`. Set these environment variables: `FUNCCONTEXT`, `APPPROTOCOL`. Create Function Deployment with annotation `dapr.io/enabled: "false"`. Set these environment variables: `FUNCCONTEXT`, `APPPROTOCOL`, `DAPR_HOST`. Create Function Service to accept event(for async functions). ```yaml apiVersion: core.openfunction.io/v1beta1 kind: Function metadata: name: sink spec: version: "v1.0.0" image: "openfunction/sink-sample:latest" port: 8080 serving: annotations: openfunction.io/dapr-service-mode: "standalone" openfunction.io/enable-dapr: "true" runtime: "knative" template: containers: name: function imagePullPolicy: Always ``` Adjustments that need to be made: To support dapr-proxy mode, functions-framework need to get `DAPR_HOST` from env vars, init daprClient based on `DAPRHOST` and `DAPRHTTPPORT`/`DAPRGRPC_PORT`. Do not generate/init daprClient when the sync function uses the OpenFunction signature but does not define inputs and outputs. The implementation of proxy requires: The method is called when the dapr runtime starts, so we need proxy to listen on app-port. The proxy is responsible for forwarding events to the function's service(only for async functions). The proxy should support both `GRPC` and `HTTP` protocol. The proxy should support load balancing.
Project: Envoy (Orchestration & Management / Service Proxy)
File: POLICY.md

Github workflows that are not triggered by a `pull_request` generally run with the repository context/permissions. In various ways, these workflows can be triggered as the result of a `pull_request` and/or be made to run untrusted code (ie PR code). This can be useful, but carries significant risks. In particular this can effect: `pullrequesttarget` `workflow_run` `workflow_dispatch` Do not use these trigger events unless they are required. If a job requires specific permissions, these should be added on per-job basis. Global permissions should be set as follows: ```yaml permissions: contents: read ``` Likewise, any secrets that a job requires should be set per-job. It is important to restrict who can trigger these types of workflow. Do not allow any bots or app users to do so, unless this is specifically required. For example, you could add a `job` condition to prevent any bots from triggering the workflow: ```yaml if: >- ${{ github.repository == 'envoyproxy/envoy' && (github.event.schedule || !contains(github.actor, '[bot]')) }} ``` If a trusted workflow is used to run untrusted code, then the entire job that runs this code should be treated as untrusted. In this case, it is essential to ensure: no write permissions in the untrusted job no secrets in the untrusted job
Project: Contour (Orchestration & Management / Service Proxy)
File: support.md

title: Contour Support Policy layout: page This document describes which versions of Contour are supported by the Contour team. Contour is changing both to quarterly releases and three supported releases. The first Contour version covered by the quarterly release cadence is Contour v1.20, released in Jan 2022. At the time it is released, it will be the only supported version, and versions 1.21 and 1.22 will continue supporting back to Contour 1.20. When Contour 1.23 releases, Contour 1.20 will fall out of support. The following table illustrates how this will work. The given dates are estimates, not guarantees. They are our best guess as to when each version will be released. | Version | v1.19 | v1.20 | v1.21 | v1.22 | v1.23 | ||-|-|-|-|-| | Q4 2021 | | | Q1 2022 | | | | Q2 2022 | | | | | Q3 2022 | | | | | | Q4 2022 | | | | | | In short, "supported" means that Contour will issue fixes for security and other critical bugs for that release's supported lifetime. However, the project will require users to upgrade to the most recent patch release for a version to be supported. That is: The latest patch version in each release is the supported version. If you are not running the supported version from your release train, you'll need to upgrade first if you have any problems. When a new patch is cut, that will become the supported version for that release. So, if Contour 1.20.0 is the only supported version, and Contour 1.20.1 is released, then the supported version will change to 1.20.1. If, later on, the supported versions are 1.21, 1.22, and 1.23, and 1.21.1, 1.22.1, and 1.23.1 are released, then the patch releases will be the only supported versions. The latest stable release is identified by the . `:latest` is an alias for {{< param latest_version >}} which is the current stable release. `:latest` is always guaranteed to point to the highest available `:<major>.<minor>.<patch>` release. When a new `:<major>.<minor>` release track is out the `:latest` tag will move along. For example, prior to a patch release version Contour 1.20.0 was the `:latest` stable release. If Contour 1.20.1 is released, the `:latest` tag will move to that version.
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: README-iOS.md

is used to convert googletest cases to XCTest that can be run on iOS. GTMGoogleTestRunner doesn't execute the `main` function, so we can't have any test logic in `main`. However, it's ok to call `::testing::InitGoogleTest` in `main`, as `GTMGoogleTestRunner` . `grpc::testing::TestEnvironment` can also be called from `main`, as it does some test initialization (install crash handler, seed RNG) that's not strictly required to run testcases on iOS. Please follow these guidelines when porting tests to run on iOS: Tests need to use the googletest framework Any setup/teardown code in `main` needs to be moved to `SetUpTestCase`/`TearDownTestCase`, and `TEST` needs to be changed to `TEST_F`. are not supported on iOS, so use the `*IFSUPPORTED()` macros to ensure that your code compiles on iOS. For example, the following test ```c++ TEST(MyTest, TestOne) { ASSERT_DEATH(ThisShouldDie(), ""); } int main(int argc, char argv) { grpc::testing::TestEnvironment env(&argc, argv); ::testing::InitGoogleTest(&argc, argv); grpc_init(); return RUNALLTESTS(); grpc_shutdown(); } ``` should be changed to ```c++ class MyTest : public ::testing::Test { protected: static void SetUpTestCase() { grpc_init(); } static void TearDownTestCase() { grpc_shutdown(); } }; TEST_F(MyTest, TestOne) { ASSERTDEATHIF_SUPPORTED(ThisShouldDie(), ""); } int main(int argc, char argv) { grpc::testing::TestEnvironment env(&argc, argv); ::testing::InitGoogleTest(&argc, argv); return RUNALLTESTS(); } ``` Due to a in GTMGoogleTestRunner, `SetUpTestCase`/`TeardownTestCase` will be called before/after every individual test case, similar to `SetUp`/`TearDown`.