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

| Name | Type | Description | Required | |:|:--|:|:-| | mountPoint | string | Mount point | Yes | | volName | string | Volume name | Yes | | owner | string | Owner | Yes | | masterAddr | string | Master node address | Yes | | logDir | string | Log directory | No | | logLevel | string | Log level: debug, info, warn, error | No | | profPort | string | Golang pprof debug port | No | | exporterPort | string | Prometheus monitoring data port | No | | consulAddr | string | Monitoring registration server address | No | | lookupValid | string | Kernel FUSE lookup validity period, in seconds | No | | attrValid | string | Kernel FUSE attribute validity period, in seconds | No | | icacheTimeout | string | Client inode cache validity period, in seconds | No | | enSyncWrite | string | Enable DirectIO synchronous write, i.e., force data node to write to disk with DirectIO | No | | autoInvalData | string | Use the AutoInvalData option for FUSE mount | No | | rdonly | bool | Mount in read-only mode, default is false | No | | writecache | bool | Use the write cache function of kernel FUSE module, requires kernel FUSE module support for write cache, default is false | No | | keepcache | bool | Keep kernel page cache. This function requires the writecache option to be enabled, default is false | No | | token | string | If enableToken is enabled when creating a volume, fill in the token corresponding to the permission | No | | readRate | int | Limit the number of reads per second, default is unlimited | No | | writeRate | int | Limit the number of writes per second, default is unlimited | No | | followerRead | bool | Read data from follower, default is false | No | | accessKey | string | Authentication key of the user to whom the volume belongs | No | | secretKey | string | Authentication key of the user to whom the volume belongs | No | | disableDcache | bool | Disable Dentry cache, default is false | No | | subdir | string | Set subdirectory mount | No | | fsyncOnClose | bool | Perform fsync operation after file is closed, default is true | No | | maxcpus | int | Maximum number of CPUs that can be used, can limit the CPU usage of the client process | No | | enableXattr | bool | Whether to use xattr, default is false | No | | enableBcache | bool | Whether to enable local level-1 cache, default is false | No | | enableAudit | bool | Whether to enable local audit logs, default is false | No | ``` json { "mountPoint": "/cfs/mountpoint", "volName": "ltptest", "owner": "ltptest", "masterAddr": "10.196.59.198:17010,10.196.59.199:17010,10.196.59.200:17010", "logDir": "/cfs/client/log", "logLevel": "info", "profPort": "27510" } ```
Project: Kata Containers (Runtime / Container Runtime)
File: RestoreConfig.md

Name | Type | Description | Notes | - | - | - SourceUrl | string | | Prefault | Pointer to bool | | [optional] `func NewRestoreConfig(sourceUrl string, ) *RestoreConfig` NewRestoreConfig instantiates a new RestoreConfig 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 NewRestoreConfigWithDefaults() *RestoreConfig` NewRestoreConfigWithDefaults instantiates a new RestoreConfig 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 *RestoreConfig) GetSourceUrl() string` GetSourceUrl returns the SourceUrl field if non-nil, zero value otherwise. `func (o RestoreConfig) GetSourceUrlOk() (string, bool)` GetSourceUrlOk returns a tuple with the SourceUrl field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *RestoreConfig) SetSourceUrl(v string)` SetSourceUrl sets SourceUrl field to given value. `func (o *RestoreConfig) GetPrefault() bool` GetPrefault returns the Prefault field if non-nil, zero value otherwise. `func (o RestoreConfig) GetPrefaultOk() (bool, bool)` GetPrefaultOk returns a tuple with the Prefault field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *RestoreConfig) SetPrefault(v bool)` SetPrefault sets Prefault field to given value. `func (o *RestoreConfig) HasPrefault() bool` HasPrefault returns a boolean if a field has been set.
Project: Spiderpool (Runtime / Cloud Native Network)
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: Antrea (Runtime / Cloud Native Network)
File: minikube.md

<!-- toc --> - <!-- /toc --> Follow these to install minikube and set its development environment. ```bash curl -Lo https://github.com/antrea-io/antrea/releases/download/<TAG>/antrea.yml minikube start --cni=antrea.yml --network-plugin=cni ``` These instructions assume that you have built the Antrea Docker image locally (e.g. by running `make` from the root of the repository, or in case of arm64 architecture by running `./hack/build-antrea-linux-all.sh --platform linux/arm64`). ```bash minikube image load antrea/antrea-controller-ubuntu:latest minikube image load antrea/antrea-agent-ubuntu:latest kubectl apply -f antrea/build/yamls/antrea.yml ``` After a few seconds you should be able to observe the following when running `kubectl get pods -l app=antrea -n kube-system`: ```txt NAME READY STATUS RESTARTS AGE antrea-agent-9ftn9 2/2 Running 0 66m antrea-controller-56f97bbcff-zbfmv 1/1 Running 0 66m ```
Project: Inclavare Containers (Runtime / Container Runtime)
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. , 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: Carina (Runtime / Cloud Native Storage)
File: topology.md

When starts up, carina-node will label each node with `topology.carina.storage.io/node=${nodename}`. For storageclass, user can set `allowedTopologies` to affect pod scheduling. Creating storageclass with `kubectl apply -f storageclass.yaml` ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: csi-carina-sc provisioner: carina.storage.io parameters: csi.storage.k8s.io/fstype: xfs carina.storage.io/disk-group-name: hdd reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: Immediate mountOptions: allowedTopologies: matchLabelExpressions: key: beta.kubernetes.io/os values: linux key: kubernetes.io/hostname values: 10.20.9.153 10.20.9.154 ``` `allowedTopologies` policy only works with `volumeBindingMode: Immediate`. Example as follows: ```yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: carina-topo-stateful namespace: carina spec: serviceName: "nginx" replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: matchExpressions: key: kubernetes.io/os operator: In values: linux podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: labelSelector: matchExpressions: key: app operator: In values: nginx topologyKey: topology.carina.storage.io/node containers: name: nginx image: nginx imagePullPolicy: "IfNotPresent" ports: containerPort: 80 name: web volumeMounts: name: www mountPath: /usr/share/nginx/html name: logs mountPath: /logs volumeClaimTemplates: metadata: name: www spec: accessModes: [ "ReadWriteOnce" ] storageClassName: csi-carina-sc resources: requests: storage: 10Gi metadata: name: logs spec: accessModes: [ "ReadWriteOnce" ] storageClassName: csi-carina-sc resources: requests: storage: 5Gi ```
Project: containerd (Runtime / Container Runtime)
File: lifecycle.md

While containerd is a daemon that provides API to manage multiple containers, the containers themselves are not tied to the lifecycle of containerd. Each container has a shim that acts as the direct parent for the container's processes as well as reporting the exit status and holding onto the STDIO of the container. This also allows containerd to crash and restore all functionality to containers. The daemon provides an API to manage multiple containers. It can handle locking in process where needed to coordinate tasks between subsystems. While the daemon does fork off the needed processes to run containers, the shim and runc, these are re-parented to the system's init. Each container has its own shim that acts as the direct parent of the container's processes. The shim is responsible for keeping the IO and/or pty master of the container open, writing the container's exit status for containerd, and reaping the container's processes when they exit. Since the shim owns the container's pty master, it provides an API for resizing. Overall, a container's lifecycle is not tied to the containerd daemon. The daemon is a management API for multiple container whose lifecycle is tied to one shim per container.
Project: Spiderpool (Runtime / Cloud Native Network)
File: spiderpoolctl.md

This page describes CLI usage of spiderpoolctl for debug. Trigger the GC request to spiderpool-controller. ``` --address string [optional] address for spider-controller (default to service address) ``` Show a pod that is taking this IP. ``` --ip string [required] ip ``` Try to release an IP. ``` --ip string [optional] ip --force [optional] force release ip ``` Set IP to be taken by a pod. This will update ippool and workload endpoint resource. ``` --ip string [required] ip --pod string [required] pod name --namespace string [required] pod namespace --containerid string [required] pod container id --node string [required] the node name who the pod locates --interface string [required] pod interface who taking effect the ip ```
Project: lxd (Runtime / Container Runtime)
File: server.md

(incus-server)= ```{toctree} :maxdepth: 1 Migrating from LXD </howto/servermigratelxd> Configure the server <howto/server_configure> /server_config System settings <reference/server_settings> Backups <backup> Performance tuning <explanation/performance_tuning> Benchmarking <howto/benchmark_performance> Monitor metrics <metrics> Recover instances <howto/disaster_recovery> Database </database> /architectures ```
Project: Antrea (Runtime / Cloud Native Network)
File: configuration.md

```text --config string The path to the configuration file --v Level number for the log level verbosity ``` Use `antrea-agent -h` to see complete options. The `antrea-agent` configuration file specifies the agent configuration parameters. For all the agent configuration parameters of a Linux Node, refer to this . For all the configuration parameters of a Windows Node, refer to this [base configuration file](../build/yamls/windows/base/conf/antrea-agent.conf) ```text --config string The path to the configuration file --v Level number for the log level verbosity ``` Use `antrea-controller -h` to see complete options. The `antrea-controller` configuration file specifies the controller configuration parameters. For all the controller configuration parameters, refer to this . A typical CNI configuration looks like this: ```json { "cniVersion":"0.3.0", "name": "antrea", "plugins": [ { "type": "antrea", "ipam": { "type": "host-local" } }, { "type": "portmap", "capabilities": { "portMappings": true } }, { "type": "bandwidth", "capabilities": { "bandwidth": true } } ] } ``` You can also set the MTU (for the Pod's network interface) in the CNI configuration using `"mtu": <MTU_SIZE>`. When using an `antrea.yml` manifest, the MTU should be set with the `antrea-agent` `defaultMTU` configuration parameter, which will apply to all Pods and the host gateway interface on every Node. It is strongly discouraged to set the `"mtu"` field in the CNI configuration to a value that does not match the `defaultMTU` parameter, as it may lead to performance degradation or packet drops. Antrea enables portmap and bandwidth CNI plugins by default to support `hostPort` and traffic shaping functionalities for Pods respectively. In order to disable them, remove the corresponding section from `antrea-cni.conflist` in the Antrea manifest. For example, removing the following section disables portmap plugin: ```json { "type": "portmap", "capabilities": { "portMappings": true } } ```
Project: StratoVirt (Runtime / Container Runtime)
File: quickstart.md

Host os You can run StratoVirt on both x86_64 and aarch64 platforms. And on top of that, the StratoVirt is based on KVM, so please make sure you have KVM module on your platform. Authority You should have read/write permissions to `/dev/kvm`. If not, you can get your permissions by: ```shell $ sudo setfacl -m u:${USER}:rw /dev/kvm ``` StratoVirt is offerred by openEuler 20.09 or later. You can install by yum directly. ```shell $ sudo yum install stratovirt ``` Now you can find StratoVirt binary with path: `/usr/bin/stratovirt`. If you'd like to build StratoVirt yourself, you should check out the . With StratoVirt binary (either installed with yum, or built from source), we can boot a guest linux machine. Now StratoVirt provides two kinds of machine, which are microvm and standardvm("q35" on x8664 platform and "virt" on aarch64 platform). As a quick start, we show how to start a VM with microvm. First, you will need an PE format Linux kernel binary, and an ext4 file system image (as rootfs). `x86_64` boot source: and . `aarch64` boot source: and . Or get the kernel and rootfs with shell: ```shell arch=`uname -m` dest_kernel="vmlinux.bin" dest_rootfs="rootfs.ext4" imagebucketurl="https://repo.openeuler.org/openEuler-22.03-LTS/stratovirt_img" if [ ${arch} = "x86_64" ] || [ ${arch} = "aarch64" ]; then kernel="${imagebucketurl}/${arch}/vmlinux.bin" rootfs="${imagebucketurl}/${arch}/openEuler-22.03-LTS-stratovirt-${arch}.img.xz" else echo "Cannot run StratoVirt on ${arch} architecture!" exit 1 fi echo "Downloading $kernel..." wget ${kernel} -O ${dest_kernel} --no-check-certificate echo "Downloading $rootfs..." wget ${rootfs} -O ${dest_rootfs}.xz --no-check-certificate xz -d ${dest_rootfs}.xz echo "kernel file: ${destkernel} and rootfs image: ${destrootfs} download over." ``` Start guest linux machine with StratoVirt: ```shell socket_path=`pwd`"/stratovirt.sock" kernel_path=`pwd`"/vmlinux.bin" rootfs_path=`pwd`"/rootfs.ext4" rm -f ${socket_path} /usr/bin/stratovirt \ -machine microvm \ -kernel ${kernel_path} \ -smp 1 \ -m 1024 \ -append "console=ttyS0 pci=off reboot=k quiet panic=1 root=/dev/vda" \ -drive file=${rootfs_path},id=rootfs,readonly=off,direct=off \ -device virtio-blk-device,drive=rootfs,id=rootfs \ -qmp unix:${socket_path},server,nowait \ -serial stdio ``` You should now see a serial in stdio prompting you to log into the guest machine. If you used our `openEuler-22.03-LTS-stratovirt.img` image, you can login as `root`, using the password `openEuler12#$`. If you want to quit the guest machine, using a `reboot` command inside the guest will actually shutdown StratoVirt. This is due to that StratoVirt didn't implement guest power management in microvm type. If you want to know more information on running StratoVirt, go to the .
Project: Weave Net (Runtime / Cloud Native Network)
File: name-resolution-proxy.md

title: Name resolution via `/etc/hosts` menu_order: 50 search_type: Documentation When starting Weave Net enabled containers, the proxy automatically replaces the container's `/etc/hosts` file, and disables Docker's control over it. The new file contains an entry for the container's hostname and Weave Net IP address, as well as additional entries that have been specified using the `--add-host` parameters. This ensures that: name resolution of the container's hostname, for example, via `hostname -i`, returns the Weave Net IP address. This is required for many cluster-aware applications to work. unqualified names get resolved via DNS, for example typically via weaveDNS to Weave Net IP addresses. This is required so that in a typical setup one can simply "ping `<container-name>`", i.e. without having to specify a `.weave.local` suffix. If you prefer to keep `/etc/hosts` under Docker's control (for example, because you need the hostname to resolve to the Docker-assigned IP instead of the Weave IP, or you require name resolution for Docker-managed networks), the proxy must be launched using the `--no-rewrite-hosts` flag. host1$ weave launch --no-rewrite-hosts See Also
Project: Kata Containers (Runtime / Container Runtime)
File: kata-design-requirements.md

The Kata Containers runtime MUST fulfill all of the following requirements: The Kata Containers runtime MUST implement the and support all the OCI runtime operations. In theory, being OCI compatible should be enough. In practice, the Kata Containers runtime should comply with the latest stable `runc` CLI. In particular, it MUST implement the following `runc` commands: `create` `delete` `exec` `kill` `list` `pause` `ps` `start` `state` `version` The Kata Containers runtime MUST implement the following command line options: `--console-socket` `--pid-file` The Kata Containers project MUST provide two interfaces for CRI shims to manage hardware virtualization based Kubernetes pods and containers: An OCI and `runc` compatible command line interface, as described in the previous section. This interface is used by implementations such as and , for example. A hardware virtualization runtime library API for CRI shims to consume and provide a more CRI native implementation. The CRI shim is an example of such a consumer. The Kata Containers runtime MUST NOT be architecture-specific. It should be able to support multiple hardware architectures and provide a modular and flexible design for adding support for additional ones. The Kata Containers runtime MUST NOT be tied to any specific hardware virtualization technology, hypervisor, or virtual machine monitor implementation. It should support multiple hypervisors and provide a pluggable and flexible design to add support for additional ones. The Kata Containers runtime MUST support nested virtualization environments. The Kata Containers runtime MUST* support CNI plugin. The Kata Containers runtime MUST* support both legacy and IPv6 networks. In order for containers to directly consume host hardware resources, the Kata Containers runtime MUST provide containers with secure pass through for generic devices such as GPUs, SRIOV, RDMA, QAT, by leveraging I/O virtualization technologies (IOMMU, interrupt remapping). The Kata Containers runtime MUST support accelerated and user-space-based I/O operations for networking (e.g. DPDK) as well as storage through `vhost-user` sockets. The Kata Containers runtime MUST support scalable I/O through the SRIOV technology. A compelling aspect of containers is their minimal overhead compared to bare metal applications. A container runtime should keep the overhead to a minimum in order to provide the expected user experience. The Kata Containers runtime implementation SHOULD be optimized for: Minimal workload boot and shutdown times Minimal workload memory footprint Maximal networking throughput Minimal networking latency Each Kata Containers runtime pull request MUST pass at least the following set of container-related tests: Unit tests: runtime unit tests coverage >75% Functional tests: the entire runtime CLI and APIs Integration tests: Docker and Kubernetes The Kata Containers runtime implementation MUST use structured logging in order to namespace log messages to facilitate debugging.
Project: lxd (Runtime / Container Runtime)
File: network_external.md

(network-external)= <!-- Include start external intro --> External networks use network interfaces that already exist. Therefore, Incus has limited possibility to control them, and Incus features like network ACLs, network forwards and network zones are not supported. The main purpose for using external networks is to provide an uplink network through a parent interface. This external network specifies the presets to use when connecting instances or other networks to a parent interface. Incus supports the following external network types: <!-- Include end external intro --> ```{toctree} :maxdepth: 1 /reference/network_macvlan /reference/network_sriov /reference/network_physical ```
Project: Kata Containers (Runtime / Container Runtime)
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`