cwielenb/CNCF-Dataset huggingface dataset:
Project: etcd (Orchestration & Management / Coordination & Service Discovery)
File: GOVERNANCE.md

The etcd community adheres to the following principles: Open: etcd is open source. Welcoming and respectful: See [Code of Conduct]. Transparent and accessible: Changes to the etcd code repository and CNCF related activities (e.g. level, involvement, etc) are done in public. Merit: Ideas and contributions are accepted according to their technical merit for the betterment of the project. For specific guidance on practical contribution steps please see [contributor guide] guide. Etcd project roles along with their requirements and responsibilities are defined in [community membership]. Decisions are built on consensus between [maintainers] publicly. Proposals and ideas can either be submitted for agreement via a GitHub issue or PR, or by sending an email to `etcd-maintainers@googlegroups.com`. In general, we prefer that technical issues and maintainer membership are amicably worked out between the persons involved. However, any technical dispute that has reached an impasse with a subset of the community, any contributor may open a GitHub issue or PR or send an email to `etcd-maintainers@googlegroups.com`. If the maintainers themselves cannot decide an issue, the issue will be resolved by a supermajority of the maintainers with a fallback on lazy consensus after three business weeks inactive voting period and as long as two maintainers are on board. Changes in project governance could be initiated by opening a GitHub PR.
Project: Fluid (Orchestration & Management / Scheduling & Orchestration)
File: README.md

](https://pkg.go.dev/sigs.k8s.io/json) This library is a subproject of . It provides case-sensitive, integer-preserving JSON unmarshaling functions based on `encoding/json` `Unmarshal()`. The `UnmarshalCaseSensitivePreserveInts()` function behaves like `encoding/json#Unmarshal()` with the following differences: JSON object keys are treated case-sensitively. Object keys must exactly match json tag names (for tagged struct fields) or struct field names (for untagged struct fields). JSON integers are unmarshaled into `interface{}` fields as an `int64` instead of a `float64` when possible, falling back to `float64` on any parse or overflow error. Syntax errors do not return an `encoding/json` `*SyntaxError` error. Instead, they return an error which can be passed to `SyntaxErrorOffset()` to obtain an offset. The `UnmarshalStrict()` function decodes identically to `UnmarshalCaseSensitivePreserveInts()`, and also returns non-fatal strict errors encountered while decoding: Duplicate fields encountered Unknown fields encountered You can reach the maintainers of this project via the . Participation in the Kubernetes community is governed by the . features), or :warning: (breaking changes) Breaking changes will find their way into the next major release, other changes will go into an semi-immediate patch or minor release For a quick PR template suggesting the right information, use one of these PR templates: * * See Learn how to engage with the Kubernetes community on the . controller-runtime is a subproject of the project in sig apimachinery. You can reach the maintainers of this project at: Slack channel: Google Group: Contributions are greatly appreciated. The maintainers actively manage the issues list, and try to highlight issues suitable for newcomers. The project follows the typical GitHub pull request model. See for more details. Before starting any work, please either comment on an existing issue, or file a new one. Participation in the Kubernetes community is governed by the .
Project: Avro (Orchestration & Management / Remote Procedure Call)
File: avro-1.6.2-released.md

title: "Avro 1.6.2" linkTitle: "Avro 1.6.2" date: 2012-02-14 <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> Apache Avro 1.6.2 has been released!
Project: kratos (Orchestration & Management / Remote Procedure Call)
File: bug-report.md

name: "\U0001F41B Bug Report" about: Report something that's broken. Please ensure your kratos version is still supported. title: '' labels: bug assignees: '' <!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://go-kratos.dev/docs/getting-started/faq --> Kratos version (use `kratos -v`): Go version (use `go version`): OS (e.g: `cat /etc/os-release`): Others:
Project: hami (Orchestration & Management / Scheduling & Orchestration)
File: dashboard.md

You can load this dashboard json file This dashboard also includes some NVIDIA DCGM metrics: deploy`kubectl create -f https://raw.githubusercontent.com/NVIDIA/dcgm-exporter/master/dcgm-exporter.yaml` use this prometheus custom metric configure: ```yaml job_name: 'kubernetes-vgpu-exporter' kubernetessdconfigs: role: endpoints relabel_configs: sourcelabels: [metakubernetesendpointsname] regex: vgpu-device-plugin-monitor replacement: $1 action: keep sourcelabels: [metakubernetespodnode_name] regex: (.*) targetlabel: nodename replacement: ${1} action: replace sourcelabels: [metakubernetespodhost_ip] regex: (.*) target_label: ip replacement: $1 action: replace job_name: 'kubernetes-dcgm-exporter' kubernetessdconfigs: role: endpoints relabel_configs: sourcelabels: [metakubernetesendpointsname] regex: dcgm-exporter replacement: $1 action: keep sourcelabels: [metakubernetespodnode_name] regex: (.*) targetlabel: nodename replacement: ${1} action: replace sourcelabels: [metakubernetespodhost_ip] regex: (.*) target_label: ip replacement: $1 action: replace ``` reload promethues ```bash curl -XPOST http://{promethuesServer}:{port}/-/reload ```
Project: APISIX (Orchestration & Management / API Gateway)
File: redis.md

title: redis keywords: Apache APISIX API Gateway xRPC redis description: This document contains information about the Apache APISIX xRPC implementation for Redis. <!-- --> The Redis protocol support allows APISIX to proxy Redis commands, and provide various features according to the content of the commands, including: codec Fault injection according to the commands and key :::note This feature requires APISIX to be run on . It also requires the data sent from clients are well-formed and sane. Therefore, it should only be used in deployments where both the downstream and upstream are trusted. ::: Like other protocols based on the xRPC framework, the Redis implementation here also has the concept of `request`. Each Redis command is considered a request. However, the message subscribed from the server won't be considered a request. For example, when a Redis client subscribes to channel `foo` and receives the message `bar`, then it unsubscribes the `foo` channel, there are two requests: `subscribe foo` and `unsubscribe foo`. | Name | Type | Required | Default | Valid values | Description | |-||-|--|--|-| | faults | array[object] | False | | | Fault injections which can be applied based on the commands and keys | Fields under an entry of `faults`: | Name | Type | Required | Default | Valid values | Description | |-||-|--|--|-| | commands | array[string] | True | | ["get", "mget"] | Commands fault is restricted to | | key | string | False | | "blahblah" | Key fault is restricted to | | delay | number | True | | 0.1 | Duration of the delay in seconds | `apisixrediscommands_total`: Total number of requests for a specific Redis command. | Labels | Description | | - | -- | | route | matched stream route ID | | command | the Redis command | `apisixrediscommandslatencyseconds`: Latency of requests for a specific Redis command. | Labels | Description | | - | -- | | route | matched stream route ID | | command | the Redis command | :::note You can fetch the `admin_key` from `config.yaml` and save to an environment variable with the following command: ```bash adminkey=$(yq '.deployment.admin.adminkey[0].key' conf/config.yaml | sed 's/"//g') ``` ::: Assumed the APISIX is proxying TCP on port `9101`, and the Redis is listening on port `6379`. Let's create a Stream Route: ```shell curl http://127.0.0.1:9180/apisix/admin/streamroutes/1 -H "X-API-KEY: $adminkey" -X PUT -d ' { "upstream": { "type": "none", "nodes": { "127.0.0.1:6379": 1 } }, "protocol": { "name": "redis", "conf": { "faults": [{ "commands": ["get", "ping"], "delay": 5 }] } } } ' ``` Once you have configured the stream route, as shown above, you can make a request to it: ```shell redis-cli -p 9101 ``` ``` 127.0.0.1:9101> ping PONG (5.00s) ``` You can notice that there is a 5 seconds delay for the ping command.
Project: Kusk Gateway (Orchestration & Management / API Gateway)
File: observability.md

Envoy's admin interface is opened on post `19000` and could be used for troubleshooting, configuration dumps, changing logs levels and other administrative tasks. Refer to the on the usage. Envoy exposes a Stats service on the admin interface. Currently, we don't configure any stats sinks to publish the metrics, but Prometheus can discover Envoy pods and query them for the metrics, if pods have the following annotations: ```yaml annotations: prometheus.io/scrape: 'true' prometheus.io/port: '19000' prometheus.io/path: /stats/prometheus ``` This can be configured with `spec.annotations` field. The list of exported HTTP metrics is described in . See also .
Project: Gloo (Orchestration & Management / API Gateway)
File: cidr.proto.sk.md

title: "cidr.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> CidrRange specifies an IP Address and a prefix length to construct the subnet mask for a `CIDR <https://tools.ietf.org/html/rfc4632>`_ range. ```yaml "addressPrefix": string "prefixLen": .google.protobuf.UInt32Value ``` | Field | Type | Description | | -- | - | -- | | `addressPrefix` | `string` | IPv4 or IPv6 address, e.g. ``192.0.0.0`` or ``2001:db8::``. | | `prefixLen` | | Length of prefix, e.g. 0, 32. Defaults to 0 when unset. | <!-- 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: Prefect (Orchestration & Management / Scheduling & Orchestration)
File: api-keys.md

description: Create an API key to access Prefect Cloud from a local execution environment. tags: Prefect Cloud API keys configuration search: boost: 2 API keys enable you to authenticate a local environment to work with Prefect Cloud. If you run `prefect cloud login` from your CLI, you'll have the choice to authenticate through your browser or by pasting an API key. If you choose to authenticate through your browser, you'll be directed to an authorization page. After you grant approval to connect, you'll be redirected to the CLI and the API key will be saved to your local . If you choose to authenticate by pasting an API key, you'll need to create an API key in the Prefect Cloud UI first. To create an API key, select the account icon at the bottom-left corner of the UI. Select API Keys. The page displays a list of previously generated keys and lets you create new API keys or delete keys. Select the + button to create a new API key. Provide a name for the key and an expiration date. !!! warning Note that an API key cannot be revealed again in the UI after it is generated, so copy the key to a secure location. <div class="terminal"> ```bash prefect cloud login -k '<my-api-key>' ``` </div> Service accounts are a feature of Prefect Cloud that enable you to create a Prefect Cloud API key that is not associated with a user account. Service accounts are typically used to configure API access for running workers or executing flow runs on remote infrastructure. Events and logs for flow runs in those environments are then associated with the service account rather than a user, and API access may be managed or revoked by configuring or removing the service account without disrupting user access. See the documentation for more information about creating and managing service accounts in Prefect Cloud.
Project: Apache Mesos (Orchestration & Management / Scheduling & Orchestration)
File: 2015-07-28-register-for-mesoscon-seattle-save.md

layout: post title: Register for MesosCon by 7/31 and Save $100 permalink: /blog/register-for-mesoscon-seattle-save/ published: true post_author: display_name: Steven Borrelli twitter: stevendborrelli tags: MesosCon is less than a month away, and the standard registration fee of $399 expires July 31, 2015. . Beginning August 1, 2015 the registration fee will be $499. Students are eligible for a special registration fee of US$99 (Note that a valid student id will be required at onsite check-in). MesosCon is an annual conference organized by the Apache Mesos community, bringing together users and developers to share and learn about the project and its growing ecosystem. This year MesosCon will take place August 20 - 21, 2015 at Sheraton Seattle in Seattle, WA, and features four tracks of talks for developers, operations and users. MesosCons Keynote speakers feature Adrian Crockroft (Battery Ventures), Benjamin Hindman (Mesosphere), Neha Narula (MIT), and Peter Bailis (Berkeley). The Mesos community will once again hold a , this year on Wednesday, August 19th and sponsored by SignalFx. On behalf of the #MesosCon Program Committee, we couldnt be more excited about this years conference and what this means for the open source projects community. We hope that youll join us!
Project: APISIX (Orchestration & Management / API Gateway)
File: build-apisix-dev-environment-on-mac.md

id: build-apisix-dev-environment-on-mac title: Build development environment on Mac description: This paper introduces how to use Docker to quickly build the development environment of API gateway Apache APISIX on Mac. <!-- --> If you want to quickly build and develop APISIX on your Mac platform, you can refer to this tutorial. :::note This tutorial is suitable for situations where you need to quickly start development on the Mac platform, if you want to go further and have a better development experience, the better choice is the Linux-based virtual machine, or directly use this kind of system as your development environment. You can see the specific supported systems . ::: We use Docker to build the test environment of Apache APISIX. When the container starts, we can mount the source code of Apache APISIX into the container, and then we can build and run test cases in the container. First, clone the APISIX source code, build an image that can run test cases, and compile the Apache APISIX. ```shell git clone https://github.com/apache/apisix.git cd apisix docker build -t apisix-dev-env -f example/build-dev-image.dockerfile . ``` Next, start Etcd: ```shell docker run -d --name etcd-apisix --net=host pachyderm/etcd:v3.5.2 ``` Mount the APISIX directory and start the development environment container: ```shell docker run -d --name apisix-dev-env --net=host -v $(pwd):/apisix:rw apisix-dev-env:latest ``` Finally, enter the container, build the Apache APISIX runtime, and configure the test environment: ```shell docker exec -it apisix-dev-env make deps docker exec -it apisix-dev-env ln -s /usr/bin/openresty /usr/bin/nginx ``` ```shell docker exec -it apisix-dev-env make run docker exec -it apisix-dev-env make stop ``` :::note If you encounter an error message like `nginx: [emerg] bind() to unix:/apisix/logs/worker_events.sock failed (95: Operation not supported)` while running `make run`, please use this solution. Change the `File Sharing` settings of your Docker-Desktop: Changing to either `gRPC FUSE` or `osxfs` can resolve this issue. ::: ```shell docker exec -it apisix-dev-env prove t/admin/routes.t ```
Project: Armada (Orchestration & Management / Scheduling & Orchestration)
File: manual-localdev.md

Here, we give an overview of a development setup for Armada that gives users full control over the Armada components and dependencies. Before starting, please ensure you have installed (version 1.20 or later), gcc (for Windows, see, e.g., ), , , , and, if you need to compile `.proto` files, . For a full list of mage commands, run `mage -l`. You will need to set the `PULSAR_IMAGE` enviromental variable to an arm64 image. We provide an optimised image for this purpose: ```bash export PULSAR_IMAGE=richgross/pulsar:2.11.0 ``` ```bash go mod tidy mage BootstrapTools mage proto mage dotnet mage buildDockers "bundle,lookout-bundle,jobservice" mage Kind mage StartDependencies && mage checkForPulsarRunning docker compose up -d server executor-legacy mage checkForArmadaRunning ``` Run the Armada test suite against the local environment to verify that it is working correctly. ```bash go run cmd/armadactl/main.go create queue e2e-test-queue export ARMADAEXECUTORINGRESS_URL="http://localhost" export ARMADAEXECUTORINGRESS_PORT=5001 go run cmd/testsuite/main.go test --tests "testsuite/testcases/basic/*" --junit junit.xml ``` Tear down the local environment using the following: ```bash docker compose down mage KindTeardown ```
Project: Fluid (Orchestration & Management / Scheduling & Orchestration)
File: CONDUCT.md

Cobra will follow a steady release cadence. Non breaking changes will be released as minor versions quarterly. Patch bug releases are at the discretion of the maintainers. Users can expect security patch fixes to be released within relatively short order of a CVE becoming known. For more information on security patch fixes see the CVE section below. Releases will follow . Users tracking the Master branch should expect unpredictable breaking changes as the project continues to move forward. For stability, it is highly recommended to use a release. We will maintain two major releases in a moving window. The N-1 release will only receive bug fixes and security updates and will be dropped once N+1 is released. Deprecation of Go versions or dependent packages will only occur in major releases. To reduce the change of this taking users by surprise, any large deprecation will be preceded by an announcement in the and an Issue on Github. Maintainers will make every effort to release security patches in the case of a medium to high severity CVE directly impacting the library. The speed in which these patches reach a release is up to the discretion of the maintainers. A low severity CVE may be a lower priority than a high severity one. Cobra maintainers will use GitHub issues and the as the primary means of communication with the community. This is to foster open communication with all users and contributors. Breaking changes are generally allowed in the master branch, as this is the branch used to develop the next release of Cobra. There may be times, however, when master is closed for breaking changes. This is likely to happen as we near the release of a new version. Breaking changes are not allowed in release branches, as these represent minor versions that have already been released. These version have consumers who expect the APIs, behaviors, etc, to remain stable during the lifetime of the patch stream for the minor release. Examples of breaking changes include: Removing or renaming exported constant, variable, type, or function. Updating the version of critical libraries such as `spf13/pflag`, `spf13/viper` etc... Some version updates may be acceptable for picking up bug fixes, but maintainers must exercise caution when reviewing. There may, at times, need to be exceptions where breaking changes are allowed in release branches. These are at the discretion of the project's maintainers, and must be carefully considered before merging. Maintainers will ensure the Cobra test suite utilizes the current supported versions of Golang. Changes to this document and the contents therein are at the discretion of the maintainers. None of the contents of this document are legally binding in any way to the maintainers or the users.
Project: Koordinator (Orchestration & Management / Scheduling & Orchestration)
File: pull_request_template.md

<!-- Summarize your change (mandatory) How does this PR work? Need a brief introduction for the changed logic (optional) Describe clearly one logical change and avoid lazy messages (optional) Describe any limitations of the current code (optional) --> <!--If so, add "fixes #xxxx" below in the next line, for example, fixes #15. Otherwise, add "NONE" --> [ ] I have written necessary docs and comments [ ] I have added necessary unit tests and integration tests [ ] All checks passed in `make test`
Project: StackStorm (Orchestration & Management / Scheduling & Orchestration)
File: bug_report.md

name: Bug report about: Create a report to help us improve Provide a quick summary of your bug report. Paste the output of ``st2 --version``: Post what OS you are running this on, along with any other relevant information/ e.g. Docker, Vagrant, Kubernetes, etc. Describe how you installed ST2 e.g. one-line install, custom install, etc --> Show how to reproduce the problem, using a minimal test-case. Make sure to include any content (pack content - workflows, actions, etc.) which are needed to reproduce the problem. What did you expect to happen when running the steps above? What happened? What output did you get? Making sure to follow these steps will guarantee the quickest resolution possible. Thanks!
Project: Gloo (Orchestration & Management / API Gateway)
File: glooctl_add.md

title: "glooctl add" weight: 5 Adds configuration to a top-level Gloo resource ``` glooctl add [flags] ``` ``` --dry-run print kubernetes-formatted yaml rather than creating or updating a resource -h, --help help for add --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) ``` ``` -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 - Add a Route to a Virtual Service