cwielenb/CNCF-Dataset huggingface dataset:
Project: Velero (Runtime / Cloud Native Storage)
File: support-process.md

title: "Support Process" layout: docs Velero provides best effort support through the process on this page for the current version of Velero and n-1 Velero version, including all patch releases in the supported minor releases. For example, if the current version is 1.9, the Velero maintainers would offer best effort support for v1.9 and v1.8. If you have a question about a previous Velero version (for example, 1.7), please note that maintainers may ask you to upgrade to a supported version before doing any investigation into your issue. For more information about Velero testing and supported Kubernetes versions, see Velero's . The Velero maintainers use a weekly rotation to manage community support. Each week, a different maintainer is the point person for responding to incoming support issues via Slack, GitHub, and the Google group. The point person is not expected to be on-call 24x7. Instead, they choose one or more hour(s) per day to be available/responding to incoming issues. They will communicate to the community what that time slot will be each week. We will update the public Slack channel's topic to indicate that you are the point person for the week, and what hours you'll be available. `#velero` public Slack channel in Kubernetes org in GitHub (`velero`, `velero-plugin-for-[aws|gcp|microsoft-azure|csi]`, `helm-charts`) Generally speaking, new GitHub issues will fall into one of several categories. We use the following process for each: Feature request Label the issue with `Enhancement/User` or `Enhancement/Dev` Leave the issue in the `New Issues` swimlane for triage by product mgmt Bug Label the issue with `Bug` Leave the issue in the `New Issues` swimlane for triage by product mgmt User question/problem that does not clearly fall into one of the previous categories When you start investigating/responding, label the issue with `Investigating` Add comments as you go, so both the user and future support people have as much context as possible Use the `Needs Info` label to indicate an issue is waiting for information from the user. Remove/re-add the label as needed. If you resolve the issue with the user, close it out If the issue ends up being a feature request or a bug, update the title and follow the appropriate process for it If the reporter becomes unresponsive after multiple pings, close out the issue due to inactivity and comment that the user can always reach out again as needed We ensure all GitHub issues worked on during the week on are labeled with `Investigating` and `Needs Info` (if appropriate), and have updated comments so the next person can pick them up.
Project: containerd (Runtime / Container Runtime)
File: mounts.md

Mounts are the main interaction mechanism in containerd. Container systems of the past typically end up having several disparate components independently perform mounts, resulting in complex lifecycle management and buggy behavior when coordinating large mount stacks. In containerd, we intend to keep mount syscalls isolated to the container runtime component, opting to have various components produce a serialized representation of the mount. This ensures that the mounts are performed as a unit and unmounted as a unit. From an architecture perspective, components produce mounts and runtime executors consume them. More imaginative use cases include the ability to virtualize a series of mounts from various components without ever having to create a runtime. This will aid in testing and implementation of satellite components. The `Mount` type follows the structure of the historic mount syscall: | Field | Type | Description | |-|-|-| | Type | `string` | Specific type of the mount, typically operating system specific | | Target | `string` | Intended filesystem path for the mount destination. | | Source | `string` | The object which originates the mount, typically a device or another filesystem path. | | Options | `[]string` | Zero or more options to apply with the mount, possibly `=`-separated key value pairs. | We may want to further parameterize this to support mounts with various helpers, such as `mount.fuse`, but this is out of scope, for now.
Project: WasmEdge Runtime (Runtime / Container Runtime)
File: frameworks.md

WasmEdge applications can be plugged into existing application frameworks or platforms. WasmEdge provides a safe and efficient extension mechanism for those frameworks. In this chapter, we will introduce several such frameworks and platforms. support WasmEdge to run as containers for microservices. We will cover distributed application framework , service mesh , and event mesh . support WasmEdge as an embedded function or plug-in runtime. We will cover streaming data framework and Go function schedulder / framework . allows WasmEdge programs to run as serverless functions in their infrastructure. We will cover , , , , and .
Project: Velero (Runtime / Cloud Native Storage)
File: upgrade-to-1.12.md

title: "Upgrading to Velero 1.12" layout: docs Velero installed. If you're not yet running at least Velero v1.7, see the following: Before upgrading, check the to make sure your version of Kubernetes is supported by the new version of Velero. Caution: From Velero v1.10, except for using restic to do file-system level backup and restore, kopia is also been integrated, it could be upgraded from v1.10 or higher to v1.12 directly, but it would be a little bit of difference when upgrading to v1.12 from a version lower than v1.10.0. Install the Velero v1.12 command-line interface (CLI) by following the . Verify that you've properly installed it by running: ```bash velero version --client-only ``` You should see the following output: ```bash Client: Version: v1.12.0 Git commit: <git SHA> ``` Update the Velero custom resource definitions (CRDs) to include schema changes across all CRDs that are at the core of the new features in this release: ```bash velero install --crds-only --dry-run -o yaml | kubectl apply -f - ``` NOTE: Since velero v1.10.0 only v1 CRD will be supported during installation, therefore, the v1.10.0 will only work on Kubernetes version >= v1.16 Update the container image and objects fields used by the Velero deployment and, optionally, the restic daemon set: ```bash kubectl get deploy -n velero -ojson \ | sed "s#\"image\"\: \"velero\/velero\:v[0-9].[0-9].[0-9]\"#\"image\"\: \"velero\/velero\:v1.12.0\"#g" \ | sed "s#\"server\",#\"server\",\"--uploader-type=$uploader_type\",#g" \ | sed "s#default-volumes-to-restic#default-volumes-to-fs-backup#g" \ | sed "s#default-restic-prune-frequency#default-repo-maintain-frequency#g" \ | sed "s#restic-timeout#fs-backup-timeout#g" \ | kubectl apply -f - echo $(kubectl get ds -n velero restic -ojson) \ | sed "s#\"image\"\: \"velero\/velero\:v[0-9].[0-9].[0-9]\"#\"image\"\: \"velero\/velero\:v1.12.0\"#g" \ | sed "s#\"name\"\: \"restic\"#\"name\"\: \"node-agent\"#g" \ | sed "s#\[ \"restic\",#\[ \"node-agent\",#g" \ | kubectl apply -f - kubectl delete ds -n velero restic --force --grace-period 0 ``` Confirm that the deployment is up and running with the correct version by running: ```bash velero version ``` You should see the following output: ```bash Client: Version: v1.12.0 Git commit: <git SHA> Server: Version: v1.12.0 ``` If it's directly upgraded from v1.10 or higher, the other steps remain the same only except for step 3 above. The details as below: Update the container image used by the Velero deployment, plugin and, optionally, the node agent daemon set: ```bash kubectl set image deployment/velero \ velero=velero/velero:v1.12.0 \ velero-plugin-for-aws=velero/velero-plugin-for-aws:v1.8.0 \ --namespace velero kubectl set image daemonset/node-agent \ node-agent=velero/velero:v1.12.0 \ --namespace velero ``` If upgraded from v1.9.x, there still remains some resources left over in the cluster and never used in v1.12.x, which could be deleted through kubectl and it is based on your desire: resticrepository CRD and related CRs velero-restic-credentials secret in velero install namespace
Project: Velero (Runtime / Cloud Native Storage)
File: 2019-10-01-announcing-gh-move.md

title: Announcing a new GitHub home for Velero slug: announcing-gh-move image: /img/posts/vmware-tanzu.png excerpt: The next Velero release (v1.2) will be built out of a new GitHub organization, and we have significant changes to our plugins. author_name: Carlisia Thompson author_avatar: /img/contributors/carlisia-thompson.png categories: ['velero'] tags: ['Carlisia Thompson'] We are now part of a brand new GitHub organization: . VMware Tanzu is a new family of projects, products and services for the cloud native world. With the Velero project being a cloud native technology that extends Kubernetes, it is only natural that it would be moved to sit alongside all the other VMware-supported cloud native repositories. You can read more about this change in this . The new Velero repository can now be found at . Past issues, pull requests, commits, contributors, etc., have all been moved to this repo. The next Velero release, version 1.2, will be built out of this new repository and is slated to come out at the end of October. The main for version 1.2 is the restructuring around how we will be handling all Object Store and Volume Snapshotter plugins. Previously, Velero included both types of plugins for AWS, Microsoft Azure, and Google Cloud Platform (GCP) in-tree. Beginning with Velero 1.2, these plugins will be moved out of tree and installed like any other plugin. With more and more providers wanting to support Velero, it gets more difficult to justify excluding new plugins from being in-tree while continuing to maintain the AWS, Microsoft Azure, and GCP plugins in-tree. At the same time, if we were to include any more plugins in-tree, it would ultimately become the responsibility of the Velero team to maintain an increasing number of plugins in an unsustainable way. As the opportunity to move to a new GitHub organization presented itself, we thought it was a good time to make structural changes. The three original native plugins and their respective documentation will each have their own repo under the new VMware Tanzu GitHub organization as of version 1.2. You will be able to find them by looking up our list of . Maintenance of these plugins will continue to be done by the Velero core team as usual, although we will gladly promote active contributors to maintainers. This change mainly aims to achieve the following goals: Interface with all plugins equally and consistently Encourage developers to get involved with the smaller code base of each plugin and potentially be promoted to plugin maintainers Iterate on plugins separately from the core codebase Reduce the size of the Velero binaries and images by extracting these SDKs and having a separate release for each individual provider Instructions for upgrading to version 1.2 and installing Velero and its plugins will be added to . As always, we welcome feedback and participation in the development of Velero. All information on how to contact us or become involved can be found here: https://velero.io/community/
Project: Piraeus Datastore (Runtime / Cloud Native Storage)
File: talos.md

This guide shows you how to set the DRBD Module Loader when using [Talos Linux]. To complete this guide, you should be familiar with: editing `LinstorSatelliteConfiguration` resources. using the `talosctl` command line to to access Talos Linux nodes. using the `kubectl` command line tool to access the Kubernetes cluster. By default, the DRBD Module Loader will try to find the necessary header files to build DRBD from source on the host system. In [Talos Linux] these header files are not included in the host system. Instead, the Kernel modules is packed into a system extension. Ensure Talos has the correct `drbd` loaded for the running Kernel. This can be achieved by updating the machine config: ```yaml machine: install: extensions: image: ghcr.io/siderolabs/drbd:9.2.0-v1.3.6 kernel: modules: name: drbd parameters: usermode_helper=disabled name: drbdtransporttcp ``` NOTE: Replace `v1.3.6` with the Talos version running. Validate `drbd` module is loaded: ```shell $ talosctl -n <NODE_IP> read /proc/modules drbdtransporttcp 28672 - - Live 0xffffffffc046c000 (O) drbd 643072 - - Live 0xffffffffc03b9000 (O) ``` Validate `drbd` module parameter `usermode_helper` is set to `disabled`: ```shell $ talosctl -n <NODEIP> read /sys/module/drbd/parameters/usermodehelper disabled ``` To change the DRBD Module Loader, so that it uses the modules provided by system extension, apply the following `LinstorSatelliteConfiguration`: ```yaml apiVersion: piraeus.io/v1 kind: LinstorSatelliteConfiguration metadata: name: talos-loader-override spec: podTemplate: spec: initContainers: name: drbd-shutdown-guard $patch: delete name: drbd-module-loader $patch: delete volumes: name: run-systemd-system $patch: delete name: run-drbd-shutdown-guard $patch: delete name: systemd-bus-socket $patch: delete name: lib-modules $patch: delete name: usr-src $patch: delete name: etc-lvm-backup hostPath: path: /var/etc/lvm/backup type: DirectoryOrCreate name: etc-lvm-archive hostPath: path: /var/etc/lvm/archive type: DirectoryOrCreate ``` Explanation: `/etc/lvm/` is read-only in Talos and therefore can't be used. Let's use `/var/etc/lvm/` instead. Talos does not ship with Systemd, so everything Systemd related needs to be removed `/usr/lib/modules` and `/usr/src` are not needed as the Kernel module is already compiled and needs just to be used.
Project: StratoVirt (Runtime / Container Runtime)
File: stratovirt-img.md

stratovirt-img is an offline tool for virtual disks. Usage: ```shell stratovirt-img command [command options] ``` Command parameters: img_path: the path for image. fmt: disk format. img_size: size for image, the unit can be K, M, G or none for bytes. options is a comma separated list of format specific options in a name=value format. Following commands are supported now: Create virtual disk with different format. Command syntax: ```shell create [-f fmt] [-o options] imgpath imgsize ``` Sample Configuration ```shell stratovirt-img create -f raw imgpath imgsize stratovirt-img create -f qcow2 -o cluster-size=65536 imgpath imgsize ``` Note: 1. The cluster size can be only be set for `qcow2` or default to 65536. 2. Disk format is default to raw. Check if there are some mistakes on the image and choose to fix. Command syntax: ```shell check [-r {leaks|all}] [-noprinterror] [-f fmt] img_path ``` -r: `leaks` means only the leaked cluster will be fixed, `all` means all repairable mistake will be fixed. -noprinterror: do not print detailed error messages. Sample Configuration ```shell stratovirt-img check img_path ``` Note: The command of check is not supported by raw format. Change the virtual size of the disk. `+size`means increase from old size, while `size` means resize to new size. Command syntax: ```shell resize [-f fmt] img_path [+]size ``` Sample Configuration ```shell stratovirt-img resize -f qcow2 img_path +size stratovirt-img resize -f raw img_path +size ``` Note: Shrink operation is not supported now. Operating internal snapshot for disk, it is only supported by qcow2. Command syntax: ```shell snapshot [-l | -a snapshotname | -c snapshotname | -d snapshotname] imgpath ``` -a snapshot_name: applies a snapshot (revert disk to saved state). -c snapshot_name: creates a snapshot. -d snapshot_name: deletes a snapshot. -l: lists all snapshots in the given image. Sample Configuration ```shell stratovirt-img snapshot -c snapshotname imgpath stratovirt-img snapshot -a snapshotname imgpath stratovirt-img snapshot -d snapshotname imgpath stratovirt-img snapshot -l img_path ``` Note: The internal snapshot is not supported by raw.
Project: Rook (Runtime / Cloud Native Storage)
File: custom-images.md

title: Custom Images By default, Rook will deploy the latest stable version of the Ceph CSI driver. Commonly, there is no need to change this default version that is deployed. For scenarios that require deploying a custom image (e.g. downstream releases), the defaults can be overridden with the following settings. The CSI configuration variables are found in the `rook-ceph-operator-config` ConfigMap. These settings can also be specified as environment variables on the operator deployment, though the configmap values will override the env vars if both are specified. ```console kubectl -n $ROOKOPERATORNAMESPACE edit configmap rook-ceph-operator-config ``` The default upstream images are included below, which you can change to your desired images. ```yaml ROOKCSICEPH_IMAGE: "quay.io/cephcsi/cephcsi:v3.11.0" ROOKCSIREGISTRAR_IMAGE: "registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.10.1" ROOKCSIPROVISIONER_IMAGE: "registry.k8s.io/sig-storage/csi-provisioner:v4.0.1" ROOKCSIATTACHER_IMAGE: "registry.k8s.io/sig-storage/csi-attacher:v4.5.1" ROOKCSIRESIZER_IMAGE: "registry.k8s.io/sig-storage/csi-resizer:v1.10.1" ROOKCSISNAPSHOTTER_IMAGE: "registry.k8s.io/sig-storage/csi-snapshotter:v7.0.2" ROOKCSIADDONSIMAGE: "quay.io/csiaddons/k8s-sidecar:v0.8.0" ``` If image version is not passed along with the image name in any of the variables above, Rook will add the corresponding default version to that image. Example: if `ROOKCSICEPH_IMAGE: "quay.io/private-repo/cephcsi"` is passed, Rook will add internal default version and consume it as `"quay.io/private-repo/cephcsi:v3.11.0"`. If you would like Rook to use the default upstream images, then you may simply remove all variables matching `ROOKCSI*_IMAGE` from the above ConfigMap and/or the operator deployment. You can use the below command to see the CSI images currently being used in the cluster. Note that not all images (like `volumereplication-operator`) may be present in every cluster depending on which CSI features are enabled. ```console kubectl --namespace rook-ceph get pod -o jsonpath='{range .items[]}{range .spec.containers[]}{.image}{"\n"}' -l 'app in (csi-rbdplugin,csi-rbdplugin-provisioner,csi-cephfsplugin,csi-cephfsplugin-provisioner)' | sort | uniq ``` The default images can also be found with each release in the
Project: Gluster (Runtime / Cloud Native Storage)
File: ganesha-ha.md

The ganesha_mon RA monitors its ganesha.nfsd daemon. While the daemon is running, it creates two attributes: ganesha-active and grace-active. When the daemon stops for any reason, the attributes are deleted. Deleting the ganesha-active attribute triggers the failover of the virtual IP (the IPaddr RA) to another node according to constraint location rules where ganesha.nfsd is still running. The ganesha_grace RA monitors the grace-active attribute. When the grace-active attibute is deleted, the ganesha_grace RA stops, and will not restart. This triggers pacemaker to invoke the notify action in the ganesha_grace RAs on the other nodes in the cluster; which send a DBUS message to their respective ganesha.nfsd. (N.B. grace-active is a bit of a misnomer. while the grace-active attribute exists, everything is normal and healthy. Deleting the attribute triggers putting the surviving ganesha.nfsds into GRACE.) To ensure that the remaining/surviving ganesha.nfsds are put into NFS-GRACE before the IPaddr (virtual IP) fails over there is a short delay (sleep) between deleting the grace-active attribute and the ganesha-active attribute. To summarize, e.g. in a four node cluster: on node 2 ganesha_mon::monitor notices that ganesha.nfsd has died on node 2 ganesha_mon::monitor deletes its grace-active attribute on node 2 ganesha_grace::monitor notices that grace-active is gone and returns OCFERRGENERIC, a.k.a. new error. When pacemaker tries to (re)start ganesha_grace, its start action will return OCFNOTRUNNING, a.k.a. known error, don't attempt further restarts. on nodes 1, 3, and 4, ganesha_grace::notify receives a post-stop notification indicating that node 2 is gone, and sends a DBUS message to its ganesha.nfsd, putting it into NFS-GRACE. on node 2 ganesha_mon::monitor waits a short period, then deletes its ganesha-active attribute. This triggers the IPaddr (virt IP) failover according to constraint location rules.
Project: Kanister (Runtime / Cloud Native Storage)
File: ROADMAP.md

Please join the Kanister community to give feedback on the roadmap and open issues with your suggestions. Lifecycle for contributors: Roles, Privs, and lifecycle project admin? maintainer (core) reviewer+approval: PR + branch protections? contributor Blueprints Maintenance and Support Policy project test matrix: Kopia vs Restic vs Stow, downstream adopters vs Kanister standalone community maintained examples: move to a new public repo Move the Kanister.io website to GitHub Repo Leverage GitHub Issues and Projects for planning Fork block storage functions, deprecate unused Kanister code Kopia.io Repository Controller with a CR to control the lifecycle of a Kopia Repository Server ActionSet metrics Container image vulnerability scanning Track and log events triggered by Blueprint Actions ARM support Use GitHub pages with Jekyll or Hugo for documentation Vault integration for Repository Server secrets Deprecate Restic Generate Kanister controller using KubeBuilder - current one is based on rook operator Merge the Repository controller into the Kanister controller after 2. Replace package with a supported fork Replace http://gopkg.in/check.v1 with a better test framework Release notes Adopt license scanning tool and OpenSSF Best Practices Badge
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_node.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage cluster nodes ``` -h, --help help for node ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI - List nodes
Project: StratoVirt (Runtime / Container Runtime)
File: test.md

StratoVirt supports two test modes: unit test and mod test. It should be noted that mod test is not fully supported on the x86_64 architecture now. Unit tests are Rust functions that verify that the non-test code is functioning in the expected manner. We recommend performing unit test execution separately, run StratoVirt unit test as follows: ```shell $ cargo test --workspace --exclude mod_test -- --nocapture --test-threads=1 ``` StratoVirt mod test is an integrated testing method. During the test, the StratoVirt process will be started as the server and communicate through socket and QMP to test the StratoVirt module function. Before running mod test, we need to compile `stratovirt` and `virtiofsd` first, and then export the environment variables `STRATOVIRTBINARY` and `VIRTIOFSDBINARY`. Build StratoVirt: ```shell $ cargo build --workspace --bins --release --target=aarch64-unknown-linux-gnu --all-features ``` Build virtiofsd: ```shell $ git clone https://gitlab.com/virtio-fs/virtiofsd.git $ cd virtiofsd $ cargo build --release ``` Export the environment variables `STRATOVIRTBINARY` and `VIRTIOFSDBINARY`: ```shell $ export STRATOVIRT_BINARY="/path/to/stratovirt" $ export VIRTIOFSD_BINARY="/path/to/virtiofsd" ``` Run StratoVirt mod test as follows: ```shell $ cargo test --all-features -p mod_test -- --nocapture --test-threads=1 ```
Project: CubeFS (Runtime / Cloud Native Storage)
File: metapartition.md

Get information of the specified meta Partition. ```bash cfs-cli metapartition info [Partition ID] ``` Decommission the specified meta partition on the target node and automatically transfer it to other available nodes. ```bash cfs-cli metapartition decommission [Address] [Partition ID] ``` Add a new meta partition on the target node. ```bash cfs-cli metapartition add-replica [Address] [Partition ID] ``` Delete the meta partition on the target node. ```bash cfs-cli metapartition del-replica [Address] [Partition ID] ``` Fault diagnosis, find meta partitions that are mostly unavailable and missing. ```bash cfs-cli metapartition check ```