cwielenb/CNCF-Dataset huggingface dataset:
Project: Kuma (Orchestration & Management / Service Mesh)
File: virtualhost-policy.md

Since Kuma 1.1.4 the dataplane now embeds a CoreDNS instance which forwards all DNS traffic to envoy proxy. This opens the door to more flexible implementation of vips. We propose here to create a new policy which will enable users to create arbitrary hostnames and ports that will route to a specific sets of tags. We will add a new policy type: ```yaml type: VirtualOutbound mesh: string # The mesh this policy applies to name: string #The name of the policy selectors: match: conf: host: string # A go template that uses tags to compile the template port: int # A port to expose the virtual host on tags: ``` Simple service with no wildcard replacement: ```yaml type: VirtualOutbound mesh: default name: my-service selectors: match: kuma.io/service: my-service conf: host: httpbin.mesh port: 8080 ``` Create different hostnames for each version of a service: ```yaml type: VirtualOutbound mesh: default name: my-service-by-version selectors: match: kuma.io/service: "*" version: "*" conf: host: "{{version}}.{{service}}.mesh" port: 8080 tags: "kuma.io/service": service "version": version ``` A policy to enable things to be backward compatible: ```yaml type: VirtualOutbound mesh: default name: default selectors: match: kuma.io/service: "*" conf: host: "{{service}}.mesh" port: 80 tags: "kuma.io/service": service ``` A virtual host to get per zone domains ```yaml type: VirtualOutbound mesh: default name: service-by-zone selectors: match: kuma.io/service: "*" conf: host: "{{service}}.{{zone}}.mesh" port: 80 tags: "kuma.io/service": service "kuma.io/zone": zone ``` The vip management and DNS propagation is already present we will simply add AAAA record to add IPv6 support to the DNS. We'll add a `hostname` field in the `DataplaneNetworkingOutbound`. This field will be visible to users in their dataplane insights. Hostnames that overlaps won't be treated any differently. The user has the endpoint view to troubleshoot. In the future we might want to add a weight to prioritize a `VirtualOutbound` over another. VIPs will be allocated per DP and won't need to be persisted anywhere outside of the DP. This implies that a service may have a different ip on different DPs. Add hostname to outbound and populate it in `VipOutbounds()`. Update `dns_generator` to read the hostname from the `hostname` field in the outbound instead of generating one. Add `VirtualOutbound` policy and on reconcile populate the outbounds of the matching dataplanes accordingly. Make sure that the new VirtualOutbound use ips not already used by the current vip allocator (execute them sequentially). Once it is proven reliable enough we will be able to add a default `virtualOutbound` and remove the auto generated vips. This provides us with two new features: Possibility to have vips with specific ports. Possibility to have multiple hostnames for a service or a subset of a service. This might be useful for more complex setups or simply for debugging by adding temporary policies.
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2014-07-24-mesoscon-2014-hackathon-details-announced.md

layout: post title: "#MesosCon Hackathon Details Announced" permalink: /blog/mesoscon-2014-hackathon-details-announced/ published: true post_author: display_name: Dave Lester twitter: davelester tags: Announcement, MesosCon, Hackathon After a at , we're challenging participants to hack on during an -sponsored hackathon taking place Friday, August 22nd. This event is an opportunity to contribute to the project, collaborate with other members of the community, and learn in the process. We've identified two categories of hacks that we hope participants will focus on: Community Need: These are issues logged in the that have received a large amount of activity (comments, votes, etc), and address some of the larger problems or pain points for the community. Suggested projects include new features, bugs, or documentation. People's Choice: These contributions will be voted on by your peers, and our guidance is intentionally open-ended so teams will run wild with their ideas. We're excited to see what you come up with. We strongly encourage hackathon participants to use the public to log and discuss their ideas prior to the hackathon, using the . The are good places to discover and share project ideas in advance. Thursday evening of MesosCon, teams will form and ideas may be pitched. Additionally, project committers will be on-site to act as mentors and shepherds throughout the hackathon. Actual development on submissions should begin the evening of August 21st and must not begin earlier. However, teams are encouraged to have community discussions prior to the event. In order for an entry to be valid, a pull request or review board patch must be submitted. Submitted applications must run. Teams may have a maximum of four contributors. A team may only win one category. Submissions must be related to Mesos in some way. Following sessions on day one of MesosCon, we will hold a hackathon kickoff that includes an explanation of the rules, and a chance for ideas to be pitched and teams formed. Hacking may begin at this time, although evening hacking is optional. 9:00 - Hacking begins at conference center 13:00 - Lunch arrives 17:00 - Coding stops, refreshments are served 17:15 - Re-explain the voting rules 17:20 - Presentations start - Each team gets 5 minutes to pitch what they built and show it off 18:00 - Voting occurs 18:15 - Winners announced Interested in participating in the hackathon? Participants must . For new MesosCon registrants, you will see a checkbox at the time of registration. If you've already registered for MesosCon, you will be contacted to confirm whether you plan to participate in the hackathon.
Project: Armada (Orchestration & Management / Scheduling & Orchestration)
File: oidc.md

Setting up OIDC can be an art. The provides a nice to test OAuth flow. 1) Create a Okta Developer Account I used my github account. 2) Create a new App in the Okta UI. Select OIDC - OpenID Connect. Select Web Application. 3) In grant type, make sure to select Client Credentials. This has the advantage of requiring little interaction. 4) Select 'Allow Everyone to Access' 5) Deselect Federation Broker Mode. 6) Click okay and generate a client secret. 7) Navigate in the Okta settings to the API settings for your default authenticator. 8) Select Audience to be your client id. Setting up OIDC for Armada requires two separate configs (one for Armada server and one for the clients) You can add this to your armada server config. ``` auth: anonymousAuth: false openIdAuth: providerUrl: "https://OKTADEVUSERNAME.okta.com/oauth2/default" groupsClaim: "groups" clientId: "CLIENTIDFROM_UI" scopes: [] ``` For client credentials, you can use the following config for the executor and other clients. ``` openIdClientCredentialsAuth: providerUrl: "https://OKTADEVUSERNAME.okta.com/oauth2/default" clientId: "CLIENTIDFROM_UI" clientSecret: "CLIENT_SECRET" scopes: [] ``` If you want to interact with Armada, you will have to use one of our client APIs. The armadactl is not setup to work with OIDC at this time.
Project: Tyk (Orchestration & Management / API Gateway)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: bug assignees: Branch/Environment/Version Branch/Version: [e.g. Master/Release/Stable/Feature branch] Environment: [e.g. On-prem/Hybrid/MDCB] Describe the bug A clear and concise description of what the bug is. Reproduction steps Steps to reproduce the behavior: Add api... Actual behavior A clear and concise description of what you expected to happen. Expected behavior A clear and concise description of what you expected to happen. Screenshots/Video If applicable, add screenshots or video to help explain your problem. Logs (debug mode or log file): Log from console or from log file. Configuration (tyk config file): Attach tyk configuration file Additional context Add any other context about the problem here.
Project: OpenNebula (Orchestration & Management / Scheduling & Orchestration)
File: COMMIT_MESSAGES.md

It is extremely important to be able to link changes in the code to specific issues (bugs, features or linting actions). Therefore, commit messages MUST conform to the following rule. First line of commit messages must have the following structure: ``` % {type} #%{issue_number}: %{description} ``` Where type must be one of the following: revert F (for new functionality) B (for bug fixing) L (for linting) M (for minor changes with no issue, use the "M #-:" syntax in this case) Issue number must refer to a GitHub issue of the OpenNebula/one repo Description needs to be a succinct explanation of the code. Overall length should be equal or less than 50 characters (this is not enforced) Remaining text should be wrapped at 72 characters.
Project: BFE (Orchestration & Management / Service Proxy)
File: overview.md

BFE is an open-source layer 7 load balancer derived from proprietary Baidu Front End. Written in Golang BFE is written in a memory safety language and immune to Buffer Overflow vulnerability; BFE recovers from the runtime panics and handles them appropriately without killing the BFE process; BFE runs on Linux, Windows, Mac OS and almost anything to which Go compiles. Flexible plugin framework BFE has a builtin plugin framework that makes it possible to develop new features rapidly by writing plugins. Multi-tenancy architecture BFE is designed to provide every tenant a dedicated share of the instance. Each tenants configuration is isolated and remains invisible to other tenants. Multiple protocols supported BFE supports HTTP, HTTPS, SPDY, HTTP2, WebSocket, TLS, gRPC, FastCGI, etc. Future support is planned for HTTP/3. Content based routing BFE provides an to describe routing rules which are easy to understand and maintain. Advanced load balancing BFE supports global load balancing and distributed load balancing for zone aware balancing, zone level failure resilience, overload protection etc. A rich set of builtin plugins BFE provides a rich set of plugins for traffic management, security, observability, etc. Best-in-class observability BFE includes detailed built-in metrics for all subsystems. BFE writes various logs(server log/access log/TLS key log) for trouble shooting, data analysis and visualization. BFE also supports distributed tracing. Easily integrated with ecosystem projects BFE is easily integrated with mainstream layer 4 load balancing solution, and other ecosystem projects(e.g. KubernetesPrometheusJaegerFluentd etc). BFE system consists of components in both data plane and control plane: Data plane BFE ServerBFE forward engine. BFE Server performs content based routing, load balancing and forwards the traffic to backend servers. Control plane provides API and handles update, storage and generation of BFE config component for loading config, fetches latest config from API-Server and triggers BFE Server to reload it provides a graphic interface for user to manage and view major config of BFE This diagram illustrates the architecture of BFE and some of its ecosystem components: The incoming user traffic reaches the BFE server through the Layer 4 load balancing facilities. During the processing of user traffic, BFE routes each HTTP request to a target cluster based on request content (URI, header, cookie, etc), and then choose the best backend server instance from the target cluster based on the load balancing policy. For more details about traffic forwarding process, see . The control plane is responsible for management and configuration of BFE system, which can be maintained via BFE Dashboard or RESTful API. BFE Conf Agent will trigger BFE Server to load the latest configuration.
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-api-plans-wizard.md

This wizard allows you to define a plan, define its security and its policies (quota / rate limit..). 4 types are available for plans: OAuth2 The OAuth2 plan type allows you to check an access token and identify the application with its client ID JWT The JWT plan type allows you to check that the given JSON web token is valid and not expired API Key The API Key plan type allows you to identify and to check that the given API Key is valid and not expired Keyless Nothing is required: public access
Project: Contour (Orchestration & Management / Service Proxy)
File: question.md

name: Question about: Ask a question about configuration, recommendations, general guidance, etc. title: '' labels: kind/question, lifecycle/needs-triage assignees: '' What question do you have?: Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.] Environment: Contour version: Kubernetes version: (use `kubectl version`): Kubernetes installer & version: Cloud provider or hardware configuration: OS (e.g. from `/etc/os-release`):
Project: KubeStellar (Orchestration & Management / Scheduling & Orchestration)
File: contributor.md

Make sure all pre-requisites are installed as described in . The Makefile has a target for running all the unit tests. ```shell make test ``` There are currently two integration tests. Contributors can run them. There is also a GitHub Actions workflow (in `.github/workflows/pr-test-integration.yml`) that runs these tests. These tests require you to already have `etcd` on your `$PATH`. See https://github.com/kubernetes/kubernetes/blob/v1.28.2/hack/install-etcd.sh for an example of how to do that. To run the tests sequentially, issue a command like the following. ```shell CONTROLLERTESTNUM_OBJECTS=24 go test -v ./test/integration/controller-manager &> /tmp/test.log ``` If `CONTROLLERTESTNUM_OBJECTS` is not set then the number of objects will be 18. This parameterization by an environment variable is only a point-in-time hack, it is expected to go away once we have a test that runs reliably on a large number of objects. To run one of the individual tests, issue a command like the following example. ```shell go test -v -timeout 60s -run ^TestCRDHandling$ ./test/integration/controller-manager ``` See .
Project: Consul (Orchestration & Management / Service Mesh)
File: add-a-changelog-entry.md

Any change that a Consul user might need to know about should have a changelog entry. What doesn't need a changelog entry? Docs changes Typos fixes, unless they are in a public-facing API Code changes we are certain no Consul users will need to know about To include a in a PR, commit a text file named `.changelog/<PR#>.txt`, where `<PR#>` is the number associated with the open PR in Github. The text file should describe the changes in the following format: ```` ```release-note:<change type> <code area>: <brief description of the improvement you made here> ``` ```` Valid values for `<change type>` include: `feature`: for the addition of a new feature `improvement`: for an improvement (not a bug fix) to an existing feature `bug`: for a bug fix `security`: for any Common Vulnerabilities and Exposures (CVE) resolutions `breaking-change`: for any change that is not fully backwards-compatible `deprecation`: for functionality which is now marked for removal in a future release `<code area>` is meant to categorize the functionality affected by the change. Some common values are: `checks`: related to node or service health checks `cli`: related to the command-line interface and its commands `config`: related to configuration changes (e.g., adding a new config option) `connect`: catch-all for the Connect subsystem that provides service mesh functionality if no more specific `<code area>` applies `http`: related to the HTTP API interface and its endpoints `dns`: related to DNS functionality `ui`: any change related to the built-in Consul UI (`website/` folder) Look in the folder for examples of existing changelog entries. If a PR deserves multiple changelog entries, just add multiple entries separated by a newline in the format described above to the `.changelog/<PR#>.txt` file.
Project: Consul (Orchestration & Management / Service Mesh)
File: dns.md

The DNS interface allows users to find the IP address and port of services, using DNS queries. The DNS interface is in many ways similar to an HTTP API. The major difference is in the DNS protocol. There are lots of guides to DNS, the following list is a short reference that should help you understand the parts that are relevant to the DNS interface in Consul. Full details about the DNS protocol can be found in the RFCs: [RFC 1035], [RFC 6891], [RFC 2782], and others. is a quick introduction to the format used for queries and replies is a good reference for when to use specific response codes and what the different header bits refer to. The DNS interface is implemented as a DNS server using [miekg/dns] and the handlers for requests are in `agent/dns.go`. The DNS interface handles queries where OPCODE=0 (standard query). The following table describe the current DNS behaviour for different record types and domain names. The Domain names (along the top) are always in the form `<prefix>.<name in table>.<domain>`, where `domain` is generally documented as `consul` but can be set using the `domain` or `alt_domain` config fields. The `prefix` is an identifier (service name, node name, prepared query name, etc). | Type | service | connect | ingress | node | query | addr | ||-|-|-||--|| | SOA | Supported | Supported | Supported | Supported | Supported | Supported | | NS | Supported | Supported | Supported | Supported | Supported | Supported | | AXFR | Not Implemented | Not Implemented | Not Implemented | Not Implemented | Not Implemented | Not Implemented | | A/AAAA | Supported | Supported | Supported | Supported | | Supported | | ANY | Supported (return A) | Supported (return A) | Supported (return A) | Supported | | Supported (return A) | | CNAME | Supported (node cname) | Supported (node cname) | Supported (node cname) | Supported (node cname) | | return empty with A as extra | | OPT | Supported (node OPT) | Supported (node OPT) | Supported (node OPT) | Supported (node OPT) | | return empty with A as extra | | PTR | Supported (node PTR) | Supported (node PTR) | Supported (node PTR) | Supported (node PTR) | | return empty with A as extra | | SRV | Supported (service SRV) | Supported (service SRV) | Supported (service SRV) | No error but empty | | return empty with A as extra | | TXT | Answer A record (????) | Answer A record (????) | Answer A record (????) | Supported | | return empty with A as extra |
Project: Kubernetes (Orchestration & Management / Scheduling & Orchestration)
File: RELEASE.md

The `yaml` Project is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
Project: APISIX (Orchestration & Management / API Gateway)
File: kafka-proxy.md

title: kafka-proxy keywords: Apache APISIX API Gateway Plugin Kafka proxy description: This document contains information about the Apache APISIX kafka-proxy Plugin. <!-- --> The `kafka-proxy` plugin can be used to configure advanced parameters for the kafka upstream of Apache APISIX, such as SASL authentication. | Name | Type | Required | Default | Valid values | Description | |-||-|||| | sasl | object | optional | | {"username": "user", "password" :"pwd"} | SASL/PLAIN authentication configuration, when this configuration exists, turn on SASL authentication; this object will contain two parameters username and password, they must be configured. | | sasl.username | string | required | | | SASL/PLAIN authentication username | | sasl.password | string | required | | | SASL/PLAIN authentication password | NOTE: `encrypt_fields = {"sasl.password"}` is also defined in the schema, which means that the field will be stored encrypted in etcd. See . :::note If SASL authentication is enabled, the `sasl.username` and `sasl.password` must be set. The current SASL authentication only supports PLAIN mode, which is the username password login method. ::: When we use scheme as the upstream of kafka, we can add kafka authentication configuration to it through this plugin. ```shell curl -X PUT 'http://127.0.0.1:9180/apisix/admin/routes/r1' \ -H 'X-API-KEY: <api-key>' \ -H 'Content-Type: application/json' \ -d '{ "uri": "/kafka", "plugins": { "kafka-proxy": { "sasl": { "username": "user", "password": "pwd" } } }, "upstream": { "nodes": { "kafka-server1:9092": 1, "kafka-server2:9092": 1, "kafka-server3:9092": 1 }, "type": "none", "scheme": "kafka" } }' ``` Now, we can test it by connecting to the `/kafka` endpoint via websocket. To remove the `kafka-proxy` Plugin, you can delete the corresponding JSON configuration from the Plugin configuration. APISIX will automatically reload and you do not have to restart for this to take effect.
Project: Contour (Orchestration & Management / Service Proxy)
File: CHANGELOG-v1.20.2.md

We are delighted to present version v1.20.2 of Contour, our layer 7 HTTP reverse proxy for Kubernetes clusters. A big thank you to everyone who contributed to the release. Bumps Envoy to security patch version 1.21.3. Envoy announcement . See Envoy release notes . (#4569, @sunjayBhatia) When validating secrets, don't log an error for an Opaque secret that doesn't contain a `ca.crt` key. (#4528, @skriss) Fixes TLS private key validation logic which previously ignored errors for PKCS1 and PKCS8 private keys. (#4544, @sunjayBhatia) Update gopkg.in/yaml.v3 to v3.0.1 to address CVE-2022-28948. (#4551, @tsaarni) For a fresh install of Contour, consult the . To upgrade an existing Contour installation, please consult the . Contour v1.20.2 is tested against Kubernetes 1.21 through 1.23. Were immensely grateful for all the community contributions that help make Contour even better! 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: Volcano (Orchestration & Management / Scheduling & Orchestration)
File: getting-started.md

Volcano is a batch system built on Kubernetes. It provides a suite of mechanisms currently missing from Kubernetes that are commonly required by many classes of batch & elastic workload including: machine learning/deep learning, bioinformatics/genomics other "big data" applications. These types of applications typically run on generalized domain frameworks like TensorFlow, Spark, Ray, PyTorch, MPI, etc, which Volcano integrates with. // TODO better to add separate md file & Link Learn about Volcano To get the most out of Volcano, start by reviewing a few introductory topics: - preoaration for development - Install Volcano - Contribute to Volcano - Troubleshoot commonly occurring issues. GitHub issues are
Project: Kuma (Orchestration & Management / Service Mesh)
File: new-feature.md

If this is a bigger feature, consider writing a proposal, so we can avoid a situation that PR needs to be reimplemented. When designing a new feature, consider the following questions How does it work on Kubernetes? How does it work on Universal? How does it work with multi-zone (hybrid) deployment? Is it backwards compatible? Does it affect projects that are based on Kuma? If possible, write E2E test that verifies the behavior If a new behavior is introduced or the old is changed, write . Does it need changes in the ? How is deployed on Universal? How is deployed on Kubernetes with kumactl? How is deployed on Kubernetes with HELM?