cwielenb/CNCF-Dataset huggingface dataset:
Project: SmartOS (Runtime / Container Runtime)
File: vminfo.8.md

vminfo <SUBCOMMAND> [OPTIONS] `vminfo(8)` is a tool to interface with the `vminfod` service on a machine using the exposed HTTP interface. It can be used for administrators to determine service level health and status. help Print a help message and exit. ping Ping the server (GET /ping) and return the output with the appropriate exit status code set. status [-j] [-f] Show server status (GET /status). Supply `-f` for "full" output (more internal details about vminfod's state) and `-j` for JSON output. vms Return a JSON array of all VMs known by vminfod (GET /vms). To use this programatically prefer `vmadm lookp -j`. vm [uuid] Return a JSON object for the VM uuid given known by vminfod (GET /vms/:uuid). To use this programatically prefer `vmadm get :uuid`. events Connect to the events stream (GET /events) and print events as they come in. To use this programatically prefer `vmadm events`. `vminfo ping` Check if the service is up. `vminfo status -f` Print full status. This tool should be used for interactive output only, and is not meant to provide a stable interface to use for vminfod. If you are trying to interface with `vminfod` use the `vmadm(8)` command (especially `vmadm events`) and, for internal platform code, the `vminfod/client` Node.js library.
Project: lxd (Runtime / Container Runtime)
File: image_servers.md

(image-servers)= The CLI command comes pre-configured with the following default remote image server: `images:` : This server provides unofficial images for a variety of Linux distributions. The images are maintained by the team and are built to be compact and minimal. See for an overview of available images. Additional image servers can be added through `incus remote add`. (image-server-types)= Incus supports the following types of remote image servers: Simple streams servers : Pure image servers that use the . No special software is required to run such a server as it's only made of static files. The default `images:` server uses simplestreams. Public Incus servers : Incus servers that are used solely to serve images and do not run instances themselves. To make an Incus server publicly available over the network on port 8443, set the {config:option}`server-core:core.https_address` configuration option to `:8443` and do not configure any authentication methods (see {ref}`server-expose` for more information). Then set the images that you want to share to `public`. Incus servers : Regular Incus servers that you can manage over a network, and that can also be used as image servers. For security reasons, you should restrict the access to the remote API and configure an authentication method to control access. See {ref}`server-expose` and {ref}`authentication` for more information. (image-server-tooling)= Incus includes a tool called `incus-simplestreams` which can be used to manage a file system tree using the Simple streams format. It supports importing either a container (`squashfs`) or virtual-machine (`qcow2`) image with `incus-simplestreams add`, list all images available as well as their fingerprints with `incus-simplestreams list` and remove images from the server with `incus-simplestreams remove`. That file system tree must then be placed on a regular web server which supports HTTPS with a valid certificate. When importing an image that doesn't come with an Incus metadata tarball, the `incus-simplestreams generate-metadata` command can be used to generate a new basic metadata tarball from a few questions.
Project: CubeFS (Runtime / Cloud Native Storage)
File: meta-partition.md

``` bash curl -v "http://10.196.59.198:17010/metaPartition/create?name=test&start=10000" ``` Manually splits the metadata shard. If the maximum metadata shard inode range of the volume is `[begin, end)`: If start is greater than begin and less than end, the inode range of the original maximum metadata shard becomes `[begin, start]`, and the range of the newly created metadata shard is `[start+1,+inf)`. If start is less than begin, max is the maximum inode number on the current shard, and the inode range becomes `[begin, max+16777216]`, and the range of the newly created metadata shard is `[max+16777217,+inf)`. If start is greater than end, max is the maximum inode number on the current shard, and the inode range becomes `[begin, start]`, and the range of the newly created metadata shard is `[start+1, +inf)`. ::: warning Note A large start value will cause a large inode on a single shard, occupying a large amount of memory. When there are too many inodes on the last shard, automatic splitting of the metadata partition will also be triggered. ::: Parameter List | Parameter | Type | Description | |--|--|-| | name | string | Volume name | | start | uint64 | Split the metadata shard based on this value | ``` bash curl -v "http://10.196.59.198:17010/metaPartition/get?id=1" | python -m json.tool ``` Displays detailed information about the metadata shard, including the shard ID, the starting range of the shard, etc. Parameter List | Parameter | Type | Description | |--|--|-| | id | uint64 | Metadata shard ID | Response Example ``` json { "PartitionID": 1, "Start": 0, "End": 9223372036854776000, "MaxNodeID": 1, "VolName": "test", "Replicas": {}, "ReplicaNum": 3, "Status": 2, "IsRecover": true, "Hosts": {}, "Peers": {}, "Zones": {}, "MissNodes": {}, "LoadResponse": {} } ``` ``` bash curl -v "http://10.196.59.198:17010/metaPartition/decommission?id=13&addr=10.196.59.202:17210" ``` Removes a replica of the metadata shard and creates a new replica. Parameter List | Parameter | Type | Description | |--|--|--| | id | uint64 | Metadata partition ID | | addr | string | Address of the replica to be removed | ``` bash curl -v "http://10.196.59.198:17010/metaPartition/load?id=1" ``` Sends a task to compare the replica to each replica, and then checks whether the CRC of each replica is consistent. Parameter List | Parameter | Type | Description | |--|--|--| | id | uint64 | Metadata partition ID |
Project: Cilium (Runtime / Cloud Native Network)
File: MAINTAINERS.md

This page lists all active maintainers of this repository. If you were a maintainer and would like to add your name to the Emeritus list, please send us a PR. See for governance guidelines and how to become a maintainer. See for general contribution guidelines. , Datadog, Inc. , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_endpoint_disconnect.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Disconnect an endpoint from the network ``` cilium-dbg endpoint disconnect <endpoint-id> [flags] ``` ``` -h, --help help for disconnect ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage endpoints
Project: Multus (Runtime / Cloud Native Network)
File: CONTRIBUTING.md

Welcome to Kubernetes. We are excited about the prospect of you joining our ! The Kubernetes community abides by the CNCF . Here is an excerpt: As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. We have full documentation on how to get started contributing here: <! If your repo has certain guidelines for contribution, put them here ahead of the general k8s resources --> Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests - Main contributor documentation, or you can just jump directly to the - Common resources for existing developers - We have a diverse set of mentorship programs available that are always looking for volunteers! <! Custom Information - if you're copying this template for the first time you can add custom content here, for example: - Replace `kubernetes-users` with your slack channel string, this will send users directly to your channel. --> ontributor-cheatsheet) - Common resources for existing developers You can reach the maintainers of this project via the . - We have a diverse set of mentorship programs available that are always looking for volunteers!
Project: CubeFS (Runtime / Cloud Native Storage)
File: atomicity.md

CubeFS supports atomic operation. After turning on the atomic function, the metadata atomicity of the file operation is met, and the metadata uses the final consistency, that is, the metadata modification of the file operation is ether successfully committed, or rolled back. Create Mkdir Remove Rename Mknod Symlink Link ::: tip tip Atomicity supports the Fuse interface, and S3 interface is not supported for now. ::: CubeFS implements part of the characteristics of transaction, but it is different from the traditional strict sense of transaction. For the convenience, the operation of files is referred to as transaction. The transaction is effective in the volume, and a cluster can have multiple volumes. Each volume can switch on or off transaction separately. The client get configuration of transaction from the master when started. The switch can control all supported interfaces, or only open some interfaces, the default transaction time out is 1 minute. ``` curl "192.168.0.11:17010/vol/update?name=ltptest&enableTxMask=all&txForceReset=true&txConflictRetryNum=13&txConflictRetryInterval=30&txTimeout=1&authKey=0e20229116d5a9a4a9e876806b514a85" ``` ::: tip tip After modifying the parameter of the transaction, new config will be synchronized from Master within 2 minutes. ::: | Parameters | Type | Description | |-|--|-| | enableTxMask | String | Value can be: Create, MKDIR, Remove, RENAME, MKNod, Symlink, Link, off, all. off and all and other values are mutually exclusive | | txtimeout | uint32 | the default transaction time out is 1 minute, the maximum 60 minutes | | txForceReset | bool | The difference from enableTxMask is that value of enableTxMask will be merged, and txForceReset is forced to reset to the specified value | | txConflictRetryNum | uint32 | Value range [1-100], defaults to 10 | | txConflictRetryInterval | uint32 | Unit: milliseconds, the range of value [10-1000], the default is 20ms | You can check transaction config by getting the volume information ``` curl "192.168.0.11:17010/admin/getvol?name=ltptest" ``` You can also specify transaction parameters when creating the volume ``` curl "192.168.0.11:17010/admin/createVol?name=test&capacity=100&owner=cfs&mpCount=3&enableTxMask=all&txTimeout=5" ```
Project: Multus (Runtime / Cloud Native Network)
File: RELEASE.md

The `yaml` Project is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
Project: Kata Containers (Runtime / Container Runtime)
File: core-scheduling.md

Core scheduling is a Linux kernel feature that allows only trusted tasks to run concurrently on CPUs sharing compute resources (for example, hyper-threads on a core). Containerd versions >= 1.6.4 leverage this to treat all of the processes associated with a given pod or container to be a single group of trusted tasks. To indicate this should be carried out, containerd sets the `SCHED_CORE` environment variable for each shim it spawns. When this is set, the Kata Containers shim implementation uses the `prctl` syscall to create a new core scheduling domain for the shim process itself as well as future VMM processes it will start. For more details on the core scheduling feature, see the .
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_config_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List all runtime config entries List all runtime config entries ``` cilium-dbg bpf config list [flags] ``` ``` -h, --help help for list -o, --output string json| yaml| jsonpath='{}' ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage runtime config
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_lb_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List load-balancing configuration ``` cilium-dbg bpf lb list [flags] ``` ``` --backends List all service backend entries --frontends List all service frontend entries -h, --help help for list -o, --output string json| yaml| jsonpath='{}' --revnat List reverse NAT entries --source-ranges List all source range entries ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Load-balancing configuration
Project: Alluxio (Runtime / Cloud Native Storage)
File: Design-Document-Template.md

Design Title: Authors: Date: This section explains the motivation of the work, providing the status quo and the problems associated with it. This section also proposes the high level solution to the problem. This section explains the detailed goals and minimum requirements for the design. It should also include any non-goals of the design which would be expected from a reader. This also includes some high level functionality or performance gains. This section explains the use cases which will be enabled by the implementation of this design. This section should be from the perspective of a user and how they would be able to interact with the feature described. This section explains the high level changes proposed to achieve the design. Changes should be grouped by project components or in another logical way which makes the design easy to follow. If applicable, the design should be broken down into separate phases which each delivers incremental value. The first phase should achieve the minimum requirements outlined in the goals. If applicable, alternative approaches should be noted and evaluated for different sections of the design. This is a section detailing any user facing or internal APIs added to components, including configuration changes. Any changes to user facing components are mentioned here (ie. WebUI, command line). If no changes are made, it should be stated in this section. Changes should be formatted in a reader friendly manner. This section explains any compatibility assumptions or limitations. This section also analyzes any dependency changes (ie. pom file changes). In particular, the addition of new external libraries should be justified. This section explains any security considerations which must be taken into account. If there are no security implications, it should be stated explicitly here. This is an OPTIONAL and possibly REPEATED section which dives into a specific implementation detail in the design. Diagrams, code snippets, and other figures are encouraged. This section explains the various failure cases which the design must tolerate as well as failure cases the design neglects to address. Each failure should be noted with the expected behavior as well as ideal behavior, and if different, what effort is required to bridge the gap. This section should also outline any potential risks due to the implementation of this design such as performance loss, undesired behavior, and system instability. This section details the tests which will be added to ensure the quality and maintainability of the implementation. Unit tests should be added under the corresponding Alluxio module. Integration tests should be added to alluxio/tests module. System tests performed manually can be mentioned in the PR. In addition, any new functionality to support testing should be noted. This section covers the schedule of the design, implementation and testing phases. This will help us estimate the complete time of the feature and align with releases.
Project: Rook (Runtime / Cloud Native Storage)
File: release-cycle.md

Rook plans to release a new minor version three times a year, or about every four months. The most recent two minor Rook releases are actively maintained. Patch releases for the latest minor release are typically bi-weekly. Urgent patches may be released sooner. Patch releases for the previous minor release are commonly monthly, though will vary depending on the urgency of fixes. The Rook community defines maintenance in that relevant bug fixes that are merged to the main development branch will be eligible to be back-ported to the release branch of any currently maintained version. Patches will be released as needed. It is also possible that a fix may be merged directly to the release branch if no longer applicable on the main development branch. While Rook maintainers make significant efforts to release urgent issues in a timely manner, maintenance does not indicate any SLA on response time. The minimum version supported by a Rook release is specified in the . Rook expects to support the most recent six versions of Kubernetes. While these K8s versions may not all be supported by the K8s release cycle, we understand that clusters may take time to update.
Project: runc (Runtime / Container Runtime)
File: spec-conformance.md

This branch of runc implements the for the `linux` platform. The following features are not implemented yet: Spec version | Feature | PR -||- v1.1.0 | `SECCOMPFILTERFLAGWAITKILLABLE_RECV` | The following architectures are supported: runc binary | seccomp -|- `amd64` | `SCMPARCHX86`, `SCMPARCHX8664`, `SCMPARCH_X32` `arm64` | `SCMPARCHARM`, `SCMPARCHAARCH64` `armel` | `SCMPARCHARM` `armhf` | `SCMPARCHARM` `ppc64le` | `SCMPARCHPPC64LE` `riscv64` | `SCMPARCHRISCV64` `s390x` | `SCMPARCHS390`, `SCMPARCHS390X` The runc binary might be compilable for i386, big-endian PPC64, and several MIPS variants too, but these architectures are not officially supported.
Project: StratoVirt (Runtime / Container Runtime)
File: design.md

StratoVirt is an open-source lightweight virtualization technology based on Linux Kernel-based Virtual Machine(KVM), which reduces memory resource consumption and improves VM startup speed while retains isolation capability and security capability of traditional virtualization. StratoVirt can be applied to microservices or serverless scenarios such as function computing, and reserves interface and design for importing more features, even standard virtualization. The following figure shows StratoVirt's core architecture which consist of three layers from top to bottom. External API: StratoVirt uses the QMP protocol to communicate with external systems and is compatible with OCI. Meanwhile, StratoVirt can be managed by libvirt too. BootLoader: abandon the traditional BIOS+GRUB boot mode to achieve fast boot in lightweight scenarios, and provide UEFI boot support for standard VM. Emulated mainboard: microvm: To improve performance as well as reduce the attack surface, StratoVirt minimizes the simulation of user-mode devices. KVM simulation devices and paravirtualization devices, such as GIC, serial, RTC and virtio-mmio devices are implemented; standard VM: realize UEFI boot with constructed ACPI tables. Virtio-pci and VFIO devices can be attached to greatly improve the I/O performance; High isolation ability based on hardware; Fast cold boot: Benefit from the minimalist design, microvm can be started within 50ms; Low memory overhead: StratoVirt works with a memory footprint at 4MB; IO enhancement: StratoVirt offers normal IO ability with minimalist IO device emulation; OCI compatibility: StratoVirt works with isula and kata container, and can be integrated in Kubernetes ecosystem perfectly; Multi-platform support: Fully support for Intel and Arm platform; Expansibility: StratoVirt reserves interface and design for importing more features, even expand to standard virtualization support; Security: less than 55 syscalls while running; StratoVirt VM is an independent process in Linux. The process has three types of threads: main thread, VCPU thread and I/O thread: The main thread is a cycle for asynchronous collecting and processing events from external modules, such as a VCPU thread; Each VCPU has a thread to process trap events of this VCPU; Iothreads can be configured for I/O devices to improve I/O performance; Only the Linux operating system is supported; The recommended kernel version is 4.19; Only Linux is supported as the client operating system, and the recommended kernel version is 4.19; StratoVirt is fully tested on openEuler; Supports a maximum of 254 CPUs;
Project: lxd (Runtime / Container Runtime)
File: instance_units.md

(instances-limit-units)= Any value that represents bytes or bits can make use of a number of suffixes to make it easier to understand what a particular limit is. Both decimal and binary (kibi) units are supported, with the latter mostly making sense for storage limits. The full list of bit suffixes currently supported is: bit (1) kbit (1000) Mbit (1000^2) Gbit (1000^3) Tbit (1000^4) Pbit (1000^5) Ebit (1000^6) Kibit (1024) Mibit (1024^2) Gibit (1024^3) Tibit (1024^4) Pibit (1024^5) Eibit (1024^6) The full list of byte suffixes currently supported is: B or bytes (1) kB (1000) MB (1000^2) GB (1000^3) TB (1000^4) PB (1000^5) EB (1000^6) KiB (1024) MiB (1024^2) GiB (1024^3) TiB (1024^4) PiB (1024^5) EiB (1024^6)
Project: Kata Containers (Runtime / Container Runtime)
File: storage.md

Kata Containers is with existing standards and runtime. From the perspective of storage, this means no limits are placed on the amount of storage a container may use. Since cgroups are not able to set limits on storage allocation, if you wish to constrain the amount of storage a container uses, consider using an existing facility such as `quota(1)` limits or limits. If a block-based graph driver is , `virtio-scsi` is used to share the workload image (such as `busybox:latest`) into the container's environment inside the VM. If a block-based graph driver is not , a (`VIRTIO`) overlay filesystem mount point is used to share the workload image instead. The uses this mount point as the root filesystem for the container processes. For virtio-fs, the starts one `virtiofsd` daemon (that runs in the host context) for each VM created. The is a special case. The `snapshotter` uses dedicated block devices rather than formatted filesystems, and operates at the block level rather than the file level. This knowledge is used to directly use the underlying block device instead of the overlay file system for the container root file system. The block device maps to the top read-write layer for the overlay. This approach gives much better I/O performance compared to using `virtio-fs` to share the container file system. Kata Containers has the ability to hot plug add and hot plug remove block devices. This makes it possible to use block devices for containers started after the VM has been launched. Users can check to see if the container uses the `devicemapper` block device as its rootfs by calling `mount(8)` within the container. If the `devicemapper` block device is used, the root filesystem (`/`) will be mounted from `/dev/vda`. Users can disable direct mounting of the underlying block device through the runtime .
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_endpoint_delete.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Delete local endpoint entries ``` cilium-dbg bpf endpoint delete [flags] ``` ``` -h, --help help for delete ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Local endpoint map