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

The results of metadata performance testing through are as follows: tool settings ``` bash TEST_PATH=/mnt/cfs/mdtest # mount point of CubeFS volume for CLIENTS in 1 2 4 8 # number of clients do mpirun --allow-run-as-root -np $CLIENTS --hostfile hfile01 mdtest -n 5000 -u -z 2 -i 3 -d $TEST_PATH; done ``` | | 1 Process | 4 Processes | 16 Processes | 64 Processes | |--|--|-|--|--| | 1 Client | 769.908 | 3630.337 | 12777.619 | 20629.592 | | 2 Clients | 1713.038 | 7259.282 | 24064.052 | 36769.599 | | 4 Clients | 3723.993 | 14002.366 | 42976.837 | 61513.648 | | 8 Clients | 6681.783 | 23946.143 | 64191.38 | 93729.222 | | | 1 Process | 4 Processes | 16 Processes | 64 Processes | |--|--|-|--|--| | 1 Client | 853.995 | 4012.404 | 15238.647 | 42028.845 | | 2 Clients | 1906.261 | 7967.688 | 28410.308 | 62338.506 | | 4 Clients | 3942.590 | 15601.799 | 46741.945 | 87411.655 | | 8 Clients | 7072.080 | 25183.092 | 69054.923 | 79459.091 | | | 1 Process | 4 Processes | 16 Processes | 64 Processes | |--|-|-|--|--| | 1 Client | 462527.445 | 1736760.332 | 6194206.768 | 15509755.836 | | 2 Clients | 885454.335 | 3414538.352 | 12263175.104 | 24951003.498 | | 4 Clients | 1727030.782 | 6874284.765 | 24371306.250 | 10412238.894 | | 8 Clients | 1897588.214 | 7499219.744 | 25927923.646 | 4264896.279 | | | 1 Process | 4 Processes | 16 Processes | 64 Processes | |--|--|-|--|--| | 1 Client | 706.453 | 3306.270 | 9647.176 | 10879.290 | | 2 Clients | 1601.891 | 6601.522 | 19181.965 | 20756.693 | | 4 Clients | 3369.911 | 13165.056 | 36158.061 | 41817.753 | | 8 Clients | 6312.911 | 22560.687 | 55801.062 | 76157.675 | | | 1 Process | 4 Processes | 16 Processes | 64 Processes | |--|--|-|--|--| | 1 Client | 1220.322 | 4606.340 | 11715.457 | 23653.043 | | 2 Clients | 2360.133 | 8971.361 | 22097.206 | 41579.985 | | 4 Clients | 4547.021 | 17242.900 | 34965.471 | 61726.902 | | 8 Clients | 8809.381 | 20379.839 | 55363.389 | 71101.736 | | | 1 Process | 4 Processes | 16 Processes | 64 Processes | |--|--|-|--|--| | 1 Client | 734.383 | 379.403 | 146.070 | 37.811 | | 2 Clients | 648.938 | 432.150 | 148.921 | 30.699 | | 4 Clients | 756.639 | 394.733 | 123.722 | 23.998 | | 8 Clients | 607.547 | 263.439 | 124.911 | 7.510 | | | 1 Process | 4 Processes | 16 Processes | 64 Processes | |--|--|-|--|--| | 1 Client | 552.706 | 83.197 | 23.823 | 5.747 | | 2 Clients | 448.557 | 84.633 | 24.037 | 5.137 | | 4 Clients | 453.520 | 85.636 | 23.490 | 5.233 | | 8 Clients | 429.920 | 83.449 | 23.777 | 1.667 |
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_policy.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage security policies ``` -h, --help help for policy ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI - Delete policy rules - Display policy node information - Import security policy in JSON format - Display cached information about selectors - Validate a policy - Wait for all endpoints to have updated to a given policy revision
Project: OpenEBS (Runtime / Cloud Native Storage)
File: code-structuring.md

Every project has certain philosophical conundrums, that its contributors have to grapple with. These may sound very straightforward at onset, but you know they go deeper when the same question keeps coming back. Following are some such conundrums and our current stand on it. As most philosophical answers start, the answer is "it depends". But here are some general guidelines. If the functionality is a straightforward extension of current functionality, like adding new API to or support for new CO, use the existing repository. If the functionality is experimental/poc/exploratory and you would like to seek feedback from the OpenEBS community, you can put it under . If the functionality has been accepted to make it into a release, but requires some work to make it part of existing repository like - , or , put it into a new repository, till it gets cooked. Typical examples are - when the functionality has to be packaged into its own container or runs as an independent service etc,. Follow the principles listed by There are several different ways in which Go projects are structured out there - for instance from (using a single repository for multiple binaries) to (with single binary - that acts as both cli, client, and server), and (with somewhere in between). With these choices, it also becomes difficult to pick a path forward, especially with the language that is strongly opinionated. After having tried a few ways, the current stance stands as follows: pkg will contain the utility packages (homegrown or wrappers around other libraries - like log helpers, network helpers etc.,) types that are defined as high level structs without dependency on any other types. These can be used for interacting with other systems (outside this repository) or between apps in this repository. internal will contain the first class citizens of the product - or what were called the main objects on which CRUDs are performed. cmd will contain the binaries (main package) or multiple applications, which will delegate the heavy lifting to their corresponding apps. The pkg and types are intentionally kept at the top level, in case they need to be moved their own repositories in the future. The order of the listing also roughly determines the dependencies or the import rules. For example, packages in cmd can import anything from above packages but not vice-versa.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-azure_metrics_list.md

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> List all metrics for the operator ``` cilium-operator-azure 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: CubeFS (Runtime / Cloud Native Storage)
File: nodeset.md

```bash cfs-cli nodeset list ``` ```bash cfs-cli nodeset info [NODESET ID] ``` ```bash cfs-cli nodeset update [NODESET ID] [flags] ``` ```bash Flags: --dataNodeSelector string Set the node select policy(datanode) for specify nodeset -h, --help help for update --metaNodeSelector string Set the node select policy(metanode) for specify nodeset ```
Project: StratoVirt (Runtime / Container Runtime)
File: build_guide.md

To build StratoVirt, make sure that Rust language environment and Cargo have already been installed. The recommended version of rustc is 1.64.0 or later, otherwise compilation may be failed. ```shell $ rustc --version rustc 1.64.0 ``` If you want to deploy rust environment, the following link will help you: <https://www.rust-lang.org/tools/install> With glibc, StratoVirt is linked dynamically. It's the default target to build StratoVirt. ```shell $ arch=`uname -m` $ rustup target add ${arch}-unknown-linux-gnu $ cargo build --workspace --bins --release --target ${arch}-unknown-linux-gnu ``` Now you can find StratoVirt binary file in `target/${arch}-unknown-linux-gnu/release/stratovirt`. StratoVirt can also be built using musl-libc toolchains. By this way, StratoVirt is linked statically and has no library dependencies. ```shell $ arch=`uname -m` $ rustup target add ${arch}-unknown-linux-musl $ cargo build --workspace --bins --release --target ${arch}-unknown-linux-musl ``` Now you can find StratoVirt static binary file in `target/${arch}-unknown-linux-musl/release/stratovirt`. For different scenarios, StratoVirt provides feature conditional compilation options based on the cargo `feature`. List of optional features: scream_alsa: enable virtual sound card with `ALSA` interface scream_pulseaudio: enable virtual sound card with `PulseAudio` interface usb_host: enable USB Host device usbcamerav4l2: enable USB camera with `v4l2` backend gtk: enable GTK display vnc: enable VNC display ramfb: enable ramfb display device virtio_gpu: enable virtio-gpu virtualized graphics card pvpanic: enable virtualized pvpanic pci device ```shell $ cargo build --workspace --bins --release --features "scream_alsa" ``` Stratovirt now can run on OpenHarmony OS(OHOS). Stratovirt, OHOS version, is compiled on x64, and relies on RUST cross compilation toolchain and SDK offered by OHOS. Before compiling, specify OHOS SDK path in environment variable OHOS_SDK. Some crates needed by StratoVirt now are not support OHOS platform, adapting is essential. Here is a command demo: ``` RUSTFLAGS="-C link-arg=--target=aarch64-linux-ohos -C linker={OHOS_SDK}/llvm/bin/clang" cargo build --target aarch64-linux-ohos --features {FEATURES}" ``` In order to build StratoVirt in containers, ensure that the docker software is installed. This can be checked with the following command: ```shell $ docker -v Docker version 18.09.0 ``` If you want to deploy a docker environment, the following link can help you: <https://docs.docker.com/get-docker/> Run the script under tools/buildstratovirtstatic directory to automatically run a docker container to build a statically linked StratoVirt. ```shell $ cd tools/buildstratovirtstatic $ sh buildstratovirtfromdocker.sh customimage_name ``` After the build is complete, you can find the statically linked binary StratoVirt in the path: `target/${arch}-unknown-linux-musl/release/stratovirt`.
Project: Project Calico (Runtime / Cloud Native Network)
File: dns-srv-records.md

SRV records can be used to declare the backend nodes; just use the `-srv-domain` flag. ``` dig SRV etcd.tcp.confd.io ``` ``` ... ;; ANSWER SECTION: etcd.tcp.confd.io. 300 IN SRV 1 100 4001 etcd.confd.io. ``` ``` confd -backend etcd -srv-domain confd.io ``` ``` dig SRV consul.tcp.confd.io ``` ``` ... ;; ANSWER SECTION: consul.tcp.confd.io. 300 IN SRV 1 100 8500 consul.confd.io. ``` ``` confd -backend consul -srv-domain confd.io ``` By default the `scheme` is set to http; change it with the `-scheme` flag. ``` confd -scheme https -srv-domain confd.io ``` Both the SRV domain and scheme can be configured in the confd configuration file. See the for more details.
Project: Cilium (Runtime / Cloud Native Network)
File: VERSIONING.md

We follow the , and use the corresponding tooling. For the purposes of the aforementioned guidelines, controller-runtime counts as a "library project", but otherwise follows the guidelines exactly. For release branches, we generally tend to support backporting one (1) major release (`release-{X-1}` or `release-0.{Y-1}`), but may go back further if the need arises and is very pressing (e.g. security updates). Note the . Particularly: We DO guarantee Kubernetes REST API compatibility -- if a given version of controller-runtime stops working with what should be a supported version of Kubernetes, this is almost certainly a bug. We DO NOT guarantee any particular compatibility matrix between kubernetes library dependencies (client-go, apimachinery, etc); Such compatibility is infeasible due to the way those libraries are versioned.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_multicast_group.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage the multicast groups. ``` -h, --help help for group ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage multicast BPF programs - Add a multicast group. - Delete a multicast group. - List the multicast groups.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-agent_completion_zsh.md

<!-- This file was autogenerated via cilium-agent --cmdref, do not edit manually--> Generate the autocompletion script for zsh Generate the autocompletion script for the zsh shell. If shell completion is not already enabled in your environment you will need to enable it. You can execute the following once: echo "autoload -U compinit; compinit" >> ~/.zshrc To load completions in your current shell session: source <(cilium-agent completion zsh) To load completions for every new session, execute once: cilium-agent completion zsh > "${fpath[1]}/_cilium-agent" cilium-agent completion zsh > $(brew --prefix)/share/zsh/site-functions/_cilium-agent You will need to start a new shell for this setup to take effect. ``` cilium-agent completion zsh [flags] ``` ``` -h, --help help for zsh --no-descriptions disable completion descriptions ``` - Generate the autocompletion script for the specified shell
Project: Inclavare Containers (Runtime / Container Runtime)
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: Velero (Runtime / Cloud Native Storage)
File: plugins.md

title: "Plugins" layout: docs Velero has a plugin architecture that allows users to add their own custom functionality to Velero backups & restores without having to modify/recompile the core Velero binary. To add custom functionality, users simply create their own binary containing implementations of Velero's plugin kinds (described below), plus a small amount of boilerplate code to expose the plugin implementations to Velero. This binary is added to a container image that serves as an init container for the Velero server pod and copies the binary into a shared emptyDir volume for the Velero server to access. Multiple plugins, of any type, can be implemented in this binary. A fully-functional is provided to serve as a convenient starting point for plugin authors. When naming your plugin, keep in mind that the name needs to conform to these rules: have two parts separated by '/' none of the above parts can be empty the prefix is a valid DNS subdomain name a plugin with the same name cannot already exist ``` example.io/azure 1.2.3.4/5678 example-with-dash.io/azure ``` You will need to give your plugin(s) a name when registering them by calling the appropriate `RegisterX` function: <https://github.com/vmware-tanzu/velero/blob/0e0f357cef7cf15d4c1d291d3caafff2eeb69c1e/pkg/plugin/framework/server.go#L42-L60> Velero currently supports the following kinds of plugins: Object Store - persists and retrieves backups, backup logs and restore logs Volume Snapshotter - creates volume snapshots (during backup) and restores volumes from snapshots (during restore) Backup Item Action - executes arbitrary logic for individual items prior to storing them in a backup file Restore Item Action - executes arbitrary logic for individual items prior to restoring them into a cluster Velero provides a that can be used by plugins to log structured information to the main Velero server log or per-backup/restore logs. It also passes a `--log-level` flag to each plugin binary, whose value is the value of the same flag from the main Velero process. This means that if you turn on debug logging for the Velero server via `--log-level=debug`, plugins will also emit debug-level logs. See the for an example of how to use the logger within your plugin. Velero uses a ConfigMap-based convention for providing configuration to plugins. If your plugin needs to be configured at runtime, define a ConfigMap like the following: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: my-plugin-config namespace: velero labels: velero.io/plugin-config: "" <fully-qualified-plugin-name>: <plugin-type> data: ``` Then, in your plugin's implementation, you can read this ConfigMap to fetch the necessary configuration. See the for an example of this -- in particular, the `getPluginConfig(...)` function.
Project: Antrea (Runtime / Cloud Native Network)
File: updating-ovs-windows.md

Antrea ships a zip archive with OVS binaries for Windows. The binaries are hosted on the antrea.io website and updated as needed. This file documents the procedure to upload a new version of the OVS binaries. The archive is served from AWS S3, and therefore access to the Antrea S3 account is required for this procedure. We assume that you have already built the OVS binaries (if a custom built is required), or retrieved them from the official OVS build pipelines. The binaries must be built in Release mode for acceptable performance. Name the zip archive appropriately: `ovs-<OVS VERSION>[-antrea.<BUILD NUM>]-win64.zip` the format for `<OVS VERSION>` is `<MAJOR>.<MINOR>.<PATCH>`, with no `v` prefix. the `-antrea.<BUILD NUM>` component is optional but must be provided if this is not the official build for the referenced OVS version. `<BUILD NUM>` starts at 1 and is incremented for every new upload corresponding to that OVS version. Generate the SHA256 checksum for the archive. place yourself in the directory containing the archive. run `sha256sum -b <NAME>.zip > <NAME>.zip.sha256`, where `<NAME>` is determined by the previous step. Upload the archive and SHA256 checksum file to the `ovs/` folder in the `downloads.antrea.io` S3 bucket. As you upload the files, grant public read access to them (you can also do it after the upload with the `Make public` action). Validate both public links: `https://downloads.antrea.io/ovs/<NAME>.zip` `https://downloads.antrea.io/ovs/<NAME>.zip.sha256` Update the Antrea Windows documentation and helper scripts as needed, e.g. `hack/windows/Install-OVS.ps1`.
Project: Kata Containers (Runtime / Container Runtime)
File: upcall.md

`Upcall` is a direct communication tool between VMM and guest developed upon `vsock`. The server side of the `upcall` is a driver in guest kernel (kernel patches are needed for this feature) and it'll start to serve the requests after the kernel starts. And the client side is in Dragonball VMM , it'll be a thread that communicates with `vsock` through `uds`. We want to keep the lightweight of the VM through the implementation of the `upcall`. We define specific operations in the device manager service (one of the services in `upcall` we developed) to perform device hotplug / hot-unplug including vCPU hotplug, `virtio-mmio` hotplug, and memory hotplug. We have accomplished device hotplug / hot-unplug directly through `upcall` in order to avoid the virtualization of ACPI to minimize virtual machines overhead. And there could be many other uses if other services are implemented. `Upcall` needs a server in the guest kernel which will be several kernel patches for the `upcall` server itself and different services registered in the `upcall` server. It's currently tested on upstream Linux kernel 5.10. To make it easy for users to use, we have open-source the `upcall` guest patches in and develop `upcall` support in . You could use following command to download the upstream kernel (currently Dragonball uses 5.10.25) and put the `upcall` patches and other Kata patches into kernel code. `sh build-kernel.sh -e -t dragonball -f setup` `-e` here means experimental, mainly because `upcall` patches are not in upstream Linux kernel. `-t dragonball` is for specifying hypervisor type `-f` is for generating `.config` file After this command, the kernel code with `upcall` and related `.config` file are all set up in the directory `kata-linux-dragonball-experimental-5.10.25- to build and use this guest kernel. Also, a client-side is also needed in VMM. Dragonball has already open-source the way to implement `upcall` client and Dragonball compiled with `dbs-upcall` feature will enable Dragonball client side.