cwielenb/CNCF-Dataset huggingface dataset:
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_completion.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Output shell completion code ``` cilium-dbg completion [shell] [flags] ``` ``` source <(cilium-dbg completion bash) cilium-dbg completion bash > ~/.cilium/completion.bash.inc printf " source '$HOME/.cilium/completion.bash.inc' " >> $HOME/.bash_profile source $HOME/.bash_profile source <(cilium-dbg completion zsh) cilium-dbg completion zsh > ~/.cilium/completion.zsh.inc printf " source '$HOME/.cilium/completion.zsh.inc' " >> $HOME/.zshrc source $HOME/.zshrc cilium-dbg completion fish > ~/.config/fish/completions/cilium.fish ``` ``` -h, --help help for completion ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI
Project: LINSTOR (Runtime / Cloud Native Storage)
File: Default.md

<details><summary>Commit messages</summary> ``` %{all_commits} ``` </details> Do all methods have proper Javadoc*? Are (flux-) exceptions* properly documented? Are special return values* properly documented? (i.e. -1) Are parameters* properly explained? Does the Javadoc (still) properly describe the functionality*? Are all parameters annotated with `@javax.annotation.{Nullable,Nonnull}`*? Do tests (unit/E2E)* exist (if needed)? Does this MR require updates in UG*? Does this MR require updates in linstor-client*? Does this MR require updates in linstor-api-py*? CHANGELOG.md*? If `restv1openapi.yaml` was modified: Was the changelog section* of the file also updated? Version-bump* (if first change of new release)? Are new JSON structures (response AND requests) extendable*? (i.e. allows for new fields for future features)
Project: Carina (Runtime / Cloud Native Storage)
File: CHANGELOG.md

All notable changes to this project will be documented in this file. This project adheres to . Removed csi.proto upgrade CSI_VERSION=1.5 Remove device registration and use the CRD resource NodeStorageResource instead Added controllers that maintain NodeStorageResource The scheduler supports fetching resources from NodeStorageResource Upgrade go.mod to depend on K8s1.23 Upgrade the Webhook certificate using job Raw disk support under development add helm chart to deploy when node is notready, migrate pods to ready node if pod annotations contains "carina.io/rebuild-node-notready: true" (<https://github.com/carina-io/carina/issues/14>)) multiple VGS are supported for the same type of storage csi configmap change new version to support mutil vgroup (https://github.com/carina-io/carina/issues/10) Fixes configmap spradoutspreadout(<https://github.com/carina-io/carina/issues/12>) provisioning raw disk doc/manual_zh/velero.md replace carina.storage.io/backend-disk-type: hdd ==> carina.storage.io/backend-disk-group-name: hdd replace carina.storage.io/cache-disk-type: ssd ==> carina.storage.io/cache-disk-group-name: ssd replace carina.storage.io/disk-type: "hdd" ==> carina.storage.io/disk-group-name: "hdd" replace kubernetes.customized/blkio.throttle.readbpsdevice: "10485760" ==> carina.storage.io/blkio.throttle.readbpsdevice: "10485760" replace kubernetes.customized/blkio.throttle.readiopsdevice: "10000" ==> carina.storage.io/blkio.throttle.readiopsdevice: "10000" replace kubernetes.customized/blkio.throttle.writebpsdevice: "10485760" ==> carina.storage.io/blkio.throttle.writebpsdevice: "10485760" replace kubernetes.customized/blkio.throttle.writeiopsdevice: "100000" ==> carina.storage.io/blkio.throttle.writeiopsdevice: "100000" replace carina.io/rebuild-node-notready: true ==> carina.storage.io/allow-pod-migration-if-node-notready: true Support the cgroup v1 and v2 Adjustment of project structure The HTTP server is deleted Logicvolume changed from Namespace to Cluster, Fixed the problem that message notification is not timely Fix the metric server panic problem #91 Mirrored warehouse has personal space migrated to Carina exclusive space To improve LVM volume performance, do not create a thin-pool when creating an LVM volume #96 Add parameter `carina.storage.io/allow-pod-migration-if-notready` to storageclass. Webhook will automatically add this annotation for POD when SC has this parameter #95 Nodestorageresource structuring and issue fixing #87 Remove ConfigMap synchronization control #75 The Carina E2E test is being refined Promote carina into cncf sandbox project and roadmap Update outdated documents Optimize the container scheduling algorithm to make it more concise and understandable Repair The pv is lost due to node restart Added the upgrade upgrade script Helm chat deployment adds psp resources It is clear that the current version of carina supports 1.18-1.24 Planning discussion carina supports the Kubernetes 1.25 solution Added e2e unit test scripts
Project: Virtual Kubelet (Runtime / Container Runtime)
File: _index.md

title: Overview description: The basics of Virtual Kubelet weight: 1 Virtual Kubelet is an implementation of the Kubernetes that masquerades as a kubelet for the purpose of connecting a Kubernetes cluster to other APIs. This allows Kubernetes to be backed by other services, such as serverless container platforms. Virtual Kubelet supports a variety of providers: {{< providers >}} You can also .
Project: Velero (Runtime / Cloud Native Storage)
File: faq.md

title: "FAQ" layout: docs Etcd's backup/restore tooling is good for recovering from data loss in a single etcd cluster. For example, it is a good idea to take a backup of etcd prior to upgrading etcd itself. For more sophisticated management of your Kubernetes cluster backups and restores, we feel that Velero is generally a better approach. It gives you the ability to throw away an unstable cluster and restore your Kubernetes resources and data into a new cluster, which you can't do easily just by backing up and restoring etcd. Examples of cases where Velero is useful: you don't have access to etcd (e.g. you're running on GKE) backing up both Kubernetes resources and persistent volume state cluster migrations backing up a subset of your Kubernetes resources backing up Kubernetes resources that are stored across multiple etcd clusters (for example if you run a custom apiserver) Yes, with some exceptions. For example, when Velero restores pods it deletes the `nodeName` from the pod so that it can be scheduled onto a new node. You can see some more examples of the differences in We strongly recommend that each Velero instance use a distinct bucket/prefix combination to store backups. Having multiple Velero instances write backups to the same bucket/prefix combination can lead to numerous problems - failed backups, overwritten backups, inadvertently deleted backups, etc., all of which can be avoided by using a separate bucket + prefix per Velero instance. It's fine to have multiple Velero instances back up to the same bucket if each instance uses its own prefix within the bucket. This can be configured in your `BackupStorageLocation`, by setting the `spec.objectStorage.prefix` field. It's also fine to use a distinct bucket for each Velero instance, and not to use prefixes at all. Related to this, if you need to restore a backup that was created in cluster A into cluster B, you may configure cluster B with a backup storage location that points to cluster A's bucket/prefix. If you do this, you should configure the storage location pointing to cluster A's bucket/prefix in `ReadOnly` mode via the `--access-mode=ReadOnly` flag on the `velero backup-location create` command. This will ensure no new backups are created from Cluster B in Cluster A's bucket/prefix, and no existing backups are deleted or overwritten.
Project: Longhorn (Runtime / Cloud Native Storage)
File: YYYYMMDD-template.md

This is the title of the enhancement. Keep it simple and descriptive. The file name should be lowercased and spaces/punctuation should be replaced with `-`. The Summary section is incredibly important for producing high-quality user-focused documentation such as release notes or a development roadmap. A good summary is probably at least a paragraph in length. The URL For the related enhancement issues in the Longhorn repository. List the specific goals of the enhancement. How will we know that this has succeeded? What is out of scope for this enhancement? Listing non-goals helps to focus discussion and make progress. This is where we get down to the nitty-gritty of what the proposal actually is. Detail the things that people will be able to do if this enhancement is implemented. A good practice is including a comparison of what the user cannot do before the enhancement is implemented, why the user would want an enhancement, and what the user needs to do after, to make it clear why the enhancement is beneficial to the user. The experience details should be in the `User Experience In Detail` later. Detail what the user needs to do to use this enhancement. Include as much detail as possible so that people can understand the "how" of the system. The goal here is to make this feel real for users without getting bogged down. Overview of how the enhancement will be implemented. Integration test plan. For engine enhancement, also requires engine integration test plan. Anything that requires if the user wants to upgrade to this enhancement. Additional notes.
Project: Gluster (Runtime / Cloud Native Storage)
File: Language-Bindings.md

GlusterFS 3.4 introduced the libgfapi client API for C programs. This page lists bindings to the libgfapi C library from other languages. Go -- - Go language bindings for libgfapi, aiming to provide an api consistent with the default Go file apis. Java - Low level JNI binding for libgfapi - High level NIO.2 FileSystem Provider implementation for the Java platform - Java bindings for libgfapi, similar to java.io Python - Libgfapi bindings for Python Ruby - Libgfapi bindings for Ruby using FFI Rust - Libgfapi bindings for Rust using FFI Perl - Libgfapi bindings for Perl using FFI
Project: Kata Containers (Runtime / Container Runtime)
File: example-command.md

The following containerd command creates a container. It is referred to throughout the architecture document to help explain various points: ```bash $ sudo ctr run --runtime "io.containerd.kata.v2" --rm -t "quay.io/libpod/ubuntu:latest" foo sh ``` This command requests that containerd: Create a container (`ctr run`). Use the Kata runtime (`--runtime "io.containerd.kata.v2"`). Delete the container when it (`--rm`). Attach the container to the user's terminal (`-t`). Use the Ubuntu Linux to create the container that will become the (`quay.io/libpod/ubuntu:latest`). Create the container with the name "`foo`". Run the `sh(1)` command in the Ubuntu rootfs based container environment. The command specified here is referred to as the . Note: For the purposes of this document and to keep explanations simpler, we assume the user is running this command in the .
Project: Ceph (Runtime / Cloud Native Storage)
File: pull_request_template.md

<!-- Please give your pull request a title like Please use this format for each git commit message: [A longer multiline description] Fixes: [ticket URL on tracker.ceph.com, create one if necessary] Signed-off-by: [Your Name] <[your email]> For examples, use "git log". --> To sign and title your commits, please refer to . If you are submitting a fix for a stable branch (e.g. "quincy"), please refer to for the proper workflow. When filling out the below checklist, you may click boxes directly in the GitHub web UI. When entering or editing the entire PR message in the GitHub web UI editor, you may also select a checklist item by adding an `x` between the brackets: `[x]`. Spaces and capitalization matter when checking off items this way. Tracker (select at least one) [ ] References tracker ticket [ ] Very recent bug; references commit where it was introduced [ ] New feature (ticket optional) [ ] Doc update (no ticket needed) [ ] Code cleanup (no ticket needed) Component impact , opened tracker ticket , opened tracker ticket [ ] No impact that needs to be tracked Documentation (select at least one) [ ] Updates relevant documentation [ ] No doc update is appropriate Tests (select at least one) - [ ] Includes bug reproducer [ ] No tests <details> <summary>Show available Jenkins commands</summary> `jenkins retest this please` `jenkins test classic perf` `jenkins test crimson perf` `jenkins test signed` `jenkins test make check` `jenkins test make check arm64` `jenkins test submodules` `jenkins test dashboard` `jenkins test dashboard cephadm` `jenkins test api` `jenkins test docs` `jenkins render docs` `jenkins test ceph-volume all` `jenkins test ceph-volume tox` `jenkins test windows` `jenkins test rook e2e` </details>
Project: Firecracker (Runtime / Container Runtime)
File: actions.md

Firecracker microVMs can execute actions that can be triggered via `PUT` requests on the `/actions` resource. Details about the required fields can be found in the . The `InstanceStart` action powers on the microVM and starts the guest OS. It does not have a payload. It can only be successfully called once. ```bash curl --unix-socket ${socket} -i \ -X PUT "http://localhost/actions" \ -d '{ "action_type": "InstanceStart" }' ``` The `FlushMetrics` action flushes the metrics on user demand. ```bash curl --unix-socket /tmp/firecracker.socket -i \ -X PUT "http://localhost/actions" \ -d '{ "action_type": "FlushMetrics" }' ``` This action will send the CTRL+ALT+DEL key sequence to the microVM. By convention, this sequence has been used to trigger a soft reboot and, as such, most Linux distributions perform an orderly shutdown and reset upon receiving this keyboard input. Since Firecracker exits on CPU reset, `SendCtrlAltDel` can be used to trigger a clean shutdown of the microVM. For this action, Firecracker emulates a standard AT keyboard, connected via an i8042 controller. Driver support for both these devices needs to be present in the guest OS. For Linux, that means the guest kernel needs `CONFIGSERIOI8042` and `CONFIGKEYBOARDATKBD`. Note1: at boot time, the Linux driver for i8042 spends a few tens of milliseconds probing the device. This can be disabled by using these kernel command line parameters: ```console i8042.noaux i8042.nomux i8042.nopnp i8042.dumbkbd ``` Note2 This action is only supported on `x86_64` architecture. ```bash curl --unix-socket /tmp/firecracker.socket -i \ -X PUT "http://localhost/actions" \ -d '{ "action_type": "SendCtrlAltDel" }' ```
Project: gVisor (Runtime / Container Runtime)
File: runtime_monitoring.md

The Runtime Monitoring feature provides an interface to observe runtime behavior of applications running inside gVisor. Although it can be used for many purposes, it was built with the primary focus on threat detection. NOTE: Runtime monitoring is about the ability to understand the behavior of sandboxed workloads. This differs from . Out of the box, gVisor comes with support to stream application actions (called trace points) to an external process, that is used to validate the actions and alert when abnormal behavior is detected. Trace points are available for all syscalls and other important events in the system, e.g. container start. More trace points can be easily added as needed. The trace points are sent to a process running alongside the sandbox, which is isolated from the sandbox for security reasons. Additionally, the monitoring process can be shared by many sandboxes. You can use the following links to learn more:
Project: Kilo (Runtime / Cloud Native Network)
File: network-policies.md

Network policies allow specifying whether and how different groups of Pods running in a Kubernetes cluster can communicate with one another. In other words, they can be used to control and limit the ingress and egress traffic to and from Pods. Naturally, network policies can be used to restrict which WireGuard peers have access to which Pods and vice-versa. Support for can be easily added to any cluster running Kilo by deploying a utility such as . The following command adds network policy support by deploying kube-router to work alongside Kilo: ```shell kubectl apply -f https://raw.githubusercontent.com/squat/kilo/main/manifests/kube-router.yaml ``` Network policies could now be deployed to the cluster. Consider the following example scenarios. Imagine that an organization wants to limit access to a namespace to only allow traffic from the WireGuard VPN. Access to a namespace could be limited to only accept ingress from a CIDR range with: ```shell cat <<'EOF' | kubectl apply -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-ingress-except-wireguard spec: podSelector: {} policyTypes: Ingress ingress: from: ipBlock: cidr: 10.5.0.0/16 # The WireGuard mesh/s CIDR. EOF ``` Consider the case where Pods running in one namespace should not have access to resources in the WireGuard mesh, e.g. because the Pods are potentially untrusted. In this scenario, a policy to restrict access to the WireGuard peers could be created with: ```shell cat <<'EOF' | kubectl apply -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-egress-to-wireguard spec: podSelector: {} policyTypes: Egress egress: to: ipBlock: cidr: 0.0.0.0/0 except: 10.5.0.0/16 # The WireGuard mesh's CIDR. EOF ```
Project: Firecracker (Runtime / Container Runtime)
File: hugepages.md

\[!WARNING\] Support is currently in developer preview. See for more info. Firecracker supports backing the guest memory of a VM by 2MB hugetlbfs pages. This can be enabled by setting the `huge_pages` field of `PUT` or `PATCH` requests to the `/machine-config` endpoint to `2M`. Backing guest memory by huge pages can bring performance improvements for specific workloads, due to less TLB contention and less overhead during virtual->physical address resolution. It can also help reduce the number of KVM_EXITS required to rebuild extended page tables post snapshot restore, as well as improve boot times (by up to 50% as measured by Firecracker's ) Using hugetlbfs requires the host running Firecracker to have a pre-allocated pool of 2M pages. Should this pool be too small, Firecracker may behave erratically or receive the `SIGBUS` signal. This is because Firecracker uses the `MAP_NORESERVE` flag when mapping guest memory. This flag means the kernel will not try to reserve sufficient hugetlbfs pages at the time of the `mmap` call, trying to claim them from the pool on-demand. For details on how to manage this pool, please refer to the . Restoring a Firecracker snapshot of a microVM backed by huge pages will also use huge pages to back the restored guest. There is no option to flip between regular, 4K, pages and huge pages at restore time. Furthermore, snapshots of microVMs backed with huge pages can only be restored via UFFD. Lastly, note that even for guests backed by huge pages, differential snapshots will always track write accesses to guest memory at 4K granularity. When restoring snapshots via UFFD, Firecracker will send the configured page size (in KiB) for each memory region as part of the initial handshake, as described in our documentation on . Currently, hugetlbfs support is mutually exclusive with the following Firecracker features: Memory Ballooning via the Initrd Firecracker's guest memory is memfd based. Linux (as of 6.1) does not offer a way to dynamically enable THP for such memory regions. Additionally, UFFD does not integrate with THP (no transparent huge pages will be allocated during userfaulting). Please refer to the for more information.
Project: Antrea (Runtime / Cloud Native Network)
File: eks-terraform.md

Antrea may run in networkPolicyOnly mode in AKS and EKS clusters. This document describes the steps to create an EKS cluster with Antrea using terraform. To run EKS cluster, install and configure AWS cli(either version 1 or 2), see <https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html>, and <https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html> Install aws-iam-authenticator, see <https://docs.aws.amazon.com/eks/latest/userguide/install-aws-iam-authenticator.html> Install terraform, see <https://learn.hashicorp.com/tutorials/terraform/install-cli> You must already have ssh key-pair created. This key pair will be used to access worker Node via ssh. ```bash ls ~/.ssh/ idrsa idrsa.pub ``` Ensures that you have permission to create EKS cluster, and have already created EKS cluster role as well as worker Node profile. ```bash export TFVAReksclusteriamrolename=YOUREKSROLE export TFVAReksiaminstanceprofilename=YOUREKSWORKERNODEPROFILE export TFVARekskeypairname=YOURKEYPAIRTOACCESSWORKER_NODE ``` Where TFVAReksclusteriamrolename may be created by following these TFVAReksiaminstanceprofilename may be created by following these TFVARekskeypair_name is the aws key pair name you have configured by following these , using ssh-pair created in Prerequisites item 4 Create EKS cluster ```bash ./hack/terraform-eks.sh create ``` Interact with EKS cluster ```bash ./hack/terraform-eks.sh kubectl ... # issue kubectl commands to EKS cluster ./hack/terraform-eks.sh load ... # load local built images to EKS cluster ./hack/terraform-eks.sh destroy # destroy EKS cluster ``` and worker Node can be accessed with ssh via their external IPs. Apply Antrea to EKS cluster ```bash ./hack/generate-manifest.sh --encap-mode networkPolicyOnly | ~/terraform/eks kubectl apply -f - ```