cwielenb/CNCF-Dataset huggingface dataset:
Project: BFE (Orchestration & Management / Service Proxy)
File: client_auth.md

The server needs to authenticate the client using TLS client authentication Step 1. Generate root certificate ```bash openssl genrsa -out root.key 2048 openssl req -new -x509 -days 365 -key root.key -out root.crt ``` Step 2. Create a client certificate signing request ```bash openssl genrsa -out client.key 2048 openssl req -new -out client.csr -key client.key ``` Step 3. Generate client certificate ```bash echo "extendedKeyUsage = clientAuth" > openssl.cnf openssl x509 -req -in client.csr -out client.crt -signkey client.key -CA root.crt -CAkey root.key -days 365 -extfile openssl.cnf ``` Step4. Configure layer 4 load balancing service. In this example, HAproxy is used as the layer 4 load balancing service, and VIP is passed to BFE using PROXY protocol. HAproxy can be installed through "apt install haproxy" on Ubuntu system. For more details, see . Configuration file(haproxy.cfg) example ``` global defaults mode tcp balance leastconn timeout client 3000ms timeout server 3000ms timeout connect 3000ms frontend frserverhttp bind 0.0.0.0:7080 defaultbackend bkserver_http backend bkserverhttp server srv1 0.0.0.0:8080 maxconn 2048 send-proxy frontend frserverhttps bind 0.0.0.0:7443 defaultbackend bkserver_https backend bkserverhttps server srv1 0.0.0.0:8443 maxconn 2048 send-proxy ``` Run HAproxy ```bash haproxy -f haproxy.cfg ``` Step 5. Configure BFE. Copy root.crt to tlsconf/clientca directory(note: the suffix of root certificate should be ".crt"). ```ini [server] ... Layer4LoadBalancer = "PROXY" ... [HttpsBasic] ... clientCABaseDir = tlsconf/clientca ... ``` Modify conf/tlsconfrule.data and set "ClientAuth" to true and "ClientCAName" to name of the root certificate. ```json { "Version": "12", "DefaultNextProtos": [ "http/1.1" ], "Config": { "example_product": { "VipConf": [ "127.0.0.1" ], "SniConf": null, "CertName": "example.org", "NextProtos": [ "h2;rate=0;isw=65535;mcs=200;level=0", "http/1.1" ], "Grade": "C", "ClientAuth": true, "ClientCAName": "root" } } } ``` Run BFE. ```bash ./bfe -c ../conf ``` Step 6. Verify configuration ```bash openssl s_client -connect 127.0.0.1:7443 -cert client.crt -key client.key -state -quiet ```
Project: Traefik (Orchestration & Management / API Gateway)
File: ISSUE_TEMPLATE.md

<!-- PLEASE FOLLOW THE ISSUE TEMPLATE TO HELP TRIAGE AND SUPPORT! --> <!-- DO NOT FILE ISSUES FOR GENERAL SUPPORT QUESTIONS. The issue tracker is for reporting bugs and feature requests only. For end-user related support questions, please refer to one of the following: the Traefik community forum: https://community.traefik.io/ --> Bug <!-- The configurations between 1.X and 2.X are NOT compatible. Please have a look here https://doc.traefik.io/traefik/getting-started/configuration-overview/. --> <!-- HOW TO WRITE A GOOD BUG REPORT? Respect the issue template as much as possible. The title should be short and descriptive. Explain the conditions which led you to report this issue: the context. The context should lead to something, an idea or a problem that youre facing. Remain clear and concise. Format your messages to help the reader focus on what matters and understand the structure of your message, use Markdown syntax https://help.github.com/articles/github-flavored-markdown --> <!-- `latest` is not considered as a valid version. For the Traefik Docker image: docker run [IMAGE] version ex: docker run traefik version --> ``` (paste your output here) ``` ```toml ``` <!-- Add more configuration information here. --> ``` (paste your output here) ```
Project: BFE (Orchestration & Management / Service Proxy)
File: install_using_go.md

golang 1.15+ Get the source code and install ```bash $ go get github.com/bfenetworks/bfe ``` Executable object file location is ${GOPATH}/bin/bfe !!! tip If you encounter an error such as "https fetch: Get ... connect: connection timed out", please set the GOPROXY and try again. See Run BFE with example configuration files: ```bash $ cd ${GOPATH}/bin/ $ ./bfe -c ${GOPATH}/src/github.com/bfenetworks/bfe/conf/ ``` Get familiar with Get started with
Project: Open Cluster Management (Orchestration & Management / Scheduling & Orchestration)
File: CHANGELOG-v0.11.md

Add installStrategy in addon v1alpha1 API ( ) add cluster autoapproval feature gate ( ) Add ManifestWorkReplicaSet Feature ( ) addon rollout strategy ( ) add evictionStartTime for appliedmanifestwork ( ) add addon manager ( ) add addon condition types and reasons ( ) Add addon lifecycle annotation definition ( ) add reasons for condition progressing ( ) add addon condition RegistrationApplied ( ) Add registration configuration ( ) Add registries for addon deployment config ( ) add short names for addon CRDs ( ) Return json raw string in feedback result ( ) clusterset v1beta1 migration ( ) Set omitempty on the ManifestWork UpdateStrategy field ( ) Rename placemanifestwork to manifestworkset ( ) modify InstallStrategy to structure ( ) add maxLength and pattern for clustername ( ) upgrade sets to use generic and add cilint ( ) update work annotations ( ) check work annotation update in ut ( ) Fix inline bug in placement install strategy ( ) fix work hash confilict and compare mainfests ( ) skip IsAlreadyExists during create work ( ) Remove Enable field in ClusterManager API ( )
Project: Apache bRPC (Orchestration & Management / Remote Procedure Call)
File: wireshark_baidu_std.md

`wiresharkbaidustd.lua` is a Wireshark Lua dissector written for protocol, including the protocol. Example for the Echo request: Example for the Echo response: Put under "Personal Lua Plugins" And put , and in `protobuf` directory under "Personal configuration", create if not exist Set `Protobuf Search Paths` for Protobuf official library include directory(e.g. `/opt/homebrew/opt/protobuf/include`), see for more details. Optional, turn on `Dissect Protobuf fields as Wireshark fields` if you want to use related `baidu_std` fields for filtering: The "Personal Lua Plugins" and "Personal configuration" folders above can be found under the `Folders` page of `About Wireshark`, for macOS:
Project: Tengine (Orchestration & Management / Service Proxy)
File: ngx_http_upstream_consistent_hash_module.md

Name ==== consistent hash module Description =========== This module provides consistent hashing algorithm for upstream load-balancing. If one of backend servers is down, the request of this client will be transferred to another server. `server` id* field: Id field can be used as server flag. If id field is not set, ip address and port are used to identify server. You can use id field to set server flag mannually. In that case, although ip address or port of a server is changed, id can still identify the server. BTW, it can reduce remapping keys effectively to use id field. `server` weight* field: server weight, the number of virtual peers Algorithm: It supposes that 1 server is mapped to m virtual peers, so n servers correspond to nm virtual peers. All these peers will be mapped to hash ring on average. Every time request comes, it calculates a hash key via configuration parameter, and finds a peer on the hash ring nearest to the location specified by the hash key. It can dispatch requests to backend servers on average according to nginx configuration parameter. `consistenthash $remoteaddr`: mapping via client ip address `consistenthash $requesturi`: mapping via request-uri `consistent_hash $args`: mapping via url query string Example =========== worker_processes 1; http { upstream test { consistenthash $requesturi; server 127.0.0.1:9001 id=1001 weight=3; server 127.0.0.1:9002 id=1002 weight=10; server 127.0.0.1:9003 id=1003 weight=20; } } Directives ========== consistent_hash Syntax: consistent_hash variable_name Default: none Context: upstream This directive causes requests to be distributed between upstreams based on consistent hashing alogrithm. And it uses nginx variables, specified by variable_name, as input data of hash function. Installation =========== This module is built by default, it can be disabled with the `--without-httpupstreamconsistenthashmodule` configuration parameter. $ ./configure compile $ make install $ make install
Project: Prefect (Orchestration & Management / Scheduling & Orchestration)
File: contribute.md

description: Contribute blocks and integrations to the Prefect Integrations Catalog. tags: blocks storage secrets configuration infrastructure integrations integrations contributing search: boost: 2 We welcome contributors! You can help contribute blocks and integrations by following these steps. Building your own custom block is simple! Subclass from `Block`. Add a description alongside an `Attributes` and `Example` section in the docstring. Set a `logourl` to point to a relevant image. Create the `pydantic.Field`s of the block with a type annotation, `default` or `default_factory`, and a short description about the field. Define the methods of the block. For example, this is how the : ```python from pydantic import Field, SecretStr from prefect.blocks.core import Block class Secret(Block): """ A block that represents a secret value. The value stored in this block will be obfuscated when this block is logged or shown in the UI. Attributes: value: A string value that should be kept secret. Example: ```python from prefect.blocks.system import Secret secretblock = Secret.load("BLOCKNAME") secret_block.get() ``` """ logourl = "https://example.com/logo.png" value: SecretStr = Field( default=..., description="A string value that should be kept secret." ) # ... indicates it's a required field def get(self): return self.value.getsecretvalue() ``` To view in Prefect Cloud or the Prefect server UI, . Anyone can create and share a Prefect Integration and we encourage anyone interested in creating an integration to do so! To help you get started with your integration, we've created a template that gives the tools you need to create and publish your integration. Use the to get started creating an integration with a bootstrapped project! To list your integration in the Prefect Integrations Catalog, submit a PR to the Prefect repository adding a file to the `docs/integrations/catalog` directory with details about your integration. Please use `TEMPLATE.yaml` in that folder as a guide. If you'd like to help contribute to fix an issue or add a feature to any of our Integrations, please . Install the repository and its dependencies: ``` pip install -e ".[dev]" ``` Make desired changes Add tests Insert an entry to the Integration's CHANGELOG.md Install `pre-commit` to perform quality checks prior to commit: ``` pre-commit install ``` `git commit`, `git push`, and create a pull request
Project: Gloo (Orchestration & Management / API Gateway)
File: metadata.proto.sk.md

title: "metadata.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Metadata contains general properties of resources for purposes of versioning, annotating, and namespacing. ```yaml "name": string "namespace": string "cluster": string "resourceVersion": string "labels": map<string, string> "annotations": map<string, string> "generation": int "ownerReferences": []core.solo.io.Metadata.OwnerReference ``` | Field | Type | Description | | -- | - | -- | | `name` | `string` | Name of the resource. Names must be unique and follow the following syntax rules: One or more lowercase rfc1035/rfc1123 labels separated by '.' with a maximum length of 253 characters. | | `namespace` | `string` | Namespace is used for the namespacing of resources. | | `cluster` | `string` | Cluster indicates the cluster this resource belongs to Cluster is only applicable in certain contexts, e.g. Kubernetes An empty string here refers to the local cluster. | | `resourceVersion` | `string` | An opaque value that represents the internal version of this object that can be used by clients to determine when objects have changed. | | `labels` | `map<string, string>` | Map of string keys and values that can be used to organize and categorize (scope and select) objects. Some resources contain `selectors` which can be linked with other resources by their labels. | | `annotations` | `map<string, string>` | Annotations is an unstructured key value map stored with a resource that may be set by external tools to store and retrieve arbitrary metadata. | | `generation` | `int` | A sequence number representing a specific generation of the desired state. Currently only populated for resources backed by Kubernetes. | | `ownerReferences` | | List of objects depended by this object. Currently only populated for resources backed by Kubernetes. | proto message representing kubernertes owner reference https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#ownerreference-v1-meta ```yaml "apiVersion": string "blockOwnerDeletion": .google.protobuf.BoolValue "controller": .google.protobuf.BoolValue "kind": string "name": string "uid": string ``` | Field | Type | Description | | -- | - | -- | | `apiVersion` | `string` | | | `blockOwnerDeletion` | | | | `controller` | | | | `kind` | `string` | | | `name` | `string` | | | `uid` | `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: Fluid (Orchestration & Management / Scheduling & Orchestration)
File: CONTRIBUTING.md

Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests. Please see https://git.k8s.io/community/CLA.md for more info Submit an issue describing your proposed change to the repo in question. The will respond to your issue promptly. If your proposed change is accepted, and you haven't already done so, sign a Contributor License Agreement (see details above). Fork the desired repo, develop and test your code changes. Submit a pull request. Run the command `make test` to test the changes locally. es for contribution, put them here ahead of the general k8s resources --> Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests - Main contributor documentation, or you can just jump directly to the - Common resources for existing developers - We have a diverse set of mentorship programs available that are always looking for volunteers! <! Custom Information - if you're copying this template for the first time you can add custom content here, for example: - Replace `kubernetes-users` with your slack channel string, this will send users directly to your channel. -->
Project: BFE (Orchestration & Management / Service Proxy)
File: condition_grammar.md

A condition primitive is a basic and built-in function which check some specified condition matched or not. ``` go // return true if the request Host is "www.bfe-networks.com" or "bfe-networks.com" reqhostin("www.bfe-networks.com|bfe-networks.com") ``` BFE provides a set of built-in A condition expression is a series of condition primitives combined with operators (e.g. AND, OR, NOT, etc). ```go // return ture if the request host is "bfe-networks.com" and the request method is "GET" reqhostin("bfe-networks.com") && reqmethodin("GET") ``` The supported operators are described in another section below. You can define a variable and assign a condition expression to it. ```go // define a condition variable bfehost = reqhost_in("bfe-networks.com") ``` An advanced condition expression is a series of condition primitives and condition variables combined with operators (e.g. AND, OR, NOT, etc). In an advanced condition expression, the condition variable is identified by "$" prefix ```go // return true if the value of new_host is true and the request method is GET $newhost && reqmethod_in("GET") ``` A condition primitive is shown as follows: ```go func_name(params) ``` func_name is the name of condition primitive params are the parameters condition primitive The type of return value is bool Condition Expression(CE) grammar is defined as follows: ``` CE = CE && CE | CE || CE | ( CE ) | ! CE | ConditionPrimitive ``` Advanced Condition Expression(ACE) grammar is defined as follows: ``` ACE = ACE && ACE | ACE || ACE | ( ACE) | ! ACE | ConditionPrimitive | ConditionVariable ``` The precedence and associativity of operators are similar to the C language. The following table lists the precedence and associativity of all operators. Operators are listed top to bottom, in descending precedence. | Precedence | Operator | Description | Associativity | | - | -- | - | - | | 1 | () | parentheses (grouping) | Left-to-right | | 2 | ! | logical NOT | Right-to-left | | 3 | && | logical AND | Left-to-right | | 4 | \|\| | logical OR | Left-to-right |
Project: Kubernetes (Orchestration & Management / Scheduling & Orchestration)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at oss-conduct@uber.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at .
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.3.0.md

+++ title = "CoreDNS-1.3.0 Release" description = "CoreDNS-1.3.0 Release Notes." tags = ["Release", "1.3.0", "Notes"] release = "1.3.0" date = "2018-12-15T16:14:29+00:00" author = "coredns" +++ We are pleased to announce the of CoreDNS-1.3.0! In this release we do the EDNS0 handling in the server and make it compliant with . This fits a theme where we move more and more protocol details into the server to make life easier for plugin authors. a new plugin that allows external zones to point to Kubernetes in-cluster services. fixes a bug where a rule would eat the first character of a name now supported the labels. It also fixes a bug in the formatting of a plugin logging a info/failure/warning removes the dynamic read timeout and uses a fixed value now. now checks if a zone transfer is allowed. Also allow a TTL of 0 to avoid caching in the cache plugin. Chris O'Haver, Cricket Liu, Daniel Garcia, DavadDi, Francois Tur, Jiacheng Xu, John Belamaric, Miek Gieben, moredhel, Sandeep Rajan, StormXX, stuart nelson, Yong Tang. For documentation see our (in progress!) . For help and other resources, see our .
Project: Istio (Orchestration & Management / Service Mesh)
File: GKE.md

This section walks you through the one-time set-up for creating and configuring a Google Cloud Platform (GCP) project. If you haven't already installed the Google Cloud SDK, follow the instructions . If you're not sure if you have it installed, you can check with: ```bash which gcloud ``` If you haven't already, . You must grant your default compute service account the correct permissions before creating the deployment. Otherwise, the installation will fail. Note the Project Number for your project by visiting the of Google Cloud Console. Navigate to the of the Google Cloud Console and make sure that your default compute service account (by default `[PROJECT_NUMBER]-compute@developer.gserviceaccount.com`) includes the following roles: Kubernetes Engine Admin* (`roles/container.admin`) Editor* (`roles/editor`, included by default) The following steps are automated with the script `createclustergke.sh` located in this directory. To create a cluster with the script, simply run: ```bash ./tests/integration/createclustergke.sh -c ${CLUSTER_NAME} ``` To list the options for the script, you can get help via `-h`: ```bash ./tests/integration/createclustergke.sh -h ``` E2E tests require a Kubernetes cluster. You can create one using the Google Container Engine using the following command: ```bash gcloud container clusters \ create ${CLUSTER_NAME} \ --zone ${ZONE} \ --project ${PROJECT_ID} \ --cluster-version ${CLUSTER_VERSION} \ --machine-type ${MACHINE_TYPE} \ --num-nodes ${NUM_NODES} \ --enable-kubernetes-alpha \ --no-enable-legacy-authorization ``` `CLUSTER_NAME`: Whatever suits your fancy, 'istio-e2e' is a good choice. `ZONE`: 'us-central1-f' is a good value to use. `PROJECT_ID`: is the ID of the GCP project that will house the cluster. You get a project by visiting . `CLUSTER_VERSION`: 1.7.3 or later. `MACHINE_TYPE`: Use 'n1-standard-4' `NUM_NODES`: Use 3. `no-enable-legacy-authorization`: Optional, needed if you want to test RBAC. ```bash gcloud container clusters get-credentials ${CLUSTER_NAME} \ --zone ${ZONE} --project ${PROJECT_ID} ``` ```bash kubectl create clusterrolebinding myname-cluster-admin-binding \ --clusterrole=cluster-admin \ --user=$(gcloud config get-value core/account) ``` You can set the HUB and TAG environment variables to point to your own Docker registry. Additionally, you can also set GS_BUCKET to use a different Google Storage Bucket than the default one (you need write permissions) it allows you to customize Makefile rules. For example: ```bash export HUB=myname export TAG=latest export GS_BUCKET=mybucket ``` Then you can build and push the docker images to your registry: ```bash make docker make push ``` On MacOS, you need to set the target operating system before building the images ```bash GOOS=linux make docker push ``` In this case, you'll need to specify the image SHA in the `TAG` environment variable. You can pick any SHA available from the or the `latest` for latest released dev images. ```bash export HUB="gcr.io/istio-testing" export TAG="latest" ```