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

name: Feature request about: Suggest an idea for this project title: '' labels: '' assignees: '' <!-- Here is for bug reports and feature requests ONLY! If you're looking for help, please check our mail list and the Gitter room. Please try to use English to describe your issue, or at least provide a snippet of English translation. --> Type: feature request Add any other context or screenshots about the feature request here.
Project: Eraser (Orchestration & Management / Scheduling & Orchestration)
File: manual-removal.md

title: Manual Removal Create an `ImageList` and specify the images you would like to remove. In this case, the image `docker.io/library/alpine:3.7.3` will be removed. ```shell cat <<EOF | kubectl apply -f - apiVersion: eraser.sh/v1alpha1 kind: ImageList metadata: name: imagelist spec: images: docker.io/library/alpine:3.7.3 # use "*" for all non-running images EOF ``` `ImageList` is a cluster-scoped resource and must be called imagelist. `"*"` can be specified to remove all non-running images instead of individual images. Creating an `ImageList` should trigger an `ImageJob` that will deploy Eraser pods on every node to perform the removal given the list of images. ```shell $ kubectl get pods -n eraser-system eraser-system eraser-controller-manager-55d54c4fb6-dcglq 1/1 Running 0 9m8s eraser-system eraser-kind-control-plane 1/1 Running 0 11s eraser-system eraser-kind-worker 1/1 Running 0 11s eraser-system eraser-kind-worker2 1/1 Running 0 11s ``` Pods will run to completion and the images will be removed. ```shell $ kubectl get pods -n eraser-system eraser-system eraser-controller-manager-6d6d5594d4-phl2q 1/1 Running 0 4m16s eraser-system eraser-kind-control-plane 0/1 Completed 0 22s eraser-system eraser-kind-worker 0/1 Completed 0 22s eraser-system eraser-kind-worker2 0/1 Completed 0 22s ``` The `ImageList` custom resource status field will contain the status of the last job. The success and failure counts indicate the number of nodes the Eraser agent was run on. ```shell $ kubectl describe ImageList imagelist ... Status: Failed: 0 Success: 3 Timestamp: 2022-02-25T23:41:55Z ... ``` Verify the unused images are removed. ```shell $ docker exec kind-worker ctr -n k8s.io images list | grep alpine ``` If the image has been successfully removed, there will be no output.
Project: kcp (Orchestration & Management / Scheduling & Orchestration)
File: etcd-structure.md

description: Changes kcp has made to etcd storage paths. kcp has made some changes to etcd storage paths to support logical clusters and APIExport identities. Please see below for details. Built-in APIs, such as `namespaces`, `configmaps`, `clusterroles`, etc., use the following storage path structure: ``` /etcd prefix/API group name/API resource name/logical cluster name/[namespace, if applicable]/name ``` Let's break down the segments in the etcd path for this example ConfigMap instance: ``` /registry/core/configmaps/root/default/kube-root-ca.crt ``` | Segment name | Description | ||-| | registry | etcd prefix | | core | API group name | | configmaps | API resource name | | root | logical cluster name | | default | namespace | | kube-root-ca.crt | ConfigMap name | Custom resource instances for a CustomResourceDefinition in a workspace use the following storage path structure: ``` /etcd prefix/API group name/API resource name/"customresources"/logical cluster name/[namespace, if applicable]/name ``` Let's break down the segments in the etcd path for this example APIBinding instance: ``` /registry/apis.kcp.io/apibindings/customresources/2cynbfy2m0wtjqcs/scheduling.kcp.io-1mc2w ``` | Segment name | Description | |-|-| | registry | etcd prefix | | apis.kcp.io | API group name | | apibindings | API resource name | | customresources | hard-coded (as opposed to an APIExport identity hash) | | 2cynbfy2m0wtjqcs | logical cluster name | | scheduling.kcp.io-1mc2w | APIBinding name | Custom resource instances for an API provided by an APIExport, bound by an APIBinding, use the following storage path structure: ``` /etcd prefix/API group name/API resource name/APIExport identity hash/logical cluster name/[namespace, if applicable] /name ``` Let's break down the segments in the etcd path for this example Workspace instance: ``` /registry/tenancy.kcp.io/workspaces/cbf732f90c9b7eac67e3d8f8e4c22cf8de0e36acefab6bbab738a85535c0d4cf/root/compute ``` | Segment name | Description | ||-| | registry | etcd prefix | | tenancy.kcp.io | API group name | | workspaces | API resource name | | cbf732f90c9b7eac67e3d8f8e4c22cf8de0e36acefab6bbab738a85535c0d4cf | APIExport identity hash | | root | logical cluster name | | compute | Workspace name |
Project: Gloo (Orchestration & Management / API Gateway)
File: opentelemetry.proto.sk.md

title: "opentelemetry.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Configuration for the OpenTelemetry tracer. [#extension: envoy.tracers.opentelemetry] ```yaml "collectorUpstreamRef": .core.solo.io.ResourceRef "clusterName": string ``` | Field | Type | Description | | -- | - | -- | | `collectorUpstreamRef` | | The upstream to use for submitting traces to the OpenTelemetry agent. Only one of `collectorUpstreamRef` or `clusterName` can be set. | | `clusterName` | `string` | The name of the Envoy cluster to use for submitting traces to the OpenTelemetry agent. Only one of `clusterName` or `collectorUpstreamRef` can be set. | <!-- Start of HubSpot Embed Code --> <script type="text/javascript" id="hs-script-loader" async defer src="//js.hs-scripts.com/5130874.js"></script> <!-- End of HubSpot Embed Code -->
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: databend.md

| Datasource | Description | |-|-| | Datasource | Select DATABEND. | | Datasource Name | Enter the name of the datasource. | | Description | Enter a description of the datasource. | | IP/Host Name | Enter the DATABEND service IP. | | Port | Enter the DATABEND service port. | | Username | Set the username for DATABEND connection. | | Password | Set the password for DATABEND connection. | | Database Name | Enter the database name of the DATABEND connection. | | jdbc connect parameters | Parameter settings for DATABEND connection, in JSON format. | Yes, could use this datasource by default.
Project: CoreDNS (Orchestration & Management / Coordination & Service Discovery)
File: coredns-1.1.2.md

+++ title = "CoreDNS-1.1.2 Release" description = "CoreDNS-1.1.2 Release Notes." tags = ["Release", "1.1.2", "Notes"] release = "1.1.2" date = "2018-04-23T09:21:29+01:00" author = "coredns" +++ We are pleased to announce the of CoreDNS-1.1.2! This release has some fixes in the plugins and no core updates. has received a large pile of fixes and improvements. : the metrics and health* plugin saw fixes for this reload issue, still not 100% perfect, but a whole lot better than it was. now allows `OR`ing of log classes. : add a server label to make each metric unique to the server handling it. This impacts all plugins, currently proxy and forward have been updated to include a server label. : when enabled plugins show their `log.Debug` output (none of the included plugins use this yet). has a small fix for apex queries. The following people helped with getting this release done: Chris O'Haver, Francois Tur, Maksim Paramonau, Miek Gieben, Moto Ishizawa, Ruslan Drozhdzh, Scott Donovan, Tobias Schmidt, Uladzimir Trehubenka. For documentation see our (in progress!) . For help and other resources, see our .
Project: Nomad (Orchestration & Management / Scheduling & Orchestration)
File: bug_report.md

name: Bug Report about: Let us know about an unexpected error, a crash, or an incorrect behavior. labels: "type/bug" <!-- Hi there, Thank you for opening an issue. Please note that we try to keep the Nomad issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://developer.hashicorp.com/nomad/community --> Output from `nomad version` <!-- If possible please post relevant logs in the issue. ` Logs and other artifacts may also be sent to: nomad-oss-debug@hashicorp.com Please link to your Github issue in the email and reference it in the subject line: To: nomad-oss-debug@hashicorp.com Subject: GH-1234: Errors garbage collecting allocs Emails sent to that address are readable by all HashiCorp employees but are not publicly visible. -->
Project: Easegress (Orchestration & Management / API Gateway)
File: 7.09.Maintain.md

These are the steps to release a new version of Easegress. Let's suppose that the next version is `X.Y.Z`. Then new tag is `vX.Y.Z` (note prefix `v`) and new release title is `easegress-vX.Y.Z`. Please collect all Pull Request's that will be mentioned in `CHANGELOG.md` and in the Release Note. Create a Pull Request that updates release version `X.Y.Z` in Makefile and adds the new version to `CHANGELOG.md`. Include significant changes, implemented enchantments and fixed bugs to `CHANGELOG.md`. Once the PR is reviewed and approved, merge it to main branch. Create new release note at https://github.com/megaease/easegress/releases/new with release title `easegress-vX.Y.Z`, click Choose a tag and add new tag `vX.Y.Z`. Write the Release note. You can use the modifications written to `CHANGELOG.md` in previous step. Follow the same format, as previous Release notes. Once written, click `Save draft`. New tag triggers Goreleaser Github action. Follow up that it creates and uploads successfully all binaries and Docker images. Ensure that the release note created in step 2 contains the command to pull the new Docker image. Edit the release note create in step 2, and click `Publish release`. New version of Easegress is now released! Notify everyone to check it out!
Project: Aeraki Mesh (Orchestration & Management / Service Mesh)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: '' assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] 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. Additional context Add any other context or screenshots about the feature request here.
Project: wasmCloud (Orchestration & Management / Scheduling & Orchestration)
File: 0016-rename-lattice-prefix.md

| Status | Deciders | Date | |-|-|-| | Accepted | Commenters & tagged contributors in | 18 Jan 2024 | This ADR covers a naming change to one of our most important ideas, the lattice prefix, to just calling it a lattice. It's a simple change, but worth documenting. The simplification from lattice prefix to just lattice is aimed at reducing the cognitive burden of learning the term when you're a newcomer to the wasmCloud project, as we don't use it as a prefix rather than something more like a distributed network namespace. Namespace Network Namespace Lattice Lattice Prefix wasmCloud Namespace We chose option 3, Lattice, because it's the simplest and most intuitive. The lattice is unique to wasmCloud, and is a simple way to describe the distributed namespace that wasmCloud uses to identify actors, providers, and capability providers. We'll focus on keeping terms simple and providing clear documentation to help newcomers understand the concepts.
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: binary-logging.md

The log format is described in . It is intended that multiple parts of the call will be logged in separate files, and then correlated by analysis tools using the rpc\_id. The binary logger will be a separate library from gRPC, in each language that we support. The user will need to explicitly call into the library to generate logs. The library will provide the ability to log sending or receiving, as relevant, the following on both the client and the server: Initial metadata Messages Status with trailing metadata from the server Additional key/value pairs that are associated with a call but not sent over the wire The following is an example of what such an API could look like in C++: ```c++ // The context provides the method_name, deadline, peer, and metadata contents. // direction = CLIENT_SEND LogRequestHeaders(ClientContext context); // direction = SERVER_RECV LogRequestHeaders(ServerContext context); // The context provides the metadata contents // direction = CLIENT_RECV LogResponseHeaders(ClientContext context); // direction = SERVER_SEND LogResponseHeaders(ServerContext context); // The context provides the metadata contents // direction = CLIENT_RECV LogStatus(ClientContext context, grpcstatuscode code, string details); // direction = SERVER_SEND LogStatus(ServerContext context, grpcstatuscode code, string details); // The context provides the user data contents // direction = CLIENT_SEND LogUserData(ClientContext context); // direction = SERVER_SEND LogUserData(ServerContext context); // direction = CLIENT_SEND LogRequestMessage(ClientContext context, uint32_t length, T message); // direction = SERVER_RECV LogRequestMessage(ServerContext context, uint32_t length, T message); // direction = CLIENT_RECV LogResponseMessage(ClientContext context, uint32_t length, T message); // direction = SERVER_SEND LogResponseMessage(ServerContext context, uint32_t length, T message); ``` In all of those cases, the `rpc_id` is provided by the context, and each combination of method and context argument type implies a single direction, as noted in the comments. For the message log functions, the `length` argument indicates the length of the complete message, and the `message` argument may be only part of the complete message, stripped of sensitive material and/or shortened for efficiency. In other languages, more or less data will need to be passed explicitly as separate arguments. In some languages, for example, the metadata will be separate from the context-like object and will need to be passed as a separate argument.
Project: Reactive Interaction Gateway (Orchestration & Management / API Gateway)
File: https.md

id: https title: HTTPS sidebar_label: HTTPS In order to enable HTTPS, the `HTTPSCERTFILE` and `HTTPSKEYFILE` environment variables must be set. During development, this may be set to the self-signed certificate that comes with the repository: ```bash $ export HTTPS_CERTFILE=cert/selfsigned.pem $ export HTTPSKEYFILE=cert/selfsignedkey.pem $ mix phx.server ``` WARNING: only use the generated certificate for testing in a closed network environment, such as running a development RIG instance on localhost. For production, staging, or testing on the public internet, obtain a proper certificate, for example from . For production you should use proper HTTPS certificates instead (for that reason the Docker image comes without certificates). Create your own certificate Store it on your machine Run the docker image by mounting the files as shown here: ```bash $ docker run \ -v "$(pwd)"/cert/own-certificate.pem:/cert/own-certificate.pem \ -e HTTPS_CERTFILE=/cert/own-certificate.pem \ -v "$(pwd)"/cert/own-certificatekey.pem:/cert/own-certificatekey.pem \ -e HTTPSKEYFILE=/cert/own-certificatekey.pem \ -p 4000:4000 -p 4010:4010 \ -p 4001:4001 -p 4011:4011 \ accenture/reactive-interaction-gateway ``` Refer to the to learn more about available configuration options.
Project: kcp (Orchestration & Management / Scheduling & Orchestration)
File: rest-access-patterns.md

description: > Information on the different types of URLs that kcp serves. This describes the various REST access patterns the kcp apiserver supports. These requests are all prefixed with `/clusters/<workspace path | logical cluster name>`. Here are some example URLs: `GET /clusters/root/apis/tenancy.kcp.io/v1alpha1/workspaces` - lists all kcp Workspaces in the `root` workspace. `GET /clusters/root:compute/api/v1/namespaces/test` - gets the namespace `test` from the `root:compute` workspace `GET /clusters/yqzkjxmzl9turgsf/api/v1/namespaces/test` - same as above, using the logical cluster name for `root:compute` An APIExport provides a view into workspaces that contain APIBindings that are bound to the APIExport. This allows the service provider - the owner of the APIExport - to access data in its consumers' workspaces. Here is an example APIExport virtual workspace URL: ``` /services/apiexport/root:my-ws/my-service/clusters/root:consumer-1/apis/example.kcp.io/v1/widgets ``` Let's break down the segments in the URL path: | Segment | Description | |--|-| | /services/apiexport | Prefix for every APIExport virtual workspace | | root:my-ws | Workspace where the APIExport lives | | my-service | Name of the APIExport | | clusters/root:consumer-1 | Consumer workspace path | | apis/example.kcp.io/v1/widgets | Normal API path | A virtual workspace typically allows the service provider to set up shared informers that can list and watch resources across all the consumer workspaces bound to or supported by the virtual workspace. For example, the APIExport virtual workspace lets you inform across all workspaces that have an APIBinding to your APIExport. The syncer virtual workspace lets a syncer inform across all workspaces that have a Placement on the syncer's associated SyncTarget. To set up shared informers to span multiple workspaces, you use a special cluster called the wildcard cluster, denoted by `*`. An example URL you would use when constructing a shared informer in this manner might be: ``` /services/apiexport/root:my-ws/my-service/clusters/*/api/v1/configmaps ``` or, to set up an entire shared informer factory, you give it the wildcard base: ``` /services/apiexport/root:my-ws/my-service/clusters/* ```
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_demo.md

title: "glooctl demo" weight: 5 Demos (requires 4 tools to be installed and accessible via the PATH: glooctl, kubectl, docker, and kind.) ``` glooctl demo [flags] ``` ``` -h, --help help for demo ``` ``` -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) ``` - CLI for Gloo - Bootstrap a multicluster demo with Gloo Federation.
Project: Service Mesh Performance (Orchestration & Management / Service Mesh)
File: GOVERNANCE.md

Any maintainer who is unresponsive or non-participatory (across the various forms of communication used by the project) for a period of two months forfeits maintainer privileges and resumes a contributor role. While much communication is asynchronous, maintainers are required to attend a minimum of one meeting a month in order facilitate high-fidelity, synchronous communication, which is necessary for the quality collaboration, conveyance of complex topics, and real-time advancement of the project. A core team of maintainers steward SMP, however, Service Mesh Performance is comprised of any number of components (adapters, load generators, ...) and any number of logical areas of concern (e.g. community, governance, ...). The size of SMP's project vision and the pace of its development, requires sub-teams to supplement the core team. Each sub-team is focused on a specific area/component e.g., adapters, docs, website, UI, CLI, and so on. To ensure global coordination and a strong, coherent vision for the project as a whole, each sub-team is led by a member of the core team.
Project: Nomad (Orchestration & Management / Scheduling & Orchestration)
File: cgo.md

Nomad requires the use of CGO on Linux. Issue tracks the desire for Nomad to not require CGO. One of the core features of Nomad (the exec driver) depends on . Until `nsenter` no longer requires CGO, the standalone Nomad executable on Linux will not be able to ship without depending on CGO.
Project: gRPC (Orchestration & Management / Remote Procedure Call)
File: http-grpc-status-mapping.md

Since intermediaries are a common part of HTTP infrastructure some responses to gRPC requests may be received that do not include the grpc-status header. In some cases mapping error codes from an intermediary allows the gRPC client to behave more appropriately to the error situation without overloading the semantics of either error code. This table is to be used only for clients that received a response that did not include grpc-status. If grpc-status was provided, it must be used. Servers must not use this table to determine an HTTP status code to use; the mappings are neither symmetric nor 1-to-1. | HTTP Status Code | gRPC Status Code | |-|--| | 400 Bad Request | INTERNAL | | 401 Unauthorized | UNAUTHENTICATED | | 403 Forbidden | PERMISSION\_DENIED | | 404 Not Found | UNIMPLEMENTED | | 429 Too Many Requests | UNAVAILABLE | | 502 Bad Gateway | UNAVAILABLE | | 503 Service Unavailable | UNAVAILABLE | | 504 Gateway Timeout | UNAVAILABLE | | All other codes | UNKNOWN | Technically, 1xx should have the entire header skipped and a subsequent header be read. See RFC 7540 8.1. 200 is UNKNOWN because there should be a grpc-status in case of truly OK response.
Project: k8gb (Orchestration & Management / Coordination & Service Discovery)
File: GOVERNANCE.md

This document defines governance policies for k8gb project. The k8gb project community adheres to the following principles: Open: k8gb is open source. Welcoming and inclusive: See our Transparent and accessible: Any changes to k8gs source code and collaborations on the project are publicly accessible (GitHub issues, PRs, and discussions). Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, scope, and design principles. k8gb follows , which is aligned with the . Anyone can contribute to the project. More about contribution rules and technical aspects can be found in the documentation. Maintainers are defined in the file by their GitHub user handles. New maintainers are nominated by existing maintainers and are elected by a supermajority of votes of existing maintainers. If the maintainer is no longer be able to perform the maintainer duties, they should volunteer to be moved to emeritus status. Maintainers can be also removed from active maintainers list by a supermajority of votes of existing maintainers. Below is the list of maintainer's general responsibilities in additions to those defined for project contributors: Triages GitHub issues Reviews pull requests Runs k8gb releases Forms k8gb architecture, strategy and roadmap Actively supports k8gb community in related channels Represents k8bg project in public media (events, slack channels, etc) Is involved in CNCF-related activities and projects Ensures CNCF guidelines compliancy Owns project infrastructure Project Lead is a project maintainer with the final vote on project decisions In most cases, it is expected that conflicts are amicably resolved by involved parties. In case of escalation, conflicts are resolved by voting, with the ruling of a supermajority of votes of project maintainers. The project lead has the final vote on the ruling. Project Governance is a living document. All key project changes including changes in project governance can be proposed by a GitHub PR and then reviewed and voted for by project maintainers. Sections of this document have been borrowed from , and projects.