cwielenb/CNCF-Dataset huggingface dataset:
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2014-09-23-mesos-0-20-1-released.md

layout: post title: Apache Mesos 0.20.1 Released permalink: /blog/mesos-0-20-1-released/ published: true post_author: display_name: Adam B tags: Release The latest Mesos release, 0.20.1 is now available for . One of the major features of Mesos 0.20.0 was native Docker support, and that support has been improved in 0.20.1 by the following bug fixes and improvements: - Docker run networking should be configurable and support bridge network - Can't include port in DockerInfo's image - Should be an error if commandinfo shell=true when using docker containerizer - Mesos containerizer doesn't reject tasks with container info set - Isolation=external result in core dump on 0.20.0 - Add docker support to mesos-execute - Freezer failure leads to lost task during container destruction. - Avoid docker pull on each container run - Docker with command shell=true should override entrypoint - Modify docker pull to use docker inspect after a successful pull Full release notes are available in the release . Upgrading to 0.20.1 can be done seamlessly on a 0.20.0 cluster. If upgrading from 0.19.x, please refer to the documentation. Thanks to all the contributors for 0.20.1: Timothy Chen, Jie Yu, Timothy St. Clair, Vinod Kone, Chris Heller, Kamil Domaski, and Till Toenshoff.
Project: Clusterpedia (Orchestration & Management / Scheduling & Orchestration)
File: README.md

](https://travis-ci.org/kubernetes-sigs/yaml) kubernetes-sigs/yaml is a permanent fork of . A wrapper around designed to enable a better way of handling YAML when marshaling to and from structs. In short, this library first converts YAML to JSON using go-yaml and then uses `json.Marshal` and `json.Unmarshal` to convert to or from the struct. This means that it effectively reuses the JSON struct tags as well as the custom JSON methods `MarshalJSON` and `UnmarshalJSON` unlike go-yaml. For a detailed overview of the rationale behind this method, . This package uses and therefore supports . Caveat #1: When using `yaml.Marshal` and `yaml.Unmarshal`, binary data should NOT be preceded with the `!!binary` YAML tag. If you do, go-yaml will convert the binary data from base64 to native binary data, which is not compatible with JSON. You can still use binary in your YAML files though - just store them without the `!!binary` tag and decode the base64 in your code (e.g. in the custom JSON methods `MarshalJSON` and `UnmarshalJSON`). This also has the benefit that your YAML and your JSON binary data will be decoded exactly the same way. As an example: ``` BAD: exampleKey: !!binary gIGC GOOD: exampleKey: gIGC ... and decode the base64 data in your code. ``` Caveat #2: When using `YAMLToJSON` directly, maps with keys that are maps will result in an error since this is not supported by JSON. This error will occur in `Unmarshal` as well since you can't unmarshal map keys anyways since struct fields can't be keys. To install, run: ``` $ go get sigs.k8s.io/yaml ``` And import using: ``` import "sigs.k8s.io/yaml" ``` Usage is very similar to the JSON library: ```go package main import ( "fmt" "sigs.k8s.io/yaml" ) type Person struct { Name string `json:"name"` // Affects YAML field names too. Age int `json:"age"` } func main() { // Marshal a Person struct to YAML. p := Person{"John", 30} y, err := yaml.Marshal(p) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(y)) /* Output: age: 30 name: John */ // Unmarshal the YAML back into a Person struct. var p2 Person err = yaml.Unmarshal(y, &p2) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(p2) /* 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: Pipy (Orchestration & Management / Service Proxy)
File: congestion-control.md

Congestion control API design ============================= We use an abstract interface for the QUIC congestion controller to facilitate use of pluggable QUIC congestion controllers in the future. The interface is based on interfaces suggested by RFC 9002 and MSQUIC's congestion control APIs. `OSSLCCMETHOD` provides a vtable of function pointers to congestion controller methods. `OSSLCCDATA` is an opaque type representing a congestion controller instance. For details on the API, see the comments in `include/internal/quic_cc.h`. Congestion controllers are not thread safe; the caller is responsible for synchronisation. Congestion controllers may vary their state with respect to time. This is facilitated via the `getwakeupdeadline` method and the `now` argument to the `new` method, which provides access to a clock. While no current congestion controller makes use of this facility, it can be used by future congestion controllers to implement packet pacing. Congestion controllers may expose arbitrary configuration parameters via the `setinputparams` method. Equally, congestion controllers may expose diagnostic outputs via the `binddiagnostics` and `unbinddiagnostics` methods. The configuration parameters and diagnostics supported may be specific to the congestion controller method, although there are some well known ones intended to be common to all congestion controllers. Currently, the only dependency injected to a congestion controller is access to a clock. In the future it is likely that access at least to the statistics manager will be provided. Excessive futureproofing of the congestion controller interface has been avoided as this is currently an internal API for which no API stability guarantees are required; for example, no currently implemented congestion control algorithm requires access to the statistics manager, but such access can readily be added later as needed. QUIC congestion control state is per-path, per-connection. Currently we support only a single path per connection, so there is one congestion control instance per connection. This may change in future. While the congestion control API is roughly based around the arrangement of functions as described by the congestion control pseudocode in RFC 9002, there are some deliberate changes in order to obtain cleaner separation between the loss detection and congestion control functions. Where a literal option of RFC 9002 pseudocode would require a congestion controller to access the ACK manager's internal state directly, the interface between the two has been changed to avoid this. This involves some small amounts of functionality which RFC 9002 considers part of the congestion controller being part of the ACK manager in our implementation. See the comments in `include/internal/quic_cc.h` and `ssl/quic/quic_ackm.c` for more information. The congestion control API may be revised to allow pluggable congestion controllers via a provider-based interface in the future.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: linkis.md

`Linkis` task type for creating and executing `Linkis` tasks. When the worker executes this task, it will parse the shell parameters through the `linkis-cli` command. Click for more information about `Apache Linkis`. Click Project Management -> Project Name -> Workflow Definition, and click the "Create Workflow" button to enter the DAG editing page. Drag the <img src="../../../../img/tasks/icons/linkis.png" width="15"/> from the toolbar to the drawing board. Please refer to `Default Task Parameters` section for default parameters. Please refer to `Linkis Support Parameters` section for Linkis parameters. This sample demonstrates using the Spark engine to execute sql script. If you want to use the Linkis task type in the production environment, you need to configure the required environment first. The configuration file is as follows: `/dolphinscheduler/conf/env/dolphinscheduler_env.sh`. According to the above parameter description, configure the required content. ``` sh ./bin/linkis-cli -engineType spark-2.4.3 -codeType sql -code "select count(*) from testdb.test;" -submitUser hadoop -proxyUser hadoop ``` No need to fill `sh ./bin/linkis-cli` in the configuration column, it has been configured in advance. The default configuration is asynchronous submission. You do not need to configure the `--async` parameter.
Project: Gloo (Orchestration & Management / API Gateway)
File: osa_included.md

Name|Version|License || |v1.14.0|Mozilla Public License 2.0 |v1.1.1|Mozilla Public License 2.0 |v1.0.2|Mozilla Public License 2.0 |v1.8.2|Mozilla Public License 2.0 |v0.3.0|Mozilla Public License 2.0
Project: Apache Zookeeper (Orchestration & Management / Coordination & Service Discovery)
File: verification-statistics.md

<!-- 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 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. //--> Our statistical results include: diameter of the system states that have been traversed, the number of states that have been traversed, the number of different states that have been discovered, and the time spent in the experiment. The machine configuration used in the experiment is 2.40 GHz, 10-core CPU, 64GB memory. The TLC version number is 1.7.0. Due to the state space explosion in model checking and the complex actions of Zab protocol, as well as unlimited number of rounds and unlimited length of history, it is impossible to traverse all states. We try to let models can tap into larger state space. See CONSTANT Parameters for details. | Mode | TLC model | Diameter | num of states | time of checking(hh:mm:ss) | | -- | - | - | | | | BFS | (2 servers,3 rounds,2 transactions) | 59 | 7758091583 | 17:28:17| | Simulation | (2 servers,3 rounds,2 transactions) | -| 6412825222| 17:07:20 | | BFS | (3 servers,2 rounds,2 transactions) | 19 | 4275801206 | 09:40:08| | Simulation | (3 servers,2 rounds,2 transactions) | -| 10899460942| 20:15:11 | | BFS | (3 servers,2 rounds,3 transactions) | 22 | 8740566213 | 17:49:09 | | Simulation | (3 servers,2 rounds,3 transactions) | - | 9639135842 | 20:10:00 | | BFS | (3 servers,3 rounds,2 transactions) | 21 | 7079744342 |14:17:45 | | Simulation | (3 servers,3 rounds,2 transactions) | - | 6254964039 | 15:08:42 | | BFS | (4 servers,3 rounds,2 transactions) | 16 | 5634112480 |15:42:09 | | Simulation | (4 servers,3 rounds,2 transactions) | - | 3883461291 | 15:52:03 | | Mode | TLC model | Diameter | num of states | time of checking(hh:mm:ss) | | -- | - | - | | | | BFS | (2,2,3,2,termination) | 55 | 10772649 | 00:02:21| | BFS | (3,1,1,2) | 45 | 9602018536 | 31:01:57| Besides, we have found several issues related to the ambiguous description of the Zab protocol. Details can be found at .
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: install-cmd.md

The `install` command will install Kusk Gateway and all its components with a single command. Kusk uses Helm to do this, so you will need to have . Kusk Gateway Manager* - Responsible for updating and rolling out the Envoy configuration to your Envoy Fleets as you deploy APIs and Static Routes. Envoy Fleet* - Responsible for exposing and routing to your APIs and frontends. Kusk Gateway API* - REST API, which is exposed by Kusk Gateway and allows you to programmatically query which APIs, Static Routes and Envoy Fleets are deployed. Kusk Gateway Dashboard* - A web UI for Kusk Gateway where you can deploy APIs and see which APIs, StaticRoutes and Envoy Fleets are deployed. The default `kusk cluster install` command will install Kusk Gateway, a public (for your APIs) and private (for the Kusk dashboard and API) envoy-fleet, api, and dashboard in the kusk-system namespace using Helm and using the current kubeconfig context. ```sh $ kusk cluster install Looking for Helm... Adding Kubeshop repository... Fetching the latest charts... Installing Kusk Gateway Installing Envoy Fleet... Installing Private Envoy Fleet... Installing Kusk API server... Installing Kusk Dashboard... kusk dashboard is now available. To access it run: $ kusk dashboard ``` The following command will create a Helm release named with --name in the namespace specified by --namespace. ```sh $ kusk cluster install --name=my-release --namespace=my-namespace ... ``` The following command will install Kusk Gateway, but not the dashboard, api, or envoy-fleet. ```sh $ kusk cluster install --no-dashboard --no-api --no-envoy-fleet ... ``` | Flag | Description | Required? | |:|:--|::| | `--name` | The prefix of the name to give to the helm releases for each of the Kusk Gateway components (default: kusk-gateway). | | | `--namespace`/`-n` | The namespace to install Kusk Gateway into. Will create the namespace if it doesn't exist (default: kusk-system). | | | `--no-dashboard` | When set, will not install the Kusk Dashboard. | | | `--no-api` | When set, will not install the Kusk Gateway api. implies --no-dashboard. | | | `--no-envoy-fleet` | When set, will not install any envoy fleets. | | To disable analytics set following environment variable: ``` export ANALYTICS_ENABLED=false ``` or run ``` ANALYTICS_ENABLED=false kusk cluster install ```
Project: Prefect (Orchestration & Management / Scheduling & Orchestration)
File: object-access-control-lists.md

description: Restrict Block and Deployment access to individual actors within a workspace. tags: UI Permissions Access Prefect Cloud enterprise teams workspaces organizations audit logs compliance search: boost: 2 Prefect Cloud's offers object-level access control lists to restrict access to specific users and service accounts within a workspace. ACLs are supported for blocks and deployments. Organization Admins and Workspace Owners can configure access control lists by navigating to an object and clicking manage access. When an ACL is added, all users and service accounts with access to an object via their workspace role will lose access if not explicitly added to the ACL. !!! Note "ACLs and visibility" Objects not governed by access control lists such as flow runs, flows, and artifacts will be visible to a user within a workspace even if an associated block or deployment has been restricted for that user. See the to learn more about options for supporting object-level access control.
Project: SOFARPC (Orchestration & Management / Remote Procedure Call)
File: Ask_Question.md

name: Ask Question about: Ask a question about usage or feature describe your question clearly describe your use scenes (why need this feature) describe the advice or solution you'd like SOFARPC version: JVM version (e.g. `java -version`): OS version (e.g. `uname -a`): Maven version: IDE version:
Project: BFE (Orchestration & Management / Service Proxy)
File: host_rule.data.md

host_rule.data records the domain names for each product. | Config Item | Description | | -- | | | Version | String<br>Verson of config file | | DefaultProduct | String<br>Default product name. | | Hosts | Struct<br>Host list for each HostTag | | Hosts{k} | Struct<br>HostTag | | Hosts{v} | String<br>Host list for HostTag | | HostTags | Struct<br>HostTag list for each product | | HostTags{k} | Struct<br>Product name | | HostTags{v} | Struct<br>HostTag list for product | ```json { "Version": "20190101000000", "DefaultProduct": null, "Hosts": { "exampleTag":[ "example.org" ] }, "HostTags": { "example_product":[ "exampleTag" ] } } ```
Project: Consul (Orchestration & Management / Service Mesh)
File: repo_management.md

This file helps track the configuration of the `.github/` folder. Issue templates are stored in `.github/ISSUE_TEMPLATE/` and follow the . The `.github/ISSUE_TEMPLATE/config.yml` controls links out to other support resources. GitHub Actions provides a pluggable architecture for creating simple automation. An Action is made of at least two files, the `workflow` file and a config file. All workflows are stored in `.github/workflows/`. Configuration files are stored one directory higher, in `.github/`. The workflow and the configuration file should be named the same when created. Create unique and clear names for these files. Issues are labeled with . This action supports simple regexes, and most string parsing. PRs are labeled with action. This supports glob parsing so that labels can be applied to changed files. is an action that holds all the configuration in a single file. In setting up a basic configuration with 60 labels, the JSON config became ~1200 lines. This solution may be feaseable in the future, but wouldn't seem as scaleable. This also creates a single point of failure for the entire labeling system. is an action that just responds based on tags, rather than tagging them as they come in. This would be helpful for responses for reoccuring types of messages. labels the top ten issues based on number of :+1: 's on an inssue.
Project: STUNner (Orchestration & Management / Service Proxy)
File: bug_report.md

name: Bug report about: Create a report to help us improve STUNner title: '' labels: '' assignees: '' [Description of the problem] [Brief description of the steps you took to encounter the problem, if applicable] Expected behavior: [What you expected to happen] Actual behavior: [What actually happened] [Which version of STUNner you are using] [Please copy-paste the output of the below commands and make sure to remove all sensitive information, like usernames, passwords, IP addresses, etc.] [Output of `kubectl get gateways,gatewayconfigs,gatewayclasses,udproutes.stunner.l7mp.io --all-namespaces -o yaml`] [Output of `kubectl -n stunner-system logs $(kubectl get pods -l control-plane=stunner-gateway-operator-controller-manager --all-namespaces -o jsonpath='{.items[0].metadata.name}')`]
Project: CloudWeGo (Orchestration & Management / Remote Procedure Call)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: '' assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: grpc-client-server-polling-engine-usage.md

Author: Sree Kuchibhotla (@sreecha) - Sep 2018 This document talks about how polling engine is used in gRPC core (both on client and server code paths). A gRPC Call is tied to a channel (more specifically a sub-channel) and a completion queue for the lifetime of the call. Once a sub-channel is picked for the call, the file-descriptor (socket fd in case of TCP channels) is added to the pollset corresponding to call's completion queue. (Recall that as per , a completion queue has a pollset by default) A gRPC channel is created between a client and a 'target'. The 'target' may resolve in to one or more backend servers. A sub-channel is the 'connection' from a client to the backend server While establishing sub-channels (i.e connections) to the backends, gRPC issues async calls which may not complete right away. When the `connect()` eventually succeeds, the socket fd is make 'writable' This means that the polling engine must be monitoring all these sub-channel `fd`s for writable events and we need to make sure there is a polling thread that monitors all these fds To accomplish this, the `grpcpollsetset` is used the following way (see picture below) The listening fd (i.e., the socket fd corresponding to the server listening port) is added to each of the server completion queues. Note that in gRPC we use SO_REUSEPORT option and create multiple listening fds but all of them map to the same listening port A new incoming channel is assigned to some server completion queue picked randomly (note that we currently over the server completion queues)
Project: APISIX (Orchestration & Management / API Gateway)
File: proxy-control.md

title: proxy-control keywords: Apache APISIX API Gateway Proxy Control description: This document contains information about the Apache APISIX proxy-control Plugin, you can use it to control the behavior of the NGINX proxy dynamically. <!-- --> The proxy-control Plugin dynamically controls the behavior of the NGINX proxy. :::info IMPORTANT This Plugin requires APISIX to run on . See for more info. ::: | Name | Type | Required | Default | Description | | -- | - | -- | - | | | request_buffering | boolean | False | true | When set to `true`, the Plugin dynamically sets the directive. | The example below enables the Plugin on a specific Route: :::note You can fetch the `admin_key` from `config.yaml` and save to an environment variable with the following command: ```bash adminkey=$(yq '.deployment.admin.adminkey[0].key' conf/config.yaml | sed 's/"//g') ``` ::: ```shell curl -i http://127.0.0.1:9180/apisix/admin/routes/1 \ -H "X-API-KEY: $admin_key" -X PUT -d ' { "uri": "/upload", "plugins": { "proxy-control": { "request_buffering": false } }, "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } }' ``` The example below shows the use case of uploading a big file: ```shell curl -i http://127.0.0.1:9080/upload -d @verybigfile ``` It's expected to not find a message "a client request body is buffered to a temporary file" in the error log. To remove the `proxy-control` Plugin, you can delete the corresponding JSON configuration from the Plugin configuration. APISIX will automatically reload and you do not have to restart for this to take effect. ```shell curl -i http://127.0.0.1:9180/apisix/admin/routes/1 \ -H "X-API-KEY: $admin_key" -X PUT -d ' { "uri": "/upload", "upstream": { "type": "roundrobin", "nodes": { "127.0.0.1:1980": 1 } } }' ```