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

title: "Traefik GrpcWeb Documentation" description: "In Traefik Proxy's HTTP middleware, GrpcWeb converts a gRPC Web requests to HTTP/2 gRPC requests. Read the technical documentation." Converting gRPC Web requests to HTTP/2 gRPC requests. {: .subtitle } The GrpcWeb middleware converts gRPC Web requests to HTTP/2 gRPC requests before forwarding them to the backends. !!! tip Please note, that Traefik needs to communicate using gRPC with the backends (h2c or HTTP/2 over TLS). Check out the user guide for more details. ```yaml tab="Docker & Swarm" labels: "traefik.http.middlewares.test-grpcweb.grpcweb.allowOrigins=*" ``` ```yaml tab="Kubernetes" apiVersion: traefik.io/v1alpha1 kind: Middleware metadata: name: test-grpcweb spec: grpcWeb: allowOrigins: "*" ``` ```yaml tab="Consul Catalog" "traefik.http.middlewares.test-grpcweb.grpcWeb.allowOrigins=*" ``` ```yaml tab="File (YAML)" http: middlewares: test-grpcweb: grpcWeb: allowOrigins: "*" ``` ```toml tab="File (TOML)" [http.middlewares] [http.middlewares.test-grpcweb.grpcWeb] allowOrigins = ["*"] ``` The `allowOrigins` contains the list of allowed origins. A wildcard origin `*` can also be configured to match all requests. More information including how to use the settings can be found at:
Project: Contour (Orchestration & Management / Service Proxy)
File: ecosystem.md

title: Contour Ecosystem layout: page This is a list of Contour related resources. If you have a suggestion on what to add, please don't hesitate to ! : The Argo Rollouts plugin implementing the Contour HTTPProxy traffic control in progressive delivery scenarios. : OSM takes a simple approach for users to uniformly manage, secure, and get out-of-the box observability features for highly dynamic microservice environments. : Linkerd is a service mesh for Kubernetes. It makes running services easier and safer by giving you runtime debugging, observability, reliability, and securityall without requiring any changes to your code. : Knative is a platform-agnostic solution for running serverless deployments.
Project: Gloo (Orchestration & Management / API Gateway)
File: others.md

title: "Gloo Edge vs others" weight: 70 description: A comparison of similar products and how Gloo Edge is different. Gloo Edge is an API Gateway and may come up in discussions about how it's different from "X". Although API Gateways are not new, in terms of deployment footprint, use cases, and their renaissance in cloud-native architectures vis-a-vis service mesh. We go into a lot of detail in , but to put it concise, the categories of API Gateways fall loosely into the following: Traditional API Management Simple reverse proxies Integration products Software frameworks to build custom Other Envoy Proxy vendors Gloo Edge can be compared to traditional API Management vendors but is significantly simpler and more powerful. Gloo Edge doesn't require complicated databases, outdated proxies, and high-friction configuration in terms of reams of XML or bespoke, complex APIs etc. Gloo Edge can act as an edge/external API management platform for external APIs. There are excellent reverse proxies out there for moving bytes from one connection to another, but Gloo Edge -- as it's built on Envoy -- provides a lot more features like powerful traffic matching, routing, and load-balancing, circuit breaking, distributed tracing, deep telemetry collection and more. In today's cloud-native environment, these features are not nice to haves -- they're table stakes. Legacy integration products have been cloud-washed to provide some of the functionality of an API Gateway, but they're typically full of baggage, don't scale, and are not easily configured for use in dynamic cloud environments. Gloo Edge is purpose built for these environments and for these cloud-native API gateway problems. Building an API Gateway for a simple use case is possible using generic software libraries and frameworks, but will it be battle tested? Will it be flexible enough? When you get past your simple use case, will you afford it the attention it needs? Building a capable gateway is easy for simple use cases, but once you need features that are standard with Gloo Edge, it will be a lot of undifferentiated heavy lifting to get your bespoke proxy up to par with industry standards. Some other vendors have also chosen Envoy as their data-plane proxy and there will be many more emerging in the near future. Choose Gloo Edge for these reasons: Dynamic and pluggable control plane to extend to your environment Route to cloud functions like Lambda Better runtime architecture: control plane decoupled from data plane Can run on Kubernetes or outside of Kubernetes with Consul and Vault (or flat files) Runtime catalog of services Can automatically discover Swagger / gRPC reflection / Lambdas Proven scalability, deployed across large number of community users and customers
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: README.md

This document describes how to fetch OpenAPI data from a live kubernetes API server. The scripts used will create a clean [kind] instance for this purpose. This will remove both the Kustomization and Kubernetes schemas: ``` make nuke ``` The compiled-in schema version should maximize API availability with respect to all actively supported Kubernetes versions. For example, while 1.20, 1.21 and 1.22 are the actively supported versions, 1.21 is the best choice. This is because 1.21 introduces at least one new API and does not remove any, while 1.22 removes a large set of long-deprecated APIs that are still supported in 1.20/1.21. If you'd like to change the default schema version, then in the Makefile in this directory, update the `API_VERSION` to your desired version. You may need to update the version of Kind these scripts use by changing `KIND_VERSION` in the Makefile in this directory. You can find compatibility information in the . In this directory, fetch the openapi schema, generate the corresponding swagger.go for the kubernetes api, and update `kubernetesapi/openapiinfo.go`: ``` make all ``` If you want to run the steps individually instead of using `make all`, you can run the following commands: ``` make kustomizationapi/swagger.go make kubernetesapi/swagger.go make kubernetesapi/openapiinfo.go ``` You can optionally delete the old `swagger.pb` and `swagger.go` files if we no longer need to support that kubernetes version of openapi data. Make sure you rerun `make kubernetesapi/openapiinfo.go` after deleting any old schemas. To avoid expensive schema lookups, some functions have precomputed results based on the schema. Unit tests ensure these are kept in sync with the schema; if these tests fail you will need to follow the suggested diff to update the precomputed results. At the top of the repository, run the tests. ``` make prow-presubmit-check >& /tmp/k.txt; echo $? ``` The exit code should be zero; if not, examine `/tmp/k.txt`. You can also regenerate the kubernetes api schemas specifically with: ``` rm kubernetesapi/swagger.go make kubernetesapi/swagger.go ``` To fetch the schema without generating the swagger.go, you can run: ``` rm kubernetesapi/swagger.pb make kubernetesapi/swagger.pb ``` Note that generating the swagger.go will re-fetch the schema. /* Output: {John 30} */ } ``` `yaml.YAMLToJSON` and `yaml.JSONToYAML` methods are also available: ```go package main import ( "fmt" "sigs.k8s.io/yaml" ) func main() { j := []byte(`{"name": "John", "age": 30}`) y, err := yaml.JSONToYAML(j) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(y)) /* Output: age: 30 name: John */ j2, err := yaml.YAMLToJSON(y) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(j2)) /* Output: {"age":30,"name":"John"} */ } ```
Project: Azure Service Fabric (Orchestration & Management / Scheduling & Orchestration)
File: SF_managed_clusters_ga_release_notes.md

Azure Service Fabric managed clusters are now generally available. In this release we are bringing additional capabilities such as availability zone spanning, stateless node types, application secrets, application managed identities, and the ability to configure cluster upgrades. In this release, Service Fabric managed clusters are now available in all Azure public cloud regions and will roll out to Azure Government regions in the coming weeks. To utilize these new features, you must update the API version in the ARM template to 2021-05-01. To see all of the properties available in the latest release, see the . The following APIs are updated as part of this release: | API | || | Microsoft.ServiceFabric/managedclusters | | Microsoft.ServiceFabric/managedclusters/nodetypes | | Microsoft.ServiceFabric/managedclusters/applications | | Microsoft.ServiceFabric/managedclusters/applicationTypes | | Microsoft.ServiceFabric/managedclusters/applications/services | - You can now deploy Service Fabric managed clusters across availability zones to eliminate single points of failure. - Stateless node types enable faster node scaling and VM patching when running services that do not require maintaining any state. - You can now access encrypted secrets from your Service Fabric application. - Application managed identities enable you to access other Azure resources from your application. - You can now select between automatic(default) or manual upgrades and configure an upgrade window to meet the needs of your environment.
Project: APIOAK (Orchestration & Management / API Gateway)
File: CONTRIBUTING.md

You can contribute to the APIOAK project in the following forms. Report bugs or usage issues via `Issues` for us to fix. Contribute code, documentation or test cases for APIOAK via `Pull Request`. Search through The issue does not exist. Open and briefly describe the issue in the title. Describe the detailed version, operating environment, and logs and other information in the content. Before new features are developed or problems are discovered, they can be announced or reported through the `Issues` method. If you are contributing code for APIOAK for the first time, you need to click the `Fork` button in the upper right corner of the project homepage to put the project` Fork` in your home directory. Clone items in home directory to local. ```shell git clone https://github.com/{username}/apioak.git ``` Add the backbone warehouse address locally to pull the latest code. ```shell git remote add upstream https://github.com/apioak/apioak.git ``` Checkout new branch from upstream repository before each development ```shell git checkout -b feature/add/contributing/document upstream/master ``` After feature development is complete, add files to the git change record. ```shell git add feature/file.lua ``` Write the commit information. Generally, the commit information will be consistent with the branch name. ```shell git commit -m "feature: add contributing document." ``` The changed code is submitted to the same branch as the home directory project. ```shell git push origin feature/add/contributing/document ``` After the submission is successful, launch `Pull Request` to the main project on the homepage of the home directory project. When initiating `Pull Request` to the trunk, if the problem has been announced in the `Issues`, you can fill it in the `Pull Request` fill-in,` FIX # ISSUES_ID`, You can associate with Issues, and automatically close Issues after Pull Request Merged.
Project: Gloo (Orchestration & Management / API Gateway)
File: service.proto.sk.md

title: "service.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Top-Level Resource A simple wrapper for a Kubernetes Service Object. ```yaml "kubeServiceSpec": .google.protobuf.Any "kubeServiceStatus": .google.protobuf.Any "metadata": .core.solo.io.Metadata ``` | Field | Type | Description | | -- | - | -- | | `kubeServiceSpec` | | a raw byte representation of the kubernetes service this resource wraps. | | `kubeServiceStatus` | | a raw byte representation of the service status of the kubernetes service object. | | `metadata` | | Metadata contains the object metadata for this resource. | <!-- 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: Gravitee.io (Orchestration & Management / API Gateway)
File: management-configuration-identityproviders.md

By activating identity provider, you are providing capabilities to users to login into the portal / management-ui using external user accounts from GitHub, Google, OpenID Connect server or Gravitee.io AM. You can activate as many identity providers as you need. Groups and roles will be automatically assigned to users depending on the identity provider used and how it has been configured. Identity providers can be managed at organization level.
Project: APISIX (Orchestration & Management / API Gateway)
File: README.md

title: Get APISIX description: This tutorial uses a script to quickly install Apache APISIX in your local environment and verify it through the Admin API. <head> <link rel="canonical" href="https://docs.api7.ai/apisix/getting-started/" /> </head> The Getting Started tutorials are contributed by . Developed and donated by API7.ai, Apache APISIX is an open source, dynamic, scalable, and high-performance cloud native API gateway for all your APIs and microservices. It is a of the Apache Software Foundation. You can use APISIX API Gateway as a traffic entrance to process all business data. It offers features including dynamic routing, dynamic upstream, dynamic certificates, A/B testing, canary release, blue-green deployment, limit rate, defense against malicious attacks, metrics, monitoring alarms, service observability, service governance, and more. This tutorial uses a script to quickly install in your local environment and verifies the installation through the Admin API. The quickstart script relies on several components: is used to install the containerized etcd and APISIX*. is used to send requests to APISIX for validation. :::caution To provide a better experience in this tutorial, the authorization of Admin API is switched off by default. Please turn on the authorization of Admin API in the production environment. ::: APISIX can be easily installed and started with the quickstart script: ```shell curl -sL https://run.api7.ai/apisix/quickstart | sh ``` The script should start two Docker containers, apisix-quickstart and etcd. APISIX uses etcd to save and synchronize configurations. Both the etcd and the APISIX use Docker network mode. That is, the APISIX can be accessed from local. You will see the following message once APISIX is ready: ```text APISIX is ready! ``` Once APISIX is running, you can use curl to interact with it. Send a simple HTTP request to validate if APISIX is working properly: ```shell curl "http://127.0.0.1:9080" --head | grep Server ``` If everything is ok, you will get the following response: ```text Server: APISIX/Version ``` `Version` refers to the version of APISIX that you have installed. For example, `APISIX/3.3.0`. You now have APISIX installed and running successfully! The following tutorial is based on the working APISIX, please keep everything running and move on to the next step.
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: internationalization.md

gRPC Internationalization ========================= As a universal RPC framework, gRPC needs to be fully usable within/across different international environments. This document describes gRPC API and behavior specifics when used in a non-english environment. While some API elements need to be able to represent non-english content, some are intentionally left as ASCII-only for simplicity & performance reasons. Method names are ASCII-only and may only contain characters allowed by HTTP/2 text header values. That should not be very limiting as most gRPC services will use protobuf which only allows method names from an even more restricted ASCII subset. Also, handling method names is a very hot code path so any additional encoding/decoding step is to be avoided. Recommended representation in language-specific APIs: string type. Host names are punycode encoded, but the user is responsible for providing the punycode-encoded string if she wishes to use an internationalized host name. Recommended representation in language-specific APIs: string/unicode string. NOTE: overriding host name when invoking RPCs is only supported by C-core based gRPC implementations. Status messages are expected to contain national-alphabet characters. Allowed values are unicode strings (content will be percent-encoded on the wire). Recommended representation in language-specific APIs: unicode string. Allowed values are defined by HTTP/2 standard (metadata keys are represented as HTTP/2 header/trailer names). Recommended representation in language-specific APIs: string. Allowed values are defined by HTTP/2 standard (metadata values are represented as HTTP/2 header/trailer text values). Recommended representation in language-specific APIs: string. TBD
Project: Gloo (Orchestration & Management / API Gateway)
File: decentralized_routing.md

title: "Decentralized Ownership" weight: 40 Gloo Edges developer-centric workflows can benefit from two specific parts of the Gloo Edge configuration API. The first is that service teams completely own the {{< protobuf name="gateway.solo.io.VirtualService" display="VirtualService">}} configuration in a build it you run it manner. The second is a that allows service teams to own certain aspects of the configuration while allowing a centralized API team to own some of the . Lets take a look at the second approach as its most applicable to our users and the workflows they wish to adopt. Gloo Edges to focus on the concerns they most care about (, , , , etc) and offload the responsibility of configuring security and operational aspects to another team more suited for that (for compliance, organizational or other reasons). Gloo Edges {{< protobuf name="gateway.solo.io.VirtualService" display="VirtualService">}} configuration can delegate to {{< protobuf name="gateway.solo.io.RouteTable" display="RouteTable">}} objects which each developer or service team can own and potentially re-use. {{<mermaid align="left">}} graph LR; vs[Virtual Service <br> <br> <code>*.petclinic.com</code>] -->|delegate <code>/api</code> prefix | rt1(Route Table <br> <br> <code>/api/pets</code> <br> <code>/api/vets</code>) vs -->|delegate <code>/site</code> prefix | rt2(Route Table <br> <br> <code>/site/login</code> <br> <code>/site/logout</code>) style vs fill:#0DFF00,stroke:#233,stroke-width:4px {{< /mermaid >}} With this delegation model, organizations can go faster without having to file tickets, wait for centralized teams, and give up control over how to manage their APIs. Platform teams can own and manage the parts of the API infrastructure that the organization demands. Developers can own the parts that are most relevant to them without the overhead and synchronization of a centralized team. Organizational workflow, GitOps, simplicity, and self-service are a primary concern for cloud-native infrastructure, and these concerns are part of the foundation of the Gloo Edge open-source API gateway project. We encourage you to take a look at Gloo Edge or reach out about Gloo Edge Enterprise and join the growing open-source community.
Project: Open Cluster Management (Orchestration & Management / Scheduling & Orchestration)
File: CHANGES.md

Documentation updates. Small linter cleanups. Added example in test. Document the usage of Cleanup when re-reading a file (thanks to @lesovsky) for issue #18. Add example directories with example and tests for issues. Fix of checksum problem because of forced tag. No changes to the code. Incorporated PR 162 by by Mohammed902: "Simplify non-Windows build tag". Incorporated PR 9 by mschneider82: "Added seekinfo to Tail". Incorporated PR 7: "Fix deadlock when stopping on non-empty file/buffer", fixes upstream issue 93. Incorporated changes of unmerged upstream PR 149 by mezzi: "added line num to Line struct". Incorporated changes of unmerged upstream PR 128 by jadekler: "Compile-able code in readme". Incorporated changes of unmerged upstream PR 130 by fgeller: "small change to comment wording". Incorporated changes of unmerged upstream PR 133 by sm3142: "removed spurious newlines from log messages". Incorporated changes of unmerged upstream PR 126 by Code-Hex: "Solved the problem for never return the last line if it's not followed by a newline". Incorporated changes of unmerged upstream PR 131 by StoicPerlman: "Remove deprecated os.SEEK consts". The changes bumped the minimal supported Go release to 1.9. migration to go modules. release of master branch of the dormant upstream, because it contains fixes and improvement no present in the tagged release.
Project: Crossplane (Orchestration & Management / Scheduling & Orchestration)
File: OWNERS.md

This page lists all active members this repository. Each repository in the will list their repository maintainers and reviewers in their own `OWNERS.md` file. Please see for governance guidelines and responsibilities for the steering committee, maintainers, and reviewers. See for automatic PR assignment. Nic Cope <negz@upbound.io> () Hasan Turken <hasan@upbound.io> () Bob Haddleton <bob.haddleton@nokia.com> () Philippe Scorsolini <philippe.scorsolini@upbound.io> () Bassam Tabbara <bassam@upbound.io> () Jared Watts <jared@upbound.io> () Illya Chekrygin <illya.chekrygin@gmail.com> () Daniel Mangum <georgedanielmangum@gmail.com> () Muvaffak Onus <me@muvaf.com> ()
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_edit_route_externalauth.md

title: "glooctl edit route externalauth" weight: 5 Configure disable external auth on a route (Enterprise) Allows disabling external auth on specific routes. External auth is a gloo enterprise feature. ``` glooctl edit route externalauth [flags] ``` ``` -d, --disable set to true to disable authentication on this route -h, --help help for externalauth --name string name of the resource to read or write -n, --namespace string namespace for reading or writing resources (default "gloo-system") ``` ``` -c, --config string set the path to the glooctl config file (default "<home_directory>/.gloo/glooctl-config.yaml") --consul-address string address of the Consul server. Use with --use-consul (default "127.0.0.1:8500") --consul-allow-stale-reads Allows reading using Consul's stale consistency mode. --consul-datacenter string Datacenter to use. If not provided, the default agent datacenter is used. Use with --use-consul --consul-root-key string key prefix for for Consul key-value storage. (default "gloo") --consul-scheme string URI scheme for the Consul server. Use with --use-consul (default "http") --consul-token string Token is used to provide a per-request ACL token which overrides the agent's default token. Use with --use-consul -x, --index uint32 edit the route with this index in the virtual service route list -i, --interactive use interactive mode --kube-context string kube context to use when interacting with kubernetes --kubeconfig string kubeconfig to use, if not standard one -o, --output OutputType output format: (yaml, json, table, kube-yaml, wide) (default table) --resource-version string the resource version of the resource we are editing. if not empty, resource will only be changed if the resource version matches --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` -