cwielenb/CNCF-Dataset huggingface dataset:
Project: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: 0002-don-t-check-for-functionclauseerror-in-tests.md

Date: 15/05/2017 Accepted Typically, a module API filters possible inputs implicitly by making use of pattern matching. For instance, a GenServer that only handles `:test` messages might have a method similar to `handlecall(:test, , _)`. Writing tests that assure that pattern matching works with the given signature (e.g., by checking that `handle_call(:illegal, 0, 0)` fails) has drawbacks: Asserting that the process `exit`s with a `FunctionClauseError` is not straight-forward. Arguably, one of the ideas of pattern matching in function signatures is to save on testing negative cases in the first place. Often, testing for missing function clauses make tests needlessly brittle. Still, there is the case of regression testing, e.g., making sure that there will never exist a handler for other messages. We think that such a restriction is rarely required, though. Except for regression tests, tests should not aim at triggering `FunctionClauseError`s. We save on writing test code, and tests are potentially less brittle.
Project: Merbridge (Orchestration & Management / Service Mesh)
File: README.md

](https://bestpractices.coreinfrastructure.org/projects/6382) ](https://app.fossa.com/projects/git%2Bgithub.com%2Fmerbridge%2Fmerbridge?ref=badge_shield) Use eBPF to speed up your Service Mesh like crossing an Einstein-Rosen Bridge. You just only need to run the following command on your Istio cluster to get eBPF to speed up Istio: ```bash kubectl apply -f https://raw.githubusercontent.com/merbridge/merbridge/main/deploy/all-in-one.yaml ``` Or on a Linkerd cluster: ```bash kubectl apply -f https://raw.githubusercontent.com/merbridge/merbridge/main/deploy/all-in-one-linkerd.yaml ``` Or on a Kuma cluster: ```bash kubectl apply -f https://raw.githubusercontent.com/merbridge/merbridge/main/deploy/all-in-one-kuma.yaml ``` Or on an / cluster: ```bash kubectl apply -f https://raw.githubusercontent.com/merbridge/merbridge/main/deploy/all-in-one-osm.yaml ``` Note: It currently only works on Linux kernel >= 5.7, run `uname -r` to check your kernel version before installing Merbridge. If you want to install Merbridge by `Helm`, read the guidelines: . Istio: ```bash kubectl delete -f https://raw.githubusercontent.com/merbridge/merbridge/main/deploy/all-in-one.yaml ``` Linkerd: ```bash kubectl delete -f https://raw.githubusercontent.com/merbridge/merbridge/main/deploy/all-in-one-linkerd.yaml ``` Kuma: ```bash kubectl delete -f https://raw.githubusercontent.com/merbridge/merbridge/main/deploy/all-in-one-kuma.yaml ``` /: ```bash kubectl delete -f https://raw.githubusercontent.com/merbridge/merbridge/main/deploy/all-in-one-osm.yaml ``` Join the . <a href="https://github.com/merbridge/merbridge/graphs/contributors"> <img src="https://contrib.rocks/image?repo=merbridge/merbridge" /> </a> Made with . Copyright 2023 the Merbridge Authors. All rights reserved. Licensed under the Apache License, Version 2.0. ](https://app.fossa.com/projects/git%2Bgithub.com%2Fmerbridge%2Fmerbridge?ref=badge_large) <p align="center"> <img src="https://landscape.cncf.io/images/left-logo.svg" width="150"/>&nbsp;&nbsp;<img src="https://landscape.cncf.io/images/right-logo.svg" width="200"/> <br/><br/> Merbridge enriches the <a href="https://landscape.cncf.io/?selected=merbridge">CNCF CLOUD NATIVE Landscape.</a> </p>
Project: Tengine (Orchestration & Management / Service Proxy)
File: ngx_http_upstream_vnswrr_module.md

ngxhttpupstreamvnswrrmodule. The `VNSWRR` module is an efficient load balancing algorithm that is smooth, decentralized, and high-performance compared to Nginx's official `SWRR` algorithm. ``` http { upstream backend { vnswrr; # enable VNSWRR load balancing algorithm. 127.0.0.1 port=81; 127.0.0.1 port=82 weight=2; 127.0.0.1 port=83; 127.0.0.1 port=84 backup; 127.0.0.1 port=85 down; } server { server_name localhost; location / { proxy_pass http://backend; } } } ``` Build Tengine with this module from source: ``` ./configure --add-module=./modules/ngxhttpupstreamvnswrrmodule/ make make install ``` vnswrr ======= ``` Syntax: vnswrr [max_init=number] Default: none Context: upstream ``` Enable `vnswrr` load balancing algorithm. max_init The max number of virtual node per initialization, to avoid initializing too many virtual nodes in one request. In very large clusters, setting this argument can significantly reduce the time overhead of a single request. There are two additional rules of `max_init`: If `max_init` is not set or `0`, it will be adjusted to the number of peers. If `max_init` is greater than total weight of peers, it will be adjusted to the total weight of peers. ``` http { upstream backend { vnswrr max_init=3; 127.0.0.1 port=81 weight=101; 127.0.0.1 port=82 weight=102; 127.0.0.1 port=83 weight=103; 127.0.0.1 port=84 weight=104; 127.0.0.1 port=85 weight=105; } server { server_name localhost; location / { proxy_pass http://backend; } } } ``` Under the same pressure (wrk, 500 concurrency, keepalive, 2000 endpoint), the CPU consumption of `VNSWRR` algorithm accounts for `0.27%` ( `ngxhttpupstreamgetvnswrr`). Compared with `VNSWRR` algorithm, the CPU consumption of `SWRR` (`ngxhttpupstreamgetpeer` `39%`) is an order of magnitude higher than `VNSWRR`. In the above environment, the QPS of `VNSWRR` increased by `60%` compared with `SWRR` algorithm. Observing the changes of QPS and RT in the different back-end number scenarios. Under SWRR algorithm, with every 500 back-end servers added, the QPS of Nginx decreases by about 10% and RT increases by about 1 ms. But under the VNSWRR algorithm, QPS and RT do not change much.
Project: ngrok (Orchestration & Management / API Gateway)
File: CHANGELOG.md

Bug fixes: Protect against writing to closed channel on shutdown Enhancements: Adds `WithAdditionalServers` and `WithMultiLeg` options Enhancements: Provides access to structs for building a Traffic Policy configuration Breaking changes: Renames pre-release option `WithPolicyConfig` to `WithPolicyString` Changes signature of `WithPolicy` option to accept the newly exposed structs for building a Traffic Policy configuration Adds the `WithPolicy` and `WithPolicyConfig` options for applying a Traffic Policy to an endpoint. Adds the `WithAppProtocol` option for labeled listeners and HTTP endpoints. This provides a protocol hint that can be used to enable support for HTTP/2 to the backend service. Adds support for remote stop of listener. Adds TLS Renegotiation to the backend `tls.Config`. Added new forwarding API. See `[Session].ListenAndForward` and `[Session].ListenAndServeHTTP`. Deprecates `WithHTTPServer` and `WithHTTPHandler`. Use `[Session].ListenAndServeHTTP` instead. Switch to `connect.ngrok-agent.com:443` as the default server address Add nicer error types that expose the ngrok error code Enhancements: Initial release
Project: Service Mesh Interface (SMI) (Orchestration & Management / Service Mesh)
File: proposal.md

name: Proposal about: Propose a change to the SMI spec labels: proposal Describe the proposal <!-- A clear and concise description of the proposal. --> Scope [ ] New specification [ ] Traffic Access Control [ ] Traffic Specs [ ] Traffic Metrics [ ] Traffic Split Possible use cases <!-- A clear and concise description of possible use cases for this proposal. -->
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2016-06-19-mesos-0-27-3-released.md

layout: post title: Apache Mesos 0.27.3 Released permalink: /blog/mesos-0-27-3-released/ published: true post_author: display_name: Jie Yu twitter: jie_yu tags: Release The latest Mesos point release for 0.27, 0.27.3, is now available for . This release includes fixes and improvements for the following: [MESOS-4705] - Linux 'perf' parsing logic may fail when OS distribution has perf backports. [MESOS-4869] - /usr/libexec/mesos/mesos-health-check using/leaking a lot of memory. [MESOS-5018] - FrameworkInfo Capability enum does not support upgrades. [MESOS-5021] - Memory leak in subprocess when 'environment' argument is provided. [MESOS-5449] - Memory leak in SchedulerProcess.declineOffer. Full release notes are available in the release . Rolling upgrades from a Mesos 0.27.2 cluster to Mesos 0.27.3 are straightforward. Please refer to the [upgrade guide](http://mesos.apache.org/documentation/latest/upgrades/) for detailed information on upgrading to Mesos 0.27.3. We encourage you to try out this release and let us know what you think. If you run into any issues, please let us know on the [user mailing list and IRC](https://mesos.apache.org/community). Thanks to the 4 contributors who made 0.27.3 possible: Fan Du, Vinod Kone, Benjamin Mahler, Dario Rexin, Yongqiao Wang, Jie Yu
Project: Aeraki Mesh (Orchestration & Management / Service Mesh)
File: metaprotocol.md

<!-- --> With the help of Aeraki Mesh, you can manage proprietary protocols in Istio Service Mesh. Just follow the below steps: Quickly build an Envoy Filter for a proprietary protocol on top of MetaProtocol: Implement the . You can refer to and as writing your own implementation. Define the protocol with Aeraki ApplicationProtocol CRD. Below is an example of the Dubbo protocol: ```yaml apiVersion: metaprotocol.aeraki.io/v1alpha1 kind: ApplicationProtocol metadata: name: dubbo namespace: istio-system spec: protocol: dubbo codec: aeraki.meta_protocol.codec.dubbo ``` You don't need to implement the control plane. Aeraki watches services and traffic rules, generate the configurations for the sidecar proxies, and send the configurations to the data plane via EnvoyFilter and MetaRoute RDS. Similar to Istio, protocols are identified by service port prefix. Please name service ports with this pattern: tcp-metaprotocol-{layer-7-protocol}-xxx. For example, a Dubbo service port could be named tcp-metaprotocol-dubbo. You can change the route via MetaRouter CRD. For example: Route the Dubbo requests calling method sayHello to v2: ```yaml apiVersion: metaprotocol.aeraki.io/v1alpha1 kind: MetaRouter metadata: name: test-metaprotocol-route spec: hosts: org.apache.dubbo.samples.basic.api.demoservice routes: name: v2 match: attributes: method: exact: sayHello route: destination: host: org.apache.dubbo.samples.basic.api.demoservice subset: v2 ``` Send 20% of the requests to v1 and 80% to v2: ```yaml apiVersion: metaprotocol.aeraki.io/v1alpha1 kind: MetaRouter metadata: name: test-metaprotocol-route spec: hosts: org.apache.dubbo.samples.basic.api.demoservice routes: name: traffic-spilt route: destination: host: org.apache.dubbo.samples.basic.api.demoservice subset: v1 weight: 20 destination: host: org.apache.dubbo.samples.basic.api.demoservice subset: v2 weight: 80 ```
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2015-09-21-mesos-0-24-0-released.md

layout: post title: Apache Mesos 0.24.0 Released permalink: /blog/mesos-0-24-0-released/ published: true post_author: display_name: Vinod Kone tags: Release The latest Mesos release, 0.24.0, is now available for . This release includes the following features and improvements: Mesos 0.24 provides experimental support for scheduler HTTP API. Framework schedulers can communicate with Mesos by sending HTTP POST requests to `/api/v1/scheduler` instead of depending on the native libmesos library. The endpoint accepts both JSON and Protobuf requests. Additionally, the master talks back to the scheduler using the same connection opened by the scheduler, mitigating communication issues in firewalled/NATed environments. Refer to the for more information. Note that, this release only adds the support for scheduler HTTP API. Support for HTTP executor API is currently in the works and will be released soon! As part of this release, we have also outlined the versioning scheme for Mesos HTTP API going forward. At a high level, the Mesos API (constituting Scheduler, Executor, Internal, Operator/Admin APIs) will have a version in the URL. The versioned URL will have a prefix of `/api/vN` where `N` is the version of the API. For simplicity, the stable version of the API will correspond to the major release version of Mesos. For example, v1 of the API will be supported by Mesos release versions 1.0.0, 1.4.0, 1.20.0 etc. Refer to the for more information. Hundreds of other bug fixes/improvements are included in Mesos 0.24.0. See the for a full list of resolved JIRA issues. Rolling upgrades from a Mesos 0.23.x cluster to Mesos 0.24 are straightforward, but there are a few caveats/deprecations. Please refer to the for detailed information on upgrading to Mesos 0.24. We encourage you to try out this release and let us know what you think. If you run into any issues, please let us know on the . Thanks to the 37 contributors who made 0.24.0 possible: Adam B, Aditi Dixit, Alex Clemmer, Alexander Rojas, Alexander Rukletsov, Anand Mazumdar, Anindya Sinha, Artem Harutyunyan, Bartek Plotka, Benjamin Hindman, Benjamin Mahler, Bernd Mathiske, Chi Zhang, Chris Heller, Dave Lester, Greg Mann, Guangya Liu, Ian Downes, Isabel Jimenez, James DeFelice, James Peach, Jan Schlicht, Jiang Yan Xu, Jie Yu, Joerg Schad, Jojy Varghese, Joris Van Remoortere, Joseph Wu, Kapil Arya, Klaus Ma, Lily Chen, Marco Massenzio, Mark Wang, Michael Park, Michael Schenck, Niklas Nielsen, Paul Brett, Ryuichi Okumura, Shuai Lin, Till Toenshoff, Tim Anderegg, Timothy Chen, Vinod Kone, Yong Qiao Wang, ayouwei, haosdent huang, usultrared.
Project: Nomad (Orchestration & Management / Scheduling & Orchestration)
File: LICENSE.md

This license is temporary while a more official one is drafted. However, this should make it clear: The text contents of this website are MPL 2.0 licensed. The design contents of this website are proprietary and may not be reproduced or reused in any way other than to run the website locally. The license for the design is owned solely by HashiCorp, Inc.
Project: Inlets (Orchestration & Management / Service Proxy)
File: CONTRIBUTING.md

If you find a typo, or wish to let us know about a correction required, feel free to raise an issue. The content in this repository is licensed under the inlets Pro EULA, available in the repository. Third party contributions are made under the MIT license and must be signed-off, signing off is not the same as signing which is a form of encryption. See also:
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_dashboard.md

title: "glooctl dashboard" weight: 5 Open Gloo dashboard Open the Gloo dashboard/UI in your default browser ``` glooctl dashboard [flags] ``` ``` -h, --help help for dashboard -n, --namespace string namespace for reading or writing resources (default "gloo-system") -v, --verbose If true, output from kubectl commands will print to stdout/stderr ``` ``` -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 -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 --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - CLI for Gloo
Project: Apache Zookeeper (Orchestration & Management / Coordination & Service Discovery)
File: index.md

<!-- Copyright 2002-2004 The Apache Software Foundation Licensed 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 http://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. //--> ZooKeeper is a high-performance coordination service for distributed applications. It exposes common services - such as naming, configuration management, synchronization, and group services - in a simple interface so you don't have to write them from scratch. You can use it off-the-shelf to implement consensus, group management, leader election, and presence protocols. And you can build on it for your own, specific needs. The following documents describe concepts and procedures to get you started using ZooKeeper. If you have more questions, please ask the or browse the archives. ZooKeeper Overview Technical Overview Documents for Client Developers, Administrators, and Contributors - a bird's eye view of ZooKeeper, including design concepts and architecture - a tutorial-style guide for developers to install, run, and program to ZooKeeper - new developer and user facing features, improvements, and incompatibilities Developers Documents for Developers using the ZooKeeper Client API - the technical reference to ZooKeeper Client APIs - a client application developer's guide to ZooKeeper - a series of use cases using the ZooKeeper. - a simple Zookeeper client application, written in Java - sample implementations of barriers and queues - higher level solutions to common problems in distributed applications Administrators & Operators Documents for Administrators and Operations Engineers of ZooKeeper Deployments - a guide for system administrators and anyone else who might deploy ZooKeeper - a guide for system administrators on Quotas in ZooKeeper. - a guide for system administrators on take snapshot and restore ZooKeeper. - how to enable JMX in ZooKeeper - a guide on how to use hierarchical quorums - the introduction to Oracle Quorum increases the availability of a cluster of 2 ZooKeeper instances with a failure detector. - non-voting ensemble members that easily improve ZooKeeper's scalability - a guide on how to use dynamic reconfiguration in ZooKeeper - a guide on how to use the ZooKeeper command line interface - a guide on how to use a series of tools for ZooKeeper - a guide on how to monitor the ZooKeeper - a guide on how to configure audit logs in ZooKeeper Server and what contents are logged. Contributors Documents for Developers Contributing to the ZooKeeper Open Source Project - assorted topics on the inner workings of ZooKeeper Miscellaneous ZooKeeper Documentation +
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: helm-install.md

A full Kusk installation is conformed of: Kusk Gateway: manages the gateway by translating your OpenAPI definition EnvoyFleet: the API's LoadBalancer Kusk Dashboard: provides a graphical experience to work with Kusk Gateway Kusk API: Kusk API server needed to control Kusk through Kusk Dashboard You can install all these components together (which we recommend), but if you don't need to use the dashboard, then you can skip installing Kusk Dashboard and Kusk API. ```sh helm repo add kubeshop https://kubeshop.github.io/helm-charts helm repo update ``` Install Kusk Manager first: ```sh helm upgrade \ --install \ --wait \ --create-namespace \ --namespace kusk-system \ kusk-gateway \ kubeshop/kusk-gateway ``` And now install the default EnvoyFleet (named `kusk-gateway-envoy-fleet`) which will serve public requests to your API: ```sh helm upgrade \ --install \ --wait \ --set service.type=LoadBalancer \ --set fullnameOverride=kusk-gateway-envoy-fleet \ --set default=true \ --namespace kusk-system \ kusk-gateway-envoy-fleet \ kubeshop/kusk-gateway-envoyfleet ``` Kusk Dashboard allows you to configure Kusk Gateway from a neat GUI. To deploy this, you will have to: Create a private EnvoyFleet: a service of type `ClusterIP`, so Kusk Dashboard isn't accessed publicly Kusk API - configured to be exposed through the private EnvoyFleet Kusk Dashboard - configured to be connected to Kusk API and exposed through the private EnvoyFleet ```sh helm upgrade \ --install \ --wait \ --set fullnameOverride=kusk-gateway-private-envoy-fleet \ --set service.type=ClusterIP \ --namespace kusk-system \ kusk-gateway-private-envoy-fleet \ kubeshop/kusk-gateway-envoyfleet ``` Now install Kusk API, which is an API server that Kusk Dashboard uses to configure the gateway: ```sh helm upgrade \ --install \ --wait \ --namespace kusk-system \ --set envoyfleet.name=kusk-gateway-private-envoy-fleet \ --set envoyfleet.namespace=kusk-system \ kusk-gateway-api \ kubeshop/kusk-gateway-api ``` ```sh helm upgrade \ --install \ --wait \ --namespace kusk-system \ --set envoyfleet.name=kusk-gateway-private-envoy-fleet \ --set envoyfleet.namespace=kusk-system \ kusk-gateway-dashboard \ kubeshop/kusk-gateway-dashboard ```
Project: 3Scale (Orchestration & Management / API Gateway)
File: development.md

``` ngx.log(ngx.DEBUG, require("inspect")(object)) ``` Clone repo. ``` git clone https://github.com/3scale/liquid-lua cd liquid-lua ``` Create the following Dockerfile ``` FROM ubuntu USER root ENV DEBIAN_FRONTEND=noninteractive RUN apt-get update && apt-get install -y \ vim \ lua5.2 \ liblua5.2-dev \ luarocks RUN luarocks install lua-cjson 2.1.0-1 RUN echo 'alias lua=lua5.2' >> ~/.bashrc ADD ./lib /home/development/lib WORKDIR "/home/development" CMD ["/bin/bash"] ``` Run the following: ``` docker build --tag lua_test . docker run --name luatest -d lua_test sleep infinity docker exec -it luatest /bin/bash $ vi test01.lua [paste one of the examples from https://github.com/3scale/liquid-lua] $ lua test01.lua ```