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

title: "Traefik Ping Documentation" description: "In Traefik Proxy, Ping lets you check the health of your Traefik instances. Read the technical documentation for configuration examples and options." Checking the Health of Your Traefik Instances {: .subtitle } To enable the API handler: ```yaml tab="File (YAML)" ping: {} ``` ```toml tab="File (TOML)" [ping] ``` ```bash tab="CLI" --ping=true ``` The `/ping` health-check URL is enabled with the command-line `--ping` or config file option `[ping]`. The `entryPoint` where the `/ping` is active can be customized with the `entryPoint` option, whose default value is `traefik` (port `8080`). | Path | Method | Description | |||--| | `/ping` | `GET`, `HEAD` | An endpoint to check for Traefik process liveness. Return a code `200` with the content: `OK` | !!! note The `cli` comes with a command which can be used for calling this endpoint. Optional, Default="traefik" Enabling /ping on a dedicated EntryPoint. ```yaml tab="File (YAML)" entryPoints: ping: address: ":8082" ping: entryPoint: "ping" ``` ```toml tab="File (TOML)" [entryPoints] [entryPoints.ping] address = ":8082" [ping] entryPoint = "ping" ``` ```bash tab="CLI" --entryPoints.ping.address=:8082 --ping.entryPoint=ping ``` Optional, Default=false If `manualRouting` is `true`, it disables the default internal router in order to allow one to create a custom router for the `ping@internal` service. ```yaml tab="File (YAML)" ping: manualRouting: true ``` ```toml tab="File (TOML)" [ping] manualRouting = true ``` ```bash tab="CLI" --ping.manualrouting=true ``` Optional, Default=503 During the period in which Traefik is gracefully shutting down, the ping handler returns a `503` status code by default. If Traefik is behind, for example a load-balancer doing health checks (such as the Kubernetes LivenessProbe), another code might be expected as the signal for graceful termination. In that case, the terminatingStatusCode can be used to set the code returned by the ping handler during termination. ```yaml tab="File (YAML)" ping: terminatingStatusCode: 204 ``` ```toml tab="File (TOML)" [ping] terminatingStatusCode = 204 ``` ```bash tab="CLI" --ping.terminatingStatusCode=204 ```
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: feature_request_csharp.md

name: Request a gRPC C# feature about: Suggest an idea for this project labels: kind/enhancement, priority/P2, lang/C# assignees: apolcyn <!-- PLEASE DO NOT POST A QUESTION HERE. This form is for bug reports and feature requests ONLY! For general questions and troubleshooting, please ask/look for answers at StackOverflow, with "grpc" tag: https://stackoverflow.com/questions/tagged/grpc For questions that specifically need to be answered by gRPC team members, please ask/look for answers at grpc.io mailing list: https://groups.google.com/forum/#!forum/grpc-io Issues specific to grpc-java, grpc-go, grpc-node, grpc-dart, grpc-web should be created in the repository they belong to (e.g. https://github.com/grpc/grpc-LANGUAGE/issues/new) --> A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] A clear and concise description of what you want to happen. A clear and concise description of any alternative solutions or features you've considered. Add any other context about the feature request here.
Project: Knative (Orchestration & Management / Scheduling & Orchestration)
File: MIGRATION_GUIDE.md

Starting from , the import path will be: "github.com/golang-jwt/jwt/v4" The `/v4` version will be backwards compatible with existing `v3.x.y` tags in this repo, as well as `github.com/dgrijalva/jwt-go`. For most users this should be a drop-in replacement, if you're having troubles migrating, please open an issue. You can replace all occurrences of `github.com/dgrijalva/jwt-go` or `github.com/golang-jwt/jwt` with `github.com/golang-jwt/jwt/v4`, either manually or by using tools such as `sed` or `gofmt`. And then you'd typically run: ``` go get github.com/golang-jwt/jwt/v4 go mod tidy ``` The original migration guide for older releases can be found at https://github.com/dgrijalva/jwt-go/blob/master/MIGRATION_GUIDE.md.
Project: kcp (Orchestration & Management / Scheduling & Orchestration)
File: built-in.md

kcp includes some, but not all, of the APIs you are likely familiar with from Kubernetes: Namespaces ConfigMaps Secrets Events LimitRanges ResourceQuotas ServiceAccounts MutatingWebhookConfigurations ValidatingWebhookConfigurations CustomResourceDefinitions TokenReviews LocalSubjectAccessReviews SelfSubjectAccessReviews SelfSubjectRulesReviews SubjectAccessReviews CertificateSigningRequests Leases Events FlowSchemas PriorityLevelConfigurations ClusterRoleBindings ClusterRoles RoleBindings Roles Notably, workload-related APIs (Pods, ReplicaSets, Deployments, Jobs, CronJobs, StatefulSets), cluster-related APIs ( Nodes), storage-related APIs (PersistentVolumes, PersistentVolumeClaims) are all missing - kcp does not include these, and it instead relies on workload clusters to provide this functionality.
Project: Kuma (Orchestration & Management / Service Mesh)
File: 045-route-transition.md

Status: accepted This document is meant to make explicit how we will transition from `TrafficRoute` to `MeshTCPRoute` and `MeshHTTPRoute` and also how these policies interact with each other. With the new paradigm "no default creation for 2.0 policies" it becomes necessary for traffic to flow when there are no `TrafficRoutes` and no `MeshTCPRoutes`/`MeshHTTPRoute`. This break from the behavior of `TrafficRoutes` and the ensuing migration need some careful consideration. When installing Kuma, traffic should continue to flow assuming the user takes no explicit action to configure routing. Avoid creation of resources by the CP when a `Mesh` is created Provide a smooth transition for `TrafficRoutes` to `Mesh*Route` Depend on the existence of any `TrafficRoute` resources in the `Mesh` to determine which behavior wins. So when would we generate Envoy listeners and routes allowing traffic to flow from service A to B? | | Any `TrafficRoutes` resource exists | No `TrafficRoutes` | | - | -- | -- | | Some `MeshRoute.spec.to` targets `B` | configured by `MeshRoute` | configured by `Mesh*Route` | | No `MeshRoute.spec.to` targets `B` | configured by `TrafficRoutes` | traffic flows, configured by `MeshRoute` | Note that currently, no `TrafficRoutes`, no `Mesh*Routes` would mean a broken cluster and is therefore in some sense an invalid state. This state is the only one for which behavior changes in a breaking way. Right now, we require a `TrafficRoute` to exist in order to route traffic if there are no `Mesh*Routes` matching a given data plane proxy. This will no longer be necessary. | | Both exist | Some `MeshHTTPRoute`, no `MeshTCPRoute` | No `MeshHTTPRoute`, no `MeshTCPRoute` | No `MeshHTTPRoute`, some `MeshTCPRoute` | | | -- | | - | | | `HTTP` | configured by `MeshHTTPRoute` | configured by `MeshHTTPRoute` | configured by `MeshHTTPRoute` | configured by `MeshTCPRoute`, as TCP | Routes to `TCP` protocol services are always configured by `MeshTCPRoute`. Users can transition to the intended behavior of `Mesh*Route` where no resource is necessary None?
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: aggregatedapi_test.md

| Test Case | E2E Describe Text | Comments | |--|--|-| | Serviceaccount Access to the member1 cluster's `/api` and `api/v1/nodes` with/without right | tom access the member1 cluster api with and without right | | | Serviceaccount Access to the member2 cluster's `/api` without right | tom access the member2 cluster without right | | | Serviceaccount Access to the specified cluster's `/api` and `api/v1/nodes` with/without right | tom access the specified cluster with/without right | |
Project: Contour (Orchestration & Management / Service Proxy)
File: prometheus.md

title: Collecting Metrics with Prometheus <div id="toc" class="navigation"></div> Envoy typically through an endpoint on its admin interface. To avoid exposing the entire admin interface to Prometheus (and other workloads in the cluster), Contour configures a static listener that sends traffic to the stats endpoint and nowhere else. Envoy supports Prometheus-compatible `/stats/prometheus` endpoint for metrics on port `8002`. Contour exposes a Prometheus-compatible `/metrics` endpoint that defaults to listening on port 8000. This can be configured by using the `--http-address` and `--http-port` flags for the `serve` command. Note: the `Service` deployment manifest when installing Contour must be updated to represent the same port as the configured flag. The metrics endpoint exposes the following metrics: {{% metrics-table %}} Follow the instructions to install a monitoring stack to your cluster using the project sample manifests. These instructions install the , a instance, a `Deployment`, and other components. Note that this is a quickstart installation, see documentation for more details on customizing the installation for production usage. The instructions above show how to access the Prometheus and Grafana web interfaces using `kubectl port-forward`. Sample `HTTPProxy` resources in the `examples/` directory can also be used to access these through your Contour installation: ```sh $ kubectl apply -f examples/prometheus/httpproxy.yaml $ kubectl apply -f examples/grafana/httpproxy.yaml ``` To enable Prometheus to scrape metrics from the Contour and Envoy pods, we can add some RBAC customizations with a `Role` and `RoleBinding` in the `projectcontour` namespace: ```sh kubectl apply -f examples/prometheus/rbac.yaml ``` Now add resources for scraping metrics from Contour and Envoy pods in the `projectcontour` namespace: ```sh kubectl apply -f examples/prometheus/podmonitors.yaml ``` You should now be able to browse Contour and Envoy Prometheus metrics in the Prometheus and Grafana web interfaces to create dashboards and alerts. Some sample Grafana dashboards are provided as `ConfigMap` resources in the `examples/grafana` directory. To use them with your Grafana installation, apply the resources: ```sh $ kubectl apply -f examples/grafana/dashboards.yaml ``` And update the Grafana `Deployment`: ```sh $ kubectl -n monitoring patch deployment grafana --type=json --patch-file examples/grafana/deployment-patch.json ``` You should now see dashboards for Contour and Envoy metrics available in the Grafana web interface.
Project: Envoy (Orchestration & Management / Service Proxy)
File: http3_upstream.md

Support for Upstream HTTP/3 connections is slightly more complex than for HTTP/1 or HTTP/2 and requires specific configurations to enable it. If HTTP/3 is configured in auto_config, HTTP/3 connections will only be attempted to servers which advertise HTTP/3 support either via or the . If no such advertisement exists, then HTTP/2 or HTTP/1 will be used instead. Further, HTTP/3 runs over QUIC (which uses UDP) and not over TCP (which HTTP/1 and HTTP/2 use). It is not uncommon for network devices to block UDP traffic, and hence block HTTP/3. This means that upstream HTTP/3 connection attempts might be blocked by the network and should fall back to using HTTP/2. On such networks, the upstream connection code needs to track that HTTP/3 connects attempts are not succeeding and avoid making connections which are doomed to fail. On networks where HTTP/3 is working correctly, however, the upstream connection code should avoid attempting HTTP/2 unnecessarily. The `BrokenHttp3Tracker` is a per-grid object which tracks the state of HTTP/3 for that grid. When HTTP/3 is marked as broken, it remains broken for 5 minutes after which point it is no longer broken. If it is marked as broken again, it remains broken for twice the previous period, up to a maximum of 1 day. If it is instead marked as confirmed, then the period is reset to the default and the next time HTTP/3 is marked as broken it will be for the initial 5 minutes. The `HttpServerPropertiesCache` is responsible for tracking servers which advertise HTTP/3. These advertisements may arrive via HTTP Alternative Service (alt-svc) or soon via the HTTPS DNS RR. Currently only advertisements which specify the same hostname and port are stored. The `ConnectivityGrid` is a `ConnectionPool` which wraps a `Http3ConnPoolImpl` connection pool (QUIC) and a `HttpConnPoolImplMixed` connection pool (TCP). If HTTP/3 is currently broken, stream requests will be sent directly to the mixed connection pool. If HTTP/3 is not advertised in the alternate protocols cache, stream requests will be sent directly to the mixed connection pool. If, however, HTTP/3 is advertised and working then the request will be sent to the HTTP/3 connection pool. After 300ms, if this request has not succeeded, then the request will also be sent to the mixed pool, and whichever succeeds first will be passed back up to the caller. Specific Envoy configuration is required in order to enable the previously described components. The Alternate Protocols Cache Filter must be enabled in order for alt-svc headers to be parsed and stored in the cache, and the `alternateprotocolscache_options` field must be specified in the filter config. The "Auto" must be enabled via the Upstream `HttpProtocolOptions` message. The `upstreamprotocoloptions` field needs to specify `auto_config`. This config muse specify all three protocols: HTTP/1, HTTP/2 and HTTP/3. In addition, the `alternateprotocolscache_options` field must be specified in `upstreamprotocoloptions` and the value must match that in the filter config.
Project: OpenFunction (Orchestration & Management / Scheduling & Orchestration)
File: 202112-support-function-tracing.md

Tracing is important to functions. We need to support popular tracing technologies like SkyWalking and OpenTelemetry. Users can select to use SkyWalking/OpenTelemetry for tracing or turn function tracing off. Tracing code and options should be added in the function framework instead of user functions. Global level tracing plugin setting can be added to a configmap named `openfunction-config` in the `openfunction` namespace: ```yaml apiVersion: v1 kind: ConfigMap metadata: labels: app.kubernetes.io/version: v0.5.0 name: openfunction-config namespace: openfunction data: plugins.tracing: | enabled: true provider: name: "skywalking" oapServer: "localhost:xxx" tags: func: function-with-tracing layer: faas tag1: value1 tag2: value2 baggage: key: sw8-correlation # key should be baggage for opentelemetry value: "base64(string key):base64(string value),base64(string key2):base64(string value2)" ``` Function level tracing plugin setting can be added to the annotation of the Serving CRD and pass these options via function context to function framework: ```yaml apiVersion: core.openfunction.io/v1alpha2 kind: Function metadata: name: function-with-tracing annotations: plugins.tracing: | enabled: true provider: name: "skywalking" oapServer: "localhost:xxx" tags: func: function-with-tracing layer: faas tag1: value1 tag2: value2 baggage: key: sw8-correlation # key should be baggage for opentelemetry value: "base64(string key):base64(string value),base64(string key2):base64(string value2)" spec: serving: runtime: "OpenFuncAsync" ``` Changes to function context: ```json { "name": "function-with-tracing", "version": "v1", "requestID": "a0f2ad8d-5062-4812-91e9-95416489fb01", "port": "50002", "inputs": {}, "outputs": {}, "runtime": "OpenFuncAsync", "state": "", "plugins.tracing": { "enabled": true, "provider": { "name": "skywalking", "oapServer": "localhost:xxx" }, "tags": [ { "func": "function-with-tracing" }, { "layer": "faas" }, { "tag1": "value1" }, { "tag2": "value2" } ], "baggage": { "key": "sw8-correlation", "value": "base64(string key):base64(string value),base64(string key2):base64(string value2)" } } } ```
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: api.md

This resource uses an OpenAPI file with x-kusk annotations as the source of truth to configure routing. Refer to for the further information on how to add routing information to OpenAPI file. The required field of API resource is `spec.spec` where `x-kusk`-enhanced OpenAPI file is supplied as an embedded string. You can generate API resources from an OpenAPI definition (and integrate into your CI) using the Kusk CLI - see . The optional spec.fleet field specifies to what Envoy Fleet (Envoy Proxy instances with the exposing K8s Service) this configuration applies. The fleet.name and fleet.namespace fields reference the deployed Envoy Fleet Custom Resource name and namespace. Deploy your API configuration in any namespace with any name and it will be applied to the specific Envoy Fleet. If this option is missing, auto-detection will be performed to find the single fleet deployed in the Kubernetes cluster fleet, which is considered as the default fleet. The deployed API custom resource will be changed to map to that fleet accordingly. If there are multiple fleets deployed, the spec.fleet is required to specify in the manifest. Once the resource manifest is deployed, Kusk Gateway Manager will use it to configure routing for Envoy Fleet. Multiple resources can exist in different namespaces; all of them will be evaluated and the configuration merged on any update with these resources. Trying to apply a resource that has conflicting routes with the existing resources (i.e. same HTTP method and path) will result in error. Currently, the resource status* field is not updated by the manager when the configuration process finishes. Example: ```yaml apiVersion: gateway.kusk.io/v1alpha1 kind: API metadata: name: api-sample spec: fleet: name: default namespace: default spec: | openapi: 3.0.2 servers: url: /api/v3 info: description: Some description version: 1.0.0 title: the best API in the world x-kusk: disabled: false hosts: [ "*" ] cors: origins: "*" methods: POST GET OPTIONS headers: Content-Type credentials: true expose_headers: X-Custom-Header1 max_age: 86200 upstream: service: name: oldapi namespace: default port: 80 rewrite: pattern: "^/api" substitution: "" path: prefix: /api paths: /pet: x-kusk: disabled: true post: x-kusk: disabled: false upstream: host: hostname: newapi.default.svc.cluster.local port: 8080 skipped put: summary: Update pet description: Update an existing pet by Id operationId: updatePet skipped ```
Project: Traefik (Orchestration & Management / API Gateway)
File: include-dashboard-examples.md

```yaml tab="Docker & Swarm" labels: "traefik.http.routers.dashboard.rule=Host(`traefik.example.com`) && (PathPrefix(`/api`) || PathPrefix(`/dashboard`))" "traefik.http.routers.dashboard.service=api@internal" "traefik.http.routers.dashboard.middlewares=auth" "traefik.http.middlewares.auth.basicauth.users=test:$$apr1$$H6uskkkW$$IgXLP6ewTrSuBkTrqE8wj/,test2:$$apr1$$d9hr9HBB$$4HxwgUir3HP4EsggP/QNo0" ``` ```yaml tab="Docker (Swarm)" deploy: labels: "traefik.http.routers.dashboard.rule=Host(`traefik.example.com`) && (PathPrefix(`/api`) || PathPrefix(`/dashboard`))" "traefik.http.routers.dashboard.service=api@internal" "traefik.http.routers.dashboard.middlewares=auth" "traefik.http.middlewares.auth.basicauth.users=test:$$apr1$$H6uskkkW$$IgXLP6ewTrSuBkTrqE8wj/,test2:$$apr1$$d9hr9HBB$$4HxwgUir3HP4EsggP/QNo0" "traefik.http.services.dummy-svc.loadbalancer.server.port=9999" ``` ```yaml tab="Kubernetes CRD" apiVersion: traefik.io/v1alpha1 kind: IngressRoute metadata: name: traefik-dashboard spec: routes: match: Host(`traefik.example.com`) && (PathPrefix(`/api`) || PathPrefix(`/dashboard`)) kind: Rule services: name: api@internal kind: TraefikService middlewares: name: auth apiVersion: traefik.io/v1alpha1 kind: Middleware metadata: name: auth spec: basicAuth: secret: secretName # Kubernetes secret named "secretName" ``` ```yaml tab="Consul Catalog" "traefik.http.routers.dashboard.rule=Host(`traefik.example.com`) && (PathPrefix(`/api`) || PathPrefix(`/dashboard`))" "traefik.http.routers.dashboard.service=api@internal" "traefik.http.routers.dashboard.middlewares=auth" "traefik.http.middlewares.auth.basicauth.users=test:$$apr1$$H6uskkkW$$IgXLP6ewTrSuBkTrqE8wj/,test2:$$apr1$$d9hr9HBB$$4HxwgUir3HP4EsggP/QNo0" ``` ```yaml tab="File (YAML)" http: routers: dashboard: rule: Host(`traefik.example.com`) && (PathPrefix(`/api`) || PathPrefix(`/dashboard`)) service: api@internal middlewares: auth middlewares: auth: basicAuth: users: "test:$apr1$H6uskkkW$IgXLP6ewTrSuBkTrqE8wj/" "test2:$apr1$d9hr9HBB$4HxwgUir3HP4EsggP/QNo0" ``` ```toml tab="File (TOML)" [http.routers.my-api] rule = "Host(`traefik.example.com`) && (PathPrefix(`/api`) || PathPrefix(`/dashboard`))" service = "api@internal" middlewares = ["auth"] [http.middlewares.auth.basicAuth] users = [ "test:$apr1$H6uskkkW$IgXLP6ewTrSuBkTrqE8wj/", "test2:$apr1$d9hr9HBB$4HxwgUir3HP4EsggP/QNo0", ] ```
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.9.0-released.md

title: "Avro 1.9.0" linkTitle: "Avro 1.9.0" date: 2019-05-14 <!-- 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.9.0 has been released!
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: db2.md

| Datasource | Description | |-|--| | Datasource | Select DB2. | | Datasource Name | Enter the name of the datasource. | | Description | Enter a description of the datasource. | | IP/Host Name | Enter the DB2 service IP. | | Port | Enter the DB2 service port. | | Username | Set the username for DB2 connection. | | Password | Set the password for DB2 connection. | | Database Name | Enter the database name of the DB2 connection. | | jdbc connect parameters | Parameter settings for DB2 connection, in JSON format. | Yes, could use this datasource by default.
Project: OpenNebula (Orchestration & Management / Scheduling & Orchestration)
File: enhancement-request.md

name: New Feature request about: Suggest an idea to improve OpenNebula labels: 'Type: Feature' Description Brief description of the new functionality Use case How are you going to use this new feature? Why do you need it? Interface Changes Describe any changes you'd like to see to current interfaces including Sunstone, CLI, or/and API Additional Context Please feel free to add any other context or screenshots about the feature request here. Or any other alternative you have considered to address this new feature. <!--////////////////////////////////////////////--> <!-- THIS SECTION IS FOR THE DEVELOPMENT TEAM --> <!-- BOTH FOR BUGS AND ENHANCEMENT REQUESTS --> <!-- PROGRESS WILL BE REFLECTED HERE --> <!--////////////////////////////////////////////--> [ ] Code committed [ ] Testing - QA [ ] Documentation (Release notes - resolved issues, compatibility, known issues)