cwielenb/CNCF-Dataset huggingface dataset:
Project: Skipper (Orchestration & Management / Service Proxy)
File: CONTRIBUTING.md

Thank you for your interest in making Skipper even better and more awesome. Your contributions are highly welcome. There are multiple ways of getting involved: Below are a few guidelines we would like you to follow. If you need help, please reach out to us: Reporting bugs is one of the best ways to contribute. Before creating a bug report, please check that an reporting the same problem does not already exist. If there is an such an issue, you may add your information as a comment. To report a new bug you should open an issue that summarizes the bug and set the label to "bug". If you want to provide a fix along with your bug report: That is great! In this case please send us a pull request as described in section . To request a new feature you should open an and summarize the desired functionality and its use case. Set the issue label to "enhancement". This is a rough outline of what the workflow for code contributions looks like: Check the list of open . Either assign an existing issue to yourself, or create a new one that you would like work on and discuss your ideas and use cases. Fork the repository on GitHub Create a topic branch, for example feature/foo fix/bar refactor/baz, from where you want to base your work. The base is usually master. Make commits of logical units. Write good commit messages (see below). Push your changes to a topic branch in your fork of the repository. Submit a pull request to Your pull request must receive a :thumbsup: from two Major changes need to include tests. Features need additionally include documentation for developers as and add in the docs/ directory. Thanks for your contributions! Skipper is formatted with . Please run it on your code before making a pull request. The coding style suggested by the Golang community is the preferred one for the cases that are not covered by gofmt, see the for details. Your commit messages ideally can answer two questions: what changed and why. The subject line should feature the what and the body of the commit should describe the why. When creating a pull request, its comment should reference the corresponding issue id. Have fun and enjoy hacking! The project owner and lead makes all final decisions, if there is a disagreement between contributors and maintainers.
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: cronfederatedhpa_test.md

| Test Case | E2E Describe Text | Comments | |--||--| | Test the scaling of FederatedHPA by creating a CronFederatedHPA rule | Test scale FederatedHPA | | | Test the scaling of a Deployment by creating a CronFederatedHPA rule | Test scale Deployment | | | Test the suspend rule in CronFederatedHPA by creating a rule that is supposed to be suspended | Test suspend rule in CronFederatedHPA | | | Test the unsuspend rule, then suspend it in CronFederatedHPA by manipulating the rule's suspension status | Test unsuspend rule then suspend it in CronFederatedHPA | |
Project: Gloo (Orchestration & Management / API Gateway)
File: backoff.proto.sk.md

title: "backoff.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Configuration defining a jittered exponential back off strategy. ```yaml "baseInterval": .google.protobuf.Duration "maxInterval": .google.protobuf.Duration ``` | Field | Type | Description | | -- | - | -- | | `baseInterval` | | The base interval to be used for the next back off computation. It should be greater than zero and less than or equal to :ref:`maxinterval <envoyapifieldconfig.core.v3.BackoffStrategy.max_interval>`. | | `maxInterval` | | Specifies the maximum interval between retries. This parameter is optional, but must be greater than or equal to the :ref:`baseinterval <envoyapifieldconfig.core.v3.BackoffStrategy.baseinterval>` if set. The default is 10 times the :ref:`baseinterval <envoyapifieldconfig.core.v3.BackoffStrategy.baseinterval>`. | <!-- 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: Kuma (Orchestration & Management / Service Mesh)
File: 023-retry-host-selection.md

Status: accepted Technical Story: https://github.com/kumahq/kuma/issues/5897 We want to add some additional retry fields plumbed through from Envoy to our Retry policy based on user demand. This is an HTTP only policy (no GRPC). ``` retry_priority retryhostpredicate hostselectionretrymaxattempts ``` Envoy has "host predicates" and "priority predicates" to enforce an additional logic when selecting a host for the attempt. With `retryhostpredicate` we get: don't retry on previously retried hosts don't retry on canary hosts (the host should be preliminarily marked with `canary: true`) (doesn't make sense for us to implement) don't retry on hosts with specified metadata key/value And with `retry_priority` we get: don't retry on previous priorities These predicates can be combined into a single `hostSelection` section: ```yaml hostSelection: predicate: OMITPREVIOUSHOSTS predicate: OMITHOSTSWITH_TAGS tags: env: dev predicate: OMITPREVIOUSPRIORITIES updateFrequency: 2 ``` Having configurable `hostSelection` implies exposing the `hostselectionretrymaxattempts` parameter as well. It allows configuring the maximum number of times host selection will be reattempted before giving up. ```go type HTTP struct { // ... // HostSelection is a list of predicates that dictate how hosts should be selected // when requests are retried. HostSelection *[]Predicate `json:"hostSelection,omitempty"` // HostSelectionMaxAttempts is the maximum number of times host selection will be // reattempted before giving up, at which point the host that was last selected will // be routed to. If unspecified, this will default to retrying once. HostSelectionMaxAttempts *int64 `json:"hostSelectionMaxAttempts,omitempty"` } type PredicateType string var ( OmitPreviousHosts PredicateType = "OmitPreviousHosts" OmitHostsWithTags PredicateType = "OmitHostsWithTags" OmitPreviousPriorities PredicateType = "OmitPreviousPriorities" ) type Predicate struct { // Type is requested predicate mode. Available values are OmitPreviousHosts, OmitHostsWithTags, // and OmitPreviousPriorities. PredicateType PredicateType `json:"predicate"` // Tags is a map of metadata to match against for selecting the omitted hosts. Required if Type is // OmitHostsWithTags Tags map[string]string `json:"tags,omitempty"` // UpdateFrequency is how often the priority load should be updated based on previously attempted priorities. // Used for OmitPreviousPriorities. Default is 2 if not set. UpdateFrequency int32 `json:"updateFrequency,omitempty"` } ``` Implement these 3 fields / options. Implement these 3 fields / options.
Project: Skipper (Orchestration & Management / Service Proxy)
File: README.md

As with , the lightstep tracer is configured by setting `-opentracing="lightstep OPTIONS"`. Valid options are: `component-name` - set component name instead of `skipper` `token` - Access token for the lightstep satellites (REQUIRED) `protocol` - sets `UseGRPC` option to true if set to `"grpc"`, defaults to `"grpc"` `grpc-max-msg-size` - maximum size for gRPC messages `min-period` - minimum time to wait before sending spans to the satellites, string with value parseable by `time.ParseDuration` `max-period` - maximum time to wait before sending spans to the satellites, string with value parseable by `time.ParseDuration` `max-buffered-spans` - maximum number of buffered spans before sending to the satellites `tag` - key-value pairs (`key=value`) separated by commas (`,`) to set as tags in every span `collector` - hostname (+port) - (e.g. `lightstep-satellites.example.org:4443`) to send the spans to, i.e. your lightstep satellites `plaintext` (boolean) - force plaintext communication with satellites `cmd-line` - override what is reported as command line `log-events` - if this option is present, it will log events from the tracer `propagators` - set propagators to use (i.e. format of http headers used for tracing). This can be used to pick up traces from / to applications which only understand the B3 format (e.g. grafana where the jaeger instrumentation can be switched to use the B3 format). This can be combined, e.g. `lightstep,b3` should be used to pick up both formats (attempted in that order). `lightstep` or `ls` - use the standard lightstep headers (default) `b3` - use the B3 propagation format
Project: Apache Zookeeper (Orchestration & Management / Coordination & Service Discovery)
File: zookeeperQuotas.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. //--> * * <a name="zookeeper_quotas"></a> ZooKeeper has both namespace and bytes quotas. You can use the ZooKeeperMain class to setup quotas. ZooKeeper prints WARN messages if users exceed the quota assigned to them. The messages are printed in the log of the ZooKeeper. Notice: What the `namespace` quota means is the count quota which limits the number of children under the path(included itself). $ bin/zkCli.sh -server host:port The above command gives you a command line option of using quotas. <a name="Setting+Quotas"></a> You can use `setquota` to set a quota on a ZooKeeper node. It has an option of setting quota with `-n` (for namespace/count) and `-b` (for bytes/data length). The ZooKeeper quota is stored in ZooKeeper itself in /zookeeper/quota. To disable other people from changing the quotas, users can set the ACL for /zookeeper/quota ,so that only admins are able to read and write to it. If the quota doesn't exist in the specified path,create the quota, otherwise update the quota. The Scope of the quota users set is all the nodes under the path specified (included itself). In order to simplify the calculation of quota in the current directory/hierarchy structure, a complete tree path(from root to leaf node) can be set only one quota. In the situation when setting a quota in a path which its parent or child node already has a quota. `setquota` will reject and tell the specified parent or child path, users can adjust allocations of quotas(delete/move-up/move-down the quota) according to specific circumstances. Combined with the Chroot, the quota will have a better isolation effectiveness between different applications.For example: ```bash 192.168.0.1:2181,192.168.0.2:2181,192.168.0.3:2181/apps/app1 setquota -n 100000 /apps/app1 ``` Users cannot set the quota on the path under /zookeeper/quota The quota supports the soft and hard quota. The soft quota just logs the warning info when exceeding the quota, but the hard quota also throws a `QuotaExceededException`. When setting soft and hard quota on the same path, the hard quota has the priority. <a name="Listing+Quotas"></a> You can use listquota to list a quota on a ZooKeeper node. <a name="Deleting+Quotas"></a> You can use delquota to delete quota on a ZooKeeper node.
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: linux-nnp.md

title: Apache Mesos - Linux NNP (no\new\privs) Isolator in Mesos Containerizer layout: documentation This document describes the `linux/nnp` isolator. This isolator sets the flag for all containers launched using the . The `nonewprivs` flag disables the ability of container tasks to acquire any additional privileges by means of executing a child process e.g. through invocation of `setuid` or `setgid` programs. To enable the `linux/nnp` isolator, append `linux/nnp` to the flag when starting the Mesos agent.
Project: BFE (Orchestration & Management / Service Proxy)
File: mod_compress.md

mod_compress compresses responses based on specified rules. conf/modcompress/modcompress.conf | Config Item | Description | | | - | | Basic.DataPath | String<br>Path of rule configuration | | Log.OpenDebug | Boolean<br>Whether enable debug logs<br>Default False | ```ini [Basic] DataPath = modcompress/compressrule.data [Log] OpenDebug = false ``` | Config Item | Description | | -- | -- | | Version | String<br>Version of config file | | Config | Object<br>Compress rule for each product | | Config{k} | String<br>Product name | | Config{v} | Object<br>A list of compress rules | | Config{v}[] | Object<br>A compress rule | | Config{v} | | Config{v}[].Action | Object<br>Action | | Config{v}[].Action.Cmd | String<br>Name of Action | | Config{v}[].Action.Quality | Integer<br>Compression level | | Config{v}[].Action.FlushSize | Integer<br>Flush size | | Action | Description | | | | | GZIP | Compress response using gzip method | | BROTLI | Compress response using brotli method | ```json { "Config": { "example_product": [ { "Cond": "reqhostin(\"www.example.org\")", "Action": { "Cmd": "GZIP", "Quality": 9, "FlushSize": 512 } } ] }, "Version": "20190101000000" } ```
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: kusk_completion.md

Generate the autocompletion script for the specified shell Generate the autocompletion script for kusk for the specified shell. See each sub-command's help for details on how to use the generated script. ``` -h, --help help for completion ``` ``` --config string config file (default is $HOME/.kusk.yaml) ``` - - Generate the autocompletion script for bash - Generate the autocompletion script for fish - Generate the autocompletion script for powershell - Generate the autocompletion script for zsh
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.16.0.md

We are delighted to present version 1.16.0 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. A big thank you to everyone who contributed to the release. PR https://github.com/projectcontour/contour/pull/3627 added support for TLSRoute to enable Passthrough TCP Proxying to pods via SNI. See https://github.com/projectcontour/contour/issues/3440 for additional information on TLSRoute feature requirements. PR https://github.com/projectcontour/contour/pull/3659 added GatewayClass support through the gateway.controllerName configuration parameter. The gateway.namespace and gateway.name parameters are required when setting gateway.controllerName. When the cluster contains Gateway API CRDs and this parameter is set, Contour will reconcile GatewayClass resources with the spec.controller field that matches gateway.controllerName. ControllerName should take the form of `projectcontour.io/<namespace>/contour`, where `<namespace>` is the namespace that Contour runs in. With PR https://github.com/projectcontour/contour/pull/3661, Contour will no longer ignore a certificate under the following conditions: If no CA is set and "skip verify" is true, client certs are not required by Envoy. If CA set and "skip verify" is true, client certs are required by Envoy. CA is still required if "skip verify" is false. `caCert` is now optional since skipClientCertValidation can be true. PR https://github.com/projectcontour/contour/pull/3658 added an `omitempty` JSON tag to omit the `caCert` field when serializing to JSON and it hasn't been specified. PR https://github.com/projectcontour/contour/pull/3704 revamps the Contour website based on . Check out the fresh new look and tell us what you think. PR https://github.com/projectcontour/contour/pull/3642 removed the `experimental-service-apis` flag has been removed. The gateway.name & gateway.namespace in the Contour configuration file should be used for configuring Gateway API (formerly Service APIs). PR https://github.com/projectcontour/contour/pull/3645 removed support for Ingress v1beta1. Ingress v1 resources should be used with Contour. Please consult the . Were immensely grateful for all the community contributions that help make Contour even better! For this release, special thanks go out to the following contributors: @geoffcline @pandeykartikey @pyaillet 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: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: 2018-05-15-new-website.md

title: RIG has a website! author: Kevin Bader authorURL: https://twitter.com/KevnBadr RIG version 1.0 was basically a working prototype, but with version 2.0 approaching, we're thinking a lot about ways of improving the user experience and getting the community aboard. Right now, RIG may not be the most inviting product on earth, so let's change that! In the following weeks, we're going to put a strong focus on improving the user experience: We'll be working on the documentation, so that it'll be easier and more obvious what RIG can do, and how to get started using it. To lower the learning curve, we're planning a "development mode" with sane defaults for running RIG on your laptop. Since writing a login service shouldn't be your highest priority when starting a project, JWT validation will be made optional. Also, a new subscription mechanism will enable clients to create subscriptions without any tokens at allmore on that in a later blog post! Speaking of blog posts.. Blog posts! We realize that communication is key to building a community around RIG. We start off by writing blog posts on a regular basis (hopefully), but there are also other ideas, like video tutorials. Stay tuned!
Project: Easegress (Orchestration & Management / API Gateway)
File: SECURITY.md

Supported : | Version | Supported | | - | | | 1.22.x | :whitecheckmark: | | 1.21.x | :whitecheckmark: | | < 1.21 | :x: | If you would like to report a vulnerability in the Easegress or to let us know of a publicly disclosed security vulnerability (e.g. https://nvd.nist.gov/vuln/detail/CVE-2019-6486 ), please email us security@megaease.com.
Project: Flomesh Service Mesh (FSM) (Orchestration & Management / Service Mesh)
File: improvement---feature-request.md

name: Improvement / Feature Request about: Suggest an enhancement for the fsm project title: '' labels: improvement / feature request assignees: '' Please describe the Improvement and/or Feature Request <!-- A clear and concise description of the proposal. --> Scope (please mark with X where applicable) New Functionality [ ] Install [ ] SMI Traffic Access Policy [ ] SMI Traffic Specs Policy [ ] SMI Traffic Split Policy [ ] Permissive Traffic Policy [ ] Ingress [ ] Egress [ ] Envoy Control Plane [ ] CLI Tool [ ] Metrics [ ] Certificate Management [ ] Sidecar Injection [ ] Logging [ ] Debugging [ ] Tests [ ] CI System [ ] Demo [ ] Project Release [ ] Possible use cases <!-- A clear and concise description of possible use cases for this proposal. -->
Project: Envoy (Orchestration & Management / Service Proxy)
File: coverage.md

In a PR run, for example https://github.com/envoyproxy/envoy/pull/14672 Click on the check mark or X for the CI results you want to look at. Generally this will be the last run, but for this example well pick an earlier, failed run. Next, click on the Details link on the coverage run. If the run was a success you may need to scroll down to see the coverage build. Next up, click on the warnings/errors link. For a successful coverage run, this will list zero errors/warnings but will still be clickable On the azure results page, again click through to see results. In this case the error reason was clear, and the directory missing coverage is listed. To get an understanding of what lines arent covered, you can browse further. Scroll down on the left, and click on Upload coverage reports This will provide a link on the right, telling you where the coverage upload went, in this case a link to https://storage.googleapis.com/envoy-pr/269d783/coverage/index.html (which will only be valid for some number of days). Clicking on the link provides a full color-annotated coverage report You can browse this report to the directory in question. In this particular case the coverage issue was actually a coverage bug, where trailing braces in tested switch statements are considered uncovered lines. Generally this will instead provide a branch of code which simply needs unit tests.
Project: Sentinel (Orchestration & Management / Service Proxy)
File: PULL_REQUEST_TEMPLATE.md

<!-- Thanks for submitting a pull request! Here are some tips for you: Please make sure you have read and understood the contributing guidelines: https://github.com/alibaba/Sentinel/blob/master/CONTRIBUTING.md Please make sure the PR has a corresponding issue. --> <!--If that, add "Fixes #xxxx" below in the next line. For example, Fixes #15. Otherwise, add "NONE" -->
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2014-03-28-mesos-community-update-1.md

layout: post title: "Mesos Community Update #1" permalink: /blog/mesos-community-update-1/ published: true post_author: display_name: Matt Trifiro twitter: mtrifiro tags: Community canonical_url: http://mesosphere.io/community/2014/03/20/mesos-community-update-1/ This is a cross post from the . Our community is in the midst of a revolution. Mesos is no longer an edge technology, only for the Twitters and Airbnbs of the world; its going mainstream and we are at its center. There is more activity on the Apache mailing lists, more commits in the code, more frameworks being developed, more developers building tools around Mesosand, perhaps most excitingly, there are more companies deploying Mesos into production. All of this activity makes it harder to keep up! The Mesosphere team wants to help you keep up with all of the community activity by curating a concise semi-regular update, of which this is the first. We are looking to share the most interesting and important activities in the Mesos community. Venture capital icon gave a call-out to Mesos in his 2014 Open Networking Summit keynote, where he waxed about the need for a data center OS. The Mesos portion begins at 24:07 in the . Lab49 software engineer re-implemented Stripes legendary Capture the Flag (CTF) system on Mesos. Read his blow-by-blow description here: . Community member gave an introductory talk on Mesos at the in Prague. In his 59-slide talk, he covered everything from workload balancing to Mesos fault tolerance. View his presentation on SlideShare: . On February 27, and you can . The 0.17.0 release features auto-recovery of the replicated log, which enhances Mesoss high-availability and fault-tolerance. Read more here: On the path toward fully implementing the , we saw progress toward creating . Placing a small amount of state information in highly-available storage will make recovery of slaves faster and more graceful (this has been ). Mesosphere has packaged a pre-release version of Mesos 0.18.0 (release candidate 4) that you can now . The primary features of the are changes that make it easier to insert pluggable container technologies, like Docker. 0.18.0 foreshadows some pretty interesting Docker integrations with Mesos. BBQ at Mesosphere HQ, 6-8 pm, March 28th. Come join us for a low-key BBQ. 145A Hampshire St, San Francisco (near Potrero @ 15th). Swing by and meet . , April 7-9 in Denver. Come see two Mesos presentations: and . We hope to publish these updates at least a few times each month, and were interested in your suggestions. Please let us know what you think about the length, content and style, and send us your tips on what to publish each week. Do you have something to share? Write to us at . This post was co-authored by Abhishek Parolkar. Follow him on Twitter at .