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

title: "ark backup describe" layout: docs Describe backups Describe backups ``` ark backup describe [NAME1] [NAME2] [NAME...] [flags] ``` ``` -h, --help help for describe -l, --selector string only show items matching this label selector --volume-details display details of restic volume backups ``` ``` --alsologtostderr log to standard error as well as files --kubeconfig string Path to the kubeconfig file to use to talk to the Kubernetes apiserver. If unset, try the environment variable KUBECONFIG, as well as in-cluster configuration --kubecontext string The context to use to talk to the Kubernetes apiserver. If unset defaults to whatever your current-context is (kubectl config current-context) --logbacktraceat traceLocation when logging hits line file:N, emit a stack trace (default :0) --log_dir string If non-empty, write log files in this directory --logtostderr log to standard error instead of files -n, --namespace string The namespace in which Ark should operate (default "heptio-ark") --stderrthreshold severity logs at or above this threshold go to stderr (default 2) -v, --v Level log level for V logs --vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging ``` - Work with backups
Project: Velero (Runtime / Cloud Native Storage)
File: versions.md

title: "Upgrading Velero versions" layout: docs Velero supports multiple concurrent versions. Whether you're setting up Velero for the first time or upgrading to a new version, you need to pay careful attention to versioning. This doc page is new as of version 0.10.0, and will be updated with information about subsequent releases. The documentation site provides docs for minor versions only, not for patch releases. Patch releases are guaranteed not to be breaking, but you should carefully read the to make sure that you understand any relevant changes. If you're upgrading from a patch version to a patch version, you only need to update the image tags in your configurations. No other steps are needed. Breaking changes are documented in the release notes and in the documentation. See Not all Velero versions support all versions of Kubernetes. You should be aware of the following known limitations: Velero version 0.9.0 requires Kubernetes version 1.8 or later. In version 0.9.1, Velero was updated to support earlier versions. Restic support requires Kubernetes version 1.10 or later, or an earlier version with the mount propagation feature enabled. See .
Project: Kata Containers (Runtime / Container Runtime)
File: VmResize.md

Name | Type | Description | Notes | - | - | - DesiredVcpus | Pointer to int32 | | [optional] DesiredRam | Pointer to int64 | desired memory ram in bytes | [optional] DesiredBalloon | Pointer to int64 | desired balloon size in bytes | [optional] `func NewVmResize() *VmResize` NewVmResize instantiates a new VmResize 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 NewVmResizeWithDefaults() *VmResize` NewVmResizeWithDefaults instantiates a new VmResize 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 *VmResize) GetDesiredVcpus() int32` GetDesiredVcpus returns the DesiredVcpus field if non-nil, zero value otherwise. `func (o VmResize) GetDesiredVcpusOk() (int32, bool)` GetDesiredVcpusOk returns a tuple with the DesiredVcpus field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *VmResize) SetDesiredVcpus(v int32)` SetDesiredVcpus sets DesiredVcpus field to given value. `func (o *VmResize) HasDesiredVcpus() bool` HasDesiredVcpus returns a boolean if a field has been set. `func (o *VmResize) GetDesiredRam() int64` GetDesiredRam returns the DesiredRam field if non-nil, zero value otherwise. `func (o VmResize) GetDesiredRamOk() (int64, bool)` GetDesiredRamOk returns a tuple with the DesiredRam field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *VmResize) SetDesiredRam(v int64)` SetDesiredRam sets DesiredRam field to given value. `func (o *VmResize) HasDesiredRam() bool` HasDesiredRam returns a boolean if a field has been set. `func (o *VmResize) GetDesiredBalloon() int64` GetDesiredBalloon returns the DesiredBalloon field if non-nil, zero value otherwise. `func (o VmResize) GetDesiredBalloonOk() (int64, bool)` GetDesiredBalloonOk returns a tuple with the DesiredBalloon field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *VmResize) SetDesiredBalloon(v int64)` SetDesiredBalloon sets DesiredBalloon field to given value. `func (o *VmResize) HasDesiredBalloon() bool` HasDesiredBalloon returns a boolean if a field has been set.
Project: Inclavare Containers (Runtime / Container Runtime)
File: ROADMAP.md

containerd uses the issues and milestones to define its roadmap. `ROADMAP.md` files are common in open source projects but we find they quickly become out of date. We opt for an issues and milestone approach that our maintainers and community can keep up-to-date as work is added and completed. Issues tagged with the `roadmap` label are high level roadmap items. They are tasks and/or features that the containerd community wants completed. Smaller issues and pull requests can reference back to the main roadmap issue that is tagged to help detail progress towards the overall goal. Milestones define when an issue, pull request, and/or roadmap item is to be completed. Issues are the what, milestones are the when. Development is complex therefore roadmap items can move between milestones depending on the remaining development and testing required to release a change. To find the roadmap items currently planned for containerd you can filter on the `roadmap` label. After searching for roadmap items you can view what milestone they are scheduled to be completed in along with the progress.
Project: WasmEdge Runtime (Runtime / Container Runtime)
File: smart_device.md

Smart device apps could embed WasmEdge as a middleware runtime to render interactive content on the UI, connect to native device drivers, and access specialized hardware features (i.e, the GPU for AI inference). The benefits of the WasmEdge runtime over native-compiled machine code include security, safety, portability, manageability, OTA upgradability, and developer productivity. WasmEdge runs on the following device OSes. With WasmEdge on both the device and the edge server, we can support and for rich-client mobile applications that is both portable and upgradable.
Project: runc (Runtime / Container Runtime)
File: runc-run.8.md

% runc-run "8" runc-run - create and start a container runc run [option ...] container-id The run command creates an instance of a container from a bundle, and starts it. You can think of run as a shortcut for create followed by start. --bundle|-b path : Path to the root of the bundle directory. Default is current directory. --console-socket path : Path to an AF_UNIX socket which will receive a file descriptor referencing the master end of the console's pseudoterminal. See . --detach|-d : Detach from the container's process. --pid-file path : Specify the file to write the initial container process' PID to. --no-subreaper : Disable the use of the subreaper used to reap reparented processes. --no-pivot : Do not use pivot root to jail process inside rootfs. This should not be used except in exceptional circumstances, and may be unsafe from the security standpoint. --no-new-keyring : Do not create a new session keyring for the container. This will cause the container to inherit the calling processes session key. --preserve-fds N : Pass N additional file descriptors to the container (stdio + $LISTEN_FDS + N in total). Default is 0. --keep : Keep container's state directory and cgroup. This can be helpful if a user wants to check the state (e.g. of cgroup controllers) after the container has exited. If this option is used, a manual runc delete is needed afterwards to clean an exited container's artefacts. runc(8).
Project: Cilium (Runtime / Cloud Native Network)
File: failing_test_template.md

name: Failing Test about: Report test failures in Cilium CI jobs title: 'CI: ' labels: area/CI, ci/flake assignees: '' Set title to be in the format `CI: <test-name>`. Copy-paste the output the test failure. Upload the zip file generated from that test failure. Copy-paste the link of the CI build where that test failure has happen. Include any output from logs that you think may be relevant (to ease GitHub searches).
Project: Gluster (Runtime / Cloud Native Storage)
File: gfid-to-path.md

GlusterFS internal file identifier (GFID) is a uuid that is unique to each file across the entire cluster. This is analogous to inode number in a normal filesystem. The GFID of a file is stored in its xattr named `trusted.gfid`. ``` mount -t glusterfs -o aux-gfid-mount vm1:test /mnt/testvol ``` Assuming, you have `GFID` of a file from changelog (or somewhere else). For trying this out, you can get `GFID` of a file from mountpoint: ``` getfattr -n glusterfs.gfid.string /mnt/testvol/dir/file ``` (Lists hardlinks delimited by `:`, returns path as seen from mountpoint) ``` gluster volume set test build-pgfid on ``` Read virtual xattr `glusterfs.ancestry.path` which contains the file path ``` getfattr -n glusterfs.ancestry.path -e text /mnt/testvol/.gfid/<GFID> ``` Example: ``` [root@vm1 glusterfs]# ls -il /mnt/testvol/dir/ total 1 10610563327990022372 -rw-r--r--. 2 root root 3 Jul 17 18:05 file 10610563327990022372 -rw-r--r--. 2 root root 3 Jul 17 18:05 file3 [root@vm1 glusterfs]# getfattr -n glusterfs.gfid.string /mnt/testvol/dir/file getfattr: Removing leading '/' from absolute path names glusterfs.gfid.string="11118443-1894-4273-9340-4b212fa1c0e4" [root@vm1 glusterfs]# getfattr -n glusterfs.ancestry.path -e text /mnt/testvol/.gfid/11118443-1894-4273-9340-4b212fa1c0e4 getfattr: Removing leading '/' from absolute path names glusterfs.ancestry.path="/dir/file:/dir/file3" ``` (Does not list all hardlinks, returns backend brick path) ``` getfattr -n trusted.glusterfs.pathinfo -e text /mnt/testvol/.gfid/<GFID> ``` Example: ``` [root@vm1 glusterfs]# getfattr -n trusted.glusterfs.pathinfo -e text /mnt/testvol/.gfid/11118443-1894-4273-9340-4b212fa1c0e4 getfattr: Removing leading '/' from absolute path names trusted.glusterfs.pathinfo="(<DISTRIBUTE:test-dht> <POSIX(/mnt/brick-test/b):vm1:/mnt/brick-test/b/dir//file3>)" ```
Project: Velero (Runtime / Cloud Native Storage)
File: ark_get.md

title: "ark get" layout: docs Get ark resources Get ark resources ``` -h, --help help for get ``` ``` --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 ``` - Back up and restore Kubernetes cluster resources. - Get backups - Get restores - Get schedules
Project: Velero (Runtime / Cloud Native Storage)
File: upgrade-to-1.3.md

title: "Upgrading to Velero 1.3" layout: docs Velero , or installed. If you're not yet running at least Velero v1.2, see the following: Install the Velero v1.3 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.3.2 Git commit: <git SHA> ``` Update the container image used by the Velero deployment and, optionally, the restic daemon set: ```bash kubectl set image deployment/velero \ velero=velero/velero:v1.3.2 \ --namespace velero kubectl set image daemonset/restic \ restic=velero/velero:v1.3.2 \ --namespace velero ``` 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.3.2 Git commit: <git SHA> Server: Version: v1.3.2 ```
Project: rkt (Runtime / Container Runtime)
File: examples-bridge.md

The can be configured to create a separate network on the host that will be NAT'ed similar to the default network. The difference to a ptp configured network is that the pods will be able to communicate directly through the bridge and don't have to pass the host as a gateway. ```json $ cat /etc/rkt/net.d/10-bridge-nat.conf { "name": "bridge-nat", "type": "bridge", "bridge": "rkt-bridge-nat", "ipMasq": true, "isGateway": true, "ipam": { "type": "host-local", "subnet": "10.2.0.0/24", "routes": [ { "dst": "0.0.0.0/0" } ] } } ``` This will add a bridge interface named rkt-bridge-nat on the host and attach the pod's veth endpoint to it. It will not attach any other interface to the bridge, which remains the user's responsibility. Inside the pod, the interface configuration looks like this: ``` $ sudo rkt run --net=bridge-nat --interactive --debug kinvolk.io/aci/busybox:1.24 (...) 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue inet 127.0.0.1/8 scope host lo validlft forever preferredlft forever 3: eth0@if68: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue inet 10.2.0.2/24 scope global eth0 validlft forever preferredlft forever 5: eth1@if69: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue inet 172.16.28.2/24 scope global eth1 validlft forever preferredlft forever default via 10.2.0.1 dev eth0 10.2.0.0/24 dev eth0 src 10.2.0.2 172.16.28.0/24 via 172.16.28.1 dev eth1 src 172.16.28.2 172.16.28.1 dev eth1 src 172.16.28.2 ``` Note that the network has been loaded in addition to the requested network.
Project: Firecracker (Runtime / Container Runtime)
File: DEPRECATED.md

The following functionality of Firecracker is deprecated, and will be removed in a future major Firecracker release, in accordance with our . \\] The `vsock_id` body field in `PUT` requests on `/vsock` \\] The `memfilepath` body field in `PUT` requests on `/snapshot/load` \\] MicroVM Metadata Service v1 (MMDSv1) \\] Static CPU templates \\] The `rebase-snap` tool \\] The `--start-time-cpu-us` and `--start-time-us` CLI arguments \\] Booting microVMs using MPTable and command line parameters for VirtIO devices. The functionality is substituted with ACPI.
Project: lxd (Runtime / Container Runtime)
File: third_party.md

Below are a list of common operations tools which feature Incus support, either natively or through a plugin. and are infrastructure as code tools which focus on creating the infrastructure itself. For Incus, this means the ability to create projects, profiles, networks, storage volumes and of course instances. In most cases, one will then use Ansible to deploy the workloads themselves once the instances and everything else they need as been put in place. The integration with Incus is done through a . is an infrastructure as code tool with particular focus on software provisioning and configuration management. It does most of its work by first connecting to the system that it's deploying software on. To do that, it can connect over SSH and a variety of other protocols, one of which is . That allows for easily deploying software inside of Incus instances without needing to first setup SSH. is a tool to generate custom OS images across a wide variety of platforms. A exists that allows Packer to generate Incus images directly. is an image building tool most known for producing the official LXC and Incus images. It consumes YAML definitions for its images and generates LXC container images as well as Incus container and VM images. The focus of Distrobuilder is in producing clean images from scratch, as opposed to repacking existing images. is the Github Actions Runner Manager which allows for running self-hosted Github runners. It supports a variety of providers for those runners, including .
Project: Rook (Runtime / Cloud Native Storage)
File: ceph-object-realm-crd.md

title: CephObjectRealm CRD Rook allows creation of a realm in a configuration through a CRD. The following settings are available for Ceph object store realms. ```yaml apiVersion: ceph.rook.io/v1 kind: CephObjectRealm metadata: name: realm-a namespace: rook-ceph spec: pull: endpoint: http://10.2.105.133:80 ``` `name`: The name of the object realm to create `namespace`: The namespace of the Rook cluster where the object realm is created. `pull`: This optional section is for the pulling the realm for another ceph cluster. `endpoint`: The endpoint in the realm from another ceph cluster you want to pull from. This endpoint must be in the master zone of the master zone group of the realm.
Project: lxd (Runtime / Container Runtime)
File: container-environment.md

(container-runtime-environment)= Incus attempts to present a consistent environment to all containers it runs. The exact environment will differ slightly based on kernel features and user configuration, but otherwise, it is identical for all containers. Incus assumes that any image it uses to create a new container comes with at least the following root-level directories: `/dev` (empty) `/proc` (empty) `/sbin/init` (executable) `/sys` (empty) Incus containers have a minimal and ephemeral `/dev` based on a `tmpfs` file system. Since this is a `tmpfs` and not a `devtmpfs` file system, device nodes appear only if manually created. The following standard set of device nodes is set up automatically: `/dev/console` `/dev/fd` `/dev/full` `/dev/log` `/dev/null` `/dev/ptmx` `/dev/random` `/dev/stdin` `/dev/stderr` `/dev/stdout` `/dev/tty` `/dev/urandom` `/dev/zero` In addition to the standard set of devices, the following devices are also set up for convenience: `/dev/fuse` `/dev/net/tun` `/dev/mqueue` Incus containers may have any number of network devices attached to them. The naming for those (unless overridden by the user) is `ethX`, where `X` is an incrementing number. Incus sets up a socket at `/dev/incus/sock` that the root user in the container can use to communicate with Incus on the host. See {doc}`dev-incus` for the API documentation. The following mounts are set up by default: `/proc` ({spellexception}`proc`) `/sys` (`sysfs`) `/sys/fs/cgroup/*` (`cgroupfs`) (only on kernels that lack cgroup namespace support) If they are present on the host, the following paths will also automatically be mounted: `/proc/sys/fs/binfmt_misc` `/sys/firmware/efi/efivars` `/sys/fs/fuse/connections` `/sys/fs/pstore` `/sys/kernel/debug` `/sys/kernel/security` The reason for passing all of those paths is that legacy init systems require them to be mounted, or be mountable, inside the container. The majority of those paths will not be writable (or even readable) from inside an unprivileged container. In privileged containers, they will be blocked by the AppArmor policy. If LXCFS is present on the host, it is automatically set up for the container. This normally results in a number of `/proc` files being overridden through bind-mounts. On older kernels, a virtual version of `/sys/fs/cgroup` might also be set up by LXCFS. Incus spawns whatever is located at `/sbin/init` as the initial process of the container (PID 1). This binary should act as a proper init system, including handling re-parented processes. Incus' communication with PID1 in the container is limited to two signals: `SIGINT` to trigger a reboot of the container `SIGPWR` (or alternatively `SIGRTMIN`+3) to trigger a clean shutdown of the container The initial environment of PID1 is blank except for `container=lxc`, which can be used by the init system to detect the runtime. All file descriptors above the default three are closed prior to PID1 being spawned.
Project: lxd (Runtime / Container Runtime)
File: images.md

(images)= ```{toctree} :maxdepth: 1 image-handling Use remote images <howto/images_remote> Manage images <howto/images_manage> Copy and import images <howto/images_copy> Create images <howto/images_create> Associate profiles <howto/images_profiles> reference/image_format reference/image_servers ```
Project: Rook (Runtime / Cloud Native Storage)
File: authenticated-registry.md

title: Authenticated Container Registries If you want to use an image from authenticated docker registry (e.g. for image cache/mirror), you'll need to add an `imagePullSecret` to all relevant service accounts. See the next section for the required service accounts. The whole process is described in the . To get you started, here's a quick rundown for the ceph example from the . First, we'll create the secret for our registry as described (the secret will be created in the `rook-ceph` namespace, make sure to change it if your Rook Ceph Operator/Cluster is in another namespace): ```console kubectl -n rook-ceph create secret docker-registry my-registry-secret --docker-server=DOCKERREGISTRYSERVER --docker-username=DOCKERUSER --docker-password=DOCKERPASSWORD --docker-email=DOCKER_EMAIL ``` Next we'll add the following snippet to all relevant service accounts as described : ```yaml imagePullSecrets: name: my-registry-secret ``` The service accounts are: `rook-ceph-system` (namespace: `rook-ceph`): Will affect all pods created by the rook operator in the `rook-ceph` namespace. `rook-ceph-default` (namespace: `rook-ceph`): Will affect most pods in the `rook-ceph` namespace. `rook-ceph-mgr` (namespace: `rook-ceph`): Will affect the MGR pods in the `rook-ceph` namespace. `rook-ceph-osd` (namespace: `rook-ceph`): Will affect the OSD pods in the `rook-ceph` namespace. `rook-ceph-rgw` (namespace: `rook-ceph`): Will affect the RGW pods in the `rook-ceph` namespace. Since it's the same procedure for all service accounts, here is just one example: ```console kubectl -n rook-ceph edit serviceaccount rook-ceph-default ``` ```yaml apiVersion: v1 kind: ServiceAccount metadata: name: rook-ceph-default namespace: rook-ceph secrets: name: default-token-12345 imagePullSecrets: name: my-registry-secret ``` After doing this for all service accounts all pods should be able to pull the image from your registry.