cwielenb/CNCF-Dataset huggingface dataset:
Project: CubeFS (Runtime / Cloud Native Storage)
File: rpc.md

```json { "clienttimeoutms": "Request timeout time", "bodybandwidthmbps": "Read body bandwidth, default is 1MBps", "bodybasetimeoutms": "Read body benchmark time, so the maximum time to read body is bodybasetimeoutms+size/bodybandwidthmbps(converted to ms)", "transport_config": { "...": "See the detailed configuration of the golang http library transport. In general, it can be ignored, and the default configuration is provided in the code" } } ``` ::: tip Note This default configuration is supported starting from version v3.2.1. ::: The following default configuration is only enabled when all items in `transport_config` are default values. ```json { "maxconnsper_host": 10, "maxidleconns": 1000, "maxidleconnsperhost": 10, "idleconntimeout_ms": 10000 } ``` The Lb version mainly implements load balancing, failure node removal and reuse of multiple nodes. Its configuration is based on single-point configuration, with the following additional configuration items. ```json { "hosts": "List of destination hosts for requests", "backup_hosts": "List of backup destination hosts. When all hosts are unavailable, they will be used", "hosttrytimes": "Number of retries for each node failure, used in conjunction with node removal. When a target host fails continuously for hosttrytimes times, if the failure removal mechanism is enabled, the node will be removed from the available list", "try_times": "Number of retries for each request failure", "failretryinterval_s": "Used in conjunction with node removal to implement the time interval for failed nodes to be reused. If this value is less than or equal to 0, no removal will be performed. The default value is -1", "MaxFailsPeriodS": "Time interval for recording consecutive failures. For example, if the current node has failed N times, when the time interval between the N+1th failure and the Nth failure is less than this value, the node will be recorded as the N+1th failure. Otherwise, it will be recorded as the first failure" }
Project: Soda Foundation (Runtime / Cloud Native Storage)
File: CONTRIBUTING.md

We definitely welcome your patches and contributions to gRPC! Please read the gRPC organization's and before proceeding. If you are new to github, please start by reading In order to protect both you and ourselves, you will need to sign the . How to get your contributions merged smoothly and quickly. Create small PRs that are narrowly focused on addressing a single concern. We often times receive PRs that are trying to fix several things at a time, but only one fix is considered acceptable, nothing gets merged and both author's & review's time is wasted. Create more PRs to address different concerns and everyone will be happy. The grpc package should only depend on standard Go packages and a small number of exceptions. If your contribution introduces new dependencies which are NOT in the , you need a discussion with gRPC-Go authors and consultants. For speculative changes, consider opening an issue and discussing it first. If you are suggesting a behavioral or API change, consider starting with a [gRFC proposal](https://github.com/grpc/proposal). Provide a good PR description as a record of what change is being made and why it was made. Link to a github issue if it exists. Don't fix code style and formatting unless you are already changing that line to address an issue. PRs with irrelevant changes won't be merged. If you do want to fix formatting or style, do that in a separate PR. Unless your PR is trivial, you should expect there will be reviewer comments that you'll need to address before merging. We expect you to be reasonably responsive to those comments, otherwise the PR will be closed after 2-3 weeks of inactivity. Maintain clean commit history and use meaningful commit messages. PRs with messy commit history are difficult to review and won't be merged. Use `rebase -i upstream/master` to curate your commit history and/or to bring in latest changes from master (but avoid rebasing in the middle of a code review). Keep your PR up to date with upstream/master (if there are merge conflicts, we can't really merge your change). All tests need to be passing before your change can be merged. We recommend you run tests locally before creating your PR to catch breakages early on. `make all` to test everything, OR `make vet` to catch vet errors `make test` to run the tests `make testrace` to run tests in race mode optional `make testappengine` to run tests with appengine Exceptions to the rules can be made if there's a compelling reason for doing so.
Project: Weave Net (Runtime / Cloud Native Network)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: Antrea (Runtime / Cloud Native Network)
File: build-kubemark.md

This documentation simply describes how to build the kubemark image used in ```bash cd $KUBERNETES_PATH git checkout v1.29.0 make WHAT=cmd/kubemark KUBEBUILDPLATFORMS=linux/amd64 cp ./_output/local/bin/linux/amd64/kubemark cluster/images/kubemark cd cluster/images/kubemark docker build -t antrea/kubemark:v1.29.0 . ```
Project: Container Storage Interface (CSI) (Runtime / Cloud Native Storage)
File: enhancement.md

name: Enhancement Request about: Suggest an idea for this project Is your feature request related to a problem?/Why is this needed <!-- A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] --> Describe the solution you'd like in detail <!-- 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: Cilium (Runtime / Cloud Native Network)
File: cilium-operator_metrics_list.md

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> List all metrics for the operator ``` cilium-operator metrics list [flags] ``` ``` -h, --help help for list -p, --match-pattern string Show only metrics whose names match matchpattern -o, --output string json| yaml| jsonpath='{}' -s, --server-address string Address of the operator API server (default "localhost:9234") ``` - Access metric status of the operator
Project: Project Calico (Runtime / Cloud Native Network)
File: REPORT_TEMPLATE.md

Short summary of the problem. Make the impact and severity as clear as possible. For example: An unsafe deserialization vulnerability allows any unauthenticated user to execute arbitrary code on the server. Provide the products or components that are affected by the vulnerability. Provide versions that were tested with the vulnerability Give all details on the vulnerability. References to the source code is very helpful for the maintainer. Complete instructions, including specific configuration details, to reproduce the vulnerability What kind of vulnerability is it? Who or what component(s) is impacted? Propose a remediation suggestion if you have one. Make it clear that this is just a suggestion, as the maintainer might have a better idea to fix the issue. List all researchers who contributed to this disclosure. If you found the vulnerability with a specific tool, you can also credit this tool. Provide contact information so we can contact you for any questions or requests for additional information.
Project: Velero (Runtime / Cloud Native Storage)
File: CHANGELOG-0.7.md

- https://github.com/heptio/ark/releases/tag/v0.7.1 Run the Ark server in its own namespace, separate from backups/schedules/restores/config (#322, @ncdc) https://github.com/heptio/ark/releases/tag/v0.7.0 Run the Ark server in any namespace (#272, @ncdc) Add ability to delete backups and their associated data (#252, @skriss) Support both pre and post backup hooks (#243, @ncdc) Switch from Update() to Patch() when updating Ark resources (#241, @skriss) Don't fail the backup if a PVC is not bound to a PV (#256, @skriss) Restore serviceaccounts prior to workload controllers (#258, @ncdc) Stop removing annotations from PVs when restoring them (#263, @skriss) Update GCP client libraries (#249, @skriss) Clarify backup and restore creation messages (#270, @nrb) Update S3 bucket creation docs for us-east-1 (#285, @lypht)
Project: Velero (Runtime / Cloud Native Storage)
File: ark_backup.md

title: "ark backup" layout: docs Work with backups Work with backups ``` -h, --help help for backup ``` ``` --alsologtostderr log to standard error as well as files --kubeconfig string Path to the kubeconfig file to use to talk to the Kubernetes apiserver. If unset, try the environment variable KUBECONFIG, as well as in-cluster configuration --kubecontext string The context to use to talk to the Kubernetes apiserver. If unset defaults to whatever your current-context is (kubectl config current-context) --logbacktraceat traceLocation when logging hits line file:N, emit a stack trace (default :0) --log_dir string If non-empty, write log files in this directory --logtostderr log to standard error instead of files -n, --namespace string The namespace in which Ark should operate (default "heptio-ark") --stderrthreshold severity logs at or above this threshold go to stderr (default 2) -v, --v Level log level for V logs --vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging ``` - Back up and restore Kubernetes cluster resources. - Create a backup - Delete a backup - Describe backups - Download a backup - Get backups - Get backup logs
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> CLI CLI for interacting with the local Cilium Agent ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -h, --help help for cilium-dbg -H, --host string URI to server-side API ``` - Access to BGP control plane - Direct access to local BPF maps - Resolve all of the configuration sources that apply to this node - Cgroup metadata - Output shell completion code - Cilium configuration options - Request available debugging information from agent - Manage transparent encryption - Manage endpoints - Manage fqdn proxy - Manage security identities - Manage IP addresses and associated information - Direct access to the kvstore - Show load information - Manage local redirect policies - Access userspace cached content of BPF maps - Access metric status - Display BPF program events - Manage cluster nodes - List node IDs and associated information - Manage security policies - Remove system state installed by Cilium at runtime - Manage XDP CIDR filters - Cilium upgrade helper - Introspect or mangle pcap recorder - Manage services & loadbalancers - Inspect StateDB - Display status of daemon - Run troubleshooting utilities to check control-plane connectivity - Print version information
Project: Spiderpool (Runtime / Cloud Native Network)
File: PULL_REQUEST_TEMPLATE.md

<!--Before submitting a pull request, make sure you read about our Contribution notice here: <https://spidernet-io.github.io/spiderpool/latest/develop/contributing/>--> <!-- Add one of the following kinds: Required labels: release/none release/bug release/feature Optional labels: kind/bug kind/feature kind/ci-bug kind/doc --> What this PR does / why we need it: Which issue(s) this PR fixes: <!-- *Automatically closes linked issue when PR is merged. Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. --> Fixes # Special notes for your reviewer:
Project: rkt (Runtime / Container Runtime)
File: app-container.md

(appc) is an open specification that defines several aspects of how to run applications in containers: an image format, runtime environment, and discovery protocol. rkt's native and are those defined by the . Note that as of late 2016, appc is . However, appc is fully functional and stable and will continue to be supported. Future versions of rkt might gain . The image format defined by appc and used in rkt is the , or ACI. An ACI is a simple tarball bundle of a rootfs (containing all the files needed to execute an application) and an Image Manifest, which defines things like default execution parameters and default resource constraints. ACIs can be built with tools like , , or . Docker images can be converted to ACI using , although rkt will . Most parameters defined in an image can be overridden at runtime by rkt. For example, the `rkt run` command allows users to supply custom exec arguments to an image. appc defines the as the basic unit of execution. A pod is a grouping of one or more app images (ACIs), with some additional metadata optionally applied to the pod as a whole - for example, a resource constraint can be applied at the pod level and then forms an "outer bound" for all the applications in the pod. The images in a pod execute with a shared context, including networking. A pod in rkt is conceptually identical to a pod . rkt implements the two runtime components of the appc specification: the and the . It also uses schema and code from the upstream repo to manipulate ACIs, work with image and pod manifests, and perform image discovery. To validate that `rkt` successfully implements the ACE part of the spec, use the App Container : ``` --mds-register \ --volume=database,kind=host,source=/tmp \ https://github.com/appc/spec/releases/download/v0.8.11/ace-validator-main.aci \ https://github.com/appc/spec/releases/download/v0.8.11/ace-validator-sidekick.aci ```
Project: Weave Net (Runtime / Cloud Native Network)
File: VENDORED_CODE.md

Weave Net is licensed under the . Some vendored code is under different licenses though, all of them ship the entire license text they are under. https://github.com/weaveworks/go-checkpoint can be found in the ./vendor/ directory, is under MPL-2.0. Pulled in by dependencies are https://github.com/hashicorp/golang-lru (MPL-2.0) https://github.com/hashicorp/go-cleanhttp (MPL-2.0) https://github.com/opencontainers/go-digest (docs are under CC by-sa 4.0) is under LGPL-3, that's why we ship the license text in this repository.
Project: Kata Containers (Runtime / Container Runtime)
File: CpuTopology.md

Name | Type | Description | Notes | - | - | - ThreadsPerCore | Pointer to int32 | | [optional] CoresPerDie | Pointer to int32 | | [optional] DiesPerPackage | Pointer to int32 | | [optional] Packages | Pointer to int32 | | [optional] `func NewCpuTopology() *CpuTopology` NewCpuTopology instantiates a new CpuTopology object This constructor will assign default values to properties that have it defined, and makes sure properties required by API are set, but the set of arguments will change when the set of required properties is changed `func NewCpuTopologyWithDefaults() *CpuTopology` NewCpuTopologyWithDefaults instantiates a new CpuTopology object This constructor will only assign default values to properties that have it defined, but it doesn't guarantee that properties required by API are set `func (o *CpuTopology) GetThreadsPerCore() int32` GetThreadsPerCore returns the ThreadsPerCore field if non-nil, zero value otherwise. `func (o CpuTopology) GetThreadsPerCoreOk() (int32, bool)` GetThreadsPerCoreOk returns a tuple with the ThreadsPerCore field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *CpuTopology) SetThreadsPerCore(v int32)` SetThreadsPerCore sets ThreadsPerCore field to given value. `func (o *CpuTopology) HasThreadsPerCore() bool` HasThreadsPerCore returns a boolean if a field has been set. `func (o *CpuTopology) GetCoresPerDie() int32` GetCoresPerDie returns the CoresPerDie field if non-nil, zero value otherwise. `func (o CpuTopology) GetCoresPerDieOk() (int32, bool)` GetCoresPerDieOk returns a tuple with the CoresPerDie field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *CpuTopology) SetCoresPerDie(v int32)` SetCoresPerDie sets CoresPerDie field to given value. `func (o *CpuTopology) HasCoresPerDie() bool` HasCoresPerDie returns a boolean if a field has been set. `func (o *CpuTopology) GetDiesPerPackage() int32` GetDiesPerPackage returns the DiesPerPackage field if non-nil, zero value otherwise. `func (o CpuTopology) GetDiesPerPackageOk() (int32, bool)` GetDiesPerPackageOk returns a tuple with the DiesPerPackage field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *CpuTopology) SetDiesPerPackage(v int32)` SetDiesPerPackage sets DiesPerPackage field to given value. `func (o *CpuTopology) HasDiesPerPackage() bool` HasDiesPerPackage returns a boolean if a field has been set. `func (o *CpuTopology) GetPackages() int32` GetPackages returns the Packages field if non-nil, zero value otherwise. `func (o CpuTopology) GetPackagesOk() (int32, bool)` GetPackagesOk returns a tuple with the Packages field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *CpuTopology) SetPackages(v int32)` SetPackages sets Packages field to given value. `func (o *CpuTopology) HasPackages() bool` HasPackages returns a boolean if a field has been set.
Project: containerd (Runtime / Container Runtime)
File: 2017-01-20.md

This week we worked on refactoring the storage and runtime aspects of containerd, much of this work won't be completed until next week. @stevvooe started work on a `dist` tool for fetching images and other distribution aspects. One of the problems we wanted to solve with containerd is the ability to decouple the fetch of image contents, the unpacking of the contents, and the storage of the contents. Separating these lets us download content as non-root on machines and only elevate privileges when the contents need to be unpacked on disk. https://github.com/containerd/containerd/pull/452 A large part of my week I have been working on the shim. It is a very core aspect of containerd and allows containers to run without being tied to the lifecycle of the containerd daemon. With this work we will end up with one shim per container that manages all additional processes in the container. This saves resources on the system as well as makes interacting with the shim much easier. We are placing the shim behind a GRPC API instead of the pipe based protocol that we have today. I don't have a PR open at this time but expect something next week. We worked on the build process this week as well as improvements across the codebase. There were 31 commits merged this week from various contributors. Overall, there were no large features hitting master this week. Many of those are still in the works but a lot was done to simplify existing code and reduce complexity where we can.
Project: OpenEBS (Runtime / Cloud Native Storage)
File: git-cheatsheet.md

Fork the repository into your account, referred in the below instructions as $user. ```bash working_dir=$GOPATH/src/github.com/openebs mkdir -p $working_dir cd $working_dir ``` Set `user` to match your Github profile name: for setting global configurations use - git config --global user.name "your usernae here" git config --global user.email "your email used in github account" and for configuring locally use the above commands just remove the --global flag ```bash user={your Github profile name} ``` ```bash git clone https://github.com/$user/openebs.git cd openebs/ git remote add upstream https://github.com/openebs/openebs.git git remote set-url --push upstream no_push git remote -v ``` ```bash git checkout master git fetch upstream master git rebase upstream/master git status git push origin master ``` ```bash git branch <branch_name> git checkout <branch_name> git push --set-upstream origin <branch_name> ``` ```bash git checkout <branch-name> git fetch upstream master git rebase upstream/master git status git push ``` ```bash git add -A git commit -m "creating changes in local repository" git push ``` ```bash git push origin --delete <branch_name> git branch -d <branch_name> ``` Though it is important to write unit tests, do not try to achieve 100% code coverage if it complicates writing these tests. If a unit test is simple to write & understand, most probably it will be extended when new code gets added. However, the reverse will lead to its removal on the whole. In other words, complicated unit tests will lead to decrease in the overall coverage in the long run. OpenEBS being an OpenSource project will always try to experiment with new ideas and concepts. Hence, writing unit tests will provide the necessary checklist that reduces the scope for errors. Go back to .
Project: lxd (Runtime / Container Runtime)
File: incus_alias.md

(incus-alias)= The Incus command-line client supports adding aliases for commands that you use frequently. You can use aliases as shortcuts for longer commands, or to automatically add flags to existing commands. To manage command aliases, you use the command. For example, to always ask for confirmation when deleting an instance, create an alias for `incus delete` that always runs `incus delete -i`: incus alias add delete "delete -i" To see all configured aliases, run . Run to see all available subcommands.
Project: Longhorn (Runtime / Cloud Native Storage)
File: 20221205-concurrent-backup-restore-limit.md

Longhorn has no boundary on the number of concurrent volume backup restoring. Having a new `concurrent-backup-restore-per-node-limit` setting allows the user to limit the concurring backup restoring. Setting this restriction lowers the potential risk of overloading the cluster when volumes restoring from backup concurrently. For ex: during the Longhorn system restore. https://github.com/longhorn/longhorn/issues/4558 Introduce a new `concurrent-backup-restore-per-node-limit` setting to define the boundary of the concurrent volume backup restoring. `None` Introduce a new `concurrent-backup-restore-per-node-limit` setting. Track the number of per-node volumes restoring from backup with atomic count (thread-safe) in the engine monitor. Allow the user to set the concurrent backup restore per node limit to control the risk of cluster overload when Longhorn volume is restoring from backup concurrently. Longhorn holds the engine backup restore when the number of volume backups restoring on a node reaches the `concurrent-backup-restore-per-node-limit`. The volume backup restore continues when the number of volume backups restoring on a node is below the limit. This setting controls how many engines on a node can restore the backup concurrently. Longhorn engine monitor backs off when the volume reaches the setting limit. Set the value to 0 to disable backup restore. ``` Category = SettingCategoryGeneral, Type = integer Default = 5 # same as the default replica rebuilding number ``` Create a new atomic counter in the engine controller. ``` type EngineController struct { restoringCounter util.Counter } ``` Pass the restoring counter to each of its engine monitors. ``` type EngineMonitor struct { restoringCounter util.Counter } ``` Increase the restoring counter before backup restore. > Ignore DR volumes (volume.Status.IsStandby). Decrease the restoring counter when the backup restore caller method ends Test the setting should block backup restore when creating multiple volumes from the backup at the same time. Test the setting should be per-node limited. Test the setting should not have effect on DR volumes. `None` `None`