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

sidebar_position: 10 sidebar_label: "System Audit" It's important to record the information about the system operation history. HwameiStor provides a feature of audit to record the operations on all the system resources, including Cluster, Node, StoragePool, Volume, etc... The audit information is easier for user to understant and parse for various purposes. HwameiStor designs a new CRD for every resource as below: ```yaml apiVersion: hwameistor.io/v1alpha1 kind: Event name: spec: resourceType: <Cluster | Node | StoragePool | Volume> resourceName: records: action: actionContent: # in JSON format time: state: stateContent: # in JSON format ``` For instance, let's look at audit information of a volume: ```yaml apiVersion: hwameistor.io/v1alpha1 kind: Event metadata: creationTimestamp: "2023-08-08T15:52:55Z" generation: 5 name: volume-pvc-34e3b086-2d95-4980-beb6-e175fd79a847 resourceVersion: "10221888" uid: d3ebaffb-eddb-4c84-93be-efff350688af spec: resourceType: Volume resourceName: pvc-34e3b086-2d95-4980-beb6-e175fd79a847 records: action: Create actionContent: '{"requiredCapacityBytes":5368709120,"volumeQoS":{},"poolName":"LocalStorage_PoolHDD","replicaNumber":2,"convertible":true,"accessibility":{"nodes":["k8s-node1","k8s-master"],"zones":["default"],"regions":["default"]},"pvcNamespace":"default","pvcName":"mysql-data-volume","volumegroup":"db890e34-a092-49ac-872b-f2a422439c81"}' time: "2023-08-08T15:52:55Z" action: Mount actionContent: '{"allocatedCapacityBytes":5368709120,"replicas":["pvc-34e3b086-2d95-4980-beb6-e175fd79a847-krp927","pvc-34e3b086-2d95-4980-beb6-e175fd79a847-wm7p56"],"state":"Ready","publishedNode":"k8s-node1","fsType":"xfs","rawblock":false}' time: "2023-08-08T15:53:07Z" action: Unmount actionContent: '{"allocatedCapacityBytes":5368709120,"usedCapacityBytes":33783808,"totalInode":2621120,"usedInode":3,"replicas":["pvc-34e3b086-2d95-4980-beb6-e175fd79a847-krp927","pvc-34e3b086-2d95-4980-beb6-e175fd79a847-wm7p56"],"state":"Ready","publishedNode":"k8s-node1","fsType":"xfs","rawblock":false}' time: "2023-08-08T16:03:03Z" action: Delete actionContent: '{"requiredCapacityBytes":5368709120,"volumeQoS":{},"poolName":"LocalStorage_PoolHDD","replicaNumber":2,"convertible":true,"accessibility":{"nodes":["k8s-node1","k8s-master"],"zones":["default"],"regions":["default"]},"pvcNamespace":"default","pvcName":"mysql-data-volume","volumegroup":"db890e34-a092-49ac-872b-f2a422439c81","config":{"version":1,"volumeName":"pvc-34e3b086-2d95-4980-beb6-e175fd79a847","requiredCapacityBytes":5368709120,"convertible":true,"resourceID":2,"readyToInitialize":true,"initialized":true,"replicas":[{"id":1,"hostname":"k8s-node1","ip":"10.6.113.101","primary":true},{"id":2,"hostname":"k8s-master","ip":"10.6.113.100","primary":false}]},"delete":true}' time: "2023-08-08T16:03:38Z" ```
Project: Kata Containers (Runtime / Container Runtime)
File: README.md

This directory contains useful packaging scripts. This script generates the official set of QEMU-based hypervisor build configuration options. All repositories that need to build a hypervisor from source MUST use this script to ensure the hypervisor is built in a known way since using a different set of options can impact many areas including performance, memory footprint and security. Example usage: ``` $ configure-hypervisor.sh qemu ```
Project: containerd (Runtime / Container Runtime)
File: RUNC.md

containerd is built with OCI support and with support for advanced features provided by the . Development (`-dev`) and pre-releases of containerd may depend features in `runc` that have not yet been released, and may require a specific runc build. The version of runc that is tested against in our CI can be found in the file, which may point to a git-commit (for pre releases) or tag in the runc repository. For regular (non-pre-)releases of containerd releases, we attempt to use released (tagged) versions of runc. We recommend using a version of runc that's equal to or higher than the version of runc described in . If you encounter any runtime errors, make sure your runc is in sync with the commit or tag provided in that file. If you do not have the correct version of `runc` installed, you can refer to the to learn how to build `runc` from source. runc builds have , , and support enabled by default. Note that "seccomp" can be disabled by passing an empty `BUILDTAGS` make variable, but is highly recommended to keep enabled. Use the output of the `runc --version` output to verify if your version of runc has seccomp enabled. For example: ```sh $ runc --version runc version 1.0.1 commit: v1.0.1-0-g4144b638 spec: 1.0.2-dev go: go1.16.6 libseccomp: 2.4.4 ```
Project: JuiceFS (Runtime / Cloud Native Storage)
File: automation.md

title: Automated Deployment sidebar_position: 7 Automated deployment is recommended when JuiceFS Client is to be installed on a large number of hosts. Below examples only demonstrate the mount process, you should before getting started. Below is the example to install and mount JuiceFS in localhost: ```yaml hosts: localhost tasks: set_fact: meta_url: sqlite3:///tmp/myjfs.db jfs_path: /jfs jfs_pkg: /tmp/juicefs-ce.tar.gz jfsbindir: /usr/local/bin get_url: url: https://d.juicefs.com/juicefs/releases/download/v1.0.2/juicefs-1.0.2-linux-amd64.tar.gz dest: "{{jfs_pkg}}" ansible.builtin.unarchive: src: "{{jfs_pkg}}" dest: "{{jfsbindir}}" include: juicefs name: Create symbolic for fstab ansible.builtin.file: src: "{{jfsbindir}}/juicefs" dest: "/sbin/mount.juicefs" state: link name: Mount JuiceFS and create fstab entry mount: path: "{{jfs_path}}" src: "{{meta_url}}" fstype: juicefs opts: _netdev state: mounted ```
Project: Inclavare Containers (Runtime / Container Runtime)
File: spec_v2.md

Indicate PAL API version number implemented by runelet and enclave runtime; runelet is compatible with any enclave runtimes equal to or less than the indicated value. If this symbol is undefined in enclave runtime, version 1 is assuemd by runelet. ```c int palgetversion(); ``` ``` N/A ``` ``` @int: the PAL API version of the current enclave runtime. ``` Do libos initialization according to the incoming attr parameters. ```c struct palattrt { const char *args; const char *log_level; }; int palinit(struct palattr_t *attr); ``` ``` @args: Pass the required parameters of libos (can be instance path etc.). @log_level: Log level. ``` ``` 0: Success -EINVAL: Invalid argument -ENOSYS: The function is not supported ``` Create a new process, but do not run it; the real run is triggered by pal_exec(). ```c struct palstdiofds { int stdin, stdout, stderr; }; struct palcreateprocess_args { char *path; char *argv[]; char *env[]; struct palstdiofds *stdio; int *pid; }attribute((packed)); int palcreateprocess(struct palcreateprocess_args *args); ``` ``` @path: The path of the binary file to be run (relative path in the libos file system). @argv: Binary parameters, ending with a null element. @env: Binary environment variables, ending with a null element. @stdio: The fd of stdio. @pid: If the function return value is 0, pid stores the pid of the new process in libos. ``` ``` 0: Success -EINVAL: Invalid argument -ENOSYS: The function is not supported ``` Execute the program corresponding to pid. ```c struct palexecargs { int pid; int *exit_value; }attribute((packed)); int palexec(struct palexec_args *attr); ``` ``` @pid: The pid of the generation process. @exit_value: The exit value of the process. ``` ``` 0: Success -EINVAL: Invalid argument -ENOSYS: The function is not supported ``` Send signals to processes running in enclave runtime. ```c int pal_kill(int pid, int sig); ``` ``` @pid: Send to all processes if equal to -1, or send to current process if equal to 0, or send to the process that owns the pid if others. @sig: Signal number to be sent. ``` ``` 0: Success -EINVAL: Invalid argument -ENOSYS: The function is not supported ``` Destroy libos instance. ```c int pal_destroy(); ``` ``` N/A ``` ``` 0: Success -ENOSYS: The function is not supported ```
Project: containerd (Runtime / Container Runtime)
File: image-verification.md

The following covers the default "bindir" `ImageVerifier` plugin implementation. To enable image verification, add a stanza like the following to the containerd config: ```yaml [plugins] [plugins."io.containerd.image-verifier.v1.bindir"] bin_dir = "/opt/containerd/image-verifier/bin" max_verifiers = 10 perverifiertimeout = "10s" ``` All files in `bin_dir`, if it exists, must be verifier executables which conform to the following API. `-name`: The given reference to the image that may be pulled. `-digest`: The resolved digest of the image that may be pulled. `-stdin-media-type`: The media type of the JSON data passed to stdin. A JSON encoded payload is passed to the verifier binary's standard input. The media type of this payload is specified by the `-stdin-media-type` CLI argument, and may change in future versions of containerd. Currently, the payload has a media type of `application/vnd.oci.descriptor.v1+json` and represents the OCI Content Descriptor of the image that may be pulled. See for more details. Print to standard output a reason for the image pull judgement. Return an exit code of 0 to allow the image to be pulled and any other exit code to block the image from being pulled. If `bin_dir` does not exist or contains no files, the image verifier does not block image pulls. An image is pulled only if all verifiers that are called return an "ok" judgement (exit with status code 0). In other words, image pull judgements are combined with an `AND` operator. If any verifiers exceeds the `perverifiertimeout` or fails to exec, the verification fails with an error and a `nil` judgement is returned. If `max_verifiers < 0`, there is no imposed limit on the number of image verifiers called. If `maxverifiers >= 0`, there is a limit imposed on the number of image verifiers called. The entries in `bindir` are lexicographically sorted by name, and the first `n = max_verifiers` of the verifiers will be called, and the rest will be skipped. There is no guarantee for the order of execution of verifier binaries. Standard error output of verifier binaries is logged at debug level by containerd, subject to truncation. Standard output of verifier binaries (the "reason" for the judgement) is subject to truncation. System resources used by verifier binaries are currently accounted for in and constrained by containerd's own cgroup, but this is subject to change.
Project: CubeFS (Runtime / Cloud Native Storage)
File: fuse.md

Properly adjusting the kernel FUSE parameters can achieve better performance in sequential writing and high-concurrency scenarios. You can refer to the following steps: Obtain the Linux kernel source code. Download the corresponding Linux kernel source code package and install the source code. The source code installation directory is `~/rpmbuild/BUILD/`. ``` bash rpm -i kernel-3.10.0-327.28.3.el7.src.rpm 2>&1 | grep -v exist cd ~/rpmbuild/SPECS rpmbuild -bp --target=$(uname -m) kernel.spec ``` Optimize the Linux FUSE kernel module parameters. To achieve optimal performance, you can modify the FUSE parameters `FUSEMAXPAGESPERREQ` and `FUSEDEFAULTMAX_BACKGROUND`. The optimized reference values are as follows: ``` C / fs/fuse/fuse_i.h / / fs/fuse/inode.c / ``` Compile the corresponding version of the Linux kernel module. ``` bash yum install kernel-devel-3.10.0-327.28.3.el7.x86_64 cd ~/rpmbuild/BUILD/kernel-3.10.0-327.28.3.el7/linux-3.10.0-327.28.3.el7.x86_64/fs/fuse make -C /lib/modules/`uname -r`/build M=$PWD ``` Insert the kernel module. ``` bash cp fuse.ko /lib/modules/`uname -r`/kernel/fs/fuse rmmod fuse depmod -a modprobe fuse ```
Project: Kanister (Runtime / Cloud Native Storage)
File: pull_request_template.md

<!-- Insert PR description--> Please check the type of change your PR introduces: [ ] :construction: Work in Progress [ ] :rainbow: Refactoring (no functional changes, no api changes) [ ] :hamster: Trivial/Minor [ ] :bug: Bugfix [ ] :sunflower: Feature [ ] :world_map: Documentation [ ] :robot: Test fixes #issue-number <!-- Will run prior to merging.--> <!-- Include example how to run.--> [ ] :muscle: Manual [ ] :zap: Unit test [ ] :green_heart: E2E
Project: Carina (Runtime / Cloud Native Storage)
File: metrics.md

carina-node runs in hostNetwork mode and listens to `8080`. ```shell "--metrics-addr=:8080" ``` If changing those ports, please also change the csi-carina-node service. carina-controller listens to `8080 8443`. ```shell "--metrics-addr=:8080" "--webhook-addr=:8443" ``` carina metrics | Metrics | Description | | - | - | | carinascrapecollectordurationseconds | carinacsiexporter: Duration of a collector scrape | | carinascrapecollectorsuccess | carinacsi_exporter: Whether a collector succeeded | | carinavolumegroupstatscapacitybytestotal | The number of lvm vg total bytes | | carinavolumegroupstatscapacitybytesused | The number of lvm vg used bytes | | carinavolumegroupstatslv_total | The number of lv total | | carinavolumegroupstatspv_total | The number of pv total | | carinavolumestatsreadscompleted_total | The total number of reads completed successfully | | carinavolumestatsreadsmerged_total | The total number of reads merged | | carinavolumestatsreadbytes_total | The total number of bytes read successfully | | carinavolumestatsreadtimesecondstotal | The total number of seconds spent by all reads | | carinavolumestatswritescompleted_total | The total number of writes completed successfully | | carinavolumestatswritesmerged_total | The number of writes merged | | carinavolumestatswritebytes_total | The total number of bytes write successfully | | carinavolumestatswritetimesecondstotal | This is the total number of seconds spent by all writes | | carinavolumestatsionow | The number of I/Os currently in progress | | carinavolumestatsiotimesecondstotal | Total seconds spent doing I/Os | carina provides a wealth of storage volume metrics, and kubelet itself also exposes PVC capacity and other metrics, as seen in the Grafana Kubernetes built-in view of this template. Notice The storage capacity indicator of the PVC is displayed only when the PVC is in use and mounted to the node
Project: CNI-Genie (Runtime / Cloud Native Network)
File: ROADMAP-old.md

Enhancements as per Kubernetes Network Plumbing Working Group conclusions/decisions CNI version upgrade based on new CNI version release Support pod level network policy to co-exist with network level policy Enhancement of network crd objects to provide more CNI customizations Enhance network smart selection mechanism New requirement/usecase support based on users demands Integrate genie with other ecosystem projects (e.g., kubespray) Helm charts based on updated features Verification and user guide update for usage of SR-IOV, DPDK E2E test suite additions/improvements Enhance logging mechanisms
Project: Project Calico (Runtime / Cloud Native Network)
File: noop-mode.md

When in noop mode target configuration files will not be modified. ``` confd -noop ``` ``` noop = true ``` ``` confd -onetime -noop ``` ``` 2014-07-08T22:30:10-07:00 confd[16397]: INFO /tmp/myconfig.conf has md5sum c1924fc5c5f2698e2019080b7c043b7a should be 8e76340b541b8ee29023c001a5e4da18 2014-07-08T22:30:10-07:00 confd[16397]: WARNING Noop mode enabled /tmp/myconfig.conf will not be modified ```
Project: Kanister (Runtime / Cloud Native Storage)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: enhancement assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like 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. Environment Kubernetes Version/Provider: ... Storage Provider: ... Cluster Size (#nodes): ... Data Size: ... Additional context Add any other context or screenshots about the feature request here.
Project: lxd (Runtime / Container Runtime)
File: storage_create_instance.md

(howto-storage-create-instance)= Instance storage volumes are created in the storage pool that is specified by the instance's root disk device. This configuration is normally provided by the profile or profiles applied to the instance. See {ref}`storage-default-pool` for detailed information. To use a different storage pool when creating or launching an instance, add the `--storage` flag. This flag overrides the root disk device from the profile. For example: incus launch <image> <instancename> --storage <storagepool> % Include content from ```{include} storagemovevolume.md :start-after: (storage-move-instance)= ```
Project: Kata Containers (Runtime / Container Runtime)
File: history.md

In the old , the Kata was an executable called `kata-runtime`. The container manager called this executable multiple times when creating each container. Each time the runtime was called a different OCI command-line verb was provided. This architecture was simple, but not well suited to creating VM based containers due to the issue of handling state between calls. Additionally, the architecture suffered from performance issues related to continually having to spawn new instances of the runtime binary, and and processes for systems that did not provide VSOCK. See the section of the architecture document. | Kata version | Kata Runtime process calls | Kata shim processes | Kata proxy processes (if no VSOCK) | |-|-|-|-| | 1.x | multiple per container | 1 per container connection | 1 | | 2.x | 1 per VM (hosting any number of containers) | 0 | 0 | Notes: A single VM can host one or more containers. The "Kata shim processes" column refers to the old (`kata-shim` binary), not the new shimv2 runtime instance (`containerd-shim-kata-v2` binary). The diagram below shows how the original architecture was simplified with the advent of shimv2.
Project: Velero (Runtime / Cloud Native Storage)
File: supported-providers.md

title: "Providers" layout: docs Velero supports a variety of storage providers for different backup and snapshot operations. Velero has a plugin system which allows anyone to add compatibility for additional backup and volume storage platforms without modifying the Velero codebase. {{< table caption="Velero supported providers" >}} | Provider | Object Store | Volume Snapshotter | Plugin Provider Repo | Setup Instructions | Parameters | |--|--|-|--|-|| | | AWS S3 | AWS EBS | | | <br/> | | | | | | | <br/> | | | Azure Blob Storage | Azure Managed Disks | | | <br/> | | | | vSphere Volumes | | | | | | | CSI Volumes | | | | {{< /table >}} Contact: , {{< table caption="Community supported providers" >}} | Provider | Object Store | Volume Snapshotter | Plugin Documentation | Contact | |||||| | | Alibaba Cloud OSS | Alibaba Cloud | | | | | DigitalOcean Object Storage | DigitalOcean Volumes Block Storage | | | | | | HPE Storage | | , | | | | OpenEBS CStor Volume | | , | | | Swift | Cinder | | | | | | Portworx Volume | | , | | | Storj Object Storage | | | | {{< /table >}} Velero's AWS Object Store plugin uses to connect to the AWS S3 API. Some third-party storage providers also support the S3 API, and users have reported the following providers work with Velero: Note that these storage providers are not regularly tested by the Velero team. * * * Ceph RADOS v12.2.7 Quobyte Some storage providers, like Quobyte, may need a different . In the case you want to take volume snapshots but didn't find a plugin for your provider, Velero has support for snapshotting using restic. Please see the documentation.
Project: Weave Net (Runtime / Cloud Native Network)
File: host-network-integration.md

title: Integrating with the Host Network menu_order: 20 search_type: Documentation Weave application networks can be integrated with an external host network, establishing connectivity between the host and with application containers running anywhere. For example, returning to the , youve now decided that you need to have the application containers that are running on `$HOST2` accessible by other hosts and containers. On `$HOST2` run: host2$ weave expose 10.2.1.132 This command grants the host access to all of the application containers in the default subnet. An IP address is allocated by Weave Net especially for that purpose, and is returned after running `weave expose`. Now you are able to ping the host: host2$ ping 10.2.1.132 And you can also ping the `a1` netcat application container residing on `$HOST1`: host2$ ping $(weave dns-lookup a1) Multiple subnet addresses can be exposed or hidden using a single command: host2$ weave expose net:default net:10.2.2.0/24 10.2.1.132 10.2.2.130 host2$ weave hide net:default net:10.2.2.0/24 10.2.1.132 10.2.2.130 Exposed addresses can also be added to weaveDNS by supplying fully qualified domain names: host2$ weave expose -h exposed.weave.local 10.2.1.132 After running `weave expose`, you can use Linux routing to provide access to the Weave network from hosts that are not running Weave Net: ip route add <network-cidr> via <exposing-host> Where, `<network-cidr>` is an IP address range in use on Weave Net, for example, `10.2.0.0/16` or `10.32.0.0/12` and, `<exposing-host>` is the address of the machine on which you ran `weave expose`. Note: You must ensure that the [IP subnet used by Weave Net](/site/tasks/ipam/ipam.md#range) does not clash with anything on those other hosts. See Also *
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_map_events.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Display cached list of events for a BPF map ``` cilium-dbg map events <name> [flags] ``` ``` cilium map events cilium_ipcache ``` ``` -f, --follow If set then events will be streamed -h, --help help for events -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 ``` - Access userspace cached content of BPF maps
Project: Carina (Runtime / Cloud Native Storage)
File: PULL_REQUEST_TEMPLATE.md

<!-- Thanks for sending a pull request! Here are some tips for you: If this is your first time, please read our contributor guidelines: https://git.k8s.io/community/contributors/guide#your-first-contribution and developer guide https://git.k8s.io/community/contributors/devel/development.md#development-guide Follow the instructions for writing a release note: https://git.k8s.io/community/contributors/guide/release-notes.md If the PR is unfinished, see how to mark it: https://git.k8s.io/community/contributors/guide/pull-requests.md#marking-unfinished-pull-requests --> What type of PR is this? Uncomment only one ` /kind <>` line, hit enter to put that in a new line, and remove leading whitespaces from that line: /kind api-change /kind bug /kind cleanup /kind design /kind documentation /kind failing-test /kind feature /kind flake What this PR does / why we need it: Which issue(s) this PR fixes: <!-- *Automatically closes linked issue when PR is merged. Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. If PR is about `failing-tests or flakes`, please post the related issues/tests in a comment and do not use `Fixes`* --> Fixes # Special notes for your reviewer: Does this PR introduce a user-facing change?: <!-- If no, just write "NONE" in the release-note block below. If yes, a release note is required: Enter your extended release note in the block below. If the PR requires additional action from users switching to the new release, include the string "action required". --> ```release-note none ```