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

Run BFE with example configuration files: ```bash docker run -p 8080:8080 -p 8443:8443 -p 8421:8421 bfenetworks/bfe ``` you can access http://127.0.0.1:8080/ and got status code 500 because of there is rule be matched. you can access http://127.0.0.1:8421/ got monitor information. Run BFE with your configuration files: ```bash // prepare your configuration (see section Configuration if you need) to dir /Users/BFE/conf docker run -p 8080:8080 -p 8443:8443 -p 8421:8421 -v /Users/BFE/Desktop/log:/bfe/log -v /Users/BFE/Desktop/conf:/bfe/conf bfenetworks/bfe ``` Get familiar with Get started with
Project: Linkerd (Orchestration & Management / Service Mesh)
File: MAINTAINERS.md

The Linkerd maintainers are: Oliver Gould <ver@buoyant.io> @olix0r Alejandro Pedraza <alejandro@buoyant.io> @alpeb Alex Leong <alex@buoyant.io> @adleong Matei David <matei@buoyant.io> @mateiidavid Zahari Dichev <zahari@buoyant.io> @zaharidichev The Linkerd directors are: William Morgan <william@buoyant.io> @wmorgan The Linkerd Steering Committee members are: Steve Gray (ZeroFlucs) @steve-gray Christian Hning (BWI) @christianhuening Dan Williams (LoveHolidays) @dwilliams782 Former maintainers include: Andrew Seigner <siggy@buoyant.io> @siggy Kevin Ingleman <ki@buoyant.io> @klingerf Risha Mars <mars@buoyant.io> @rmars Hema Lee <Hemalekha.Lee@nordstrom.com> @hemakl Tarun Pothulapati <tarun@buoyant.io> @pothulapati Kevin Leimkuhler @kleimkuhler Steve Jenson @stevej Eliza Weisman <eliza@buoyant.io> @hawkw <!-- Submit a PR modifying this file Obtain approvals per GOVERNANCE.md Invite maintainer to https://github.com/orgs/linkerd/teams/maintainers/members Invite maintainer to https://github.com/orgs/linkerd/people -->
Project: wasmCloud (Orchestration & Management / Scheduling & Orchestration)
File: 0013-transition-feature-focus-to-rust.md

| Status | Deciders | Date | | -- | | - | | accepted | wasmCloud Maintainers | 08-02-2023 | This ADR is confirmation of the decision(s) made in RFC . Up until very recently, the only fully supported wasmCloud host runtime was the OTP host. As the RFC discusses, there is now a shared Rust crate that is used by the OTP host for wasm functionality. This makes the OTP host little more than a facade around these features. As we add new features to the Rust library that are intended for many potential hosts, and not just the OTP host, we will be spending less and less time managing the OTP codebase The decision drivers for this are varied. One of the primary drivers is the desire to have up-to-the-minute support for the latest developments in both WASI and WebAssembly components. This functionality starts in wasmtime, and within wasmtime the Rust libraries are primary. Further, we want to ensure that the wasmCloud host is not only easy to use for developers building actors, but we want it to be easy for people to contribute as well. It's the current opinion that the Elixir/OTP host is not as easy to contribute to as the Rust host will be. The options considered were to continue supporting the Elixir/OTP host as primary, to change to a Rust focus, or to choose a different language. The decision is that going forward the Rust host will be the primary wasmCloud host. Until such time as the OTP host can be retired, the Rust host will need to conform to the current lattice and host specifications so that it can run within the same lattice as the "legacy" OTP host.
Project: Emissary-Ingress (Orchestration & Management / API Gateway)
File: pull_request_template.md

A few sentences describing the overall goals of the pull request's commits. List related issues. A few sentences describing what testing you've done, e.g., manual tests, automated tests, deployed in production, etc. <!-- Please review the requirements for each checkbox, and check them off (change "[ ]" to "[x]") as you verify that they are complete. --> [ ] Does my change need to be backported to a previous release? What backport versions were discussed with the Maintainers in the Issue? [ ] I made sure to update `CHANGELOG.md`. Remember, the CHANGELOG needs to mention: Any new features Any changes to our included version of Envoy Any non-backward-compatible changes Any deprecations [ ] This is unlikely to impact how Ambassador performs at scale. Remember, things that might have an impact at scale include: Any significant changes in memory use that might require adjusting the memory limits Any significant changes in CPU use that might require adjusting the CPU limits Anything that might change how many replicas users should use Changes that impact data-plane latency/scalability [ ] My change is adequately tested. Remember when considering testing: Your change needs to be specifically covered by tests. Tests need to cover all the states where your change is relevant: for example, if you add a behavior that can be enabled or disabled, you'll need tests that cover the enabled case and tests that cover the disabled case. It's not sufficient just to test with the behavior enabled. You also need to make sure that the entire area being changed has adequate test coverage. If existing tests don't actually cover the entire area being changed, add tests. This applies even for aspects of the area that you're not changing check the test coverage, and improve it if needed! We should lean on the bulk of code being covered by unit tests, but... ... an end-to-end test should cover the integration points [ ] I updated `DEVELOPING.md` with any any special dev tricks I had to use to work on this code efficiently. [ ] The changes in this PR have been reviewed for security concerns and adherence to security best practices.
Project: Flomesh Service Mesh (FSM) (Orchestration & Management / Service Mesh)
File: issue_triage_guide.md

title: "Issue Triage" description: "Issue Triage Guide" type: docs This guide describes how to triage GitHub issues on the for Flomesh Service Mesh (FSM). Identify the cause of the issue as explained Tag the issue with relevant labels. Relevant labels would include what area of the codebase the issue is most aligned with (ex. cli) or if it is a bug, label the issue with the bug label Prioritize the issue with a P1, P2 or P3 label (if possible) where: P1: product cannot ship. Should be addressed as soon as possible. Eg: high priority bug P2: Product cannot ship, but it does not need to be addressed immediately. Eg: high priority feature, lower priority bug P3: Resolution of the work item is optional based on resources, time, and risk. Eg: a nice to have feature If you have time and can resolve the issue, resolve it. If not, put links to the code to where you see the problem arising If the issue looks like it is a bug that needs to be resolved immediately, either fix the issue or reach out to the core maintainers to see if you can assign the issue to someone for follow up If it's a bug: Reproduce the issue to make sure it is an actual issue Label it with the `bug` label If possible, fix it or else reference links to the code If it's a question: Ask around, go through docs, etc. Label it with the `question` label Respond to the question If it's a feature request Ask/understand the use cases Label it with the `Improvement/Feature Request` label and add other appropriate labels
Project: Karmada (Orchestration & Management / Scheduling & Orchestration)
File: VERSIONING.md

We follow the , and use the corresponding tooling. For the purposes of the aforementioned guidelines, controller-runtime counts as a "library project", but otherwise follows the guidelines exactly. For release branches, we generally tend to support backporting one (1) major release (`release-{X-1}` or `release-0.{Y-1}`), but may go back further if the need arises and is very pressing (e.g. security updates). Note the . Particularly: We DO guarantee Kubernetes REST API compatibility -- if a given version of controller-runtime stops working with what should be a supported version of Kubernetes, this is almost certainly a bug. We DO NOT guarantee any particular compatibility matrix between kubernetes library dependencies (client-go, apimachinery, etc); Such compatibility is infeasible due to the way those libraries are versioned.
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: configuration.md

title: Apache Mesos - Configuration layout: documentation The Mesos master and agent can take a variety of configuration options through command-line arguments or environment variables. A list of the available options can be seen by running `mesos-master --help` or `mesos-agent --help`. Each option can be set in two ways: By passing it to the binary using `--option_name=value`, either specifying the value directly, or specifying a file in which the value resides (`--option_name=file://path/to/file`). The path can be absolute or relative to the current working directory. By setting the environment variable `MESOSOPTIONNAME` (the option name with a `MESOS_` prefix added to it). Configuration values are searched for first in the environment, then on the command-line. Additionally, this documentation lists only a recent snapshot of the options in Mesos. A definitive source for which flags your version of Mesos supports can be found by running the binary with the flag `--help`, for example `mesos-master --help`. These are options common to both the Mesos master and agent. See . See . See . See . If you have special compilation requirements, please refer to `./configure --help` when configuring Mesos. See . See .
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.22.4.md

We are delighted to present version v1.22.4 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. Update to Envoy v1.23.4. See the for more information about the content of the release. Update to Go v1.19.5. See the for more information about the content of the release. For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.22.4 is tested against Kubernetes 1.22 through 1.24. 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: hami (Orchestration & Management / Scheduling & Orchestration)
File: MAINTAINERS.md

See the to learn how to level up through the project. Please see the file for the full list of contributors to the project | Maintainer | Email | Emplolyer | ||--|--| | | limengxuan@4paradigm.com | 4Paradigm | | | xiaozhang0210@hotmail.com | DaoCloud |
Project: k8gb (Orchestration & Management / Coordination & Service Discovery)
File: local-kuar.md

Kuar is a web based (SPA) application that contains a couple of handy features that can verify the k8gb functionality. It can resolve DNS names, simulate probe failures, can simulate a CPU-intensive workload by generating RSA key pairs, and also contains a simple API for the queue (push & pop strings). Make sure you have all the tools mentioned in installed. First, spin up two local k3s clusters: ```sh make deploy-full-local-setup ``` Again, you can verify that everything is up and running by following . ```sh make deploy-kuar-app ``` This task will deploy Kuar into both clusters and exposes it. It also patches the installed nginx controller to serve the app even if the `Host` header is not provided in the request. This way you can access the application in your browser under http://localhost:80 for cluster 1 and http://localhost:81 for cluster 2. Make sure the app on http://localhost is responding, it may take a minute for the nginx ingress controller to restart with the correct parameters. The make target also modified the deployment of the Kuar application to use our core DNS servers. To verify that this was done, one can open the Kuar's file system browser tab and `/etc/resolv.conv`. It should contain the same IP as cluster-IP assigned to `k8gb-coredns` service. Together with Kuar, we also prepared the failover gslb resource for k8gb. Where the first cluster (geotag = `eu`) is the primary one. Before we do that, we can visit Kuar on and verify that hostname `kuar.cloud.example.com` is correctly resolved IPs corresponding to nodes in the primary cluster - which is the cluster 1. This DNS resolution will work the same way on both clusters, but we will be simulating the failure on cluster 1 soon so the web API will not respond on cluster 1. Now we can open a new tab with Kuar on cluster one and simulate the readiness probe failure for the next 10 checks - http://localhost/-/readiness. Once we do that, the web API on cluster 1 will become unavailable. So we can switch to cluster 2 and run the web-based dig again. This time it should respond with IPs from cluster two. However, once the readiness probe will start succeeding again, it will switch back to cluster 1.
Project: EaseMesh (Orchestration & Management / Service Mesh)
File: Roadmap.md

- - - As we said in and , so we will focus on enhancing these features in 2021: Easy to integrate Java-compatible ecosystem High SLA Backlogs | Description | Priority | Related Issues | | | -- | -- | | Eliminate CRD MeshDeployment by k8s native deployment | High | | | Adapt to external service registry in spring ecosystem | High | | | Description | Priority | Related Issues | | | -- | -- | | Support Spring Cloud 3.X or higher version| High | | | Support Service discovery based on DNS mechanism | High | | | Support Eclipse Vert.x | Middle | | | Description | Priority | Related Issues | | - | -- | -- | | Tracing on and report metrics Elasticsearch | High | | | Maturer production-ready canary deployment | High | | | Tracing and report metrics for MongoDB | Middle | | | Tracing and report metrics for ActiveMQ | Low | | | Tracing and report metrics for Amazon S3 | Low | | |Description | Priority | Related Issues | |-|-|-| |SMI support, support |Low|| |External registry, or co-exists with registries in spring ecosystem|Low|| |Multi-Cluster MeshControl and observe multiple clusters|Low|| |Fault Injection|Low|| |Delay Injection|Low|| |Access control|Low||
Project: Emissary-Ingress (Orchestration & Management / API Gateway)
File: MAINTAINERS.md

describes governance guidelines and maintainer responsibilities. Maintainers are listed in alphabetical order. | Maintainer | GitHub ID | Affiliation | | - | | | | Alice Wasko | | | | David Dymko | | | | Flynn | | | | Hamzah Qudsi | | | | Rafael Schloming | | | In addition to the maintainers, Emissary releases may be created by any of the following (also listed in alphabetical order): | Releaser | GitHub ID | Affiliation | | | -- | | | Will Hardin | | | Ava Hahn () Alix Cook () John Esmet () Luke T. Shumaker () Alex Gervais () Lance Austin () Noah Krause ()
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: feature_request_ruby.md

name: Request a gRPC Ruby feature about: Suggest an idea for this project labels: kind/enhancement, priority/P2, lang/ruby assignees: apolcyn <!-- PLEASE DO NOT POST A QUESTION HERE. This form is for bug reports and feature requests ONLY! For general questions and troubleshooting, please ask/look for answers at StackOverflow, with "grpc" tag: https://stackoverflow.com/questions/tagged/grpc For questions that specifically need to be answered by gRPC team members, please ask/look for answers at grpc.io mailing list: https://groups.google.com/forum/#!forum/grpc-io Issues specific to grpc-java, grpc-go, grpc-node, grpc-dart, grpc-web should be created in the repository they belong to (e.g. https://github.com/grpc/grpc-LANGUAGE/issues/new) --> A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] A clear and concise description of what you want to happen. A clear and concise description of any alternative solutions or features you've considered. Add any other context about the feature request here.
Project: MetalLB (Orchestration & Management / Service Proxy)
File: index.en.md

+++ description = "List resources contained in a page bundle" title = "Resources" [[resources]] name = 'MaybeTreasure.txt' src = 'MaybeTreasure.en.txt' +++ The `resources` shortcode displays the of resources contained in a . {{% resources sort="asc" /%}} While the examples are using shortcodes with named parameter you are free to also call this shortcode from your own partials. {{< tabs groupid="shortcode-parameter">}} {{% tab title="shortcode" %}} ````go {{%/ resources sort="asc" //%}} ```` {{% /tab %}} {{% tab title="partial" %}} ````go {{ partial "shortcodes/resources.html" (dict "page" . "sort" "asc" )}} ```` {{% /tab %}} {{< /tabs >}} Multilanguage features are not supported directly by the shortcode but rely on Hugo's handling for resource translations applied when the theme iterates over all available resources. | Name | Default | Notes | |-|--|-| | style | `transparent` | The style scheme used for the box.<br><br>- by severity: `info`, `note`, `tip`, `warning`<br>- by brand color: `primary`, `secondary`, `accent`<br>- by color: `blue`, `green`, `grey`, `orange`, `red`<br>- by special color: `default`, `transparent`, `code` | | color | see notes | The to be used. If not set, the chosen color depends on the style. Any given value will overwrite the default.<br><br>- for severity styles: a nice matching color for the severity<br>- for all other styles: the corresponding color | | title | see notes | Arbitrary text for the box title. Depending on the style there may be a default title. Any given value will overwrite the default.<br><br>- for severity styles: the matching title for the severity<br>- for all other styles: `Resources`<br><br>If you want no title for a severity style, you have to set this parameter to `" "` (a non empty string filled with spaces) | | icon | see notes | set to the left of the title. Depending on the style there may be a default icon. Any given value will overwrite the default.<br><br>- for severity styles: a nice matching icon for the severity<br>- for all other styles: `paperclip`<br><br>If you want no icon, you have to set this parameter to `" "` (a non empty d with spaces) | | sort | `asc` | Sorting the output in `asc`ending or `desc`ending order. | | pattern | `.` | A , used to filter the resources . For example:<br><br>- to match a file suffix of 'jpg', use `.\.jpg` (not `.\.jpg`)<br>- to match file names ending in `jpg` or `png`, use `.\.(jpg\|png)` | ````go {{%/ resources title="Related files" pattern=".\.(png|jpg|gif)" /*/%}} ```` {{% resources title="Related files" pattern=".*\.(png|jpg|gif)" /%}} ````go {{%/ resources style="info" sort="desc" //%}} ```` {{% resources style="info" sort="desc" /%}} ````go {{%/ resources color="fuchsia" icon="fa-fw fab fa-hackerrank" //%}} ```` {{% resources color="fuchsia" icon="fa-fw fab fa-hackerrank" /%}} For further examples for style, color, title and icon, see the documentation. The parameter are working the same way for both shortcodes, besides having different defaults.
Project: Linkerd (Orchestration & Management / Service Mesh)
File: SECURITY.md

Security is critical to Linkerd and we take it very seriously. Not only must Linkerd be secure, it must improve the security of the system around it. To this end, every aspect of Linkerd's development is done with security in mind. Linkerd makes use of a variety of tools to ensure software security, including: Code review Dependency hygiene and supply chain security via And other forms of manual, static, and dynamic checking. If you believe you've found a security problem in Linkerd, whether in the control plane, proxy, or any other component, please file a [GitHub security advisory on the linkerd2 repo](https://github.com/linkerd/linkerd2/security/advisories). The maintainers will diagnose the severity of the issue and determine how to address the issue. In general, critical issues that affect Linkerd's security posture or that reduce its ability to provide security for users will receive immediate attention and be fixed as quickly as possible. Issues that do not affect Linkerd's security posture and that don't reduce its ability to provide security for users may not be immediately addressed. For example, CVEs in underlying dependencies that don't actually affect Linkerd may not be immediately addressed. Once merged into main, security updates will be available in the next edge release produced. The CNCF provides periodic third-party security audits. We publish unredacted reports in the subdirectory. When vulnerabilities in Linkerd itself are discovered and corrected, we will issue a security advisory, describing the problem and providing a pointer to the fix. These will be announced to our mailing list. There are some situations where we may delay issuing a security advisory. For example, when a vulnerability is found during a code audit or when several issues are likely to be spotted and fixed in the near future, the maintainers may delay the release of a Security Advisory so that we can issue a single comprehensive Security Advisory covering multiple vulnerabilities. Communication with vendors and other distributions shipping the same code may also cause these delays.
Project: Open Cluster Management (Orchestration & Management / Scheduling & Orchestration)
File: manifestwork.md

ManifestWork is defined as a workload that hub desires to be deployed on the managed cluster ManifestWork must be created in a cluster namespace on hub. The agent on managed cluster then deploys workload on the managed cluster. ManifestWork is declartive, so if the work on hub is updated, the corresponding workload on managed cluster should also be updated. If work is deleted, the corresponding workload on the managed cluster is deleted. The status of the work contains the conditions of deployed resources on managed cluster. After agent on managed cluster deploys or patches the resources, it needs to sync the conditions of deployed resource on managed cluster to the status.WorkloadConditions in corresponding ManifestWork on hub. Status transition of ManifestWork API. Agent on managed cluster gets `ManagedCluster` and update condition to `WorkloadProgressing` Agent apply each manifest in `spec.Manifests`, and update condition in `statu.WorkloadCondition`. if the resource exists. update the condition of the manifest to `Available`. if the resource is applied successfully, update the condition of the manifest to `Applied`. Agent on managed cluster checks `status.WorkloadCondition` and updates `status.Condition`. if all manifests is applied, update condition to `WorkloadApplied`. if all manifests exist, add a condition of `WorkloadAvailable`.
Project: Clusterpedia (Orchestration & Management / Scheduling & Orchestration)
File: LICENSE.md

MIT License Copyright (c) 2019 Josh Bleecher Snyder Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.