cwielenb/CNCF-Dataset huggingface dataset:
Project: kratos (Orchestration & Management / Remote Procedure Call)
File: proposal.md

name: "\U0001F9F1 Proposal Request" about: Implementation draft of feature. title: "[Proposal]" labels: proposal assignees: '' Please see the FAQ in our main README.md before submitting your issue. <!-- In order to accurately distinguish that the needs put forward by users are the needs of most users and reasonable needs, solicit community opinions through the process, and the features adopted by the community will be realized as new functions. In order to make the proposal process as simple as possible, the process includes three stages: feature request - > proposal - > pull-request, where feature, proposal is issue and pull-request is the specific function implementation. In order to help the community correctly understand the requirements of the feature, the feature request issue needs to describe the functional requirements and relevant references or documents in detail. And the feature request issue can contain the basic description of the function, which can be used as a reference for the function implementation in the proposal. Proposal contains the basic implementation methods of functions, such as interface definition, general usage of functions, etc. After the function is realized, a merge request will be initiated to associate the proposal issue with the function issue. After the merger is completed, all questions will be closed and the process will end. When more than five maintainer members agree to implement the feature, a proposal issue will be created for detailed design. The status of the proposal is divided into: under discussion, finalized and abandoned. After reaching the final status, start specific implementation (PR can also be implemented synchronously during the discussion) If the maintainer team members have major differences on a requirement, the final decision is made by @Terry Mao. --> <!-- example: Add event interface for accessing message oriented middleware --> <!-- ```go example: type Message interface { Key() string Value() []byte Header() map[string]string Ack() error Nack() error } type Handler func(context.Context, Message) error type Event interface { Send(ctx context.Context, key string, value []byte]) error Receive(ctx context.Context, handler Handler) error Close() error } ```` --> <!-- example: ```go msg := kafka.NewMessage("kratos", []byte("hello world"), map[string]string{ "user": "kratos", "phone": "123456", }) err := sender.Send(context.Background(), msg) ``` -->
Project: Knative (Orchestration & Management / Scheduling & Orchestration)
File: README.md

This package is a fork of the go-yaml library and is intended solely for consumption by kubernetes projects. In this fork, we plan to support only critical changes required for kubernetes, such as small bug fixes and regressions. Larger, general-purpose feature requests should be made in the upstream go-yaml library, and we will reject such changes in this fork unless we are pulling them from upstream. This fork is based on v2.4.0: https://github.com/go-yaml/yaml/releases/tag/v2.4.0 Introduction The yaml package enables Go programs to comfortably encode and decode YAML values. It was developed within as part of the project, and is based on a pure Go port of the well-known C library to parse and generate YAML data quickly and reliably. Compatibility The yaml package supports most of YAML 1.1 and 1.2, including support for anchors, tags, map merging, etc. Multi-document unmarshalling is not yet implemented, and base-60 floats from YAML 1.1 are purposefully not supported since they're a poor design and are gone in YAML 1.2. Installation and usage The import path for the package is gopkg.in/yaml.v2. To install it, run: go get gopkg.in/yaml.v2 API documentation -- If opened in a browser, the import path itself leads to the API documentation: API stability The package API for yaml v2 will remain stable as described in . License The yaml package is licensed under the Apache License 2.0. Please see the LICENSE file for details. Example ```Go package main import ( "fmt" "log" "gopkg.in/yaml.v2" ) var data = ` a: Easy! b: c: 2 d: [3, 4] ` // Note: struct fields must be public in order for unmarshal to // correctly populate the data. type T struct { A string B struct { RenamedC int `yaml:"c"` D []int `yaml:",flow"` } } func main() { t := T{} err := yaml.Unmarshal([]byte(data), &t) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" t:\n%v\n\n", t) d, err := yaml.Marshal(&t) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" t dump:\n%s\n\n", string(d)) m := make(map[interface{}]interface{}) err = yaml.Unmarshal([]byte(data), &m) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" m:\n%v\n\n", m) d, err = yaml.Marshal(&m) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" m dump:\n%s\n\n", string(d)) } ``` This example will generate the following output: ``` t: {Easy! {2 [3 4]}} t dump: a: Easy! b: c: 2 d: [3, 4] m: map[a:Easy! b:map[c:2 d:[3 4]]] m dump: a: Easy! b: c: 2 d: 3 4 ```
Project: Emissary-Ingress (Orchestration & Management / API Gateway)
File: GOVERNANCE.md

This document defines the project governance for Emissary Ingress. Emissary Ingress is an open source project that is committed to building a thriving community. This document outlines how the community governs itself. All community members must adhere to the Users:* Members that engage with the Emissary Ingress community via any medium (Slack, GitHub, mailing lists, etc.). Contributors:* Regular contributions to projects (documentation, code reviews, responding to issues, participation in proposal discussions, contributing code, etc.). Maintainers*: The Emissary Ingress project leaders. They are responsible for the overall health and direction of the project; final reviewers of PRs and responsible for releases. Maintainers are expected to triage issues, proactively fix bugs, review PRs to ensure code quality, and contribute documentation. New maintainers must be nominated by an existing maintainer and must be elected by a supermajority of existing maintainers. Likewise, maintainers can be removed by a supermajority of the existing maintainers or can resign by notifying one of the maintainers. If you're interested in becoming a maintainer, contact an existing maintainer to express your interest. A good way to start is to fix some small issues (if you haven't already), working with one or more existing maintainers. As you build up a representative body of contributions, the maintainers will provide regular feedback on your progress towards maintainer status. After you have built up that representative body of contributions (usually over a period of 3-4 months), the maintainers will meet to discuss and vote on granting maintainer status. Ideally, all project decisions are resolved by consensus. If impossible, any maintainer may call a vote. Unless otherwise specified in this document, any vote will be decided by a majority of maintainers. A supermajority is defined as two-thirds of members in the group. A supermajority of is required for adding or removing maintainers. Voting on decisions will be conducted using GitHub: Open an issue, if an appropriate issue is not already present. Write a description of the issue at hand in a comment on the issue. The description must include: A summary of the vote to be taken; Whether the vote requires a majority or a supermajority; and The meaning of a yay vote and a nay vote, if not obvious. For example, when voting to add a maintainer, the meanings of yay and nay are straightforward. On the other hand, for a choice between two alternatives, the comment should spell out which alternative is supported by a yay vote, and which by a nay vote. Maintainers vote by placing emoji on the comment: :thumbsup: for yay, :thumbsdown: for nay. All substantive changes in Governance require a supermajority agreement by all maintainers.
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-create-application.md

An application is required to subscribe to API's plan. It is the intermediate link between a user (you) and an API managed by someone else. An application is a simple entity composed of small property which are mainly defined to describe the application , what is does, ... If relevant, you can set the domain used by your application (for instance `https://my-app.com`). It will help API publishers to properly configure access controls. TIP: You can set multiple domains separated by commas.
Project: Gloo (Orchestration & Management / API Gateway)
File: range.proto.sk.md

title: "range.proto" weight: 5 <!-- Code generated by solo-kit. DO NOT EDIT. --> Specifies the int64 start and end of the range using half-open interval semantics [start, end). ```yaml "start": int "end": int ``` | Field | Type | Description | | -- | - | -- | | `start` | `int` | start of the range (inclusive). | | `end` | `int` | end of the range (exclusive). | Specifies the int32 start and end of the range using half-open interval semantics [start, end). ```yaml "start": int "end": int ``` | Field | Type | Description | | -- | - | -- | | `start` | `int` | start of the range (inclusive). | | `end` | `int` | end of the range (exclusive). | Specifies the double start and end of the range using half-open interval semantics [start, end). ```yaml "start": float "end": float ``` | Field | Type | Description | | -- | - | -- | | `start` | `float` | start of the range (inclusive). | | `end` | `float` | end of the range (exclusive). | <!-- 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: hami (Orchestration & Management / Scheduling & Orchestration)
File: iluvatar-gpu-support.md

We now support iluvatar.ai/gpu by implementing most device-sharing features as nvidia-GPU, including: *GPU sharing*: Each task can allocate a portion of GPU instead of a whole GPU card, thus GPU can be shared among multiple tasks. *Device Memory Control*: GPUs can be allocated with certain device memory size on certain type(i.e m100) and have made it that it does not exceed the boundary. *Device Core Control*: GPUs can be allocated with limited compute cores on certain type(i.e m100) and have made it that it does not exceed the boundary. *Very Easy to use*: You don't need to modify your task yaml to use our scheduler. All your GPU jobs will be automatically supported after installation. Iluvatar gpu-manager (please consult your device provider) driver version > 3.1.0 Deploy gpu-manager on iluvatar nodes (Please consult your device provider to aquire its package and document) NOTICE: Install only gpu-manager, don't install gpu-admission package. Identify the resource name about core and memory usage(i.e 'iluvatar.ai/vcuda-core', 'iluvatar.ai/vcuda-memory') set the 'iluvatarResourceMem' and 'iluvatarResourceCore' parameters when install hami ``` helm install hami hami-charts/hami --set scheduler.kubeScheduler.imageTag={your kubernetes version} --set iluvatarResourceMem=iluvatar.ai/vcuda-memory --set iluvatarResourceCore=iluvatar.ai/vcuda-core -n kube-system ``` Iluvatar GPUs can now be requested by a container using the `iluvatar.ai/vgpu`, `iluvatar.ai/vcuda-memory` and `iluvatar.ai/vcuda-core` resource type: ``` apiVersion: v1 kind: Pod metadata: name: poddemo spec: restartPolicy: Never containers: name: poddemo image: harbor.4pd.io/vgpu/corex_transformers@sha256:36a01ec452e6ee63c7aa08bfa1fa16d469ad19cc1e6000cf120ada83e4ceec1e command: bash args: -c | set -ex echo "export LDLIBRARYPATH=/usr/local/corex/lib64:$LDLIBRARYPATH">> /root/.bashrc cp -f /usr/local/iluvatar/lib64/libcuda.* /usr/local/corex/lib64/ cp -f /usr/local/iluvatar/lib64/libixml.* /usr/local/corex/lib64/ source /root/.bashrc sleep 360000 resources: requests: iluvatar.ai/vgpu: 1 iluvatar.ai/vcuda-core: 50 iluvatar.ai/vcuda-memory: 64 limits: iluvatar.ai/vgpu: 1 iluvatar.ai/vcuda-core: 50 iluvatar.ai/vcuda-memory: 64 ``` NOTICE1: Each unit of vcuda-memory indicates 256M device memory NOTICE2: You can find more examples in You need to set the following prestart command in order for the device-share to work properly ``` set -ex echo "export LDLIBRARYPATH=/usr/local/corex/lib64:$LDLIBRARYPATH">> /root/.bashrc cp -f /usr/local/iluvatar/lib64/libcuda.* /usr/local/corex/lib64/ cp -f /usr/local/iluvatar/lib64/libixml.* /usr/local/corex/lib64/ source /root/.bashrc ``` Virtualization takes effect only for containers that apply for one GPU(i.e iluvatar.ai/vgpu=1 )
Project: Armada (Orchestration & Management / Scheduling & Orchestration)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: "" assignees: "" <!-- Feel free to skip the sections if they are not applicable. --> Describe the bug <!-- A clear and concise description of what the bug is. --> Files Or Markdown that can reproduce the issue Expected behavior <!-- What's the expected behavior? --> Actual behavior <!-- What's the actual behavior? --> Additional context <!-- Add any other context about the problem here. -->
Project: Istio (Orchestration & Management / Service Mesh)
File: UPDATING-CHARTS.md

Helm charts `values.yaml` represent a complex user facing API that tends to grow uncontrollably over time due to design choices in Helm. The underlying Kubernetes resources we configure have 1000s of fields; given enough users and bespoke use cases, eventually someone will want to customize every one of those fields. If all fields are exposed in `values.yaml`, we end up with an massive API that is also likely worse than just using the Kubernetes API directly. To avoid this, the project attempts to minimize additions to the `values.yaml` API where possible. If the change is a dynamic runtime configuration, it probably belongs in the . This allows configuration without re-installing or restarting deployments. If the change is to a Kubernetes field (such as modifying a Deployment attribute), it will likely need to be install-time configuration. However, that doesn't necessarily mean a PR to add a value will be accepted. The `values.yaml` API is intended to maintain a minimal core set of configuration that most users will use. For bespoke use cases, can be used to allow arbitrary customizations. If the change truly is generally purpose, it is generally preferred to have broader APIs. For example, instead of providing direct access to each of the complex fields in , just providing a single `affinity` field that is passed through as-is to the Kubernetes resource. This provides maximum flexibility with minimal API surface overhead. Be sure to provide sufficient documentation and example usage in values.yaml. If the chart has a `values.schema.json`, that should be updated as well. If you are modifying the `gateway` chart, you can stop here. All other charts, however, are exposed by `istioctl` and need to follow the steps below. The charts in the `manifests` directory are used in istioctl to generate an installation manifest. If `values.yaml` is changed, be sure to update corresponding values changes in Istioctl uses a to validate the values. Any changes to the schema must be added here, otherwise istioctl users will see errors. Once the schema file is updated, run: ```bash $ make operator-proto ``` This will regenerate the Go structs used for schema validation. Tests of istioctl use the auto-generated manifests to ensure that the istioctl binary has the correct version of the charts. To regenerate the manifests, run: ```bash $ make copy-templates update-golden ``` Your PR should pass all the checks if you followed these steps.
Project: DolphinScheduler (Orchestration & Management / Scheduling & Orchestration)
File: remoteshell.md

RemoteShell task type is used to execute commands on remote servers. Click Project Management-Project Name-Workflow Definition, click the "Create Workflow" button to enter the DAG editing page. Drag <img src="../../../../img/tasks/icons/remoteshell.png" width="15"/> from the toolbar to the canvas to complete the creation. Please refer to `Default Task Parameters` section for default parameters. SSH Data Source: Select SSH data source. After the task connects to the server, it will not automatically source bashrc and other files. The required environment variables can be imported in the following ways Create environment variables in the security center-Environment Management, and then import them through the environment option in the task definition Enter the corresponding environment variables directly in the script
Project: Gravitee.io (Orchestration & Management / API Gateway)
File: management-configuration-dictionary.md

A dictionary can be MANUAL or DYNAMIC. In the case of a manual dictionary, it is the responsibility of the administrator (or any user with update right) to create / update or remove properties. In the same, it is the responsibility of the administrator to deploy the dictionary into API Gateways. In the case of a dynamic dictionary, properties are updated automatically according to an underlying provider. Each time a change has been detected between previous properties and new properties, the dictionary is automatically deployed into API Gateways and are then available during the HTTP request process.
Project: etcd (Orchestration & Management / Coordination & Service Discovery)
File: CHANGELOG-3.6.md

Previous change logs can be found at . <hr> See . `etcd` will no longer start on data dir created by newer versions (for example etcd v3.6 will not run on v3.7+ data dir). To downgrade data dir please check out `etcdutl migrate` command. `etcd` doesn't support serving client requests on the peer listen endpoints (--listen-peer-urls). See . `etcdctl` will sleep(2s) in case of range delete without `--range` flag. See Applications which depend on etcd v3.6 packages must be built with go version >= v1.18. Deprecated . Deprecated . Removed . Removed . Removed . Removed . Add command to generate . When print endpoint status, when displaying member list in json. into the response of command `etcdctl endpoint status`. Add flag to make-mirror command. Add flag to member list command. Display for `etcdctl endpoint hash` command. Add command to generate . Add `migrate` command for downgrading/upgrading etcd data dir files. Add . Removed . Package `mvcc` was moved to `storage/mvcc` Package `mvcc/backend` was moved to `storage/backend` Package `mvcc/buckets` was moved to `storage/schema` Package `wal` was moved to `storage/wal` Package `datadir` was moved to `storage/datadir` . Migrated raft to a separate , and renamed raft module to `go.etcd.io/raft/v3`. Add flag to support log format. Add flag to allow configuration of learner max membership. Add flag to handle upgrade from v3.5.2 clusters with this feature enabled. Add flag to support incremental mirror. Add to bootstrap a new etcd cluster. Add into the response body of endpoint `/version`. Add flag to configure the max concurrent streams each client can open at a time, and defaults to math.MaxUint32. Add flag to logging all grpc requests and responses. Add flags to support enabling reliable corruption detection on compacted revisions. Add . Graduated . Note the experimental flag is deprecated and will be decommissioned in v3.7. Add . Add flag to configure number of entries for a slow follower to catch up after compacting the raft storage entries and defaults to 5k. Decreased Add to enable support for TLS 1.3. Add Add flag to enable and configure interval of auto sync of endpoints with server. Add flag to support adding configurable cipher list. See for all metrics per release. Add . Add . Require . Compile with . Please refer to to configure `GOGC` and `GOMEMLIMIT` properly. Use Distroless as base image to make the image less vulnerable and reduce image size. . <hr>
Project: Skipper (Orchestration & Management / Service Proxy)
File: external-addresses.md

In Kubernetes, it is possible to define services with external names (type=ExternalName). For ingress objects, Skipper supports these services, and generates routes from the ingress objects that reference one or more external name service, that will have a backend pointing to the network address defined by the specified service. Route groups don't support services of type ExternalName, but they support network backends, and even LB backends with explicit endpoints with custom endpoint addresses. This way, it is possible to achieve the same with route groups. For both the ingress objects and the route groups, the accepted external addresses must be explicitly allowed by listing regexp expressions of which at least one must be matched by the domain name of these addresses. The allow list is a startup option, defined via command line flags or in the configuration file. Enforcing this list happens only in the Kubernetes Ingress mode of Skipper. For compatibility reasons, the validation needs to be enabled with an explitic toggle: ```sh skipper -kubernetes \ -kubernetes-only-allowed-external-names \ -kubernetes-allowed-external-name "^one[.]example[.]org$" \ -kubernetes-allowed-external-name "^two[.]example[.]org$" ``` For compatibility reasons, the validation needs to be enabled with an explitic toggle: ```yaml kubernetes-only-allowed-external-names: true kubernetes-allowed-external-names: ^one[.]example[.]org$ ^two[.]example[.]org$ ```
Project: Open Cluster Management (Orchestration & Management / Scheduling & Orchestration)
File: clusterhealthcheck.md

This document describes a mechanism on how hub cluster check the availability of agent running on managed cluster, a new condition `ManagedClusterConditionAvailable` will be introduced to describe whether a managed cluster is available If the kube-apiserver is health and the registration agent is running with the minimum deployment on a managed cluster, this managed cluster will be considered available The Kubernetes Metrics API may be used to get the status of managed cluster kube-apiserver or managed registration agent, but Metrics API has some limits for our cases Reporting metrics will require additional request path from hub to managed cluster (or managed cluster to hub), and if we get the metrics from hub to managed cluster, the hub may not access the managed cluster To know whether a managed cluster is available, the hub may need periodically poll all of managed clusters, this is an inefficient way So we propose hub and managed coordinate a condition to present whether a managed cluster is available Actors Klusterlet agent on managed cluster hub controller on hub cluster after a managed cluster is accepted by hub cluster admin, the agent on managed cluster will create a with a label `open-cluster-management.io/cluster-name=<cluster-name>` on its namespace on hub cluster, then the agent will periodically (by default 60s, the period time should be adjusted, see the scale problem section) update the `RenewTime` of `Lease` to keep available, and check the managed cluster kube-apiserver health by `healthz` API, and check the registration agent is running with the minimum deployment, if all of them are available the agent make sure the status of `ManagedClusterConditionAvailable` condition is `true`, otherwise, the agent updates the status to `false` hub controller watches the managed clusters on hub cluster with its informer, for each accepted managed cluster, the controller get its `Lease` from its namespace and check wether the `Lease` is constantly updated in a duration (by default 5min), if not, the controller updates the status of this managed cluster `ManagedClusterConditionAvailable` condition to `unknown` Note: the `ManagedClusterConditionAvailable` condition only represents the availability of registration agent, other agents should not expand `ManagedCluster` status. If there are many managed clusters, we will face there are a lot of QPS for an idle system due to managed lease update request, to solve this problem, we need a way to control the frequency of lease update, we will add `LeaseDuration` field in `ManagedCluster` API, the hub cluster admin is able to update it according to system QPS, and managed agent can adjust the lease update time accordingly