cwielenb/CNCF-Dataset huggingface dataset:
Project: Antrea (Runtime / Cloud Native Network)
File: antrea-docker-image.md

The main Antrea Docker images (`antrea/antrea-agent-ubuntu` and `antrea/antrea-controller-ubuntu`) are multi-arch images. For example, the `antrea/antrea-agent-ubuntu` manifest is a list of three manifests: `antrea/antrea-agent-ubuntu-amd64`, `antrea/antrea-agent-ubuntu-arm64` and `antrea/antrea-agent-ubuntu-arm`. Of these three manifests, only the first one is built and uploaded to Dockerhub by Github workflows defined in the `antrea-io/antrea` repositories. The other two are built and uploaded by Github workflows defined in a private repository (`vmware-tanzu/antrea-build-infra`), to which only the project maintainers have access. These workflows are triggered every time the `main` branch of `antrea-io/antrea` is updated, as well as every time a new Antrea Github release is created. They build the `antrea/antrea-agent-ubuntu-arm64` and `antrea/antrea-agent-ubuntu-arm` Docker images on native arm64 workers, then create the `antrea/antrea-agent-ubuntu` multi-arch manifest and push it to Dockerhub. The same goes for the controller images. They are also in charge of testing the images in a cluster. The `vmware-tanzu/antrea-build-infra` repository uses self-hosted ARM64 workers provided by the at Oregon State University. These workers enable us to build, and more importantly test, the Antrea Docker images for the arm64 and arm/v7 architectures. Being able to build Docker images on native ARM platforms is convenient as it is much faster than emulation. But if we just wanted to build the images, emulation would probably be good enough. However, testing Kubernetes ARM support using emulation is no piece of cake. Which is why we prefer to use native ARM64 workers. Github strongly not to use self-hosted runners with public repositories, for security reasons. It would be too easy for a malicious person to run arbitrary code on the runners by opening a pull request. Were we to make this repository public, we would therefore at least need to disable pull requests, which is sub-optimal for a public repository. We believe Github will address the issue eventually and provide safeguards to enable using self-hosted runners with public repositories, at which point we will migrate workflows from this repository to the main Antrea repository. In the future, we may switch over to ARM hosted Github runners provided by the CNCF.
Project: gVisor (Runtime / Container Runtime)
File: platforms.md

[TOC] This guide describes how to change the used by `runsc`. Configuring the platform provides significant performance benefits, but isn't the only step to optimizing gVisor performance. See the [Production guide] for more. If you intend to run the KVM platform, you will also need to have KVM installed on your system. If you are running a Debian based system like Debian or Ubuntu you can usually do this by ensuring the module is loaded, and your user has permissions to access the `/dev/kvm` device. Usually, this means that your user is in the `kvm` group. ```shell $ ls -l /dev/kvm crw-rw-+ 1 root kvm 10, 232 Jul 26 00:04 /dev/kvm $ groups | grep -qw kvm && echo ok ok ``` For best performance, use the KVM platform on bare-metal machines only. If you have to run gVisor within a virtual machine, the `systrap` platform will often yield better performance than KVM. If you still want to use KVM within a virtual machine, you will need to make sure that nested virtualization is configured. Here are links to documents on how to set up nested virtualization in several popular environments: Google Cloud: Microsoft Azure: VirtualBox: KVM: *Note: nested virtualization will have poor performance and is historically a cause of security issues (e.g. ). It is not recommended for production.* A third platform, `ptrace`, also has the versatility of running on any environment. However, it has higher performance overhead than `systrap` in almost all cases. `systrap` replaced `ptrace` as the default platform in mid-2023. While `ptrace` continues to exist in the codebase, it is no longer supported and is expected to eventually be removed entirely. If you depend on `ptrace`, and `systrap` doesn't fulfill your needs, please . The platform is selected by the `--platform` command line flag passed to `runsc`. By default, the `systrap` platform is selected. For example, to select the KVM platform, modify your Docker configuration (`/etc/docker/daemon.json`) to pass the `--platform` argument: ```json { "runtimes": { "runsc": { "path": "/usr/local/bin/runsc", "runtimeArgs": [ "--platform=kvm" ] } } } ``` You must restart the Docker daemon after making changes to this file, typically this is done via `systemd`: ```shell $ sudo systemctl restart docker ``` Note that you may configure multiple runtimes using different platforms. For example, the following configuration has one configuration for systrap and one for the KVM platform: ```json { "runtimes": { "runsc-kvm": { "path": "/usr/local/bin/runsc", "runtimeArgs": [ "--platform=kvm" ] }, "runsc-systrap": { "path": "/usr/local/bin/runsc", "runtimeArgs": [ "--platform=systrap" ] } } } ```
Project: Velero (Runtime / Cloud Native Storage)
File: 05-digitalocean.md

title: DigitalOcean link: https://github.com/digitalocean/velero-plugin objectStorage: true volumesnapshotter: true DigitalOcean Block Storage provider plugin for Velero. The plugin is designed to create filesystem snapshots of Block Storage backed PersistentVolumes that are used in a Kubernetes cluster running on DigitalOcean.
Project: containerd (Runtime / Container Runtime)
File: 2017-06-09.md

We added support for pulling Docker images which use the schema1 manifest format in the containerd client. This allows pulling images from older registries as well as images pushed from older versions of Docker. With this change any image from the Docker Hub or registry supporting the v2 API can be pulled. As part of our commitment to support OCI images, the schema 1 images pulled by the client are converted to OCI images before being stored by containerd. The containerd client will only support pushing these images as OCI. One of the goals of containerd is to support multiple consumers. The ability to have swarm, docker, kube, and more all running on the same system and using the same containerd without having naming and actions conflict with one another. We have the namespace API merged in and most of the underlying components updated to support namespaces. You can view the namespace PR below for more information on the functionality of namespaces. We added updates to the client to support attach, checkpoint and restore, exec of additional processes, and fixes. We also ported over the `ctr` and `dist` tools to use the client this week. We only have a few features left to implement, such as , for our 1.0 release. The rest of the month we are working on usability, bug fixes, and stability. We will be helping out with integrations of containerd into other platforms to make sure that everyone has the functionality that they need. If you run into any problems please open an issue on github. Also Pull Requests for the problems you are having are welcome. If you have any question or help working on a change, stop by the #containerd slack channel as everyone is friendly and helpful.
Project: Soda Foundation (Runtime / Cloud Native Storage)
File: opensds.md

The is a collaborative project under Linux Foundation supported by storage users and vendors, including Dell EMC, Intel, Huawei, Fujitsu, Western Digital, Vodafone, NTT and Oregon State University. The project will also seek to collaborate with other upstream open source communities such as Cloud Native Computing Foundation, Docker, OpenStack, and Open Container Initiative. It is a software defined storage controller that provides unified block, file, object storage services and focuses on: Simple*: well-defined API that follows the specification. Lightweight*: no external dependencies, deployed once in binary file or container. Extensible*: pluggable framework available for different storage systems, identity services, capability filters, etc. The OpenSDS community welcomes anyone who is interested in software defined storage and shaping the future of cloud-era storage. If you are a company, you should consider joining the . If you are a developer want to be part of the code development that is happening now, please refer to the Contributing sections below. Mailing list: slack: # Ideas/Bugs:
Project: Longhorn (Runtime / Cloud Native Storage)
File: CHANGELOG-1.6.1.md

Longhorn 1.6.1 introduces several improvements and bug fixes that are intended to improve system quality, resilience, and stability. The Longhorn team appreciates your contributions and expects to receive feedback regarding this release. Note: For more information about release-related terminology, see . Ensure that your cluster is running Kubernetes v1.21 or later before installing Longhorn v1.6.1. You can install Longhorn using a variety of tools, including Rancher, Kubectl, and Helm. For more information about installation methods and requirements, see in the Longhorn documentation. Ensure that your cluster is running Kubernetes v1.21 or later before upgrading from Longhorn v1.5.x or v1.6.x to v1.6.1. Longhorn only allows upgrades from supported versions. For more information about upgrade paths and procedures, see in the Longhorn documentation. For information about important changes, including feature incompatibility, deprecation, and removal, see in the Longhorn documentation. For information about issues identified after this release, see . - @derekbit @chriscchien - @c3y1huang @roger-ryao - @PhanLe1010 @chriscchien - @james-munson @roger-ryao - @votdev @roger-ryao - @ejweber @roger-ryao - @ChanYiLin @roger-ryao - @ChanYiLin @chriscchien - @shuo-wu @roger-ryao - @Vicente-Cheng @roger-ryao - @ejweber @chriscchien - @shuo-wu @chriscchien - @ejweber @roger-ryao - @james-munson @roger-ryao - @mantissahz @roger-ryao - @ChanYiLin @chriscchien - @ChanYiLin @khushboo-rancher @chriscchien - @c3y1huang @chriscchien - @roger-ryao - @derekbit @chriscchien - @ejweber @chriscchien - @ejweber @roger-ryao - @james-munson @chriscchien - @ejweber @roger-ryao - @ChanYiLin @chriscchien - @votdev @yangchiu - @yangchiu @ejweber - @yangchiu @ChanYiLin - @ejweber @chriscchien - @ejweber @chriscchien - @c3y1huang @chriscchien - @FrankYang0529 @roger-ryao - @ejweber @roger-ryao - @shuo-wu @roger-ryao - @yangchiu @mantissahz @PhanLe1010 @c3y1huang - @yangchiu @ChanYiLin @chriscchien - @james-munson @chriscchien - @ChanYiLin @chriscchien - @mantissahz @ChanYiLin @FrankYang0529 @PhanLe1010 @Vicente-Cheng @c3y1huang @chriscchien @derekbit @ejweber @innobead @james-munson @khushboo-rancher @mantissahz @roger-ryao @shuo-wu @votdev @yangchiu
Project: iSulad (Runtime / Container Runtime)
File: seccomp_optimization.md

| Author | | | | - | | Date | 2021-12-30 | | Email | | Seccomp stands for secure computing mode and is used to limit calls made by a process from user space to the kernel. iSulad generates a docker seccomp spec by reading a standard configuration file, and then converts it into an oci seccomp spec for the container runtime lcr. After lcr gets the oci seccomp spec, it will save each architecture in seccomp and more than 300 system calls corresponding to the architecture. Since all the architectures are copied indiscriminately when the docker seccomp spec is converted to the oci seccomp spec, there will be a situation where the seccomp information of the arm architecture is also stored on the x86 architecture machine, which leads to consumption. This reconstruction intends to obtain the current machine architecture when the program is running, and obtain the architecture in a targeted manner during the docker/oci seccomp spec conversion process, so as to reduce the file writing time and improve the container startup speed. During spec conversion, the current machine architecture is read through uname, and the architecture is converted into the seccomp standard format. The corresponding relationship is as follows (currently only x86 and arm architectures are supported): 386 || amd64 SCMP_ARCH_X86_64 arm64 || arm SCMP_ARCH_AARCH64 Then traverse all the architectures in the docker seccomp spec, find the required architecture and add it and all its sub-architectures to the oci seccomp spec. In this way, when the lower-level container is running, only the system calls of the corresponding architecture of the current system will be placed on the disk. x86_64: Create 500 containers sequentially: the average time increases from 57.00s to 56.671s, an increase of 0.6% Create 200 containers in parallel: the average time increases from 14.407s to 14.084s, an increase of 2.24% arm64: Create 500 containers sequentially: the average time increases from 75.271s to 74.263s, an increase of 1.34% Create 150 containers in parallel: average time from 10.255s to 10.131s, an increase of 1.21%
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_config.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Cilium configuration options ``` cilium-dbg config [<option>=(enable|disable) ...] [flags] ``` ``` -a, --all Display all cilium configurations -h, --help help for config --list-options List available options -n, --num-pages int Number of pages for perf ring buffer. New values have to be > 0 -o, --output string json| yaml| jsonpath='{}' -r, --read-only Display read only configurations ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI - Retrieve cilium configuration
Project: Stash by AppsCode (Runtime / Cloud Native Storage)
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: Longhorn (Runtime / Cloud Native Storage)
File: infra.md

name: Infra about: Create a test/dev infra task title: "[INFRA] " labels: ["kind/task", "area/infra"] assignees: '' <!--A clear and concise description of what test/dev infra you want to develop.--> <!-- Please use a task list for items on a separate line with a clickable checkbox https://docs.github.com/en/issues/tracking-your-work-with-issues/about-task-lists [ ] `item 1` --> <!--Add any other context or screenshots about the test infra request here.-->
Project: rkt (Runtime / Container Runtime)
File: tpm.md

rkt supports measuring container state and configuration into the event log. Enable this functionality by building rkt with the . rkt accesses the TPM via the . This `tpmd` is expected to listen on port 12041. Events are logged to PCR 15, with event type `0x1000`. Each event contains the following data: The hash of the container root filesystem The hash of the contents of the container manifest data The hash of the arguments passed to `stage1` This provides a cryptographically verifiable audit log of the containers executed on a node, including the configuration of each.
Project: runc (Runtime / Container Runtime)
File: runc-ps.8.md

% runc-ps "8" runc-ps - display the processes inside a container runc ps [option ...] container-id [ps-option ...] The command ps is a wrapper around the stock ps(1) utility, which filters its output to only contain processes belonging to a specified container-id. Therefore, the PIDs shown are the host PIDs. Any ps(1) options can be used, but some might break the filtering. In particular, if PID column is not available, an error is returned, and if there are columns with values containing spaces before the PID column, the result is undefined. --format|-f table|json : Output format. Default is table. The json format shows a mere array of PIDs belonging to a container; if used, all ps options are gnored. runc-list(8), runc(8).
Project: Kata Containers (Runtime / Container Runtime)
File: VdpaConfig.md

Name | Type | Description | Notes | - | - | - Path | string | | NumQueues | int32 | | [default to 1] Iommu | Pointer to bool | | [optional] [default to false] PciSegment | Pointer to int32 | | [optional] Id | Pointer to string | | [optional] `func NewVdpaConfig(path string, numQueues int32, ) *VdpaConfig` NewVdpaConfig instantiates a new VdpaConfig 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 NewVdpaConfigWithDefaults() *VdpaConfig` NewVdpaConfigWithDefaults instantiates a new VdpaConfig 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 *VdpaConfig) GetPath() string` GetPath returns the Path field if non-nil, zero value otherwise. `func (o VdpaConfig) GetPathOk() (string, bool)` GetPathOk returns a tuple with the Path field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *VdpaConfig) SetPath(v string)` SetPath sets Path field to given value. `func (o *VdpaConfig) GetNumQueues() int32` GetNumQueues returns the NumQueues field if non-nil, zero value otherwise. `func (o VdpaConfig) GetNumQueuesOk() (int32, bool)` GetNumQueuesOk returns a tuple with the NumQueues field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *VdpaConfig) SetNumQueues(v int32)` SetNumQueues sets NumQueues field to given value. `func (o *VdpaConfig) GetIommu() bool` GetIommu returns the Iommu field if non-nil, zero value otherwise. `func (o VdpaConfig) GetIommuOk() (bool, bool)` GetIommuOk returns a tuple with the Iommu field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *VdpaConfig) SetIommu(v bool)` SetIommu sets Iommu field to given value. `func (o *VdpaConfig) HasIommu() bool` HasIommu returns a boolean if a field has been set. `func (o *VdpaConfig) GetPciSegment() int32` GetPciSegment returns the PciSegment field if non-nil, zero value otherwise. `func (o VdpaConfig) GetPciSegmentOk() (int32, bool)` GetPciSegmentOk returns a tuple with the PciSegment field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *VdpaConfig) SetPciSegment(v int32)` SetPciSegment sets PciSegment field to given value. `func (o *VdpaConfig) HasPciSegment() bool` HasPciSegment returns a boolean if a field has been set. `func (o *VdpaConfig) GetId() string` GetId returns the Id field if non-nil, zero value otherwise. `func (o VdpaConfig) 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 *VdpaConfig) SetId(v string)` SetId sets Id field to given value. `func (o *VdpaConfig) HasId() bool` HasId returns a boolean if a field has been set.
Project: CNI-Genie (Runtime / Cloud Native Network)
File: CHANGES.md

Migrated to godep, as depman is not longer supported Introduced golang vendoring feature Fixed issue related to reopen deleted file Fix inotify watcher leak; remove `Cleanup` (#51) Don't return partial lines (PR #40) Use stable version of fsnotify (#46) Fix tail for Windows (PR #36) Improved rate limiting using leaky bucket (PR #29) Fix odd line splitting (PR #30) LimitRate now discards read buffer (PR #28) allow reading of longer lines if MaxLineSize is unset (PR #24) updated deps.json to latest fsnotify (441bbc86b1) added `Config.Logger` to suppress library logging add Cleanup to remove leaky inotify watches (PR #20) redesigned Location field (PR #12) add tail.Tell (PR #14) Rate limiting (PR #10) Detect file deletions/renames in polling file watcher (PR #1) Detect file truncation Fix potential race condition when reopening the file (issue 5) Fix potential blocking of `tail.Stop` (issue 4) Fix uncleaned up ChangeEvents goroutines after calling tail.Stop Support Follow=false Initial open source release
Project: Kube-router (Runtime / Cloud Native Network)
File: metrics.md

The scope of this document is to describe how to setup the needed for to use to discover & scape kube-router . For help with installing Prometheus please see their Metrics options: ```sh --metrics-path string Path to serve Prometheus metrics on ( default: /metrics ) --metrics-port uint16 <0-65535> Prometheus metrics port to use ( default: 0, disabled ) ``` To enable kube-router metrics, start kube-router with `--metrics-port` and provide a port over 0 Metrics is generally exported at the same rate as the sync period for each service. The default values unless other specified is iptables-sync-period - `1 min`` ipvs-sync-period - `1 min`` routes-sync-period - `1 min`` By enabling in Prometheus configuration & adding required annotations Prometheus can automaticly discover & scrape kube-router metrics kube-router v0.2.4 received a metrics overhaul where some metrics were changed into histograms, additional metrics were also added. Please make sure you are using the latest dashboard version with versions => v0.2.4 kube-router 0.1.0-rc2 and upwards supports the runtime configuration for controlling where to expose the metrics. If you are using a older version, metrics path & port is locked to `/metrics` & `8080` If metrics is enabled only services that are running have their metrics exposed The following metrics is exposed by kube-router prefixed by `kuberouter` controllerbgppeers Number of BGP peers of the instance controllerbgpadvertisements_received Total number of BGP advertisements received since kube-router started controllerbgpadvertisements_sent Total number of BGP advertisements sent since kube-router started controllerbgpinternalpeerssync_time Time it took for the BGP internal peer sync loop to complete controllerroutessync_time Time it took for controller to sync routes controlleriptablessync_time Time it took for the iptables sync loop to complete controllerpolicychainssynctime Time it took for controller to sync policy chains controlleripvsservicessynctime Time it took for the ipvs sync loop to complete controlleripvsservices The number of ipvs services in the instance controlleripvsmetricsexporttime The time it took to run the metrics export for IPVS services servicetotalconnections Total connections made to the service since creation servicepacketsin Total n/o packets received by service servicepacketsout Total n/o packets sent by service servicebytesin Total bytes received by the service servicebytesout Total bytes sent by the service serviceppsin Incoming packets per second serviceppsout Outgoing packets per second service_cps Connections per second servicebpsin Incoming bytes per second servicebpsout Outgoing bytes per second To get a grouped list of CPS for each service a Prometheus query could look like this e.g: `sum(kuberouterservicecps) by (svcnamespace, service_name)` This repo contains a example utilizing all the above exposed metrics from kube-router.