cwielenb/CNCF-Dataset huggingface dataset:
Project: APISIX (Orchestration & Management / API Gateway)
File: wasm.md

title: Wasm <!-- --> APISIX supports Wasm plugins written with . Currently, only a few APIs are implemented. Please follow to know the progress. The plugin supports the following concepts from Proxy Wasm: ``` Wasm Virtual Machine Your Plugin 1: 1 1: N VMContext PluginContext 1: N HttpContext (Http stream) ``` All plugins run in the same Wasm VM, like the Lua plugin in the Lua VM Each plugin has its own VMContext (the root ctx) Each configured route/global rules has its own PluginContext (the plugin ctx). For example, if we have a service configuring with Wasm plugin, and two routes inherit from it, there will be two plugin ctxs. Each HTTP request which hits the configuration will have its own HttpContext (the HTTP ctx). For example, if we configure both global rules and route, the HTTP request will have two HTTP ctxs, one for the plugin ctx from global rules and the other for the plugin ctx from route. First of all, we need to define the plugin in `config.yaml`: ```yaml wasm: plugins: name: wasm_log # the name of the plugin priority: 7999 # priority file: t/wasm/log/main.go.wasm # the path of `.wasm` file httprequestphase: access # default to "access", can be one of ["access", "rewrite"] ``` That's all. Now you can use the wasm plugin as a regular plugin. For example, enable this plugin on the specified route: :::note You can fetch the `admin_key` from `config.yaml` and save to an environment variable with the following command: ```bash adminkey=$(yq '.deployment.admin.adminkey[0].key' conf/config.yaml | sed 's/"//g') ``` ::: ```shell curl -i http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "uri": "/index.html", "plugins": { "wasm_log": { "conf": "blahblah" } }, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } }' ``` Attributes below can be configured in the plugin: | Name | Type | Requirement | Default | Valid | Description | | --| | -- | -- | | | | conf | string | required | | != "" | the plugin ctx configuration which can be fetched via Proxy Wasm SDK | Here is the mapping between Proxy Wasm callbacks and APISIX's phases: `proxyonconfigure`: run once there is not PluginContext for the new configuration. For example, when the first request hits the route which has Wasm plugin configured. `proxyonhttprequestheaders`: run in the access/rewrite phase, depends on the configuration of `httprequestphase`. `proxyonhttprequestbody`: run in the same phase of `proxyonhttprequestheaders`. To run this callback, we need to set property `wasmprocessreqbody` to non-empty value in `proxyonhttprequest_headers`. See `t/wasm/request-body/main.go` as an example. `proxyonhttpresponseheaders`: run in the header_filter phase. `proxyonhttpresponsebody`: run in the bodyfilter phase. To run this callback, we need to set property `wasmprocessrespbody` to non-empty value in `proxyonhttpresponseheaders`. See `t/wasm/response-rewrite/main.go` as an example. We have reimplemented some Lua plugin via Wasm, under `t/wasm/` of this repo: fault-injection forward-auth response-rewrite
Project: Contour (Orchestration & Management / Service Proxy)
File: listener-design.md

Status: Draft This document describes Contour's additional HTTP listener configuration for the purpose of separating host/port configuration for health checking and metrics services. Provide support to define custom host/port for each of the health and metrics services within Contour Maintain default backwards compatible configuration for how this is currently achieved Build a method of authentication/authorization around supporting service listeners Contour, provides listeners for health-checking (for liveness/readiness probes), and metrics(for observability). These services are often defaulted to be exposed. Allowing configuration for these additional services provides a more intentful deployment, and helps cluster operators run their application securely by default. This document proposes Contour listener configuration that should allow for custom configuration of it's exposed services. This enables end-users to maintain separate models of authentication/authorization around these services, where each of the underlying services may only be intended for specific consumers.
Project: BFE (Orchestration & Management / Service Proxy)
File: bal_state.md

The endpoint `/monitor/bal_state` exposes metrics about subcluster level load balancing. | Metric | Description | | | -- | | ERRBKNO_BACKEND | Counter for no backend found | | ERRBKNOSUBCLUSTER | Counter for no sub-cluster found | | ERRBKNOSUBCLUSTER_CROSS | Counter for no cross sub-cluster found | | ERRBKRETRYTOOMANY | Counter for reaching retry max times | | ERRGSLBBLACKHOLE | Counter for denying by blackhole |
Project: Gloo (Orchestration & Management / API Gateway)
File: sensitive.proto.sk.md

title: "sensitive.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> <!-- 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: Serverless Devs (Orchestration & Management / Scheduling & Orchestration)
File: ROADMAP.md

<h1 align="center"> <img src="https://camo.githubusercontent.com/6a8a34a2749bc61034413ff7cafc6a09c34f471e22e5a27233b1bc354c9b3a8c/68747470733a2f2f696d616765732e646576736170702e636e2f646576732d6769746875622f6c6f676f2e6a7067"> </h1> The following items are on our roadmap: Platform support: Hosted Azure Google Cloud Platform Installable Knative OpenWhisk Kubeless Function support: - - More support: More forms of serverless service supportlike Serverless Application Hosting model; Support for more BaaS products; Exploration of IAC direction; Combination with Terraform;
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: azure-sql.md

Use Azure SQL server username and password to login. | Datasource | Description | |-|| | Datasource | Select AZURE SQL. | | Datasource name | Enter the name of the DataSource. | | Description | Enter a description of the DataSource. | | IP/Host Name | Enter the AZURE SQL service Host or IP, eg: xxx.database.windows.net. | | Port | Enter the AZURE SQL service port, 1433 by default. | | Auth Mode | Set the connection auth mode. Currently support: SqlPassword,ActiveDirectoryPassword,ActiveDirectoryMSI,ActiveDirectoryServicePrincipal,accessToken. | | Username | Set the username for AZURE SQL connection. | | Password | Set the password for AZURE SQL connection. | | Database name | Enter the database name of the AZURE SQL connection. | | Jdbc connection parameters | Parameter settings for AZURE SQL connection, in JSON format. | The following only describes the different attributes. Use Azure AD username and password to login. Prerequisites: set AD account to be the admin of the Azure SQL server. Azure AD username: Azure AD account name, eg: xx@xx.onmicrosoft.com Password: Azure AD password Use Azure internal services to login. Prerequisites: set Azure virtual machine to be the admin of the Azure SQL server. MSIClientId should be VM's Application ID and it is not required. MSIClientId: input the clientId of the internal resources (eg: Azure VM, applications or Azure Active Directory application functions) of the ActiveDirectoryMSI mode. Use application (client) ID and secret to login. Prerequisites: set application to be the admin of the Azure SQL server. Meanwhile, apply for client secret for the application and use both secret and ID to login. clientId: application (client) ID clientSecret: application client secret Use application (client) ID and secret to apply for temporary token, and use token to login (not JDBC connection). clientId: application (client) ID clientSecret: application client secret OAuth 2.0 token endpoint (v2): application OAuth 2.0 token endpoint (v2) Yes, can use this datasource directly in SQL task.
Project: BFE (Orchestration & Management / Service Proxy)
File: tls_state.md

The endpoint `/monitor/tls_state` exposes metrics about TLS protocol. | Metric | Description | | | | | TLSHANDSHAKEACCEPTECDHEWITHOUT_EXT | Counter for proposing ECDHE without extensions | | TLSHANDSHAKEACCEPTSSLV2CLIENT_HELLO | Counter for accepting SSLv2 client-hello | | TLSHANDSHAKECHECKRESUMESESSION_CACHE | Counter for checking resume session cache | | TLSHANDSHAKECHECKRESUMESESSION_TICKET | Counter for checking resume session ticket | | TLSHANDSHAKEFULL_ALL | Counter for full TLS handshake | | TLSHANDSHAKEFULL_SUCC | Counter for successful TLS handshake | | TLSHANDSHAKENOSHAREDCIPHER_SUITE | Counter for no cipher suite supported by both client and server | | TLSHANDSHAKEOCSPTIMEERR | Counter for ocsp time error | | TLSHANDSHAKEREADCLIENTHELLO_ERR | Counter for reading client-hello error | | TLSHANDSHAKERESUME_ALL | Counter for resuming session | | TLSHANDSHAKERESUME_SUCC | Counter for resuming session successfully | | TLSHANDSHAKESHOULDRESUMESESSION_CACHE | Counter for resuming session by session cache | | TLSHANDSHAKESHOULDRESUMESESSION_TICKET | Counter for resuming session by session ticket | | TLSHANDSHAKESSLV2NOTSUPPORT | Counter for unsupported SSLv2 handshake received | | TLSHANDSHAKEZERO_DATA | Counter for zero data | | TLSSTATUSREQUESTEXTCOUNT | Counter for request extensions |
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.21.2.md

We are delighted to present version v1.21.2 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. A big thank you to everyone who contributed to the release. Bumps Envoy to security patch version 1.22.6. See Envoy release notes . (#4889, @sunjayBhatia) Various updates to dependencies for security updates, fixes for CI, upgrade to Go 1.18.8, and bump go module version to go 1.17. (#4885, @sunjayBhatia) For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.21.2 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: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-004.md

+++ date = "2017-01-01T10:30:31Z" description = "CoreDNS-004 Release Notes." release = "004" tags = ["Release", "004", "Notes"] title = "CoreDNS-004 Release" author = "coredns" +++ CoreDNS-004 has been ! CoreDNS is a DNS server that chains plugins, where each plugin implements a DNS feature. We are now also releasing an ARM build that can run on Raspberry Pi. file|auto*: resolve external CNAME when an upstream (new option) is specified. file|auto*: allow port numbers for transfer from/to to be specified. file|auto*: include zone's NSset in positive responses. auto*: close files and don't leak file descriptors. httpproxy*: new plugin that proxies to <https://dns.google.com> and resolves your requests over an encrypted connection. This plugin will probably be morphed into proxy at some point in the feature. Consider it experimental for the time being. metrics*: `responsesizebytes` and `requestsizebytes` export the actual length of the packet, not the advertised bufsize. log*: `{size}` is now the length in bytes of the request, `{rsize}` for the reply. Default logging is changed to show both. The following people helped with getting this release done: Chris O'Haver, Dmytro Kislov, John Belamaric, Mark Nevill, Michael Grosser, Miek Gieben, Yong Tang. If you want to help, please check out one of the and start coding! For documentation and help, see our .
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: troubleshooting.md

The admin console is configured to listen on port `19000`, so you will need to port-forward to it: ``` $ kubectl port-forward -n kusk-system deployments/kusk-gateway-envoy-fleet 19000:1900 ``` Open `http://localhost:19000` in your browser. ``` curl http://localhost:19000/configdump | jq '.configs[] | select(.["@type"] == "type.googleapis.com/envoy.admin.v3.RoutesConfigDump") | .dynamicrouteconfigs[].routeconfig.virtual_hosts[].routes[]' ``` If the command hangs at all, cancel it and run it again. You may encounter an error during the resources' deployment with kubectl like: ```shell Error from server (InternalError): error when creating "examples/todomvc/kusk-backend-api.yaml": Internal error occurred: failed calling webhook "mapi.kb.io": failed to call webhook: Post "https://kusk-gateway-webhooks-service.kusk-system.svc:443/mutate-gateway-kusk-io-v1alpha1-api?timeout=10s": context deadline exceeded ``` This means that K8s masters control plane can't call the webhooks service residing on Kusk Gateway Manager on TCP port 9443. This problem is not specific to Kusk Gateway Manager itself and is related to the configuration of your cluster and the firewall rules. To resolve this, in your firewall settings, add port 9443 to the rule containing the list of ports allowed to be accessed by K8s masters control plane.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: remote-logging.md

Apache DolphinScheduler supports writing task logs to remote storage. When remote logging is enabled, DolphinScheduler will send the task logs to the specified remote storage asynchronously after the task ends. In addition, when the user views or downloads the task log, if the log file does not exist locally, DolphinScheduler will download the corresponding log file from the remote storage to the local file system. If you deploy DolphinScheduler in `Cluster` or `Pseudo-Cluster` mode, you need to configure `api-server/conf/common.properties`, `master-server/conf/common.properties` and `worker-server/conf/common.properties`. If you deploy DolphinScheduler in `Standalone` mode, you only need to configure `standalone-server/conf/common.properties` as follows: ```properties remote.logging.enable=false remote.logging.target=OSS remote.logging.base.dir=logs remote.logging.thread.pool.size=10 ``` Configure `common.properties` as follows: ```properties remote.logging.oss.access.key.id=<access.key.id> remote.logging.oss.access.key.secret=<access.key.secret> remote.logging.oss.bucket.name=<bucket.name> remote.logging.oss.endpoint=<endpoint> ``` Configure `common.properties` as follows: ```properties remote.logging.s3.access.key.id=<access.key.id> remote.logging.s3.access.key.secret=<access.key.secret> remote.logging.s3.bucket.name=<bucket.name> remote.logging.s3.endpoint=<endpoint> remote.logging.s3.region=<region> ``` Configure `common.properties` as follows: ```properties remote.logging.google.cloud.storage.credential=/path/to/credential remote.logging.google.cloud.storage.bucket.name=<your-bucket> ``` Configure `common.properties` as follows: ```properties remote.logging.abs.account.name=<your-account-name> remote.logging.abs.account.key=<your-account-key> remote.logging.abs.container.name=<your-container-name> ``` Since Azure Blob Storage does not support the existence of empty directories, there will be empty files `<no name>` under the resource directory. But it does not affect the file display on the Dolphinscheduler resource center.
Project: Linkerd (Orchestration & Management / Service Mesh)
File: GOVERNANCE.md

This document defines project governance for Linkerd. The Linkerd maintainers are 100% committed to open governance and to being hosted by a neutral foundation. We believe that a diverse and active set of maintainers is fundamental to the long-term health of an open source project. And we want YOU to join us. &mdash; [Linkerd's Commitment to Open Governance](https://linkerd.io/2019/10/03/linkerds-commitment-to-open-governance/) Linkerd is for everyone. Anyone can become a Linkerd contributor simply by contributing to the project, whether through code, documentation, blog posts, community management, or other means. As with all Linkerd community members, contributors are expected to follow the [Linkerd Code of Conduct][coc]. All contributions to Linkerd code, documentation, or other components in the Linkerd GitHub org must follow the guidelines in . Whether these contributions are merged into the project is the prerogative of the maintainers. Directors are responsible for non-technical leadership functions within the project. This includes representing Linkerd and its maintainers to the community, to press, and to the outside world; interfacing with CNCF and other governance entities; and participating in project decision-making processes when appropriate. Directors may be elected by a majority vote of the maintainers. Maintainers have the ability to merge code into the project. Anyone can become a Linkerd maintainer (see "Becoming a maintainer" below.) Linkerd maintainers are expected to: Review pull requests, triage issues, and fix bugs in their areas of expertise, ensuring that all changes go through the project's code review and integration processes. Monitor cncf-linkerd- emails and the Linkerd Slack, and help out when possible. Rapidly respond to any time-sensitive security release processes. Attend meetings with the Linkerd Steering Committee. If a maintainer is no longer interested in or cannot perform the duties listed above, they should move themselves to emeritus status. If necessary, this can also occur through the decision-making process outlined below. Anyone can become a Linkerd maintainer. Maintainers should be extremely proficient in Go and/or Rust; have relevant domain expertise; have the time and ability to meet the maintainer expectations above; and demonstrate the ability to work with the existing maintainers and project processes. To become a maintainer, start by expressing interest to existing maintainers. Existing maintainers will then ask you to demonstrate the qualifications above by contributing PRs, doing code reviews, and other such tasks under their guidance. After several months of working together, maintainers will decide whether to grant maintainer status. Ideally, all project decisions are resolved by consensus of maintainers and directors. If this is not possible, a vote will be called. The voting process is a simple majority in which each maintainer and director receives one vote.
Project: Emissary-Ingress (Orchestration & Management / API Gateway)
File: Bug_report.md

name: Bug report about: Create a report to help us improve Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: Go to '...' Click on '....' Scroll down to '....' See error Expected behavior A clear and concise description of what you expected to happen. Versions (please complete the following information): Ambassador: [e.g. 0.32.1] Kubernetes environment [e.g. Minikube, bare metal, Google Kubernetes Engine] Version [e.g. 1.8.1] Additional context Add any other context about the problem here.
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: web-applications.md

Kusk Gatewys deploys APIs but also web applications written in any language and framework. Web application do not use OpenAPIs, so in this case to deploy a frontend application, you will need to use Kusk's `StaticRoutes`. To deploy your web application, you will need to build a container of the web app. For the purposes of this demo, we've built an example web application, containerized it and pushed it to a Docker repository. We will use this container in the example. ```sh kubectl create deployment web-app --image=kubeshop/kusk-web-app-example:v1.0.0 kubectl expose deployment web-app --name web-app-svc --port=3000 ``` ```yaml title="static-route.yaml" apiVersion: gateway.kusk.io/v1alpha1 kind: StaticRoute metadata: name: web-app-sample spec: fleet: name: kusk-gateway-envoy-fleet namespace: kusk-system upstream: service: name: web-app-svc namespace: default port: 3000 ``` And apply the Custom Resource containing the deployment details of your web application: ```sh kubectl apply -f static-route.yaml ``` ```sh title="Expected output" staticroute.gateway.kusk.io/web-app-sample created ``` Get the IP address information of Kusk: ```sh kusk ip 12.34.56.78 ``` And visit that URL in the browser: That's it, with these simple steps your web application is now deployed in Kubernetes using Kusk! You'll also be surprise by how easy it is to add OAuth to your web application so easily using Kusk, check the .
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: api-c.md

title: "C API" linkTitle: "C API" weight: 101 manualLink: /docs/++version++/api/c/ <!-- 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 C API documentation can be found <a href="/docs/++version++/api/c/">here</a>.
Project: Gloo (Orchestration & Management / API Gateway)
File: https_redirect.md

title: HTTPS Redirect weight: 20 description: Route HTTP traffic to HTTPS services To help users or old services find your https endpoints, it is a common practice to redirect http traffic to https endpoints. With Gloo Edge, this is a simple matter of creating an auxiliary http virtual service that routes to your full {{% protobuf display="https virtual service" name="gateway.solo.io.VirtualService" %}} Here is an example redirect config (which is used to host these docs). Please take note of a few details which enable this behavior: There are two virtual services, an "auxiliary" and a "main" virtual service. The main VS is an https VS because it specifies an {{% protobuf name="gloo.solo.io.SslConfig" display="sslConfig" %}} The auxiliary VS is an http VS because it does not specify an {{% protobuf name="gloo.solo.io.SslConfig" display="sslConfig" %}} The domain listed in the auxiliary VS matches that of the main VS. The auxiliary VS has a single route which matches all traffic and applies a {{% protobuf display="redirectAction" name="gloo.solo.io.RedirectAction" %}} with `httpsRedirect: true` specified. {{< highlight yaml "hl_lines=9-10 14-16 25-30 32-33" >}} apiVersion: gateway.solo.io/v1 kind: VirtualService metadata: name: docsmgmt-http namespace: docs spec: virtualHost: domains: docs.solo.io routes: matchers: prefix: / redirectAction: hostRedirect: docs.solo.io httpsRedirect: true apiVersion: gateway.solo.io/v1 kind: VirtualService metadata: name: docsmgmt namespace: docs spec: sslConfig: secretRef: name: docs.solo.io namespace: gloo-system sniDomains: docs.solo.io virtualHost: domains: 'docs.solo.io' routes: matchers: {{< /highlight >}}
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-apis-create-steps.md

4 steps will guide you to create your API. . General required Configure your API's name, version, description and context-path. . Proxy required Specify you backend endpoint. . Plan optional To subscribe to an API, you must publish one or more Plans. A Plan will allow you to gain access of the API operations. A Plan can be keyless (public access) or restricted with an API-Key. Auto-validation mode tells you if a manual action is required to validate a subscription request. . Documentation optional Import documentation to make them available to the application teams. Support four types of document: Swagger/OpenApi, AsyncApi, Markdown and AsciiDoc.