cwielenb/CNCF-Dataset huggingface dataset:
Project: Consul (Orchestration & Management / Service Mesh)
File: adding-a-topic.md

This document is a guide for adding a new streaming topic. Add the name of the topic to the . Run `make proto` to generate the Go code from the protobuf. Add a `FromChanges` function to the list of change functions in . The `FromChanges` function should examine the list of `Changes` and return a list of events that subscriptions would need to update their view. Add a snapshot function to . The snapshot function should produce a set of events to create the initial state of the view. Generally these are all "create" events. Add a new `Payload` type, similar to . This type will be used in the `Payload` field of the event. Create the protobuf for the payload, and add the `Payload` type to the `oneof` in . This may require creating other protobuf types as well, to encode anything in the payload. Run `make proto` to generate the Go code from the protobuf. Add another case to to convert from the Payload type in `state`, to the protobuf type. This may require either writing or generating a function to convert between the types. Add a new cache-type that uses similar to .
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_create_upstream_azure.md

title: "glooctl create upstream azure" weight: 5 Create an Azure Upstream Azure Upstreams represent a set of Azure Functions for a Function App that can be routed to with Gloo. Azure Upstreams require a valid set of Azure Credentials to be provided. These should be uploaded to Gloo using `glooctl create secret azure` ``` glooctl create upstream azure [flags] ``` ``` --azure-app-name string name of the Azure Functions app to associate with this upstream --azure-secret-name glooctl create secret azure --help name of a secret containing Azure credentials created with glooctl. See glooctl create secret azure --help for help creating secrets --azure-secret-namespace glooctl create secret azure --help namespace where the Azure secret lives. See glooctl create secret azure --help for help creating secrets (default "gloo-system") -h, --help help for azure ``` ``` -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 --dry-run print kubernetes-formatted yaml rather than creating or updating a resource -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 --name string name of the resource to read or write -n, --namespace string namespace for reading or writing resources (default "gloo-system") -o, --output OutputType output format: (yaml, json, table, kube-yaml, wide) (default table) --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - Create an Upstream
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.27.2.md

We are delighted to present version v1.27.2 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. Updates Envoy to v1.28.2. See the release notes for v1.28.2 . Updates Go to v1.21.9. See the release notes for v1.21.9 . For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.27.2 is tested against Kubernetes 1.26 through 1.28. If you're using Contour and want to add your organization to our adopters list, please visit this . If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this .
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2015-07-13-mesoscon-seattle-preconference-and-social-activities.md

layout: post title: Announcing MesosCon pre-conference and social activities permalink: /blog/mesoscon-seattle-preconference-and-social-activities/ published: true post_author: display_name: Dave Lester twitter: davelester tags: MesosCon The countdown until 2015 in Seattle continues: only 38 days until the event! ! We're pleased to announce several pre-conference and social activities that we hope will make this years conference even more enjoyable. Join us for a ; space is limited so be sure to register today! The hackathon is sponsored by , and hosted by at their office in downtown Seattle a short distance from the Sheraton Seattle conference hotel. The hackathon will take place from 8:30-5:00pm. What should you work on? It's really up to you, as long as it's Mesos-related. Here are a few broad categories of projects to consider. Frameworks (build your own Mesos framework or add features to an existing framework) Mesos Core (squashing bugs, adding new features, or even proposing a design document) Ops (tools to make it easier to operate a Mesos cluster; examples may include monitoring, logging, etc) Additional details about the hackathon are available on the . Open to all #MesosCon attendees, join us at the (EMP), a leading-edge nonprofit museum, dedicated to the ideas and risk-taking that fuel contemporary popular culture. Appetizers and drinks included as well as the opportunity to check out some of the current exhibits. Shuttles will be provided from the Sheraton to the EMP starting at 7:30pm and returning later in the evening. Twitter plans to host a Mesos event the night before the conference at their Seattle office. More details will be announced in the coming week, so stay tuned! MesosCon will take place August 20 - 21, 2015 at Sheraton Seattle in Seattle, WA with a hackathon taking place the day prior to the event. The standard attendee registration fee will be US$399 (Through July 31, 2015), and late registration US$499 beginning August 1, 2015. Students are eligible for a special registration fee of US$99 (Note that a valid student id will be required at onsite check-in). Hope to see you at this years MesosCon!
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_install.md

title: "glooctl install" weight: 5 install gloo on different platforms choose which version of Gloo to install. ``` --create-namespace Create the namespace to install gloo into (default true) -d, --dry-run Dump the raw installation yaml instead of applying it to kubernetes -f, --file string Install Gloo from this Helm chart archive file rather than from a release -h, --help help for install -n, --namespace string namespace to install gloo into (default "gloo-system") --release-name string helm release name (default "gloo") --values strings List of files with value overrides for the Gloo Helm chart, (e.g. --values file1,file2 or --values file1 --values file2) -v, --verbose If true, output from kubectl commands will print to stdout/stderr --version string version to install (e.g. 1.4.0, defaults to latest) ``` ``` -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 - install the Gloo Gateway on Kubernetes - install the Gloo Ingress Controller on Kubernetes
Project: Gloo (Orchestration & Management / API Gateway)
File: open_source_helm_chart_values.md

title: "Open Source Gloo Edge" description: Listing of Helm values for the Open Source Gloo Edge chart weight: 30 The table below describes all the values that you can override in your custom values file when working with the Helm chart for Open Source Gloo Edge. More information on using a Helm chart to install the Gloo Edge can be found . {{% notice note %}} If you need further customization of the Helm chart, please read our . {{% /notice %}} {{< readfile file="reference/values.txt" markdown="true" >}} Most changes that need to be made to the default helm chart are supported by the helm values above. However, there may be a case where the helm values do not cover a necessary change. Helm values which expose the kubernetes API (ie Service, Deployment) now include a `KubeResourceOverride` field. The following example uses `KubeResourceOverride` to add labels to a deployment, which is not explicitly implemented in the helm chart: Gloo deployment: ```yaml apiVersion: v1 kind: Deployment metadata: labels: gloo: gloo name: gloo ``` We want to add the `resource-owner: infra-team` label to the Deployment. We can do so by specifying the `KubeResourceOverride` in the helm values file: ```yaml gloo: deployment: kubeResourceOverride: metadata: labels: resource-owner: infra-team ``` Yaml under the `kubeResourceOverride` is merged in to the deployment yaml, to create the resulting kube resource: ```yaml apiVersion: v1 kind: Deployment metadata: labels: gloo: gloo resource-owner: infra-team ``` {{% notice note %}} `kubeResourceOverride` does not support merging in lists, and a list in the override will replace the list in the original resource. {{% /notice %}} is another solution for patching resources generated by helm. The following table enumerates differences between the offered solutions. | Kustomize | Helm KubeResourceOverride | |-|--| | - Finer control over merges, e.g. merging lists <br>- Requires additional files (overlays)<br>- Unsupported in older versions of flux helm operator | - Can be done only with helm, does not require CI/CD pipeline changes <br>- Specified through values.yaml file or command line arguments |
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.28.1.md

We are delighted to present version v1.28.1 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. Fix data race in BackendTLSPolicy status update logic. For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.28.1 is tested against Kubernetes 1.27 through 1.29. If you're using Contour and want to add your organization to our adopters list, please visit this . If you prefer to keep your organization name anonymous but still give us feedback into your usage and scenarios for Contour, please post on this .
Project: Gloo (Orchestration & Management / API Gateway)
File: resolver.proto.sk.md

title: "resolver.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Configuration of DNS resolver option flags which control the behavior of the DNS resolver. ```yaml "useTcpForDnsLookups": bool "noDefaultSearchDomain": bool ``` | Field | Type | Description | | -- | - | -- | | `useTcpForDnsLookups` | `bool` | Use TCP for all DNS queries instead of the default protocol UDP. | | `noDefaultSearchDomain` | `bool` | Do not use the default search domains; only query hostnames as-is or as aliases. | <!-- 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: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.7.2-released.md

title: "Avro 1.7.2" linkTitle: "Avro 1.7.2" date: 2012-09-25 <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> Apache Avro 1.7.2 has been released!
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: failover_test.md

| Test Case | E2E Describe Text | Comments | |||-| | Test if the deployment of failed cluster is rescheduled to other available cluster | deployment failover testing | | | Test if the deployment of taint cluster is rescheduled to other available cluster | taint cluster | | | Test if the deployment will rescheduled to other available cluster | application failover with purgeMode graciously | | | Test if the deployment will never rescheduled to other available cluster | application failover with purgeMode never | | There are 2 way to evict the deployment of the Graciously PurgeMode, the third case cover the first way only, we may add a test case .
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2016-02-22-mesos-0-27-1-released.md

layout: post title: Apache Mesos 0.27.1 Released permalink: /blog/mesos-0-27-1-released/ published: true post_author: display_name: Michael Park gravatar: 2ab9cab3a7cf782261c583c1f48a81b0 twitter: mcypark tags: Release The latest Mesos release, 0.27.1, is now available for . This release includes fixes and improvements for: reconnection logic for Zookeeper client, `/state` endpoint and `systemd` integration. - Mesos Agents needs to re-resolve hosts in zk string on leader change / failure to connect. - state.json serving duplicate "active" fields. - Support systemd with Mesos. Full release notes are available in the release . Rolling upgrades from a Mesos 0.27.0 cluster to Mesos 0.27.1 are straightforward. Please refer to the for detailed information on upgrading to Mesos 0.27.1. 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 8 contributors who made 0.27.1 possible: Jie Yu, Joerg Shad, Joris Van Remoortere, Joseph Wu, Kapil Arya, Michael Park, Neil Conway, Shuai Lin
Project: Tengine (Orchestration & Management / Service Proxy)
File: README.md

``` make config root=/path/to/libxudp ``` ``` make ``` see test.c. this from libxudp/tools/xudpechoserver.c see the commit b6170f0557db95a2ef74346515759d35f4cc70de to know how to use this xquic xdp.
Project: Serverless Devs (Orchestration & Management / Scheduling & Orchestration)
File: inner_env.md

title: built-in environment variable description: 'Serverless Devs built-in environment variables' position: 11 category: 'Overview' Configure by specifying the name of the environment variable: for example, there is currently an Alibaba Cloud key pair: AccountID: temp_accountid AccessKeyID: temp_accesskeyid AccessKeySecret: temp_accesskeysecret At this time, you can name the key as `serverlessdevsaccess` in the environment variable, such as `defaultserverlessdevsaccess`, and the value as a JSON string, such as: Key: `defaultserverlessdevs_access` Value: `{\"AccountID\":\"tempaccountid\",\"AccessKeyID\":\"tempaccesskeyid\",\"AccessKeySecret\":\"temp_accesskeysecret\"}` At this point, you can specify the key `defaultserverlessdevsaccess` when configuring the key, for example `${env(defaultserverlessdevsaccess)}` The configuration in `s.yaml` is as follows: ``` edition: 1.0.0 # Command line YAML specification version, following the Semantic Versioning specification name: fcDeployApp # project name access: defaultserverlessdevs_access # secret key alias services: fc-deploy-test: component: fc-deploy # component name props: # Component property values region: cn-shenzhen service: name: fc-deploy-service ``` By default, execution such as `s deploy` will output in the terminal. This default behavior can be controlled by the environment variable `defaultserverlessdevsautolog` ``` export defaultserverlessdevsautolog = false ``` By default, Serverless-Devs will load the latest version of the component, which can be controlled by `coreloadserverlessdevscomponent` ``` export coreloadserverlessdevscomponent="devsapp/fc@dev,devsapp/fc-plan@dev" ```
Project: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: distributed-tracing.md

id: distributed-tracing title: Distributed Tracing sidebar_label: Distributed Tracing RIG is able to process distributed tracing data following the . In certain conditions RIG expects the trace context to be in the (HTTP) header, and in other conditions in the event payload itself. With events, we always speak of cloudevents following the . There is one key rule when RIG expects the trace context either in the header or in the cloudevent: if we talk of messages, then RIG expects the trace context to be in the (HTTP) header if we talk of events (cloudevents), then RIG expects the trace context to be in the cloudevent In our point of view, the difference of a message to an event is the following: a message* is a request from one system to another for an action to be taken. The sender expects that the message will get processed somehow an event* is a notification that data has been processed and some objects state has changed thus, messages and events have a different correlation between producer and consumer: messages have 1-to-1 correlation between a producer and a consumer events have a 1-to-n correlation between a producer and (potentially multiple) consumers As a concrete example how distributed tracing has been implemented, read about it in the .
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: overview.md

Kusk Gateway includes a browser-based dashboard for inspecting deployed APIs, Envoy Fleets and Static Routes. For APIs, it is also possible to dig into the underlying OpenAPI definition and make ad-hoc requests to the API using the embedded Swagger UI. The dashboard is installed as part of the and published using Kusk Gateway via dedicated Envoy Fleet, Static Route and API resources (which you can see in the dashboard). After installing Kusk Gateway, access the dashboard by running: ```shell $ kusk dashboard ``` This will open the dashboard, showing the kusk-gateway-api API Resource deployed through Kusk Gateway (the API that the dashboard itself uses): Use the tabs on the top left to see deployed EnvoyFleets and StaticRoutes. The following EnvoyFleets are deployed by default: Use the following Static Route for exposing the dashboard itself: Selecting any object will open a details panel to the right showing corresponding information - as shown in the screenshot above for the dashboard Static Route. By default, the dashboard uses a backend API exposed on the same host as the dashboard itself with an '/api' path prefix. If you host the dashboard or its API differently, you can configure the API endpoint using the Settings button in the bottom left, which opens the following dialog: You can specify any absolute URL or relative path here - just make sure that CORS is configured accordingly if you specify a different host than the default one.
Project: APISIX (Orchestration & Management / API Gateway)
File: expose-api.md

title: Expose API keywords: API Gateway Apache APISIX Expose Service description: This article describes how to publish services through the API Gateway Apache APISIX. <!-- --> This article will guide you through APISIX's upstream, routing, and service concepts and introduce how to publish your services through APISIX. is a virtual host abstraction that performs load balancing on a given set of service nodes according to the configured rules. The role of the Upstream is to load balance the service nodes according to the configuration rules, and Upstream information can be directly configured to the Route or Service. When multiple routes or services refer to the same upstream, you can create an upstream object and use the upstream ID in the Route or Service to reference the upstream to reduce maintenance pressure. match the client's request based on defined rules, load and execute the corresponding plugins, and forwards the request to the specified Upstream. A is an abstraction of an API (which can also be understood as a set of Route abstractions). It usually corresponds to an upstream service abstraction. Please make sure you have before doing the following. Create an Upstream. Create an Upstream service containing `httpbin.org` that you can use for testing. This is a return service that will return the parameters we passed in the request. ``` curl "http://127.0.0.1:9180/apisix/admin/upstreams/1" \ -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d ' { "type": "roundrobin", "nodes": { "httpbin.org:80": 1 } }' ``` In this command, we specify the Admin API Key of Apache APISIX as `edd1c9f034335f136f87ad84b625c8f1`, use `roundrobin` as the load balancing mechanism, and set `httpbin.org:80` as the upstream service. To bind this upstream to a route, `upstream_id` needs to be set to `1` here. Here you can specify multiple upstreams under `nodes` to achieve load balancing. For more information, please refer to . Create a Route. ```shell curl "http://127.0.0.1:9180/apisix/admin/routes/1" \ -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d ' { "methods": ["GET"], "host": "example.com", "uri": "/anything/*", "upstream_id": "1" }' ``` :::note Adding an `upstream` object to your route can achieve the above effect. ```shell curl "http://127.0.0.1:9180/apisix/admin/routes/1" \ -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d ' { "methods": ["GET"], "host": "example.com", "uri": "/anything/*", "upstream": { "type": "roundrobin", "nodes": { "httpbin.org:80": 1 } } }' ``` ::: Test After creating the Route, you can test the Service with the following command: ``` curl -i -X GET "http://127.0.0.1:9080/anything/get?foo1=bar1&foo2=bar2" -H "Host: example.com" ``` APISIX will forward the request to `http://httpbin.org:80/anything/get?foo1=bar1&foo2=bar2`. You can refer to to protect your API. You can also use APISIX's to achieve more functions.