cwielenb/CNCF-Dataset huggingface dataset:
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_ct.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Connection tracking tables ``` -h, --help help for ct ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Direct access to local BPF maps - Flush all connection tracking entries - List connection tracking entries
Project: Kata Containers (Runtime / Container Runtime)
File: how-to-use-sysctls-with-kata.md

In Linux, the sysctl interface allows an administrator to modify kernel parameters at runtime. Parameters are available via the `/proc/sys/` virtual process file system. The parameters include the following subsystems among others: `fs` (file systems) `kernel` (kernel) `net` (networking) `vm` (virtual memory) To get a complete list of kernel parameters, run: ``` $ sudo sysctl -a ``` Kubernetes provide mechanisms for setting namespaced sysctls. Namespaced sysctls can be set per pod in the case of Kubernetes. The following sysctls are known to be namespaced and can be set with Kubernetes: `kernel.shm*` `kernel.msg*` `kernel.sem` `fs.mqueue.*` `net.*` Kata Containers supports setting namespaced sysctls with Kubernetes. All namespaced sysctls can be set in the same way as regular Linux based containers, the difference being, in the case of Kata they are set inside the guest. Kubernetes considers certain sysctls as safe and others as unsafe. For detailed information about what sysctls are considered unsafe, please refer to the . For using unsafe sysctls, the cluster admin would need to allow these as: ``` $ kubelet --allowed-unsafe-sysctls 'kernel.msg*,net.ipv4.route.min_pmtu' ... ``` or using the declarative approach as: ``` $ cat kubeadm.yaml apiVersion: kubeadm.k8s.io/v1alpha3 kind: InitConfiguration nodeRegistration: kubeletExtraArgs: allowed-unsafe-sysctls: "kernel.msg,kernel.shm.,net.*" ... ``` The above YAML can then be passed to `kubeadm init` as: ``` $ sudo -E kubeadm init --config=kubeadm.yaml ``` Both safe and unsafe sysctls can be enabled in the same way in the Pod YAML: ``` apiVersion: v1 kind: Pod metadata: name: sysctl-example spec: securityContext: sysctls: name: kernel.shmrmidforced value: "0" name: net.ipv4.route.min_pmtu value: "1024" ``` Kubernetes disallow sysctls without a namespace. The recommendation is to set them directly on the host or use a privileged container in the case of Kubernetes. In the case of Kata, the approach of setting sysctls on the host does not work since the host sysctls have no effect on a Kata Container running inside a guest. Kata gives you the ability to set non-namespaced sysctls using a privileged container. This has the advantage that the non-namespaced sysctls are set inside the guest without having any effect on the `/proc/sys` values of any other pod or the host itself. The recommended approach to do this would be to set the sysctl value in a privileged init container. In this way, the application containers do not need any elevated privileges. ``` apiVersion: v1 kind: Pod metadata: name: busybox-kata spec: runtimeClassName: kata-qemu securityContext: sysctls: name: kernel.shmrmidforced value: "0" containers: name: busybox-container securityContext: privileged: true image: debian command: sleep "3000" initContainers: name: init-sys securityContext: privileged: true image: busybox command: ['sh', '-c', 'echo "64000" > /proc/sys/vm/maxmapcount'] ```
Project: Rook (Runtime / Cloud Native Storage)
File: ceph-fs-subvolumegroup-crd.md

title: FilesystemSubVolumeGroup CRD !!! info This guide assumes you have created a Rook cluster as explained in the main Rook allows creation of Ceph Filesystem through the custom resource definitions (CRDs). Filesystem subvolume groups are an abstraction for a directory level higher than Filesystem subvolumes to effect policies (e.g., File layouts) across a set of subvolumes. For more information about CephFS volume, subvolumegroup and subvolume refer to the . To get you started, here is a simple example of a CRD to create a subvolumegroup on the CephFilesystem "myfs". ```yaml apiVersion: ceph.rook.io/v1 kind: CephFilesystemSubVolumeGroup metadata: name: group-a namespace: rook-ceph # namespace:cluster spec: name: csi filesystemName: myfs pinning: distributed: 1 # distributed=<0, 1> (disabled=0) ``` If any setting is unspecified, a suitable default will be used automatically. `name`: The name that will be used for the Ceph Filesystem subvolume group. `name`: The spec name that will be used for the Ceph Filesystem subvolume group if not set metadata name will be used. `filesystemName`: The metadata name of the CephFilesystem CR where the subvolume group will be created. `quota`: Quota size of the Ceph Filesystem subvolume group. `dataPoolName`: The data pool name for the subvolume group layout instead of the default data pool. `pinning`: To distribute load across MDS ranks in predictable and stable ways. See the Ceph doc for . `distributed`: Range: <0, 1>, for disabling it set to 0 `export`: Range: <0-256>, for disabling it set to -1 `random`: Range: [0.0, 1.0], for disabling it set to 0.0 !!! note Only one out of (export, distributed, random) can be set at a time. By default pinning is set with value: `distributed=1`.
Project: Alluxio (Runtime / Cloud Native Storage)
File: README.md

in spdk directory ```shell cp dpdk/build/lib/*.a build/lib/ cp isa-l/.libs/*.a build/lib/ cp isa-l-crypto/.libs/*.a build/lib/ cd build/lib/ rm libspdkutmock.a cc -shared -o libspdk_fat.so -Wl,--whole-archive *.a -Wl,--no-whole-archive sudo cp libspdk_fat.so /usr/local/lib ```
Project: HwameiStor (Runtime / Cloud Native Storage)
File: ha.md

sidebar_position: 2 sidebar_label: "Use HA Volumes" When the HA module is enabled, HwameiStor Operator will generate a StorageClass of HA automatically. As an example, we will deploy a MySQL application by creating a highly available (HA) volume. :::note The yaml file for MySQL is learnt from ::: `StorageClass` "hwameistor-storage-lvm-hdd-ha" has parameter `replicaNumber: "2"`, which indicates a DRBD replication pair. ```console $ kubectl apply -f examples/sc_ha.yaml $ kubectl get sc hwameistor-storage-lvm-hdd-ha -o yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: hwameistor-storage-lvm-hdd-ha parameters: replicaNumber: "2" convertible: "false" csi.storage.k8s.io/fstype: xfs poolClass: HDD poolType: REGULAR striped: "true" volumeKind: LVM provisioner: lvm.hwameistor.io reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true ``` With HwameiStor and its `StorageClass` ready, a MySQL StatefulSet and its volumes can be deployed by a single command: ```Console $ kubectl apply -f exapmles/sts-mysql_ha.yaml ``` Please note the `volumeClaimTemplates` uses `storageClassName: hwameistor-storage-lvm-hdd-ha`: ```yaml spec: volumeClaimTemplates: metadata: name: data labels: app: sts-mysql-ha app.kubernetes.io/name: sts-mysql-ha spec: storageClassName: hwameistor-storage-lvm-hdd-ha accessModes: ["ReadWriteOnce"] resources: requests: storage: 1Gi ``` In this example, the pod is scheduled on node `k8s-worker-3`. ```console $ kubectl get po -l app=sts-mysql-ha -o wide NAME READY STATUS RESTARTS AGE IP NODE sts-mysql-ha-0 2/2 Running 0 3m08s 10.1.15.151 k8s-worker-1 $ kubectl get pvc -l app=sts-mysql-ha NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE VOLUMEMODE data-sts-mysql-ha-0 Bound pvc-5236ee6f-8212-4628-9876-1b620a4c4c36 1Gi RWO hwameistor-storage-lvm-hdd 3m Filesystem ``` By listing `LocalVolume(LV)` objects with the same name as that of the `PV`, we can see that the `LV` object is created on two nodes: `k8s-worker-1` and `k8s-worker-2`. ```console $ kubectl get lv pvc-5236ee6f-8212-4628-9876-1b620a4c4c36 NAME POOL REPLICAS CAPACITY ACCESSIBILITY STATE RESOURCE PUBLISHED AGE pvc-5236ee6f-8212-4628-9876-1b620a4c4c36 LocalStorage_PoolHDD 1 1073741824 Ready -1 k8s-worker-1,k8s-worker-2 3m ``` `LocalVolumeReplica (LVR)` further shows the backend logical volume devices on each node. ```concole $ kubectl get lvr NAME CAPACITY NODE STATE SYNCED DEVICE AGE 5236ee6f-8212-4628-9876-1b620a4c4c36-d2kn55 1073741824 k8s-worker-1 Ready true /dev/LocalStorage_PoolHDD-HA/5236ee6f-8212-4628-9876-1b620a4c4c36 4m 5236ee6f-8212-4628-9876-1b620a4c4c36-glm7rf 1073741824 k8s-worker-3 Ready true /dev/LocalStorage_PoolHDD-HA/5236ee6f-8212-4628-9876-1b620a4c4c36 4m ```
Project: lxd (Runtime / Container Runtime)
File: networks.md

(networking)= ```{toctree} :maxdepth: 1 /explanation/networks Create and configure a network </howto/network_create> Configure a network </howto/network_configure> Configure network ACLs </howto/network_acls> Configure network forwards </howto/network_forwards> Configure network integrations </howto/network_integrations> Configure network zones </howto/network_zones> Configure Incus as BGP server </howto/network_bgp> Display Incus IPAM information </howto/network_ipam> /reference/network_bridge /reference/network_ovn /reference/network_external Increase bandwidth <howto/networkincreasebandwidth> ```
Project: Carina (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: Kube-OVN (Runtime / Cloud Native Network)
File: GOVERNANCE.md

This document defines governance policies for the Kube-OVN project. Kube-OVN Maintainers have write access to the . They can merge their own patches or patches from others. The current maintainers can be found in . Maintainers collectively manage the project's resources and contributors. This privilege is granted with some expectation of responsibility: maintainers are people who care about the Kube-OVN project and want to help it grow and improve. A maintainer is not just someone who can make changes, but someone who has demonstrated their ability to collaborate with the team, get the most knowledgeable people to review code and docs, contribute high-quality code, and follow through to fix issues (in code or tests). A maintainer is a contributor to the project's success and a citizen helping the project succeed. <!-- If you have full Contributor Ladder documentation that covers becoming a Maintainer or Owner, then this section should instead be a reference to that documentation --> To become a Maintainer, you need to demonstrate the following: commitment to the project: participate in discussions, contributions, code and documentation reviews for 3 months or more, perform reviews for 10 non-trivial pull requests, contribute 10 non-trivial pull requests and have them merged, ability to write quality code and/or documentation, ability to collaborate with the team, understanding of how the team works (policies, processes for testing and code review, etc), understanding of the project's code base and coding and documentation style. A new Maintainer must be proposed by an existing maintainer by sending a message to the . A simple majority vote of existing Maintainers approves the application. Time zones permitting, Maintainers are expected to participate in the public developer meeting, which occurs [1, 15 every month]. Maintainers will also have closed meetings in order to discuss security reports or Code of Conduct violations. Such meetings should be scheduled by any Maintainer on receipt of a security issue or CoC report. All current Maintainers must be invited to such closed meetings, except for any Maintainer who is accused of a CoC violation. Any Maintainer may suggest a request for CNCF resources, either in the , or during a meeting. A simple majority of Maintainers approves the request. The Maintainers may also choose to delegate working with the CNCF to non-Maintainer community members. While most business in Kube-OVN is conducted by "lazy consensus", periodically the Maintainers may need to vote on specific actions or changes. Votes may be taken at . Any Maintainer may demand a vote be taken. Most votes require a simple majority of all Maintainers to succeed. Maintainers can be removed by a 2/3 majority vote of all Maintainers, and changes to this Governance require a 2/3 vote of all Maintainers.
Project: Spiderpool (Runtime / Cloud Native Network)
File: crd-spiderendpoint.md

A SpiderEndpoint resource represents IP address allocation details for the corresponding pod. This resource one to one pod, and it will inherit the pod name and pod namespace. Notice: For kubevirt VM static IP feature, the SpiderEndpoint object would inherit the kubevirt VM/VMI resource name and namespace. ```yaml apiVersion: spiderpool.spidernet.io/v2beta1 kind: SpiderEndpoint metadata: name: test-app-1-9dc78fb9-rs99d status: current: ips: cleanGateway: false interface: eth0 ipv4: 172.31.199.193/20 ipv4Gateway: 172.31.207.253 ipv4Pool: worker-172 vlan: 0 node: dc-test02 uid: e7b50a38-25c2-41d0-b332-7f619c69194e ownerControllerName: test-app-1 ownerControllerType: Deployment ``` | Field | Description | Schema | Validation | |--|--|--|| | name | the name of this SpiderEndpoint resource | string | required | | namespace | the namespace of this SpiderEndpoint resource | string | required | The IPPool status is a subresource that processed automatically by the system to summarize the current state. | Field | Description | Schema | Validation | ||-||| | current | the IP allocation details of the corresponding pod | | required | | ownerControllerType | the corresponding pod top owner controller type | string | required | | ownerControllerName | the corresponding pod top owner controller name | string | required | This property describes the SpiderEndpoint corresponding pod details. | Field | Description | Schema | Validation | |-|-|--|| | uid | corresponding pod uid | string | required | | node | total IP counts of this pool to use | string | required | | ips | current allocated IP counts | list of | required | This property describes single Interface allocation details. | Field | Description | Schema | Validation | Default | |--||-||| | interface | single interface name | string | required | | | ipv4 | single IPv4 allocated IP address | string | optional | | | ipv6 | single IPv6 allocated IP address | string | optional | | | ipv4Pool | the IPv4 allocated IP address corresponding pool | string | optional | | | ipv6Pool | the IPv6 allocated IP address corresponding pool | string | optional | | | vlan | vlan ID | int | optional | 0 | | ipv4Gateway | the IPv4 gateway IP address | string | optional | | | ipv6Gateway | the IPv6 gateway IP address | string | optional | | | cleanGateway | a flag to choose whether need default route by the gateway | boolean | optional | | | routes | the allocation routes | list if | optional | |
Project: CubeFS (Runtime / Cloud Native Storage)
File: pull_request_template.md

<!-- Thanks for sending the pull request! --> <!-- PR title format should be type(scope): subject. For details, see . Each pull request should address only one issue, not mix up code from multiple issues. Each commit in the pull request has a meaningful commit message. For details, see . Fill out the template below to describe the changes contributed by the pull request. That will give reviewers the context they need to do the review. Once all items of the checklist are addressed, remove the above text and this checklist, leaving only the filled out template below. --> <!-- Either this PR fixes an issue, --> Fixes: #xyz <!-- or this PR is one task of an issue. --> Main Issue: #xyz <!-- Explain here the context, and why you're making that change. What is the problem you're trying to solve. --> blaaaaa <!-- Describe the modifications you've done. --> ``` text blaaaaa ``` <!-- Show in a checkbox-style, the expected types of changes your project is supposed to have: --> <!-- Put an `x` in the boxes that apply --> [ ] New feature (non-breaking change which adds functionality) [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) [ ] Bugfix (non-breaking change which fixes an issue) [ ] Documentation Update (if none of the other choices apply) [ ] So on... <!-- Please pick either of the following options. --> [ ] Make sure that the change passes the testing checks. This change is a trivial rework / code cleanup without any test coverage. (or) This change is already covered by existing tests, such as (please describe tests). (or) This change added tests and can be verified as follows: (example:) This can be verified in development debugging This can be realized in a mocked environment, like a test cluster consisting in docker (or) This change `MUST` reappear in online clusters, or occur in that specific scenarios. <!-- Which of the following parts are affected by this change? --> [ ] Master [ ] MetaNode [ ] DataNode [ ] ObjectNode [ ] AuthNode [ ] LcNode [ ] Blobstore [ ] Client [ ] Cli [ ] SDK [ ] Other Tools [ ] Common Packages [ ] Dependencies [ ] Anything that affects deployment <!-- Is there a chinese and english document modification? --> [ ] `doc` <!-- Your PR contains doc changes. --> [ ] `doc-required` <!-- Your PR changes impact docs and you will update later --> [ ] `doc-not-needed` <!-- Your PR changes do not impact docs --> [ ] `doc-complete` <!-- Docs have been already added --> <!-- How long would you like the team to be completed in your contributing? --> [ ] `in-two-days` [ ] `weekly` [ ] `free-time` [ ] `whenever` <!-- enter the url if has PR in forked repository. --> PR in forked repository: <!-- ENTER URL HERE --> <!-- Thanks for contributing, best days! -->
Project: Velero (Runtime / Cloud Native Storage)
File: ark_backup_download.md

title: "ark backup download" layout: docs Download a backup Download a backup ``` ark backup download NAME [flags] ``` ``` --force forces the download and will overwrite file if it exists already -h, --help help for download -o, --output string path to output file. Defaults to <NAME>-data.tar.gz in the current directory --timeout duration maximum time to wait to process download request (default 1m0s) ``` ``` --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 ``` - Work with backups
Project: StratoVirt (Runtime / Container Runtime)
File: vfio.md

The VFIO driver is an IOMMU/device agnostic framework for exposing direct access to userspace, in a secure, IOMMU protected environment. Virtual machine often makes use of direct device access when configured for the highest possible I/O performance. In order to successfully use VFIO device, it is mandatory that hardware supports virtualization and IOMMU groups. Execute the following command on your host OS to check whether the IOMMU has been turned on. ```shell ``` If the IOMMU is turned on, the terminal display as follows: ```shell iommu: Default domain type: Translated hibmc-drm 0000:0a:00.0: Adding to iommu group 0 ehci-pci 0000:7a:01.0: Adding to iommu group 1 ehci-pci 0000:ba:01.0: Adding to iommu group 2 ohci-pci 0000:7a:00.0: Adding to iommu group 3 ohci-pci 0000:ba:00.0: Adding to iommu group 4 xhci_hcd 0000:7a:02.0: Adding to iommu group 5 ... ``` Assume user wants to access PCI device 0000:1a:00.3. The device is attached to PCI bus, therefore user will make use of vfio-pci to manage the group: ```shell ``` Binding this device to the vfio-pci driver, it will create the VFIO group character devices for this group. ```shell ``` Four properties are supported for VFIO device host: PCI device info in the system that contains domain, bus number, slot number and function number. id: VFIO device name. bus: bus number of VFIO device. addr: including slot number and function number. ```shell -device vfio-pci,host=0000:1a:00.3,id=net,bus=pcie.0,addr=0x03.0x0[,multifunction=on] ``` Note: the kernel must contain physical device drivers, otherwise it cannot be loaded normally. Note: avoid using balloon devices and vfio devices together. StratoVirt standard VM supports hot-plug VFIO devices with QMP. Refer to qmp.md for specific command line parameters. hot plug VFIO device: ```json -> {"execute":"device_add", "arguments":{"id":"vfio-0", "driver":"vfio-pci", "bus": "pcie.1", "addr":"0x0", "host": "0000:1a:00.3"}} <- {"return": {}} ``` hot unplug VFIO device: ```json -> {"execute": "device_del", "arguments": {"id": "vfio-0"}} <- {"event":"DEVICE_DELETED","data":{"device":"vfio-0","path":"vfio-0"},"timestamp":{"seconds":1614310541,"microseconds":554250}} <- {"return": {}} ``` If it is necessary to unbind VFIO device directly, you can execute the following command. Note: assume uses hinic driver ```shell ```
Project: HwameiStor (Runtime / Cloud Native Storage)
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. -->
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_recorder_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List current pcap recorders ``` cilium-dbg recorder 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 ``` - Introspect or mangle pcap recorder