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

If an ActionSet fails to perform an action, then the failure events can be seen in the respective ActionSet as well as its associated Blueprint by using the following commands: ``` bash $ kubectl --namespace kanister describe actionset <ActionSet Name> Events: Type Reason Age From Message - - - Normal Started Action 14s Kanister Controller Executing action delete Normal Started Phase 14s Kanister Controller Executing phase deleteFromS3 Warning ActionSetFailed Action: delete 13s Kanister Controller Failed to run phase 0 of action delete: command terminated with exit code 1 $ kubectl --namespace kanister describe blueprint <Blueprint Name> Events: Type Reason Age From Message - - - Normal Added 4m Kanister Controller Added blueprint 'Blueprint Name' Warning ActionSetFailed Action: delete 1m Kanister Controller Failed to run phase 0 of action delete: command terminated with exit code 1 ``` If you ever need to debug a live Kanister system and the information available in ActionSets you might have created is not enough, looking at the Kanister controller logs might help. Assuming you have deployed the controller in the `kanister` namespace, you can use the following commands to get controller logs. ``` bash $ kubectl get pods --namespace kanister NAME READY STATUS RESTARTS AGE release-kanister-operator-1484730505-l443d 1/1 Running 0 1m $ kubectl logs -f <operator-pod-name-from-above> --namespace kanister ``` If you are not successful in verifying the reason behind the failure, please reach out to us on or file an issue on . A [mailing list](https://groups.google.com/forum/#!forum/kanisterio) is also available if needed. For the validating webhook to work, the Kubernetes API Server needs to connect to port `9443` of the Kanister operator. If your cluster has a firewall setup, it has to be configured to allow that communication. If you get an error while applying a blueprint, that the webhook can\'t be reached, check if your firewall misses a rule for port `9443`: ``` console $ kubectl apply -f blueprint.yaml Error from server (InternalError): error when creating "blueprint.yaml": Internal error occurred: failed calling webhook "blueprints.cr.kanister.io": failed to call webhook: Post "https://kanister-kanister-operator.kanister.svc:443/validate/v1alpha1/blueprint?timeout=5s": context deadline exceeded ``` See [GKE: Adding firewall rules for specific use cases](https://cloud.google.com/kubernetes-engine/docs/how-to/private-clusters#addfirewallrules) and [kubernetes/kubernetes: Using non-443 ports for admission webhooks requires firewall rule in GKE](https://github.com/kubernetes/kubernetes/issues/79739) for more details.
Project: CubeFS (Runtime / Cloud Native Storage)
File: volume.md

A volume is a logical concept composed of multiple metadata and data shards. From the client's perspective, a volume can be seen as a file system instance that can be accessed by containers. A volume can be mounted in multiple containers, allowing files to be accessed by different clients simultaneously. From the perspective of object storage, a volume corresponds to a bucket. The following will introduce how to create volumes in different modes. For more volume operations, please refer to . Request the master service interface to create a volume. name: volume name capacity: volume quota. If the quota is used up, it needs to be expanded. owner: the owner of the volume. If there is no user with the same name as the owner in the cluster, a user with the user ID of Owner will be created automatically. ``` bash curl -v "http://127.0.0.1:17010/admin/createVol?name=test&capacity=100&owner=cfs" ``` ::: tip Tip Example of expanding the volume (where authKey is the MD5 value of the volume owner string). ```shell curl -v "http://127.0.0.1:17010/vol/expand?name=test&authKey=57f0162b2303be3449c7008484b0d306&capacity=200" ``` ::: If the Blobstore erasure-coded subsystem is deployed, you can create an erasure-coded volume to store cold data. ```bash curl -v 'http://127.0.0.1:17010/admin/createVol?name=test-cold&capacity=100&owner=cfs&volType=1' ``` name: volume name capacity: volume quota. If the quota is used up, it needs to be expanded. owner: the owner of the volume. volType: volume type. 0 for replicated volume, 1 for erasure-coded volume. The default is 0. You can create an erasure-coded volume and set multiple replicas as read-write cache. Cache read data ```bash curl -v 'http://127.0.0.1:17010/admin/createVol?name=test-cold&capacity=100&owner=cfs&volType=1&cacheCap=10&cacheAction=1' ``` name: volume name capacity: volume quota. If the quota is used up, it needs to be expanded. owner: the owner of the volume. volType: volume type. 0 for replicated volume, 1 for erasure-coded volume. The default is 0. cacheCap: cache size in GB. cacheAction: cache type. 0 for no cache, 1 for cache read, 2 for cache read-write. The default is 0. Cache read and write data ```bash curl -v 'http://127.0.0.1:17010/admin/createVol?name=test-cold&capacity=100&owner=cfs&volType=1&cacheCap=10&cacheAction=2' ``` name: volume name capacity: volume quota. If the quota is used up, it needs to be expanded. owner: the owner of the volume. volType: volume type. 0 for replicated volume, 1 for erasure-coded volume. The default is 0. cacheCap: cache size in GB. cacheAction: cache type. 0 for no cache, 1 for cache read, 2 for cache read-write. The default is 0.
Project: Longhorn (Runtime / Cloud Native Storage)
File: 20230815-engine-upgrade-enforcement.md

The current Longhorn upgrade process lacks enforcement of the engine version, potentially leading to compatibility issues. To address this concern, we propose the implementation of an Engine Upgrade Enforcement feature. https://github.com/longhorn/longhorn/issues/5842 Longhorn needs to be able to upgrade safely without risking compatibility issue with older version engine images. Without this enhancement, we are facing various challenges like dealing with potential operation failures and increased maintenance overhead. The primary goal of this proposal is to enhance Longhorn's upgrade mechanism by introducing logic that prevents upgrading to Longhorn versions while there are incompatible engine images in use. `None` This proposal focuses on preventing users from upgrading to unsupported or incompatible engine versions. This enhancement will build upon the existing pre-upgrade checks to include validation of engine version compatibility. Previously, users had the freedom to continue using an older engine version after a Longhorn upgrade. With the proposed enhancement, the Longhorn upgrade process will be blocked if it includes an incompatible engine version. This will enforce users to manually upgrade the engine to a compatible version before proceeding with the Longhorn upgrade. User will perform upgrade a usual. Longhorn will examine the compatibility of the current engine version. If the current engine version is incompatible with the target engine version for the upgrade, Longhorn will halt the upgrade process and prompt the user to address the engine version mismatch before proceeding. `None` The implementation approach for this feature will be similar to the . Key implementation steps include: Enhance the function to include the new checks. ``` func CheckUpgradePathSupported(namespace string, lhClient lhclientset.Interface) error { if err := CheckLHUpgradePathSupported(namespace, lhClient); err != nil { return err } return CheckEngineUpgradePathSupported(namespace, lhClient, emeta.GetVersion()) } ``` Retrieve the current engine images being used and record the versions. Prevent upgrades if the targeting engine version is detact to be downgrading. Prevent upgrades if the engine image version is lower than . Create unit test for the new logic. Run manual test to verify the handling of incompatible engine image versions (e.g., Longhorn v1.4.x -> v1.5.x -> v1.6.x.) `None` `None`
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_sha_get.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Get datapath SHA header ``` cilium-dbg bpf sha get <sha> [flags] ``` ``` -h, --help help for get -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 ``` - Manage compiled BPF template objects
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_endpoint.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Local endpoint map ``` -h, --help help for endpoint ``` ``` --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 - Delete local endpoint entries - List local endpoint entries
Project: Flannel (Runtime / Cloud Native Network)
File: integrations.md

This document tracks projects that integrate with flannel. and help us keep the list current. : Container orchestration platform with options for . : Kubernetes CNI plugin that uses Calico for network policies and intra-node communications and Flannel for inter-node communications. : Kubernetes distribution with flannel embedded as CNI. : Kubernetes distribution packed with Canal as default CNI.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_fqdn.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage fqdn proxy ``` cilium-dbg fqdn [flags] ``` ``` -h, --help help for fqdn ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI - Manage fqdn proxy cache - Show internal state Cilium has for DNS names / regexes
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-bugtool.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Collects agent & system information useful for bug reporting ``` cilium-bugtool [OPTIONS] [flags] ``` ``` $ cilium-bugtool [...] $ kubectl get pods --namespace kube-system NAME READY STATUS RESTARTS AGE cilium-kg8lv 1/1 Running 0 13m [...] $ kubectl -n kube-system exec cilium-kg8lv -- cilium-bugtool $ kubectl cp kube-system/cilium-kg8lv:/tmp/cilium-bugtool-243785589.tar /tmp/cilium-bugtool-243785589.tar ``` ``` --archive Create archive when false skips deletion of the output directory (default true) --archive-prefix string String to prefix to name of archive if created (e.g., with cilium pod-name) -o, --archiveType string Archive type: tar | gz (default "tar") --cilium-agent-container-name string Name of the Cilium Agent main container (when k8s-mode is true) (default "cilium-agent") --config string Configuration to decide what should be run (default "./.cilium-bugtool.config") --dry-run Create configuration file of all commands that would have been executed --enable-markdown Dump output of commands in markdown format --envoy-dump When set, dump envoy configuration from unix socket (default true) --envoy-metrics When set, dump envoy prometheus metrics from unix socket (default true) --exclude-object-files Exclude per-endpoint object files. Template object files will be kept --exec-timeout duration The default timeout for any cmd execution in seconds (default 30s) --get-pprof When set, only gets the pprof traces from the cilium-agent binary -h, --help help for cilium-bugtool -H, --host string URI to server-side API --hubble-metrics When set, hubble prometheus metrics (default true) --hubble-metrics-port int Port to query for hubble metrics (default 9965) --k8s-label string Kubernetes label for Cilium pod (default "k8s-app=cilium") --k8s-mode Require Kubernetes pods to be found or fail --k8s-namespace string Kubernetes namespace for Cilium pod (default "kube-system") --parallel-workers int Maximum number of parallel worker tasks, use 0 for number of CPUs --pprof-debug int Debug pprof args (default 1) --pprof-port int Pprof port to connect to. Known Cilium component ports are agent:6060, operator:6061, apiserver:6063 (default 6060) --pprof-trace-seconds int Amount of seconds used for pprof CPU traces (default 180) -t, --tmp string Path to store extracted files. Use '-' to send to stdout. (default "/tmp") ``` - Generate the autocompletion script for the specified shell
Project: CubeFS (Runtime / Cloud Native Storage)
File: partition.md

``` bash curl -v http://10.196.59.202:17210/getPartitions ``` ``` bash curl -v http://10.196.59.202:17210/getPartitionById?pid=100 ``` Obtains current status information for a specified shard ID, including the raft leader address for the current shard group, the raft group members, and the inode allocation cursor. Request Parameters: | Parameter | Type | Description | |--||-| | pid | Integer | Metadata shard ID |
Project: Alluxio (Runtime / Cloud Native Storage)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: type-feature 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. Urgency Explain why the feature is important Additional context Add any other context or screenshots about the feature request here.
Project: Soda Foundation (Runtime / Cloud Native Storage)
File: LICENSE.md

Copyright (c) 2014-2015, Philip Hofer Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Project: Kata Containers (Runtime / Container Runtime)
File: VSocks.md

There are two different ways processes in the virtual machine can communicate with processes in the host. The first one is by using serial ports, where the processes in the virtual machine can read/write data from/to a serial port device and the processes in the host can read/write data from/to a Unix socket. Most GNU/Linux distributions have support for serial ports, making it the most portable solution. However, the serial link limits read/write access to one process at a time. A newer, simpler method is , which can accept connections from multiple clients. The following diagram shows how it's implemented in Kata Containers. ``` .-. | .. | | | .--. .--. | | | | |cont1| |cont2| | | | | `--' `--' | | | | | | | | | | .. | | | | | agent | | | | | `' | | | | | | | | | | POD .-. | | | `--| vsock |-' | | `-' | | | | | | .. .. | | | shim | | shim | | | `' `' | | Host | `-' ``` The host Linux kernel version must be greater than or equal to v4.8, and the `vhostvsock` module must be loaded or built-in (`CONFIGVHOST_VSOCK=y`). To load the module run the following command: ``` $ sudo modprobe -i vhost_vsock ``` The Kata Containers version must be greater than or equal to 1.2.0 and `use_vsock` must be set to `true` in the runtime . To use Kata Containers with VSOCKs in a VMWare guest environment, first stop the `vmware-tools` service and unload the VMWare Linux kernel module. ``` sudo systemctl stop vmware-tools sudo modprobe -r vmwvsockvmci_transport sudo modprobe -i vhost_vsock ``` Using a proxy for multiplexing the connections between the VM and the host uses 4.5MB per . In a high density deployment this could add up to GBs of memory that could have been used to host more PODs. When we talk about density each kilobyte matters and it might be the decisive factor between run another POD or not. Before making the decision not to use VSOCKs, you should ask yourself, how many more containers can run with the memory RAM consumed by the Kata proxies? Since communication via VSOCKs is direct, the only way to lose communication with the containers is if the VM itself or the `containerd-shim-kata-v2` dies, if this happens the containers are removed automatically.
Project: rkt (Runtime / Container Runtime)
File: cat-manifest.md

For debugging or inspection you may want to extract the PodManifest to stdout. ``` { "acVersion":"0.8.11", "acKind":"PodManifest" ... ``` | Flag | Default | Options | Description | | | | | | | `--pretty-print` | `true` | `true` or `false` | Apply indent to format the output | See the table with .
Project: Weave Net (Runtime / Cloud Native Network)
File: configuring-weave.md

title: Allocating IPs in a Specific Range menu_order: 10 search_type: Documentation The default configurations for both Weave Net and Docker use [Private Networks](https://en.wikipedia.org/wiki/Private_network), whose addresses are never found on the public Internet, and subsequently reduces the chance of IP overlap. However, it could be that you or your hosting provider are using some of these private addresses in the same range, which will cause a clash. If after `weave launch`, the following error message appears: Network 10.32.0.0/12 overlaps with existing route 10.0.0.0/8 on host. ERROR: Default --ipalloc-range 10.32.0.0/12 overlaps with existing route on host. You must pick another range and set it on all hosts. As the message indicates, the default range that Weave Net would like to use is `10.32.0.0/12` - a 12-bit prefix, where all addresses start with the bit pattern 000010100010, or in decimal everything from 10.32.0.0 through 10.47.255.255. However, your host is using a route for `10.0.0.0/8`, which overlaps, since the first 8 bits are the same. In this case, if you used the default network for an address like `10.32.5.6` the kernel would never be sure if this meant the Weave Net network of `10.32.0.0/12` or the hosting network of `10.0.0.0/8`. If you are sure the addresses you want are not in use, then explicitly setting the range with `--ipalloc-range` in the command-line arguments to `weave launch` on all hosts forces Weave Net to use that range, even though it overlaps. Otherwise, you can pick a different range, preferably another subset of the [Private Networks](https://en.wikipedia.org/wiki/Private_network). For example 172.30.0.0/16. See Also
Project: Velero (Runtime / Cloud Native Storage)
File: ark_restore_create.md

title: "ark restore create" layout: docs Create a restore Create a restore ``` ark restore create [RESTORENAME] --from-backup BACKUPNAME [flags] ``` ``` ark restore create restore-1 --from-backup backup-1 ark restore create --from-backup backup-1 ``` ``` --exclude-namespaces stringArray namespaces to exclude from the restore --exclude-resources stringArray resources to exclude from the restore, formatted as resource.group, such as storageclasses.storage.k8s.io --from-backup string backup to restore from -h, --help help for create --include-cluster-resources optionalBool[=true] include cluster-scoped resources in the restore --include-namespaces stringArray namespaces to include in the restore (use '' for all namespaces) (default ) --include-resources stringArray resources to include in the restore, formatted as resource.group, such as storageclasses.storage.k8s.io (use '*' for all resources) --label-columns stringArray a comma-separated list of labels to be displayed as columns --labels mapStringString labels to apply to the restore --namespace-mappings mapStringString namespace mappings from name in the backup to desired restored name in the form src1:dst1,src2:dst2,... -o, --output string Output display format. For create commands, display the object but do not send it to the server. Valid formats are 'table', 'json', and 'yaml'. --restore-volumes optionalBool[=true] whether to restore volumes from snapshots -l, --selector labelSelector only restore resources matching this label selector (default <none>) --show-labels show labels in the last column ``` ``` --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 restores
Project: gVisor (Runtime / Container Runtime)
File: oci.md

This guide will quickly get you started running your first gVisor sandbox container using the runtime directly with the default platform. First, follow the . Now we will create an container bundle to run our container. First we will create a root directory for our bundle. ```bash mkdir bundle cd bundle ``` Create a root file system for the container. We will use the Docker `hello-world` image as the basis for our container. ```bash mkdir --mode=0755 rootfs docker export $(docker create hello-world) | sudo tar -xf - -C rootfs --same-owner --same-permissions ``` Next, create an specification file called `config.json` that contains our container specification. We tell the container to run the `/hello` program. ```bash runsc spec -- /hello ``` Finally run the container. ```bash sudo runsc run hello ``` Next try or .