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

In Gloo Edge 0.18.0, we added support for TCP proxying, which required a breaking change to the gateway API. Please check out https://gloo.solo.io/operations/upgrading/0.18.1/ for details on how to seamlessly upgrade Gloo Edge, automatically convert existing configuration, and migrate traffic while avoiding downtime.
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_demo_federation.md

title: "glooctl demo federation" weight: 5 Bootstrap a multicluster demo with Gloo Federation. Running the Gloo Federation demo setup locally requires 4 tools to be installed and accessible via the PATH: glooctl, kubectl, docker, and kind. This command will bootstrap 2 kind clusters, one of which will run the Gloo Federation management-plane as well as Gloo Enterprise, and the other will just run Gloo. Please note that cluster registration will only work on darwin and linux OS. ``` glooctl demo federation [flags] ``` ``` -h, --help help for federation --license-key string License key to activate Gloo Fed features --version string Version of Gloo Enterprise to install (defaults to latest) ``` ``` -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) ``` - Demos (requires 4 tools to be installed and accessible via the PATH: glooctl, kubectl, docker, and kind.)
Project: Knative (Orchestration & Management / Scheduling & Orchestration)
File: ask-question.md

name: Question about: Ask a question about knative/serving title: '' labels: kind/question assignees: '' <!-- If you need to report a security issue with Knative, send an email to knative-security@googlegroups.com. --> <!-- Remove the '> ' to select: /area API /area autoscale /area build /area monitoring /area networking /area test-and-release Other classifications: /kind good-first-issue /kind process /kind spec -->
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_create_upstream.md

title: "glooctl create upstream" weight: 5 Create an Upstream Upstreams represent destination for routing HTTP requests. Upstreams can be compared to in Envoy terminology. Each upstream in Gloo has a type. Supported types include `static`, `kubernetes`, `aws`, `consul`, and more. Each upstream type is handled by a corresponding Gloo plugin. ``` glooctl create upstream [flags] ``` ``` -h, --help help for upstream ``` ``` -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 a Gloo resource - Create an Aws Upstream - Create an Azure Upstream - Create a Consul Upstream - Create an EC2 Upstream - Create a Kubernetes Upstream - Create a Static Upstream
Project: go-zero (Orchestration & Management / Remote Procedure Call)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: '' assignees: '' Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior, if applicable: The code is ```go ``` The error is ``` ``` Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Environments (please complete the following information): OS: [e.g. Linux] go-zero version [e.g. 1.2.1] goctl version [e.g. 1.2.1, optional] More description Add any other context about the problem here.
Project: Contour (Orchestration & Management / Service Proxy)
File: pull_request_template.md

name: Pull request about: Tell us about your contribution labels: ["release-note/small"] Please delete this text between the `` strings (and the strings themselves) before submitting your PR. Before submitting a pull request, make sure you read about our Contribution Workflow here: https://github.com/projectcontour/contour/blob/main/CONTRIBUTING.md#contribution-workflow Some notable call outs from our Contribution Workflow: All PR's must have a `Fixes #NNN` or `Updates #NNN` line in the pull request description. All PR's must add a `release-note/category` label, where category is one of `major`, `minor`, `small`, `docs`, `infra`,`deprecation`, or `none-required`. Contour operates according to the talk, then code rule. If you plan to submit a pull request for anything more than a typo or small bug fix, first you should raise an issue to discuss your proposal, before submitting any code. We generally won't merge a PR without an associated issue. Large changes must have an associated design document, raising an issue with your proposed change will give us a chance to determine if the change needs a design doc. All commits to Contour must have a Developer Certificate of Origin (DCO) sign off. More about that here https://github.com/projectcontour/contour/blob/main/CONTRIBUTING.md#dco-sign-off
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: deploying-apis.md

The Kusk Dashboard contains a wizard for helping you deploy your vanilla OpenAPI definitions to Kusk Gateway. It will prompt and add any required `x-kusk` extensions for you, so you can try different configurations without having to add the corresponding properties manually. Open the wizard with the "Publish new API" button on the top right. Paste your OpenAPI 3.x definition in the initial text field and proceed through the steps of the wizard as needed. As soon as your API has enough configuration to be publishable, the "Publish" button in the bottom right will be enabled, allowing you to bypass any steps that aren't further required. For example, if you select "Enable mocking" on the first page, you can immediately publish your API, as it requires no other configuration when being mocked.
Project: Kuma (Orchestration & Management / Service Mesh)
File: 041-resource-api-warnings.md

Status: accepted Resource API implements CRUDL operations for Kuma resources (policies, configs, etc.). If resource is correct it returns `200 OK` or `201 Created`. If there is a validation error it returns `400 Bad Request`. Today we're missing a way to return the information on deprecated fields or values. Kubernetes implements similar functionality using the ValidatingWebhook. The has a `warnings` field: warnings is a list of warning messages to return to the requesting API client. Warning messages describe a problem the client making the API request should correct or be aware of. Limit warnings to 120 characters if possible. Warnings over 256 characters and large numbers of warnings may be truncated. and `kubectl apply` outputs them to stderr: ```bash $ kubectl apply -f policy.yaml Warning: the field "X" is deprecated, please consider using "Y" meshtimeout.kuma.io/timeout-global created ``` Introduce a `warnings` field to the successful 200 and 201 responses. Introduce a `warnings` field to the successful 200 and 201 responses. The `response` list for Resource API should be updated: ```yaml responses: '200': description: Updated content: application/json: schema: type: object properties: warnings: type: array items: type: string '201': description: Created content: application/json: schema: type: object properties: warnings: type: array items: type: string ```
Project: Envoy (Orchestration & Management / Service Proxy)
File: PULL_REQUEST_TEMPLATE.md

<!-- !!!ATTENTION!!! If you are fixing any crash or any potential security issue, do not open a pull request in this repo. Please report the issue via emailing envoy-security@googlegroups.com where the issue will be triaged appropriately. Thank you in advance for helping to keep Envoy secure. !!!ATTENTION!!! For an explanation of how to fill out the fields, please see the relevant section in --> Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] :]
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.23.4.md

We are delighted to present version v1.23.4 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. A big thank you to everyone who contributed to the release. Update to Envoy v1.24.3. See the for more information about the content of the release. Update to Go v1.19.7. See the for more information. Update to golang.org/x/net@v0.8.0. Update to golang.org/x/image@v0.6.0. For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.23.4 is tested against Kubernetes 1.23 through 1.25. 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: Gloo (Orchestration & Management / API Gateway)
File: glooctl_edit_route.md

title: "glooctl edit route" weight: 5 ``` -h, --help help for route -x, --index uint32 edit the route with this index in the virtual service route list -o, --output OutputType output format: (yaml, json, table, kube-yaml, wide) (default table) ``` ``` -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 --name string name of the resource to read or write -n, --namespace string namespace for reading or writing resources (default "gloo-system") --resource-version string the resource version of the resource we are editing. if not empty, resource will only be changed if the resource version matches --use-consul use Consul Key-Value storage as the backend for reading and writing config (VirtualServices, Upstreams, and Proxies) ``` - Edit a Gloo resource - Configure disable external auth on a route (Enterprise) - Configure rate-limits (Enterprise)
Project: Kubernetes (Orchestration & Management / Scheduling & Orchestration)
File: cf_header.md

This document provides a summary of the tests included in the Kubernetes conformance test suite. Each test lists a set of formal requirements that a platform that meets conformance requirements must adhere to. The tests are a subset of the "e2e" tests that make up the Kubernetes testing infrastructure. Each test is identified by the presence of the `[Conformance]` keyword in the ginkgo descriptive function calls. The contents of this document are extracted from comments preceding those `[Conformance]` keywords and those comments are expected to include a descriptive overview of what the test is validating using RFC2119 keywords. This will provide a clear distinction between which bits of code in the tests are there for the purposes of validating the platform rather than simply infrastructure logic used to setup, or clean up the tests. Example: ``` /* Release: v1.13 Testname: Kubelet, log output, default Description: By default the stdout and stderr from the process being executed in a pod MUST be sent to the pod's logs. */ framework.ConformanceIt("should print the output to logs [NodeConformance]", func(ctx context.Context) { ``` would generate the following documentation for the test. Note that the "TestName" from the Documentation above will be used to document the test which make it more human readable. The "Description" field will be used as the documentation for that test. Added to conformance in release v1.13 Defined in code as: [k8s.io] Kubelet when scheduling a busybox command in a pod should print the output to logs [NodeConformance] [Conformance] By default the stdout and stderr from the process being executed in a pod MUST be sent to the pod's logs. Notational Conventions when documenting the tests with the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in . Note: Please see the Summary at the end of this document to find the number of tests documented for conformance.
Project: Xline (Orchestration & Management / Coordination & Service Discovery)
File: CODE_OF_CONDUCT.md

This project follows the . Other languages available: As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality. Examples of unacceptable behavior by participants include: The use of sexualized language or imagery Personal attacks Trolling or insulting/derogatory comments Public or private harassment Publishing other's private information, such as physical or electronic addresses, without explicit permission Other unethical or unprofessional conduct. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team. This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Instances of abusive, harassing, or otherwise unacceptable behavior in Kubernetes may be reported by contacting the via <conduct@kubernetes.io>. For other projects, please contact a CNCF project maintainer or our mediator, Mishi Choudhary <mishi@linux.com>. This Code of Conduct is adapted from the Contributor Covenant (http://contributor-covenant.org), version 1.2.0, available at http://contributor-covenant.org/version/1/2/0/ CNCF events are governed by the Linux Foundation available on the event page. This is designed to be compatible with the above policy and also includes more details on responding to incidents.
Project: Emissary-Ingress (Orchestration & Management / API Gateway)
File: MEETING_SCHEDULE.md

The Emissary-ingress Contributors Meeting is held on the first Wednesday of every month at 3:30pm Eastern. The focus of this meeting is discussion of technical issues related to development of Emissary-ingress. New contributors are always welcome! Check out our to learn how you can help make Emissary-ingress better. Zoom Meeting Link: Meeting ID: 861 3926 2248 Passcode: 113675
Project: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: bug assignees: kevinbader A clear and concise description of what the bug is. When I run RIG with these settings: Describe whether you use Docker or not, the environment variables you set and the config files you use. ..and set up clients and services like this: Describe how your clients are set up, whether they connect via SSE or WS, etc. ..I see the following error and/or log output: Add the log output to help us determine your problem. If possible, reproduce the problem after setting the environment variable `LOG_LEVEL` to `debug`. ..but I really expected this: A clear and concise description of what you expected to happen. Host OS: [e.g. Ubuntu Bionic amd64] Frontend [e.g. chrome, safari] RIG version as shown on startup [e.g. Reactive Interaction Gateway 2.0.2 [rig@127.0.0.1, ERTS 10.2.2, OTP 21]]
Project: KubeGateway (Orchestration & Management / API Gateway)
File: failing-test.md

name: Failing Test about: Report continuously failing tests or jobs in Kubernetes CI labels: kind/failing-test <!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --> Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know:
Project: Open Cluster Management (Orchestration & Management / Scheduling & Orchestration)
File: design.md

This repo describes the API implemented by controllers in the `open-cluster-management.io` project. The API enables a cluster to become a "Hub" that manages a set of other clusters. When a cluster becomes "managed", an agent is deployed that registers the managed cluster with the hub. Once registration is approved, the managed cluster can receive directives to apply specific Kubernetes manifests to run additional workloads. API Group: `operator.open-cluster-management.io/v1` Kinds: `ClusterManager`. Provides lifecycle management for the registration controller on the Hub. `Klusterlet`. Provides lifecycle management for the registration and `ManifestWork` controllers on the managed cluster. API Group: `cluster.open-cluster-management.io/v1` Kinds: `ManagedCluster`. Provides a representation of the managed cluster on the hub. `ManagedCluster` controls the lifecycle of whether the remote cluster has been "accepted" by the Hub for management and can retrieve information from the Hub to direct a set of manifests or actions to apply. API Group: `work.open-cluster-management.io/v1` Kinds: `ManifestWork`. Provides a representation of manifests that should be applied to a managed cluster.
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: CONTRIBUTING.md

Kusk Gateway code is managed with the help of that provides code scaffolding and generation of K8s Custom Resource Definitions files. Internally, Kusk Gateway uses the package to configure Envoy with its xDS protocol. Below is the (reduced) output of the `tree` command on this repository. These are the directories and packages that we suggest you need to know about to get started with Kusk Gateway development. Obviously, there are more, so feel free to investigate the others for yourself to get an idea about how they fit into the overall architecture. ``` kusk-gateway api v1alpha1 # Our Custom CRD types in Go build # Dockerfiles for the Manager and Agent processes agent manager cmd # Entry point for the Manager and Agent processes agent manager examples # Various example applications to test against httpbin todomvc spec websocket internal agent # Business Logic for the agent process which handles mocking API resposes httpserver management mocking controllers # Custom Kubernetes controllers that handle CRD events envoy # Envoy configuration, go-control-plane manager set up, and the types we manage when building the config config manager types k8sutils # useful helper functions for interacting with Kubernetes validation # Service proxy that handles request validation before forwarding the request onto the destination service webhooks # Create certs for the webhooks pkg analytics # Code for sending analytics data to telemetry provider options # Options structs that contain the fields that the user will configure with the x-kusk extension in their OpenAPI definition spec # Code for loading, parsing and validating the OpenAPI definition and the extensions. ``` You can install Kusk Gateway into any cluster offering. So you can BYOC (Bring Your Own Cluster). We have a useful Make command to set up a complete environment for development in Minikube. To set up the environment, run the following command: ``` make create-env ``` This will do the following: Start minikube with the profile name "kusk" and enable the Metallb add on. Metallb will expose the Envoy Fleet services "locally" without needing to port-forward to them. Install our CustomResourceDefinitions. Build the docker images, cache them for faster rebuilds and deploy them with Kustomize. Deploy an Envoy Fleet. If you opt to use a cluster offering that is not Minikube, you can use the following commands to launch Kusk Gateway in your cluster: ``` make install make docker-images-cache docker-build deploy kubectl rollout status -w deployment/kusk-gateway-manager -n kusk-system make deploy-envoyfleet ``` The simplest way to ensure the recompliation of everything required is to run one of the following commands: ``` make generate manifests install docker-build deploy cycle ```