cwielenb/CNCF-Dataset huggingface dataset:
Project: Apache Thrift (Orchestration & Management / Remote Procedure Call)
File: centos.md

Starting with a minimal installation, the following steps are required to build Apache Thrift on Centos 6.5. This example builds from source, using the current development master branch. These instructions should also work with Apache Thrift releases beginning with 0.9.2. sudo yum -y update sudo yum -y groupinstall "Development Tools" sudo yum install -y wget wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz tar xvf autoconf-2.69.tar.gz cd autoconf-2.69 ./configure --prefix=/usr make sudo make install cd .. wget http://ftp.gnu.org/gnu/automake/automake-1.14.tar.gz tar xvf automake-1.14.tar.gz cd automake-1.14 ./configure --prefix=/usr make sudo make install cd .. wget http://ftp.gnu.org/gnu/bison/bison-2.5.1.tar.gz tar xvf bison-2.5.1.tar.gz cd bison-2.5.1 ./configure --prefix=/usr make sudo make install cd .. All languages require the Apache Thrift IDL Compiler and at this point everything needed to make the IDL Compiler is installed (if you only need the compiler you can skip to the Build step). If you will be developing Apache Thrift clients/servers in C++ you will also need additional packages to support the C++ shared library build. sudo yum -y install libevent-devel zlib-devel openssl-devel wget http://sourceforge.net/projects/boost/files/boost/1.56.0/boost156_0.tar.gz tar xvf boost156_0.tar.gz cd boost156_0 ./bootstrap.sh sudo ./b2 install git clone https://github.com/apache/thrift.git cd thrift ./bootstrap.sh ./configure --with-lua=no make sudo make install This will build the compiler (thrift/compiler/cpp/thrift --version) and any language libraries supported. The make install step installs the compiler on the path: /usr/local/bin/thrift You can use the ./configure --enable-libs=no switch to build the Apache Thrift IDL Compiler only without lib builds. To run tests use "make check".
Project: Gloo (Orchestration & Management / API Gateway)
File: semantic_version.proto.sk.md

title: "semantic_version.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Envoy uses SemVer (https://semver.org/). Major/minor versions indicate expected behaviors and APIs, the patch version field is used only for security fixes and can be generally ignored. ```yaml "majorNumber": int "minorNumber": int "patch": int ``` | Field | Type | Description | | -- | - | -- | | `majorNumber` | `int` | | | `minorNumber` | `int` | | | `patch` | `int` | | <!-- 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: Kubernetes (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: Gloo (Orchestration & Management / API Gateway)
File: placement.proto.sk.md

title: "placement.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Object Metadata to be written with the resource into the remote cluster ```yaml "annotations": map<string, string> "labels": map<string, string> "name": string ``` | Field | Type | Description | | -- | - | -- | | `annotations` | `map<string, string>` | | | `labels` | `map<string, string>` | | | `name` | `string` | | ```yaml "clusters": map<string, .core.fed.solo.io.PlacementStatus.Cluster> "state": .core.fed.solo.io.PlacementStatus.State "message": string "observedGeneration": int "writtenBy": string ``` | Field | Type | Description | | -- | - | -- | | `clusters` | `map<string, .core.fed.solo.io.PlacementStatus.Cluster>` | map containing the name of the cluster, with the associated Cluster namespaces. | | `state` | | | | `message` | `string` | | | `observedGeneration` | `int` | metadata.Generation of the resource which has been processed. | | `writtenBy` | `string` | A field indicating the entity responsible for writing this status. This is useful for determining if the pod has been restarted since the resource was processed. Typically this value will be set to metadata.name of the pod. | ```yaml "state": .core.fed.solo.io.PlacementStatus.State "message": string ``` | Field | Type | Description | | -- | - | -- | | `state` | | | | `message` | `string` | | ```yaml "namespaces": map<string, .core.fed.solo.io.PlacementStatus.Namespace> ``` | Field | Type | Description | | -- | - | -- | | `namespaces` | `map<string, .core.fed.solo.io.PlacementStatus.Namespace>` | map containing the name of the namespace, with the associated status. | | Name | Description | | -- | -- | | `UNKNOWN` | UNKNOWN indicates that the system does not know the placement status of the resource. | | `PLACED` | PLACED indicates that the resource has been placed as specified. | | `FAILED` | FAILED indicates that the resource could not be placed in a specified destination. | | `STALE` | STALE indicates that the resource continues to be present in a destination that is no longer specified. | | `INVALID` | INVALID indicates that the resource cannot be placed as specified because one or more destinations do not exist. | | `PENDING` | PENDING indicates that the resource is waiting to be processed. | <!-- 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: APISIX (Orchestration & Management / API Gateway)
File: ua-restriction.md

title: ua-restriction keywords: Apache APISIX API Gateway UA restriction description: This document contains information about the Apache APISIX ua-restriction Plugin, which allows you to restrict access to a Route or Service based on the User-Agent header with an allowlist and a denylist. <!-- --> The `ua-restriction` Plugin allows you to restrict access to a Route or Service based on the `User-Agent` header with an `allowlist` and a `denylist`. A common scenario is to set crawler rules. `User-Agent` is the identity of the client when sending requests to the server, and the user can allow or deny some crawler request headers in the `ua-restriction` Plugin. | Name | Type | Required | Default | Valid values | Description | |-||-|--|-|| | bypass_missing | boolean | False | false | | When set to `true`, bypasses the check when the `User-Agent` header is missing. | | allowlist | array[string] | False | | | List of allowed `User-Agent` headers. | | denylist | array[string] | False | | | List of denied `User-Agent` headers. | | message | string | False | "Not allowed" | | Message with the reason for denial to be added to the response. | :::note `allowlist` and `denylist` can't be configured at the same time. ::: You can enable the Plugin on a Route or a Service as shown below: :::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 http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "uri": "/index.html", "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } }, "plugins": { "ua-restriction": { "bypass_missing": true, "denylist": [ "my-bot2", "(Twitterspider)/(\\d+)\\.(\\d+)" ], "message": "Do you want to do something bad?" } } }' ``` Send a request to the route: ```shell curl http://127.0.0.1:9080/index.html -i ``` You should receive an `HTTP/1.1 200 OK` response. Now if the `User-Agent` header is in the `denylist` i.e the bot User-Agent: ```shell curl http://127.0.0.1:9080/index.html --header 'User-Agent: Twitterspider/2.0' ``` You should receive an `HTTP/1.1 403 Forbidden` response with the following message: ```text {"message":"Do you want to do something bad?"} ``` To remove the `ua-restriction` Plugin, you can delete the corresponding JSON configuration from the Plugin configuration. APISIX will automatically reload and you do not have to restart for this to take effect. ```shell curl http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "uri": "/index.html", "plugins": {}, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } }' ```
Project: Gloo (Orchestration & Management / API Gateway)
File: authority.proto.sk.md

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

name: Membership Request about: New Membership for Clusterpedia title: "[MEMBERSHIP REQUEST] New Member of Clusterpedia" labels: kind/membership assignees: Iceber I'm requesting to be a Member of Clusterpedia Community. <!-- As a Member, we expect you to have merged at least three pr in the clusterpedia repo. --> <!-- Optional --> <!-- Optional, the issues you responded to or created. -->
Project: Gloo (Orchestration & Management / API Gateway)
File: tcp.proto.sk.md

title: "tcp.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Contains various settings for Envoy's tcp proxy filter. See here for more information: https://www.envoyproxy.io/docs/envoy/v1.10.0/api-v2/config/filter/network/tcpproxy/v2/tcpproxy.proto#envoy-api-msg-config-filter-network-tcp-proxy-v2-tcpproxy ```yaml "maxConnectAttempts": .google.protobuf.UInt32Value "idleTimeout": .google.protobuf.Duration "tunnelingConfig": .tcp.options.gloo.solo.io.TcpProxySettings.TunnelingConfig "accessLogFlushInterval": .google.protobuf.Duration ``` | Field | Type | Description | | -- | - | -- | | `maxConnectAttempts` | | | | `idleTimeout` | | | | `tunnelingConfig` | | If set, this configures tunneling, e.g. configuration options to tunnel multiple TCP payloads over a shared HTTP tunnel. If this message is absent, the payload will be proxied upstream as per usual. | | `accessLogFlushInterval` | | If set, Envoy will flush the access log on this time interval. Must be a minimum of 1 ms. By default, will only write to the access log when a connection is closed. | Configuration for tunneling TCP over other transports or application layers. ```yaml "hostname": string "headersToAdd": []tcp.options.gloo.solo.io.HeaderValueOption ``` | Field | Type | Description | | -- | - | -- | | `hostname` | `string` | The hostname to send in the synthesized CONNECT headers to the upstream proxy. | | `headersToAdd` | | Additional request headers to be sent to upstream proxy. Mainly used to trigger upstream to convert POST request back to CONNECT requests. | Header name/value pair plus option to control append behavior. ```yaml "header": .tcp.options.gloo.solo.io.HeaderValue "append": .google.protobuf.BoolValue ``` | Field | Type | Description | | -- | - | -- | | `header` | | Header name/value pair that this option applies to. | | `append` | | If true (default), the value is appended to existing values. | Header name/value pair. ```yaml "key": string "value": string ``` | Field | Type | Description | | -- | - | -- | | `key` | `string` | Header name. | | `value` | `string` | Header value. | <!-- 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: Easegress (Orchestration & Management / API Gateway)
File: 3.06.Service-Registry.md

- - Easegress servers as a reverse proxy. It can easily integrate with mainstream Service Registries. ```yaml name: pipeline-reverse-proxy kind: Pipeline flow: filter: proxy filters: name: proxy kind: Proxy pools: servers: url: http://127.0.0.1:9095 url: http://127.0.0.1:9096 url: http://127.0.0.1:9097 loadBalance: policy: roundRobin ``` We integrate `Proxy` with service registries such as , , , . You need to create one of them to connect the external service registry. The service registry config takes higher priority than static servers. If the dynamic servers pulling failed, it will use static servers if there are. First we need to create a ZookeeperServiceRegistry in Easegress ``` yaml kind: ZookeeperServiceRegistry name: zookeeper-001 zkservices: [127.0.0.1:2181] prefix: /services conntimeout: 6s syncInterval: 10s ``` Create a pipeline and set its `serviceRegistry` field into `zookeeper-001` and it will look up the zookeeper configuration for the service named `springboot-application-order` as in field `serviceName`. ```yaml name: pipeline-reverse-proxy kind: Pipeline flow: filter: proxy filters: name: proxy kind: Proxy pools: servers: url: http://127.0.0.1:9095 url: http://127.0.0.1:9096 url: http://127.0.0.1:9097 serviceRegistry: zookeeper-001 # + serviceName: springboot-application-order # + loadBalance: policy: roundRobin ``` First we need to create a ConsulServiceRegistry in Easegress ```yaml kind: ConsulServiceRegistry name: consul-001 address: '127.0.0.1:8500' scheme: http syncInterval: 10s ``` Create a pipeline and set its `serviceRegistry` field into `consul-001` and it will look up the consul configuration for the service named `springboot-application-order` as in field `serviceName`. ```yaml name: pipeline-reverse-proxy kind: Pipeline flow: filter: proxy filters: name: proxy kind: Proxy pools: servers: url: http://127.0.0.1:9095 url: http://127.0.0.1:9096 url: http://127.0.0.1:9097 serviceRegistry: consul-001 # + serviceName: springboot-application-order # + loadBalance: policy: roundRobin ``` First we need to create a EurekaServiceRegistry in Easegress ```yaml kind: EurekaServiceRegistry name: eureka-001 endpoints: ['http://127.0.0.1:8761/eureka'] syncInterval: 10s ``` Create a pipeline and set its `serviceRegistry` field into `eureka-001` and it will look up the eureka configuration for the service named `springboot-application-order` as in field `serviceName`. ```yaml name: pipeline-reverse-proxy kind: Pipeline flow: filter: proxy filters: name: proxy kind: Proxy pools: servers: url: http://127.0.0.1:9095 url: http://127.0.0.1:9096 url: http://127.0.0.1:9097 serviceRegistry: eureka-001 # + serviceName: springboot-application-order # + loadBalance: policy: roundRobin ```
Project: KubeAdmiral (Orchestration & Management / Scheduling & Orchestration)
File: cluster-joining.md

This guide describes how to join a new Kubernetes member cluster to a KubeAdmiral control plane. Ensure that the following programs are installed: version v0.20.15+ Ensure that we have the following files: The kubeconfig of the KubeAdmiral control plane's host apiserver The new member cluster's client cert, client key and CA Note: The client cert, client key and CA may be retrieved from the cluster's kubeconfig. Replace `HOSTCLUSTERKUBECONFIG` and `HOSTCLUSTERCONTEXT` with the kubeconfig and context of the host cluster respectively. ```console $ export KUBECONFIG=HOSTCLUSTERKUBECONFIG $ kubectl config use-context HOSTCLUSTERCONTEXT ``` Replace `NEWCLUSTERCA`, `NEWCLUSTERCERT` and `NEWCLUSTERKEY` with the certificate authority, client certificate and client key of the new cluster respectively. ```console $ export cadata=$(base64 NEWCLUSTER_CA) $ export certdata=$(base64 NEWCLUSTER_CERT) $ export keydata=$(base64 NEWCLUSTER_KEY) ``` Replace `CLUSTER_NAME` with the name of the new cluster. ```console $ cat << EOF > cluster-secret.yaml apiVersion: v1 kind: Secret metadata: name: CLUSTER_NAME namespace: kube-admiral-system data: certificate-authority-data: $ca_data client-certificate-data: $cert_data client-key-data: $key_data EOF $ kubectl create -f cluster-secret.yaml ``` Replace `CLUSTERNAME` and `CLUSTERENDPOINT` with the name and address of the new cluster. ```console $ cat <<EOF > cluster.yaml apiVersion: core.kubeadmiral.io/v1alpha1 kind: FederatedCluster metadata: name: CLUSTER_NAME spec: apiEndpoint: CLUSTER_ENDPOINT secretRef: name: CLUSTER_NAME useServiceAccount: true EOF $ kubectl create -f cluster.yaml ``` If both the KubeAdmiral control plane and new cluster are working properly, the joining process should complete shortly after and we should expect to see the following: ```console $ kubectl get fcluster NAME READY JOINED AGE ... CLUSTER_NAME True True 1m ... ``` Note: The new cluster should be both `READY` and `JOINED`. The new member cluster is now ready to be used. ```console $ rm cluster-secret.yaml cluster.yaml ```
Project: ngrok (Orchestration & Management / API Gateway)
File: CONTRIBUTING.md

Thank you for deciding to contribute to ngrok-go! To report a bug, please with clear reproduction steps. We will triage and investigate these issues at a regular interval. Bugfixes and small improvements are always appreciated! For any larger changes or features, please first to discuss whether the change makes sense. When in doubt, it's always okay to open an issue first. The library can be compiled with `go build`. To run tests, `go test`. Tests are split into a number of categories that can be enabled as desired via environment variables. By default, only offline tests run which validate tunnel protocol RPC messages generated from the `config` APIs. The other tests are gated behind the following environment variables: `NGROKTESTONLINE`: All online tests require this variable to be set `NGROKTESTAUTHED`: Enables tests that require an ngrok account and that the authtoken is set in `NGROK_AUTHTOKEN`. `NGROKTESTPAID`: Enables online, authenticated tests that require access to paid features. If your subscription doesn't support a feature being tested, you should see error messages to that effect. `NGROKTESTLONG`: Enables online tests that may take longer than most. May also require the `AUTHED` and/or `PAID` groups enabled. `NGROKTESTFLAKEY`: Enable online tests that may be unreliable. Their success or failure may depend on network conditions, timing, solar flares, ghosts in the machine, etc. This list may be incomplete and drift slightly as we add more tests and granularity. See the tests in `online_test.go` for the most accurate list.
Project: APISIX (Orchestration & Management / API Gateway)
File: apisix-variable.md

title: APISIX variable keywords: Apache APISIX API Gateway APISIX variable description: This article describes the variables supported by Apache APISIX. <!-- --> Besides , APISIX also provides additional variables. | Variable Name | Origin | Description | Example | |-- | - | -- | - | | balancer_ip | core | The IP of picked upstream server. | 192.168.1.2 | | balancer_port | core | The port of picked upstream server. | 80 | | consumer_name | core | Username of Consumer. | | | consumergroupid | core | Group ID of Consumer. | | | graphql_name | core | The of GraphQL. | HeroComparison | | graphql_operation | core | The operation type of GraphQL. | mutation | | graphqlrootfields | core | The top level fields of GraphQL. | ["hero"] | | mqttclientid | mqtt-proxy | The client id in MQTT protocol. | | | route_id | core | Id of Route. | | | route_name | core | Name of Route. | | | service_id | core | Id of Service. | | | service_name | core | Name of Service. | | | rediscmdline | Redis | The content of Redis command. | | | respbody | core | In the logger plugin, if some of the plugins support logging of response body, for example by configuring `includeresp_body: true`, then this variable can be used in the log format. | | | rpc_time | xRPC | Time spent at the rpc request level. | | You can also register your own .
Project: APISIX (Orchestration & Management / API Gateway)
File: echo.md

title: echo keywords: Apache APISIX API Gateway Plugin Echo description: This document contains information about the Apache APISIX echo Plugin. <!-- --> The `echo` Plugin is to help users understand how they can develop an APISIX Plugin. This Plugin addresses common functionalities in phases like init, rewrite, access, balancer, header filter, body filter and log. :::caution WARNING The `echo` Plugin is built as an example. It has missing cases and should not be used in production environments. ::: | Name | Type | Requirement | Default | Valid | Description | | -- | | -- | - | -- | -- | | before_body | string | optional | | | Body to use before the filter phase. | | body | string | optional | | | Body that replaces the Upstream response. | | after_body | string | optional | | | Body to use after the modification phase. | | headers | object | optional | | | New headers to use for the response. | At least one of `beforebody`, `body`, and `afterbody` must be specified. The example below shows how you can enable the `echo` Plugin for a specific 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 http://127.0.0.1:9180/apisix/admin/routes/1 -H "X-API-KEY: $admin_key" -X PUT -d ' { "plugins": { "echo": { "before_body": "before the body modification " } }, "upstream": { "nodes": { "127.0.0.1:1980": 1 }, "type": "roundrobin" }, "uri": "/hello" }' ``` First, we configure the Plugin as mentioned above. We can then make a request as shown below: ```shell curl -i http://127.0.0.1:9080/hello ``` ``` HTTP/1.1 200 OK ... before the body modification hello world ``` To remove the `echo` Plugin, you can delete the corresponding JSON configuration from the Plugin configuration. APISIX will automatically reload and you do not have to restart for this to take effect. ```shell curl http://127.0.0.1:9180/apisix/admin/routes/1 \ -H "X-API-KEY: $admin_key" -X PUT -d ' { "methods": ["GET"], "uri": "/hello", "plugins": {}, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } }' ```
Project: Gloo (Orchestration & Management / API Gateway)
File: envoy-segfault.md

When a segmentation fault occurs in the gateway-proxy pod, the stack trace is not visible. If you are running Gloo Edge Enterprise, replace the default docker image in that pod, with the debug replica: Original Image: ```bash $(IMAGE_REGISTRY)/gloo-ee-envoy-wrapper:$(VERSION) ``` Updated Image: ```bash $(IMAGE_REGISTRY)/gloo-ee-envoy-wrapper:$(VERSION)-debug ``` This new image should emit more information about the segmentation fault. Please note that Envoy seg faults are considered a security risk, and therefore, you should follow the