cwielenb/CNCF-Dataset huggingface dataset:
Project: lxd (Runtime / Container Runtime)
File: projects_work.md

(projects-work)= If you have more projects than just the `default` project, you must make sure to use or address the correct project when working with Incus. ```{note} If you have projects that are {ref}`confined to specific users <projects-confined>`, only users with full access to Incus can see all projects. Users without full access can only see information for the projects to which they have access. ``` To list all projects (that you have permission to see), enter the following command: incus project list By default, the output is presented as a list: ```{terminal} :input: incus project list :scroll: +-+--+-+--+--+-++++ | NAME | IMAGES | PROFILES | STORAGE VOLUMES | STORAGE BUCKETS | NETWORKS | NETWORK ZONES | DESCRIPTION | USED BY | +-+--+-+--+--+-++++ | default | YES | YES | YES | YES | YES | YES | Default Incus project | 19 | +-+--+-+--+--+-++++ | my-project (current) | YES | NO | NO | NO | YES | YES | | 0 | +-+--+-+--+--+-++++ ``` You can request a different output format by adding the `--format` flag. See for more information. By default, all commands that you issue in Incus affect the project that you are currently using. To see which project you are in, use the command. To switch to a different project, enter the following command: incus project switch <project_name> Instead of switching to a different project, you can target a specific project when running a command. Many Incus commands support the `--project` flag to run an action in a different project. ```{note} You can target only projects that you have permission for. ``` The following sections give some typical examples where you would typically target a project instead of switching to it. To list the instances in a specific project, add the `--project` flag to the command. For example: incus list --project my-project To move an instance from one project to another, enter the following command: incus move <instancename> <newinstancename> --project <sourceproject> --target-project <target_project> You can keep the same instance name if no instance with that name exists in the target project. For example, to move the instance `my-instance` from the `default` project to `my-project` and keep the instance name, enter the following command: incus move my-instance my-instance --project default --target-project my-project If you create a project with the default settings, profiles are isolated in the project ( is set to `true`). Therefore, the project does not have access to the default profile (which is part of the `default` project), and you will see an error similar to the following when trying to create an instance: ```{terminal} :input: incus launch images:ubuntu/22.04 my-instance Creating my-instance Error: Failed instance creation: Failed creating instance record: Failed initializing instance: Failed getting root disk: No root device could be found ``` To fix this, you can copy the contents of the `default` project's default profile into the current project's default profile. To do so, enter the following command: incus profile show default --project default | incus profile edit default
Project: lxd (Runtime / Container Runtime)
File: devices_unix_char.md

(devices-unix-char)= ```{note} The `unix-char` device type is supported for containers. It supports hotplugging. ``` Unix character devices make the specified character device appear as a device in the instance (under `/dev`). You can read from the device and write to it. `unix-char` devices have the following device options: % Include content from ```{include} ../config_options.txt :start-after: <!-- config group devices-unix-char-block start --> :end-before: <!-- config group devices-unix-char-block end --> ``` (devices-unix-char-hotplugging)= % Include content from ```{include} devicesunixblock.md :start-after: Hotplugging ```
Project: Triton Object Storage (Runtime / Cloud Native Storage)
File: sample-training.md

This document outlines sample topics for a training course on operating Manta. Docs: Manta Overview: https://github.com/TritonDataCenter/manta Manta Ops Guide: https://github.com/TritonDataCenter/manta/blob/master/docs/manta-ops.md Manatee Users Guide: https://github.com/TritonDataCenter/manatee/blob/master/docs/user-guide.md Manatee Troubleshooting Guide: https://github.com/TritonDataCenter/manatee/blob/master/docs/trouble-shooting.md Architecture Review Using Manta Get new users set up for Manta `m tools`: `mmkdir`, `mrmdir`, `mls`, `mfind`, `mput`, `mget`, `msign`, `mrm`, Basic Map/reduce patterns Discovery/Moving around `sdc-cnapi` `sdc-vmapi` `sdc-sapi` `sdc-login` `manta-login` - type, zonename, etc. `manta-adm` - show, cn Deployments `manta-adm` - `-s -j`, edit, `update -n`, `update` `manta-deploy` `manta-undeploy` `sapiadm reprovision ...` Upgrades Operations Typical Zone setup setup, `mdata:execute`, sapi_manifests, config-agent svcs, svcadm, svccfg Dashboards Via ssh tunnels like: `ssh -o TCPKeepAlive=yes -N -n root@[Headnode] -L 5555:[MadtomAdminIp]:80` Madtom: hint: sometimes it lies Marlin Dashboard Alarms mantamon Known issues Zookeeper Leader goes down Postgres needs vacuum/analyze Powering down Manta Command Line Tools/Where stuff is General `json` `bunyan` Zookeeper/binder `zkCli.sh` `dig @localhost` Postgres (Manatee) `manatee-adm` `psql moray` Moray/Electric Moray `getobject` `getbucket` Storage `/manta/[owner]/[object_id]` `/manta/tombstone/[date]/[object_id]`
Project: Kata Containers (Runtime / Container Runtime)
File: how-to-use-virtio-mem-with-kata.md

The basic idea of `virtio-mem` is to provide a flexible, cross-architecture memory hot plug and hot unplug solution that avoids many limitations imposed by existing technologies, architectures, and interfaces. More details can be found in https://lkml.org/lkml/2019/12/12/681. Kata Containers with `virtio-mem` supports memory resize. Kata Containers just supports `virtio-mem` with QEMU. Install and setup Kata Containers as shown . The `virtio-mem` config of the x86_64 Kata Linux kernel is open. Enable `virtio-mem` as follows: ``` $ sudo sed -i -e 's/^#enablevirtiomem.*$/enablevirtiomem = true/g' /etc/kata-containers/configuration.toml ``` The `virtio-mem` config of the others Kata Linux kernel is not open. You can open `virtio-mem` config as follows: ``` CONFIGVIRTIOMEM=y ``` Then you can build and install the guest kernel image as shown . Use following command to enable memory over-commitment of a Linux kernel. Because QEMU `virtio-mem` device need to allocate a lot of memory. ``` $ echo 1 | sudo tee /proc/sys/vm/overcommit_memory ``` Use following command to start a Kata Container. ``` $ pod_yaml=pod.yaml $ container_yaml=container.yaml $ image="quay.io/prometheus/busybox:latest" $ cat << EOF > "${pod_yaml}" metadata: name: busybox-sandbox1 uid: $(uuidgen) namespace: default EOF $ cat << EOF > "${container_yaml}" metadata: name: busybox-killed-vmm image: image: "$image" command: top EOF $ sudo crictl pull $image $ podid=$(sudo crictl runp $pod_yaml) $ cid=$(sudo crictl create $podid $containeryaml $podyaml) $ sudo crictl start $cid ``` Use the following command to set the container memory limit to 2g and the memory size of the VM to its default_memory + 2g. ``` $ sudo crictl update --memory $((210241024*1024)) $cid ``` Use the following command to set the container memory limit to 1g and the memory size of the VM to its default_memory + 1g. ``` $ sudo crictl update --memory $((110241024*1024)) $cid ```
Project: Singularity (Runtime / Container Runtime)
File: LICENSE-LBNL.md

Copyright (c) 2016-2017, The Regents of the University of California, through Lawrence Berkeley National Laboratory (subject to receipt of any required approvals from the U.S. Dept. of Energy). All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of the University of California, Lawrence Berkeley National Laboratory, U.S. Dept. of Energy nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. NOTICE. This Software was developed under funding from the U.S. Department of Energy and the U.S. Government consequently retains certain rights. As such, the U.S. Government has been granted for itself and others acting on its behalf a paid-up, nonexclusive, irrevocable, worldwide license in the Software to reproduce, distribute copies to the public, prepare derivative works, and perform publicly and display publicly, and to permit other to do so.
Project: Kilo (Runtime / Cloud Native Network)
File: CONTRIBUTING.md

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

sidebar_position: 3 sidebar_label: "Disk Storage Node" Raw disk storage nodes provide applications with raw disk data volumes and maintain the mapping between raw disks and raw disk data volumes on the storage node. Add the node to the Kubernetes cluster or select a Kubernetes node. For example, suppose you have a new node with the following information: name: k8s-worker-2 devPath: /dev/sdb diskType: SSD disk After the new node is already added into the Kubernetes cluster, make sure the following HwameiStor pods are already running on this node. ```bash $ kubectl get node NAME STATUS ROLES AGE VERSION k8s-master-1 Ready master 96d v1.24.3-2+63243a96d1c393 k8s-worker-1 Ready worker 96h v1.24.3-2+63243a96d1c393 k8s-worker-2 Ready worker 96h v1.24.3-2+63243a96d1c393 $ kubectl -n hwameistor get pod -o wide | grep k8s-worker-2 hwameistor-local-disk-manager-sfsf1 2/2 Running 0 19h 10.6.128.150 k8s-worker-2 <none> <none> $ kubectl get localdisknode k8s-worker-2 NAME FREECAPACITY TOTALCAPACITY TOTALDISK STATUS AGE k8s-worker-2 Ready 21d ``` First, change the `owner` information of the disk sdb to local-disk-manager as below: ```console $ kubectl edit ld localdisk-2307de2b1c5b5d051058bc1d54b41d5c apiVersion: hwameistor.io/v1alpha1 kind: LocalDisk metadata: name: localdisk-2307de2b1c5b5d051058bc1d54b41d5c spec: devicePath: /dev/sdb nodeName: k8s-worker-2 owner: local-disk-manager ... ``` Create the storage pool of the node by adding a LocalStorageClaim CR as below: ```console $ kubectl apply -f - <<EOF apiVersion: hwameistor.io/v1alpha1 kind: LocalDiskClaim metadata: name: k8s-worker-2 spec: nodeName: k8s-worker-2 owner: local-disk-manager description: diskType: SSD EOF ``` Finally, check if the node has created the storage pool by checking the LocalDiskNode CR. ```bash kubectl get localstoragenode k8s-worker-2 -o yaml ``` The output may look like: ```yaml apiVersion: hwameistor.io/v1alpha1 kind: LocalDiskNode metadata: name: k8s-worker-2 spec: nodeName: k8s-worker-2 status: pools: LocalDisk_PoolSSD: class: SSD disks: capacityBytes: 214744170496 devPath: /dev/sdb state: Available type: SSD freeCapacityBytes: 214744170496 freeVolumeCount: 1 totalCapacityBytes: 214744170496 totalVolumeCount: 1 type: REGULAR usedCapacityBytes: 0 usedVolumeCount: 0 volumeCapacityBytesLimit: 214744170496 volumes: state: Ready ```
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-aws_completion_fish.md

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> Generate the autocompletion script for fish Generate the autocompletion script for the fish shell. To load completions in your current shell session: cilium-operator-aws completion fish | source To load completions for every new session, execute once: cilium-operator-aws completion fish > ~/.config/fish/completions/cilium-operator-aws.fish You will need to start a new shell for this setup to take effect. ``` cilium-operator-aws completion fish [flags] ``` ``` -h, --help help for fish --no-descriptions disable completion descriptions ``` - Generate the autocompletion script for the specified shell
Project: CubeFS (Runtime / Cloud Native Storage)
File: env.md

Version: v3.3.1 | Node Type | Number of Nodes | CPU | Memory | Storage | Network | Remarks | |--|--|--||||| | Management Node | 3 | 8 Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz | 32GiB DDR4 2666 MHz | 197GiB HDD SCSI | 10 Gb/s | Docker container | | Metadata Node | 5 | 80 Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz | 377GiB DDR4 2933MHz | 4 x 3.7TiB SSD NVMe | 50 Gb/s | Mixed deployment | | Data Node | 5 | 80 Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz | 377GiB DDR4 2933MHz | 4 x 3.7TiB SSD NVMe | 50 Gb/s | Mixed deployment | No quota is set, and no flow control rate limit is set on DataNode. | Parameter | Default Value | Recommended Value | Description | |-||-|-| | FollowerRead | False | False | Whether to enable FollowerRead | | Capacity | 10 GB | 300,000,000 GB | Capacity | | Data Replica Number | 3 | 500 | Number of data replicas | | Meta Replica Number | 3 | 3 | Number of metadata replicas | | Data Partition Size | 120 GB | 120 GB | Theoretical upper limit, no space is pre-allocated | | Data Partition Count | 10 | 1500 | Number of data partitions | | Meta Partition Count | 3 | 10 | Number of metadata partitions | | Cross Zone | False | False | Whether to cross zones | Setting method: ```bash ./cfs-cli volume create test-vol {owner} --capacity=300000000 --mp-count=10 Create a new volume: Name : test-vol Owner : {owner} capacity : 300000000 G deleteLockTime : 0 h crossZone : false DefaultPriority : false description : mpCount : 10 replicaNum : size : 120 G volType : 0 followerRead : false readOnlyWhenFull : false zoneName : cacheRuleKey : ebsBlkSize : 8388608 byte cacheCapacity : 0 G cacheAction : 0 cacheThreshold : 10485760 byte cacheTTL : 30 day cacheHighWater : 80 cacheLowWater : 60 cacheLRUInterval : 5 min TransactionMask : TransactionTimeout : 1 min TxConflictRetryNum : 0 TxConflictRetryInterval : 0 ms Confirm (yes/no)[yes]: yes Create volume success. ``` Expand dp to 500 ```bash curl -v "http://10.196.59.198:17010/dataPartition/create?count=32&name=test-vol" ```
Project: Piraeus Datastore (Runtime / Cloud Native Storage)
File: linstor-affinity-controller.md

This guide shows you how to deploy the [LINSTOR Affinity Controller] for Piraeus Datastore. The LINSTOR Affinity Controller keeps the affinity of your volumes in sync between Kubernetes and LINSTOR. When using a strict volume affinity setting, such as `allowRemoteVolumeAccess: false`, the Persistent Volume (PV) resource created by Piraeus Datastore will have a fixed affinity. When the volume is moved to a different node, for example because one of the existing replicas is being evacuated, the PV is not updated automatically. The LINSTOR Affinity controller watches PVs and LINSTOR resource and keeps the affinity up-to-date. To complete this guide, you should be familiar with: Deploying workloads in Kubernetes using Piraeus Datastore maintains a helm chart repository for commonly deployed components, including the LINSTOR Affinity Controller. To add the repository to your helm configuration, run: ``` $ helm repo add piraeus-charts https://piraeus.io/helm-charts/ ``` After adding the repository, deploy the LINSTOR Affinity Controller: ``` $ helm install linstor-affinity-controller piraeus-charts/linstor-affinity-controller NAME: linstor-affinity-controller LAST DEPLOYED: Mon Dec 4 09:14:07 2023 NAMESPACE: piraeus-datastore STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: LINSTOR Affinity Controller deployed. Used LINSTOR URL: http://linstor-controller.piraeus-datastore.svc:3370 ``` If you deploy the LINSTOR Affinity Controller to the same namespace as the Piraeus Operator, the deployment will automatically determine the necessary parameters for connecting to LINSTOR. In some cases, helm may not be able to determine the connection parameters. In this case, you need to manually provide the following values: ```yaml linstor: endpoint: http://linstor-controller.piraeus-datastore.svc:3370 clientSecret: "" options: propertyNamespace: Aux/topology ```
Project: Kata Containers (Runtime / Container Runtime)
File: DeviceNode.md

Name | Type | Description | Notes | - | - | - Id | Pointer to string | | [optional] Resources | Pointer to []map[string]interface{} | | [optional] Children | Pointer to []string | | [optional] PciBdf | Pointer to string | | [optional] `func NewDeviceNode() *DeviceNode` NewDeviceNode instantiates a new DeviceNode 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 NewDeviceNodeWithDefaults() *DeviceNode` NewDeviceNodeWithDefaults instantiates a new DeviceNode 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 *DeviceNode) GetId() string` GetId returns the Id field if non-nil, zero value otherwise. `func (o DeviceNode) GetIdOk() (string, bool)` GetIdOk returns a tuple with the Id field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *DeviceNode) SetId(v string)` SetId sets Id field to given value. `func (o *DeviceNode) HasId() bool` HasId returns a boolean if a field has been set. `func (o *DeviceNode) GetResources() []map[string]interface{}` GetResources returns the Resources field if non-nil, zero value otherwise. `func (o DeviceNode) GetResourcesOk() ([]map[string]interface{}, bool)` GetResourcesOk returns a tuple with the Resources field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *DeviceNode) SetResources(v []map[string]interface{})` SetResources sets Resources field to given value. `func (o *DeviceNode) HasResources() bool` HasResources returns a boolean if a field has been set. `func (o *DeviceNode) GetChildren() []string` GetChildren returns the Children field if non-nil, zero value otherwise. `func (o DeviceNode) GetChildrenOk() ([]string, bool)` GetChildrenOk returns a tuple with the Children field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *DeviceNode) SetChildren(v []string)` SetChildren sets Children field to given value. `func (o *DeviceNode) HasChildren() bool` HasChildren returns a boolean if a field has been set. `func (o *DeviceNode) GetPciBdf() string` GetPciBdf returns the PciBdf field if non-nil, zero value otherwise. `func (o DeviceNode) GetPciBdfOk() (string, bool)` GetPciBdfOk returns a tuple with the PciBdf field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *DeviceNode) SetPciBdf(v string)` SetPciBdf sets PciBdf field to given value. `func (o *DeviceNode) HasPciBdf() bool` HasPciBdf returns a boolean if a field has been set.
Project: Rook (Runtime / Cloud Native Storage)
File: common-issues.md

title: Common Issues To help troubleshoot your Rook clusters, here are some tips on what information will help solve the issues you might be seeing. If after trying the suggestions found on this page and the problem is not resolved, the Rook team is very happy to help you troubleshoot the issues in their Slack channel. Once you have , proceed to the General channel to ask for assistance. For common issues specific to Ceph, see the page. Kubernetes status and logs are the main resources needed to investigate issues in any Rook cluster. Kubernetes status is the first line of investigating when something goes wrong with the cluster. Here are a few artifacts that are helpful to gather: Rook pod status: `kubectl get pod -n <cluster-namespace> -o wide` e.g., `kubectl get pod -n rook-ceph -o wide` Logs for Rook pods Logs for the operator: `kubectl logs -n <cluster-namespace> -l app=<storage-backend-operator>` e.g., `kubectl logs -n rook-ceph -l app=rook-ceph-operator` Logs for a specific pod: `kubectl logs -n <cluster-namespace> <pod-name>`, or a pod using a label such as mon1: `kubectl logs -n <cluster-namespace> -l <label-matcher>` e.g., `kubectl logs -n rook-ceph -l mon=a` Logs on a specific node to find why a PVC is failing to mount: Connect to the node, then get kubelet logs (if your distro is using systemd): `journalctl -u kubelet` Pods with multiple containers For all containers, in order: `kubectl -n <cluster-namespace> logs <pod-name> --all-containers` For a single container: `kubectl -n <cluster-namespace> logs <pod-name> -c <container-name>` Logs for pods which are no longer running: `kubectl -n <cluster-namespace> logs --previous <pod-name>` Some pods have specialized init containers, so you may need to look at logs for different containers within the pod. `kubectl -n <namespace> logs <pod-name> -c <container-name>` Other Rook artifacts: `kubectl -n <cluster-namespace> get all`