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

title: "glooctl create upstream kube" weight: 5 Create a Kubernetes Upstream Kubernetes Upstreams represent a collection of endpoints for Services registered with Kubernetes. Typically, Gloo will automatically discover these upstreams, meaning you don't have to create them. However, if upstream discovery in Gloo is disabled, or RBAC permissions have not been granted to Gloo to read from the registry, Kubernetes services can be added to Gloo manually via the CLI. ``` glooctl create upstream kube [flags] ``` ``` -h, --help help for kube --kube-service string name of the kubernetes service --kube-service-labels strings comma-separated list of labels (key=value) to use for customized selection of pods for this upstream. can be used to select subsets of pods for a service e.g. for blue-green deployment --kube-service-namespace string namespace where the kubernetes service lives (default "default") --kube-service-port uint32 the port exposed by the kubernetes service. for services with multiple ports, create an upstream for each port. (default 80) --service-spec-type string if set, Gloo supports additional routing features to upstreams with a service spec. The service spec defines a set of features ``` ``` -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: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2017-06-07-mesos-1-3-0-released.md

layout: post title: Apache Mesos 1.3.0 Released permalink: /blog/mesos-1-3-0-released/ published: true post_author: display_name: Neil Conway twitter: neil_conway tags: Release The latest Mesos release, 1.3.0, is now available for . This release includes the following features and improvements: - Support for frameworks to receive resources for multiple roles. This allows "multi-user" frameworks to leverage the role-based resource allocation in mesos. Prior to this support, one had to run multiple instances of a single-user framework to achieve multi-user resource allocation, or implement multi-user resource allocation in the framework. - Authentication and authorization support for HTTP executors. A new `--authenticatehttpexecutors` agent flag enables required authentication on the HTTP executor API. A new `--executorsecretkey` flag sets a key file to be used when generating and authenticating default tokens that are passed to HTTP executors. Note that enabling these flags after upgrade is disruptive to HTTP executors that were launched before the upgrade; see 'docs/authentication.md' for more information on these flags and the recommended upgrade procedure. Implicit authorization rules have been added which allow an authenticated executor to make executor API calls as that executor and make operator API calls which affect that executor's container. See 'docs/authorization.md' for more information on these implicit authorization rules. - Support for frameworks to modify the role(s) they are subscribed to. This is essential to supporting "multi-user" frameworks (see ) in that roles are expected to come and go over time (e.g. new employees join, new teams are formed, employees leave, teams are disbanded, etc). More than 140 other bug fixes and improvements made it into this release. For full release notes with all features and bug fixes, please refer to the . Rolling upgrades from a Mesos 1.2.0 cluster to Mesos 1.3.0 are straightforward. Please refer to the for detailed information on upgrading to Mesos 1.3.0. 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 55 contributors who made Mesos 1.3.0 possible: Aaron Wood, Abhishek Dasgupta, Adam B, Alex Clemmer, Alexander Rojas, Alexander Rukletsov, Anand Mazumdar, Andrew Schwartzmeyer, Andy Pang, Anindya Sinha, Anthony Sottile, Armand Grillet, Avinash sridharan, Ayanampudi Varsha, Benjamin Bannier, Benjamin Mahler, Benno Evers, Budnik Andrei, Chris Cao, Chun-Hung Hsiao, Daniel Pravat, Deshi Xiao, Dmitry Zhuk, Eric Chung, Gastn Kleiman, Gilbert Song, Greg Mann, Guangya Liu, Haosdent Huang, Haris Choudhary, Ilya Pronin, James Peach, Jan Schlicht, Jay Guo, Jeff Coffler, Jiang Yan Xu, Jie Yu, John Kordich, Joseph Wu, Kamil Wargula, Kapil Arya, Kevin Klues, Klaus Ma, Michael Park, Neil Conway, Pierre Cheynier, Qian Zhang, Srinivas Brahmaroutu, Till Toenshoff, Tomasz Janiszewski, Vinod Kone, Yan Xu, Zhitao Li, Zhongbo Tian, and ondrej.smola.
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.14.2.md

We are delighted to present version 1.14.2 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. As an additional mitigation for , has been backported to this release. Previously an ExternalName service with an address of `localhost` and port matching the Envoy admin interface listener port could expose admin endpoints that would allow an attacker to shut down Envoy remotely. Contour's bootstrap command now configures Envoy to listen on a Unix domain socket to ensure an ExternalName service cannot expose the "writable" endpoints of the admin interface. For backwards compatibility Contour now configures an additional Envoy listener to expose endpoints useful for debugging. This listener does not expose any endpoints that can be used to modify data, set Envoy healthcheck status, or shut down Envoy. See for some more detail. Note: While this fix does mitigate some aspects of CVE-2021-32783, ExternalName service usage is still discouraged as they can still be used to expose services across namespaces. If you have been using the Contour example YAMLs to deploy Contour and Envoy, no changes are required except to deploy the updated YAMLs for release 1.14.2. If you are managing your Envoy DaemonSet using another method, be sure to inspect the . An is required and it must be mounted in the and containers to ensure both have access to the Unix domain socket Envoy is now configured to listen on. Upgrades the default Envoy version to 1.17.4 for security and bug fixes. See the for more details.
Project: Gloo (Orchestration & Management / API Gateway)
File: socket_option.proto.sk.md

title: "socket_option.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Generic socket option message. This would be used to set socket options that might not exist in upstream kernels or precompiled Envoy binaries. [#next-free-field: 7] ```yaml "description": string "level": int "name": int "intValue": int "bufValue": bytes "state": .solo.io.envoy.api.v2.core.SocketOption.SocketState ``` | Field | Type | Description | | -- | - | -- | | `description` | `string` | An optional name to give this socket option for debugging, etc. Uniqueness is not required and no special meaning is assumed. | | `level` | `int` | Corresponding to the level value passed to setsockopt, such as IPPROTO_TCP. | | `name` | `int` | The numeric name as passed to setsockopt. | | `intValue` | `int` | Because many sockopts take an int value. Only one of `intValue` or `bufValue` can be set. | | `bufValue` | `bytes` | Otherwise it's a byte buffer. Only one of `bufValue` or `intValue` can be set. | | `state` | | The state in which the option will be applied. When used in BindConfig STATE_PREBIND is currently the only valid value. | | Name | Description | | -- | -- | | `STATE_PREBIND` | Socket options are applied after socket creation but before binding the socket to a port | | `STATE_BOUND` | Socket options are applied after binding the socket to a port but before calling listen() | | `STATE_LISTENING` | Socket options are applied after calling listen() | <!-- 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: Kusk Gateway (Orchestration & Management / API Gateway)
File: kusk.md

``` --config string config file (default is $HOME/.kusk.yaml) -h, --help help for kusk -t, --toggle Help message for toggle ``` - parent command for api related functions - Generate the autocompletion script for the specified shell - Access the kusk dashboard - parent command for api related functions - Install kusk-gateway, envoy-fleet, api, and dashboard in a single command - Spin up a local mocking server serving your API - Upgrade kusk-gateway, envoy-fleet, api, and dashboard in a single command - version for kusk
Project: Prefect (Orchestration & Management / Scheduling & Orchestration)
File: pull_request_template.md

<!-- Thanks for opening a pull request to Prefect! We've got a few requests to help us review contributions: Make sure that your title neatly summarizes the proposed changes. Provide a short overview of the change and the value it adds. Share an example to help us understand the change in user experience. Confirm that you've done common tasks so we can give a timely review. Review our contribution guidelines: https://docs.prefect.io/latest/contributing/overview/ Happy engineering! --> <!-- Include an overview here --> <!-- Share an example of the change in action. A code blurb is best. Changes to features should include an example that is executable by a new user. If changing documentation, a link to a preview of the page is great. --> <!-- These boxes may be checked after opening the pull request. --> [ ] This pull request references any related issue by including "closes `<link to issue>`" If no issue exists and your change is not a small fix, please first. [ ] If this pull request adds new functionality, it includes unit tests that cover the changes [ ] This pull request includes a label categorizing the change e.g. `maintenance`, `fix`, `feature`, `enhancement`, `docs`. <!-- If you do not have permission to add a label, a maintainer will add one for you --> For documentation changes: [ ] This pull request includes redirect settings in `netlify.toml` for files that are removed or renamed. For new functions or classes in the Python SDK: [ ] This pull request includes helpful docstrings. [ ] If a new Python file was added, this pull request contains a stub page in the Python SDK docs and an entry in `mkdocs.yml` navigation.
Project: KEDA (Orchestration & Management / Scheduling & Orchestration)
File: LICENSE.md

Open Source License (BSD 3-Clause) Copyright (c) 2014, Patrick Hayes / HighWire Press All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Project: Docker Swarm (Orchestration & Management / Scheduling & Orchestration)
File: ISSUE_TEMPLATE.md

<!-- Note: If your bug report relates to Docker's swarm mode, please file it against the Moby repository instead: https://github.com/moby/moby/issues/new In general, if you experienced a bug using commands that start with `docker`, the report probably belongs in the Moby repository. The swarmkit repository should only be used for specific low-level issue reports related to swarmkit's internals. That is to say, even if you have tracked the root cause of a problem to swarmkit, that issue should probably still be filed under moby/moby. This helps us organize our bug triage. For more information about reporting issues on the Docker project, see https://github.com/moby/moby/blob/master/CONTRIBUTING.md#reporting-other-issues -->
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.2.4.md

+++ title = "CoreDNS-1.2.4 Release" description = "CoreDNS-1.2.4 Release Notes." tags = ["Release", "1.2.4", "Notes"] release = "1.2.4" date = "2018-10-17T20:01:29+01:00" author = "coredns" +++ We are pleased to announce the of CoreDNS-1.2.4! Remember we was a big release and took quite a while? Well, we've fixed that glitch; as 1.2.4 is here now. CoreDNS v1.2.3's kubernetes plugin DOES NOT WORK IN KUBERNETES and our testing that didn't catch that regression, nor the Kubernetes scale testing which doesn't really exercise the whole API. use zero of the minimal negative TTL (if no suitable TTL was found in the packet). fix a grave bug that made plugin unusable* in Kubernetes. Chris O'Haver, Miek Gieben. For documentation see our (in progress!) . For help and other resources, see our .
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_plugin.md

title: "glooctl plugin" weight: 5 Commands for interacting with glooctl plugins Commands for interacting with glooctl plugins. Glooctl plugins are arbitrary binary executables in your path with the prefix 'glooctl-'. ``` glooctl plugin [flags] ``` ``` -h, --help help for plugin ``` ``` -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 - List available glooctl plugins
Project: Gloo (Orchestration & Management / API Gateway)
File: gateway.solo.io.project.sk.md

title: "gateway.solo.io.project" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> API Version: `gateway.solo.io.v1` <!-- 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: Flomesh Service Mesh (FSM) (Orchestration & Management / Service Mesh)
File: bug_report.md

name: Bug report about: Report a bug encountered while operating fsm title: '' labels: bug assignees: '' <!-- This issue tracker is a best-effort forum for users and customers to report bugs. Be sure to not include any sensitive information. Sensitive information should NOT be included in this issue. --> Bug description: Affected area (please mark with X where applicable): Install [ ] SMI Traffic Access Policy [ ] SMI Traffic Specs Policy [ ] SMI Traffic Split Policy [ ] Permissive Traffic Policy [ ] Ingress [ ] Egress [ ] Sidecar Control Plane [ ] CLI Tool [ ] Metrics [ ] Certificate Management [ ] Sidecar Injection [ ] Logging [ ] Debugging [ ] Tests [ ] Demo [ ] CI System [ ] Expected behavior: Steps to reproduce the bug (as precisely as possible): How was fsm installed?: Anything else we need to know?: Bug report archive: <!-- Generate and upload bug report archive for the given app namespaces, deployments, and pods. Use `fsm support bug-report --app-namespaces <ns1>,<ns2> --app-deployments <ns1>/<dep1>,<ns2>/<dep2> --app-pods <ns1>/<pod1>` --> Environment: fsm version (use `fsm version`): Kubernetes version (use `kubectl version`): Size of cluster (number of worker nodes in the cluster): Others:
Project: Consul (Orchestration & Management / Service Mesh)
File: health-checks.md

This section is still a work in progress. contains the logic for performing active . There are many paths to register a check. Many of these use different struct types, so to properly validate and convert a check, all of these paths must be reviewed and tested. API - the `Checks` field on `structs.RegisterRequest`. The entrypoint is `CatalogRegister` in [agent/catalog_endpoint.go]. API - the entrypoint is `AgentRegisterCheck` in [agent/agent_endpoint.go] API - the `Check` or `Checks` fields on `ServiceDefinition`. The entrypoint is `AgentRegisterService` in [agent/agent_endpoint.go]. Config - the `Checks` and `Check` fields on `config.Config` in [agent/config/config.go]. Config - the `Checks` and `Check` fields on `ServiceDefinition` in [agent/config/config.go]. The returned fields of `ServiceDefinition` in [agent/config/builder.go]. CLI - the `Checks` and `Check` fields on `api.AgentServiceRegistration`. The entrypoint is `ServicesFromFiles` in [command/services/config.go]. API - the `Transaction` API allows for registering a check.
Project: KubeBrain (Orchestration & Management / Coordination & Service Discovery)
File: README.md

English | Kubernetes is a distributed application orchestration and scheduling system. It has become the de facto standard for cloud-native application bases, but its official stable operation scale is limited to 5K nodes. This is sufficient for most application scenarios, but still insufficient for applications with millions of machine nodes. With the growth of "digitalisation" and "cloud-native" in particular, the overall global IT infrastructure will continue to grow at an accelerated rate. For distributed application orchestration and scheduling systems, there are two ways to adapt to this trend. Horizontal scaling: building the ability to manage N clusters. Vertical scaling: increasing the size of individual clusters. In order to scale a single cluster, the storage of meta/state information is one of the core scaling points, and this project is to solve the scalability and performance problems of cluster state information storage. We investigated some of existing distributed storage systems, and analyzed the performance of ETCD and the interface usage in kubernetes for state information storage. Inspired by the kine project, KubeBrain was implemented as the core service for Kubernetes state information storage. Stateless: KubeBrain is a component that implements the storage server interface required by the API Server. It performs the conversion of the storage interface and does not actually store the data. The actual metadata is stored in the underlying storage engine, and the data that the API Server needs to monitor is stored in the memory of the master node. Extensibility: KubeBrain abstracts the key-value database interface, and implements the interface needed for storage API Server storage on this basis. All key-value databases with specified characteristics can be adapted to the storage interface. High availability: KubeBrain currently uses master-slave architecture. The master node supports all operations including conditional update, read, and event monitoring. The slave node supports read operations, and automatically selects the master based on K8S's "leaderelection" to achieve high availability. Horizontal scaling: In a production environment, KubeBrain usually uses a distributed key-value database to store data. Horizontal scaling involves two levels: At the KubeBrain level, concurrent read performance can be improved by adding slave nodes; At the storage engine level, read and write performance and storage capacity can be improved by adding storage nodes. [ ] Guarantee consistence in critical cases [ ] Optimize storage engine interface [ ] Optimize unit test code, add use cases and error injection [ ] Implement Proxy to make it more scalable Please check for more details. Please check for more details. Email: kubewharf.conduct@bytedance.com Member: Please refer to . This project is licensed under the .
Project: Gloo (Orchestration & Management / API Gateway)
File: cipher_detection_input.proto.sk.md

title: "cipherdetectioninput.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Specifies that matching should be performed by the destination IP address. [#extension: io.solo.matching.inputs.cipherdetectioninput] ```yaml "passthroughCiphers": []int "terminatingCiphers": []int ``` | Field | Type | Description | | -- | - | -- | | `passthroughCiphers` | `[]int` | List of TLS ciphers to send to the passthrough cipher chain. Ciphers must be provided using their 16-bit value. These numbers of IANA standardised values for all possible cipher suites and can be found here: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml example: to select the following cipher 0x00,0x3c TLSRSAWITHAES128CBCSHA256 this field should be set to 0x003c. | | `terminatingCiphers` | `[]int` | Terminating ciphers are those that should be considered as supported. If not specified, defaults to whatever the current envoy implementation finds to be the default set of ciphers. | <!-- 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 -->