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

name: Decision about: A binding record of a decision title: '' labels: kind/decision, lifecycle/needs-triage assignees: '' <!-- Thanks for asking for a decision! Here are some tips for you: Decisions should be large ones, that cut across many parts of a repo or the project as a whole. "Should we change Contour's support policy" is an example of a decision that's relevant here, "Should we implement this feature" is an example of a decision that's not. If in doubt, ask in #contour on the Kubernetes Slack. Contour's maintainers have the binding votes, but non-binding votes are welcomed. --> What do you want the project to decide? <!-- A clear and concise description of what the decision is. --> Anything else you would like to add: <!-- Background or other information that will assist people in understanding why we need to decide this. -->
Project: Contour (Orchestration & Management / Service Proxy)
File: start-contributing.md

Thanks for taking the time to join our community and start contributing! Please familiarize yourself with the before contributing. See for information about setting up your environment, the workflow that we expect, and instructions on the developer certificate of origin that we require. Check out the . Join our Kubernetes Slack channel: Join the , every third Tuesday at 6PM ET / 3PM PT / Wednesday at 8AM Australian Eastern Time. Meeting notes can be found . Meetings are recorded and can be found .
Project: BFE (Orchestration & Management / Service Proxy)
File: http_state.md

The endpoint `/monitor/http_state` exposes metrics about HTTP protocol. | Metric | Description | | - | | | HTTPBACKENDCONN_ALL | Counter for connecting with backend | | HTTPBACKENDCONN_SUCC | Counter for connecting successfully with backend | | HTTPBACKENDREQ_ALL | Counter for sending request to backend | | HTTPBACKENDREQ_SUCC | Counter for sending successfully request to backend | | HTTPPANICBACKEND_READ | Counter for reading backend panic | | HTTPPANICBACKEND_WRITE | Counter for writing backend panic | | HTTPPANICCLIENTFLUSHLOOP | Counter for client flushing loop panic | | HTTPPANICCLIENTWATCHLOOP | Counter for client watching loop panic |
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: development.md

This document helps you get started using the Volcano code base. If you follow this guide and find some problem, please take a few minutes to update this file. You will need to clone the main `volcano` repo to `$GOPATH/src/volcano.sh/volcano` for the below commands to work correctly. To build volcano all components for your host architecture, go to the source root and run: ```bash make image_bins ``` the binaries will be generated at .../src/volcano.sh/volcano/_output/bin/linux/amd64/ but if we just make as below ```bash make ``` then the binaries would be generated at .../src/volcano.sh/volcano/_output/bin/ To build a specific component for your host architecture, go to the source root and run `make <component name>`: ```bash make vc-scheduler ``` Build the containers in your local docker cache: ```bash make images ``` To build cross-platform images: ```bash make images DOCKERPLATFORMS="linux/amd64,linux/arm64" BUILDXOUTPUTTYPE=registry IMAGEPREFIX=[yourregistry] ``` If you want to make a local change and test some component, say `vc-controller-manager`, you could do: Under volcano.sh/volcano repo ```bash pwd ``` The path should be ```bash .../src/volcano.sh/volcano ``` Set up environment variables HUB and TAG by ```bash export HUB=docker.io/yourrepo export TAG=citadel ``` Make some local change of the code, then build `vc-controller-manager` ```bash make image.vc-controller-manager ``` Use the following command to build the deploy yaml files: ```bash make generate-yaml ``` You can delete any build artifacts with: ```bash make clean ``` You can run all the available unit tests with: ```bash make unit-test ``` You can run all the available e2e tests with: ```bash make vcctl make images make e2e ``` If you want to run e2e test in a existing cluster with volcano deployed, run the following: ```bash export VCBIN= need to set vcctl binary path (eg:.../src/volcano.sh/volcano/output/bin/) KUBECONFIG=${KUBECONFIG} go test ./test/e2e ``` You can automatically format the source code to follow our conventions by going to the top of the repo and entering: ```bash ./hack/update-gofmt.sh ``` You can run all the verification we require on your local repo by going to the top of the repo and entering: ```bash make verify ``` Volcano uses to manage its dependencies. If you want to add or update a dependency, running: ```bash go get dependency-name@version go mod tidy go mod vendor ``` Note: Go's module system, introduced in Go 1.11, provides an official dependency management solution built into the go command. Make sure `GO111MODULE` env is not `off` before using it. Before sending pull requests you should at least make sure your changes have passed both unit and the verification. We only merge pull requests when all tests are passing. Unit tests should be fully hermetic Only access resources in the test binary. All packages and any significant files require unit tests. Unit tests are written using the standard Go testing package. The preferred method of testing multiple scenarios or input is Concurrent unit test runs must pass.
Project: CloudWeGo (Orchestration & Management / Remote Procedure Call)
File: CONTRIBUTING.md

We use github for our codebase. You can start by reading . We use as our branch organization, as known as We are using for our public bugs. We keep a close eye on this and try to make it clear when we have an internal fix in progress. Before filing a new task, try to make sure your problem doesn't already exist. Providing a reduced test code is a recommended way for reporting issues. Then can placed in: Just in issues Please do not report the safe disclosure of bugs to public issues. Contact us by Before you submit your Pull Request (PR) consider the following guidelines: Search for an open or closed PR that relates to your submission. You don't want to duplicate existing efforts. Please submit an issue instead of PR if you have a better suggestion for format tools. We won't accept a lot of file changes directly without issue statement and assignment. Be sure that the issue describes the problem you're fixing, or documents the design for the feature you'd like to add. Before we accepting your work, we need to conduct some checks and evaluations. So, It will be better if you can discuss the design with us. the cloudwego/kitex repo. In your forked repository, make your changes in a new git branch: ``` git checkout -b my-fix-branch develop ``` Create your patch, including appropriate test cases. Please refer to for writing guides. is recommended to mock interface, please refer to internal/mocks/readme.md for more details, and is recommended to mock functions, please refer to its readme doc for specific usage. Follow our . Commit your changes using a descriptive commit message that follows . Adherence to these conventions is necessary because release notes are automatically generated from these messages. Push your branch to GitHub: ``` git push origin my-fix-branch ``` In GitHub, send a pull request to `kitex:develop` with a clear and unambiguous title. Our development environment keeps up with . You need fully checking with lint tools before submit your pull request. and You are familiar with Maybe you need familiar with (our default workflow tool). See . Good resources:
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: feature-lifecycle.md

This document is to clarify definitions and differences between features and corresponding APIs during different development stages (versions). Each version has different level of stability, support time, and requires different graduation criteria moving to next level: The feature may be changed/upgraded in incompatible ways in the later versions. The source code will be available in the release branch/tag as well as in the binaries. Support for the feature can be stopped any time without notice. The feature may have bugs. The feature may also induce bugs in other APIs/Features if enabled. The feature may not be completely implemented. The API version names will be like v1alpha1, v1alpha2, etc. The suffixed number will be incremented by 1 in each upgrade. Each feature will start at alpha level. Should not break the functioning of other APIs/Features. The feature may not be changed/upgraded in incompatible ways in later versions, but if changed in incompatible ways then upgrade strategy will be provided. The source code will be available in the release branch/tag as well as in the binaries. Support for the feature will not be stopped without 2 minor releases notice and will be present in at least next 2 minor releases. The feature will have very less bugs. The feature will not induce bugs in other APIs/Features if enabled. The feature will be completely implemented. The API version names will be like v1beta1, v1beta2, etc. The suffixed number will be incremented by 1 in each upgrade. Should have at least 50% coverage in e2e tests. Project agrees to support this feature for at least next 2 minor releases and notice of at least 2 minor releases will be given before stopping the support. Feature Owner should commit to ensure backward/forward compatibility in the later versions. The feature will not be changed/upgraded in incompatible ways in the next couple of versions. The source code will be available in the release branch/tag as well as in the binaries. Support for the feature will not be stopped without 4 minor releases notice and will be present in at least next 4 minor releases. The feature will not have major bugs as it will be tested completely as well as have e2e tests. The feature will not induce bugs in other APIs/Features if enabled. The feature will be completely implemented. The API version names will be like v1, v2, etc. Should have complete e2e tests. Code is thoroughly tested and is reported to be very stable. Project will support this feature for at least next 4 minor releases and notice of at least 4 minor releases will be given before stopping support. Feature Owner should commit to ensure backward/forward compatibility in the later versions. Consensus from Volcano Maintainers as well as Feature/API Owners who use/interact with the Feature/API.
Project: Azure Service Fabric (Orchestration & Management / Scheduling & Orchestration)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '[Feature]: Describe feature asks or new scenario or experience you want to enable' labels: 'type-enhancement' projects: 'ServiceFabricNewFeatureRequest' assignees: '' Is your feature request related to a problem? Please describe your workload details. A clear and concise description of what the problem is. 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. Area/Component: Please mention area or component in Service Fabric where issue was found. Ex: security, monitoring, placement or resource governance Reliable services, Actors, programming models,SDK,.etc. Expected behavior A clear and concise description of what you expected to happen, expected timeline, benefits to your workload. for example, does it improve the developer experience, availability,reliability or performance of your workload. Additional context Add any other context or screenshots about the feature request here. Service Fabric Runtime Version: ex: 7.1., 7.2. Environment: Must be one of these values [Standalone OR Azure OR OneBox/Dev cluster] OS: [e.g. Windows 2019, Ubuntu 18.04] Version [e.g. 7.1, 7.2 ] Assignees: /cc @microsoft/service-fabric-triage
Project: go-zero (Orchestration & Management / Remote Procedure Call)
File: SECURITY.md

We publish releases monthly. | Version | Supported | | - | | | >= 1.4.4 | :whitecheckmark: | | < 1.4.4 | :x: | https://github.com/zeromicro/go-zero/security/advisories Accepted vulnerabilities are expected to be fixed within a month.
Project: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: extender.md

At present, volcano has not provided a mechanism for non-invasive function realization. If the user needs to implement an internal scheduling function, the source code of volcano must be modified. Such as kube-scheduler, this proposal is to dynamically extend Volcano's scheduling capabilities via an http request. Currently, the only way to implement a scheduling strategy based on Volcano is to modify Volcano's code and recompile. This method requires developers to deeply understand the working principle of Volcano and the related architecture, which is not friendly to beginners. By adding other processes and based on network communication, it will bring some performance degradation, but it will also improve scalability. Users can make their own trade-offs between the two. Similar to kube-scheduler, the user-defined scheduling algorithm is registered to volcano through http server. Does not solve the performance degradation caused by the network. Implement a plugin named extender, the plugin will register related functions in the SessionOpen function, and pass the snapshot to the endpoint through the http method. The extender plugin will choose which methods to register according to the configuration file, and is responsible for serializing and deserializing the parameters. When there is an error in the http call, the plugin decides how to deal with it according to the configuration file. ``` plugins: name: extender arguments: extender.urlPrefix: http://127.0.0.1 extender.httpTimeout: 100ms extender.onSessionOpenVerb: onSessionOpen extender.onSessionCloseVerb: onSessionClose extender.predicateVerb: predicate extender.prioritizeVerb: prioritize extender.preemptableVerb: preemptable extender.reclaimableVerb: reclaimable extender.queueOverusedVerb: queueOverused extender.jobEnqueueableVerb: jobEnqueueable extender.ignorable: true ``` extender.urlPrefix : Address of extender endpoint extender.httpTimeout : The timeout duration for a call to the extender. extender.*Verb : Verbs of extender function, ignore if verb is empty. Those verbs are appended to the urlPrefix when issuing the http call. extender.ignorable : Ignorable indicates scheduling should fail or not when this extender is unavailable. ``` func (ep ExtenderPlugin) OnSessionOpen(ssn framework.Session) { if len(ep.urlPrefix) == 0 { return } if len(ep.openSessionOpenVerb) != 0 { ep.onSessionOpen(ssn) } if len(ep.predicateVerb) != 0 { ssn.AddPredicateFn(ep.Name(), ep.predicateFn) } // ... } ``` Extender implementation should define how to handle this function call : If there are no verb exist in configuration, return nil. If there are verb definition in configuration, send http request to endpoint and handle the network error. Plugin-based methods currently only support one Extender as an extension at the same time. Support batchPredicateFn method: Add a new plugin method to calculate all nodes in one function, and implement extender method for that. Support extender Bind method : Delegate bind action to extender
Project: Consul (Orchestration & Management / Service Mesh)
File: docker-windows.md

In this file you will find which Dockerfiles are needed to run the Envoy integration tests on Windows, as well as information on how to run each of these files individually for testing purposes. After building and running the images and containers, you need to have pre-built the base images used by these Dockerfiles. See This file sole purpose is to build the test-sds-server executable using Go. To do so, we use an official provided in docker hub with Windows nano server. To build this image you need to run the following command on your terminal: ```shell docker build -t test-sds-server -f Dockerfile-test-sds-server-windows test-sds-server ``` This is the same command used in run-tests.sh You can test the built file by running the following command: ```shell docker run --rm -p 1234:1234 --name test-sds-server test-sds-server ``` If everything works properly you should get the following output: ```shell 20XX-XX-XXTXX:XX:XX.XXX-XXX [INFO] Loaded cert from file: name=ca-root 20XX-XX-XXTXX:XX:XX.XXX-XXX [INFO] Loaded cert from file: name=foo.example.com 20XX-XX-XXTXX:XX:XX.XXX-XXX [INFO] Loaded cert from file: name=wildcard.ingress.consul 20XX-XX-XXTXX:XX:XX.XXX-XXX [INFO] Loaded cert from file: name=www.example.com 20XX-XX-XXTXX:XX:XX.XXX-XXX [INFO] ==> SDS listening: addr=0.0.0.0:1234 ```
Project: Contour (Orchestration & Management / Service Proxy)
File: release-notes-template.md

We are delighted to present version {{ .Version }} of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. A big thank you to everyone who contributed to the release. {{ if .Prerelease }} Please note that this is pre-release software, and as such we do not recommend installing it in production environments. Feedback and bug reports are welcome! {{ end }} {{ range .Major }} {{ .Content }} (#{{ .PRNumber }}, {{ .Author }}) {{ end }} {{ range .Minor }} {{ .Content }} (#{{ .PRNumber }}, {{ .Author }}) {{ end }} {{ range .Small }}- {{ .Content }} (#{{ .PRNumber }}, {{ .Author }}) {{ end }} {{ range .Docs }}- {{ .Content }} (#{{ .PRNumber }}, {{ .Author }}) {{ end }} {{ range .Deprecation }} {{ .Content }} (#{{ .PRNumber }}, {{ .Author }}) {{ end }} {{ if .Prerelease}} The simplest way to install {{ .Version }} is to apply one of the example configurations: Standalone Contour: ```bash kubectl apply -f https://raw.githubusercontent.com/projectcontour/contour/{{ .Version }}/examples/render/contour.yaml ``` Contour Gateway Provisioner: ```bash kubectl apply -f https://raw.githubusercontent.com/projectcontour/contour/{{ .Version }}/examples/render/contour-gateway-provisioner.yaml ``` Statically provisioned Contour with Gateway API: ```bash kubectl apply -f https://raw.githubusercontent.com/projectcontour/contour/{{ .Version }}/examples/render/contour-gateway.yaml ``` {{ else }} For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . {{ end }} Contour {{ .Version }} is tested against Kubernetes {{ .KubernetesMinVersion }} through {{ .KubernetesMaxVersion }}. 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: {{ range .Contributors }}- {{ . }} {{ end}} 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: Linkerd (Orchestration & Management / Service Mesh)
File: STEERING.md

The goal of the Linkerd Steering Committee is to ensure that Linkerd meets the needs of its current and future users. The Steering Committee represents the voice of the user, and works with the Linkerd maintainers and directors to help guide development efforts towards solving concrete and immediate problems for Linkerd adopters. The Steering Committees responsibilities are to: Provide feedback to project maintainers about Linkerd's featureset, UX, and operational model. Assist Linkerd maintainers in prioritizing upcoming roadmap items and planned work. Represent the "voice of the Linkerd user" both internally and to the broader community. Provide neutral mediation for non-technical disputes. Develop and maintain a project continuity plan. The Steering Committee comprises at most 7 people. To be eligible for membership in the Steering Committee, you must: Be currently responsible for a production Linkerd deployment of non-trivial size, or have been responsible for such a deployment within the past two years. Be willing and able to attend regularly-scheduled Steering Committee meetings. Abide by Linkerd's Code of Conduct. Candidates for membership will be nominated by current Steering Committee members or by Linkerd maintainers and directors. Once nominated, inclusion in the Steering Committee will be determined by the normal project decision-making process. Membership expires if any of the eligibility conditions is unmet, or after one year. Members may seek reinstatement immediately in accordance with the rules above. Meetings will happen periodically not less than once a quarter. Recordings and minutes will be posted publicly. Changes to this charter must be approved by a majority of Steering Committee members and a majority of Linkerd maintainers and directors.
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_debug_logs.md

title: "glooctl debug logs" weight: 5 Debug Gloo logs (requires Gloo running on Kubernetes) ``` glooctl debug logs [flags] ``` ``` --errors-only filter for error logs only -f, --file string file to be read or written to -h, --help help for logs -n, --namespace string namespace for reading or writing resources (default "gloo-system") --zip save logs to a tar file (specify location with -f) ``` ``` -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) ``` - Debug a Gloo resource (requires Gloo running on Kubernetes)