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

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Clean fqdn cache ``` cilium-dbg fqdn cache clean [flags] ``` ``` -f, --force Skip confirmation -h, --help help for clean -p, --matchpattern string Delete cache entries with FQDNs that match matchpattern ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage fqdn proxy cache
Project: Lima (Runtime / Container Runtime)
File: MAINTAINERS.md

| Name | GitHub ID (not Twitter ID) | GPG fingerprint | |--||| | Akihiro Suda | | | | Jan Dubois | | | | Anders F Bjrklund | | | | Balaji Vijayakumar | | | See https://github.com/lima-vm/.github/blob/main/SECURITY.md for how to report security issues.
Project: WasmEdge Runtime (Runtime / Container Runtime)
File: microservice.md

The edge cloud can run application logic microservices very close to the client device. The microservices could be stateless computational tasks, such as and , which offload computation from the client. The microservices could also that sync with backend databases. The edge cloud has advantages such as low latency, high security, and high performance. Operationally, WasmEdge can be embedded into cloud-native infrastructure via its SDKs in , and . It is also an OCI compliant runtime that can be directly as a lightweight and high-performance alternative to Linux containers. The following application frameworks have been tested to work with WasmEdge-based microservices. Linkerd MOSN Envoy
Project: Longhorn (Runtime / Cloud Native Storage)
File: CHANGELOG-1.4.1.md

v1.4.1 released! This release introduces improvements and bug fixes as described below about stability, performance, space efficiency, resilience, and so on. Please try it and feedback. Thanks for all the contributions! Please ensure your Kubernetes cluster is at least v1.21 before installing Longhorn v1.4.1. Longhorn supports 3 installation ways including Rancher App Marketplace, Kubectl, and Helm. Follow the installation instructions . Please ensure your Kubernetes cluster is at least v1.21 before upgrading to Longhorn v1.4.1 from v1.3.x/v1.4.0, which are only supported source versions. Follow the upgrade instructions . N/A Please follow up on about any outstanding issues found after this release. ) - @c3y1huang @chriscchien ) - @yangchiu @mantissahz ) - @PhanLe1010 @roger-ryao ) - @c3y1huang @smallteeths @roger-ryao ) - @yangchiu @PhanLe1010 ) - @derekbit @roger-ryao ) - @derekbit @chriscchien ) - @derekbit @roger-ryao ) - @yangchiu @derekbit ) - @mantissahz @chriscchien ) - @derekbit @chriscchien ) - @mantissahz @roger-ryao ) - @shuo-wu @roger-ryao ) - @mantissahz @chriscchien ) - @c3y1huang @chriscchien ) - @yangchiu @weizhe0422 ) - @achims311 @roger-ryao ) - @derekbit @roger-ryao ) - @derekbit @chriscchien ) - @c3y1huang @chriscchien ) - @yangchiu @smallteeths ) - @derekbit ) - @yangchiu @derekbit ) - @derekbit @weizhe0422 @chriscchien ) - @yangchiu @c3y1huang ) - @yangchiu @derekbit ) - @derekbit @chriscchien ) - @ChanYiLin @roger-ryao ) - @hedefalk @shuo-wu @chriscchien ) - @yangchiu @derekbit ) - @smallteeths @chriscchien @ChanYiLin @PhanLe1010 @achims311 @c3y1huang @chriscchien @derekbit @hedefalk @innobead @mantissahz @roger-ryao @shuo-wu @smallteeths @weizhe0422 @yangchiu
Project: JuiceFS (Runtime / Cloud Native Storage)
File: spec-limits.md

sidebar_position: 7 Below are theoretical limits for JuiceFS, in real use, performance and file system size will be limited by the metadata engine and object storage of your choice. Directory tree depth: unlimited File name length: 255 Bytes Symbolic link length: 4096 Bytes Number of hard links: 2^31 Number of files in single directory: 2^31 Number of files in a single volume: unlimited Single file size: 2^(26+31) Total file size: 4EiB
Project: Kata Containers (Runtime / Container Runtime)
File: SgxEpcConfig.md

Name | Type | Description | Notes | - | - | - Id | string | | Size | int64 | | Prefault | Pointer to bool | | [optional] [default to false] `func NewSgxEpcConfig(id string, size int64, ) *SgxEpcConfig` NewSgxEpcConfig instantiates a new SgxEpcConfig 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 NewSgxEpcConfigWithDefaults() *SgxEpcConfig` NewSgxEpcConfigWithDefaults instantiates a new SgxEpcConfig 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 *SgxEpcConfig) GetId() string` GetId returns the Id field if non-nil, zero value otherwise. `func (o SgxEpcConfig) 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 *SgxEpcConfig) SetId(v string)` SetId sets Id field to given value. `func (o *SgxEpcConfig) GetSize() int64` GetSize returns the Size field if non-nil, zero value otherwise. `func (o SgxEpcConfig) GetSizeOk() (int64, bool)` GetSizeOk returns a tuple with the Size field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *SgxEpcConfig) SetSize(v int64)` SetSize sets Size field to given value. `func (o *SgxEpcConfig) GetPrefault() bool` GetPrefault returns the Prefault field if non-nil, zero value otherwise. `func (o SgxEpcConfig) GetPrefaultOk() (bool, bool)` GetPrefaultOk returns a tuple with the Prefault field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *SgxEpcConfig) SetPrefault(v bool)` SetPrefault sets Prefault field to given value. `func (o *SgxEpcConfig) HasPrefault() bool` HasPrefault returns a boolean if a field has been set.
Project: Piraeus Datastore (Runtime / Cloud Native Storage)
File: microk8s.md

This guide shows you how to configure Piraeus Datastore when using . To complete this guide, you should be familiar with: editing `LinstorCluster` resources. MicroK8s is distributed as a . Because Snaps store their state in a separate directory (`/var/snap`) the LINSTOR CSI Driver needs to be updated to use a new path for mounting volumes. To change the LINSTOR CSI Driver, so that it uses the MicroK8s state paths, apply the following `LinstorCluster`: ```yaml apiVersion: piraeus.io/v1 kind: LinstorCluster metadata: name: linstorcluster spec: patches: target: name: linstor-csi-node kind: DaemonSet patch: | apiVersion: apps/v1 kind: DaemonSet metadata: name: linstor-csi-node spec: template: spec: containers: name: linstor-csi volumeMounts: mountPath: /var/lib/kubelet name: publish-dir $patch: delete mountPath: /var/snap/microk8s/common/var/lib/kubelet name: publish-dir mountPropagation: Bidirectional ```
Project: HwameiStor (Runtime / Cloud Native Storage)
File: pvc_autoresizing.md

sidebar_position: 3 sidebar_label: "PVC Autoresizing" The component "hwameistor-pvc-autoresizer" provides the ability to automatically resize Persistent Volume Claims (PVCs). The resizing behavior is controlled by the `ResizePolicy` custom resource definition (CRD). An example of CR is as below: ```yaml apiVersion: hwameistor.io/v1alpha1 kind: ResizePolicy metadata: name: resizepolicy1 spec: warningThreshold: 60 resizeThreshold: 80 nodePoolUsageLimit: 90 ``` The three fields `warningThreshold`, `resizeThreshold`, and `nodePoolUsageLimit` are all of type integer and represent percentages. `warningThreshold` currently does not have any associated alert actions. It serves as a target ratio, indicating that the usage rate of the volume will be below this percentage after resizing is completed. `resizeThreshold` indicates a usage rate at which the resizing action will be triggered when the volume's usage rate reaches this percentage. `nodePoolUsageLimit` represents the upper limit of storage pool usage on a node. If the usage rate of a pool reaches this percentage, volumes assigned to that pool will not automatically resize. This is an examle of CR with label selectors. ```yaml apiVersion: hwameistor.io/v1alpha1 kind: ResizePolicy metadata: name: example-policy spec: warningThreshold: 60 resizeThreshold: 80 nodePoolUsageLimit: 90 storageClassSelector: matchLabels: pvc-resize: auto namespaceSelector: matchLabels: pvc-resize: auto pvcSelector: matchLabels: pvc-resize: auto ``` The `ResizePolicy` has three label selectors: `pvcSelector` indicates that PVCs selected by this selector will automatically resize according to the policy that selected them. `namespaceSelector` indicates that PVCs under namespaces selected by this selector will automatically resize according to this policy. `storageClassSelector` indicates that PVCs created from storage classes selected by this selector will automatically resize according to this policy. These three selectors have an "AND" relationship. If you specify multiple selectors in a `ResizePolicy`, the PVCs must match all of the selectors in order to be associated with that policy. If no selectors are specified in the `ResizePolicy`, it becomes a cluster-wide `ResizePolicy`, acting as the default policy for all PVCs in the entire cluster.
Project: Stash by AppsCode (Runtime / Cloud Native Storage)
File: README.md

This package is a fork of the go-yaml library and is intended solely for consumption by kubernetes projects. In this fork, we plan to support only critical changes required for kubernetes, such as small bug fixes and regressions. Larger, general-purpose feature requests should be made in the upstream go-yaml library, and we will reject such changes in this fork unless we are pulling them from upstream. This fork is based on v2.4.0: https://github.com/go-yaml/yaml/releases/tag/v2.4.0 Introduction The yaml package enables Go programs to comfortably encode and decode YAML values. It was developed within as part of the project, and is based on a pure Go port of the well-known C library to parse and generate YAML data quickly and reliably. Compatibility The yaml package supports most of YAML 1.1 and 1.2, including support for anchors, tags, map merging, etc. Multi-document unmarshalling is not yet implemented, and base-60 floats from YAML 1.1 are purposefully not supported since they're a poor design and are gone in YAML 1.2. Installation and usage The import path for the package is gopkg.in/yaml.v2. To install it, run: go get gopkg.in/yaml.v2 API documentation -- If opened in a browser, the import path itself leads to the API documentation: API stability The package API for yaml v2 will remain stable as described in . License The yaml package is licensed under the Apache License 2.0. Please see the LICENSE file for details. Example ```Go package main import ( "fmt" "log" "gopkg.in/yaml.v2" ) var data = ` a: Easy! b: c: 2 d: [3, 4] ` // Note: struct fields must be public in order for unmarshal to // correctly populate the data. type T struct { A string B struct { RenamedC int `yaml:"c"` D []int `yaml:",flow"` } } func main() { t := T{} err := yaml.Unmarshal([]byte(data), &t) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" t:\n%v\n\n", t) d, err := yaml.Marshal(&t) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" t dump:\n%s\n\n", string(d)) m := make(map[interface{}]interface{}) err = yaml.Unmarshal([]byte(data), &m) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" m:\n%v\n\n", m) d, err = yaml.Marshal(&m) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" m dump:\n%s\n\n", string(d)) } ``` This example will generate the following output: ``` t: {Easy! {2 [3 4]}} t dump: a: Easy! b: c: 2 d: [3, 4] m: map[a:Easy! b:map[c:2 d:[3 4]]] m dump: a: Easy! b: c: 2 d: 3 4 ```
Project: HwameiStor (Runtime / Cloud Native Storage)
File: volume.md

sidebar_position: 5 sidebar_label: "Volume" On-disk files in a container are ephemeral, which presents some problems for non-trivial applications when running in containers. One problem is the loss of files when a container crashes. The kubelet restarts the container but with a clean state. A second problem occurs when sharing files between containers running together in a `Pod`. The Kubernetes volume abstraction solves both of these problems. Kubernetes supports many types of volumes. A Pod can use any number of volume types simultaneously. Ephemeral volume types have a lifetime of a pod, but persistent volumes exist beyond the lifetime of a pod. When a pod ceases to exist, Kubernetes destroys ephemeral volumes; however, Kubernetes does not destroy persistent volumes. For any kind of volume in a given pod, data is preserved across container restarts. At its core, a volume is a directory, possibly with some data in it, which is accessible to the containers in a pod. How that directory comes to be, the medium that backs it, and the contents of it are determined by the particular volume type used. To use a volume, specify the volumes to provide for the Pod in `.spec.volumes` and declare where to mount those volumes into containers in `.spec.containers[*].volumeMounts`. See also the official documentation provided by Kubernetes:
Project: Curve (Runtime / Cloud Native Storage)
File: MAINTAINERS.md

The current maintainers of the Curve project are: Pan WANG, , <aspirer2004@gmail.com>, core maintainer XiaoCui Li, , <ilixiaocui@163.com>, core maintainer opencurveadmin, , <hzchenwei7@corp.netease.com>, project management Curve: https://github.com/opencurve/community/blob/master/teams/Curve/team.json CurveAdm: https://github.com/opencurve/community/blob/master/teams/CurveAdm/team.json
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_statedb_node-addresses.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Show contents of table "node-addresses" ``` cilium-dbg statedb node-addresses [flags] ``` ``` -h, --help help for node-addresses -w, --watch duration Watch for new changes with the given interval (e.g. --watch=100ms) ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Inspect StateDB
Project: Weave Net (Runtime / Cloud Native Network)
File: multi-cloud-multi-hop.md

title: Enabling Multi-Cloud, Multi-Hop Networking and Routing menu_order: 70 search_type: Documentation Before multi-cloud networking can be enabled, you must configure the network to allow connections through Weave Net's control and data ports on the Docker hosts. By default, the control port defaults to TCP 6783, and the data ports to UDP 6783/6784. To override Weave Nets default ports, specify a port using the `WEAVEPORT` setting. For example, if WEAVEPORT is set to `9000`, then Weave uses TCP 9000 for its control port and UDP 9000/9001 for its data port. Important! It is recommended that all peers be given the same setting. A network of containers across more than two hosts can be established even when there is only partial connectivity between the hosts. Weave Net routes traffic between containers as long as there is at least one path of connected hosts between them. For example, if a Docker host in a local data center can connect to hosts in GCE and EC2, but the latter two cannot connect to each other, containers in the latter two can still communicate and Weave Net in this instance will route the traffic via the local data center. See Also
Project: Spiderpool (Runtime / Cloud Native Network)
File: spidermultus.md

| Case ID | Title | Priority | Smoke | Status | Other | |||-|-|--| -- | | M00001 | testing creating spiderMultusConfig with cniType: macvlan and checking the net-attach-conf config if works | p1 | smoke | done | | | M00002 | testing creating spiderMultusConfig with cniType: ipvlan and checking the net-attach-conf config if works | p1 | smoke | done | | | M00003 | testing creating spiderMultusConfig with cniType: sriov and checking the net-attach-conf config if works | p1 | smoke | done | | | M00004 | testing creating spiderMultusConfig with cniType: custom and checking the net-attach-conf config if works | p1 | smoke | done | | | M00005 | testing creating spiderMultusConfig with cniType: custom and invalid json config, expect error happened | p2 | | done | | | M00006 | testing creating spiderMultusConfig with cniType: macvlan with vlanId with two master with bond config and checking the net-attach-conf config if works | p1 | smoke | done | | | M00007 | Manually delete the net-attach-conf of multus, it will be created automatically | p1 | smoke | done | | M00008 | After deleting spiderMultusConfig, the corresponding net-attach-conf will also be deleted | p2 | | done | | | M00009 | Update spidermultusConfig: add new bond config | p1 | smoke | done | | | M00010 | Customize net-attach-conf name via annotation multus.spidernet.io/cr-name | p2 | | done | | | M00011 | webhook validation for multus.spidernet.io/cr-name | p3 | | done | | | M00012 | Change net-attach-conf version via annotation multus.spidernet.io/cni-version | p2 | | done | | | M00013 | webhook validation for multus.spidernet.io/cni-version | p3 | | done | | | M00014 | Already have multus cr, spidermultus should take care of it | p3 | | done | | | M00015 | The value of webhook verification cniType is inconsistent with cniConf | p3 | | done | | | M00016 | vlan is not in the range of 0-4094 and will not be created | p3 | | done | | | M00017 | set disableIPAM to true and see if multus's nad has ipam config | p3 | | done | | | M00018 | set sriov.enableRdma to true and see if multus's nad has rdma config | p3 | | done | | | M00019 | set spidermultusconfig.spec to empty and see if works | p3 | | done | | | M00020 | annotating custom names that are too long or empty should fail | p3 | | done | |
Project: containerd (Runtime / Container Runtime)
File: 2017-05-05.md

This week we have been working on getting Docker integrated with the final RCs for the OCI runtime-spec and runc. We currently have a that is ready for review. This is important for the containerd project because we need a stable runtime like runc and have a spec that is not constantly changing so that people can begin integrating with containerd and know that the APIs we expose and APIs/specs that we depend on are stable for the long term. We finished moving a few of our external dependencies into the containerd organization this week. There were a few projects that we built outside but wanted to bring these under the project to ensure that our dependencies are held to the same standards as the rest of our codebase. This project contains the runc bindings that we consume in containerd to interface with runc and other OCI runtimes. It lets us interact with the binary and handles many of the common options like working with the console socket and other IO operations. This package contains helpers for handling fifos. Fifos are a little more complex than regular pipes and sometimes requires special handling and blocking semantics depending on the flags used with opening the fifo on either end. This package helps to handle many of the common use cases that we use in containerd. The console package is a refresh of the `term` package from Docker. It provides a cleaner API for working with the current console for a program or creating new terminals and keeping the flags in sync for proxying reads and writes between the two sides of the console. The cgroups package is currently used in containerd for collecting stats from cgroups that are created for a container. It exposes a package for exporting cgroup level metrics to prometheus for containers. The btrfs package handles interfacing with btrfs for our snapshotter. It binds to the btrfs C library to create subvolumes and handle any other interaction with the filesystem. continuity provides a transport agnostic filesystem metadata manifest. This allows us to work with filesystems at the file level instead of interacting with a "layer". We also intend to concentrate a rich set of file system utility packages for use in containerd.
Project: Rook (Runtime / Cloud Native Storage)
File: interacting-with-rook-resources.md

are a common set of labels that allows tools to work interoperably, describing objects in a common manner that all tools can understand. `app.kubernetes.io/name`: Is the name of the binary running in a container(combination of "ceph-"+daemonType). `app.kubernetes.io/instance`: A unique name identifying the instance of an application. Due to the nature of how resources are named in Rook, this is guaranteed to be unique per CephCluster namespace but not unique within the entire Kubernetes cluster. `app.kubernetes.io/component`: This is populated with the Kind of the resource controlling this application. For example, `cephclusters.ceph.rook.io` or `cephfilesystems.ceph.rook.io`. `app.kubernetes.io/part-of`: This is populated with the Name of the resource controlling this application. `app.kubernetes.io/managed-by`: `rook-ceph-operator` is the tool being used to manage the operation of an application `app.kubernetes.io/created-by`: `rook-ceph-operator` is the controller/user who created this resource `rook.io/operator-namespace`: The namespace in which rook-ceph operator is running. An Example of Recommended Labels on Ceph mon with ID=a will look like: ``` app.kubernetes.io/name : "ceph-mon" app.kubernetes.io/instance : "a" app.kubernetes.io/component : "cephclusters.ceph.rook.io" app.kubernetes.io/part-of : "rook-ceph" app.kubernetes.io/managed-by : "rook-ceph-operator" app.kubernetes.io/created-by : "rook-ceph-operator" rook.io/operator-namespace : "rook-ceph" ``` Another example on CephFilesystem with ID=a: ``` app.kubernetes.io/name : "ceph-mds" app.kubernetes.io/instance : "myfs-a" app.kubernetes.io/component : "cephfilesystems.ceph.rook.io" app.kubernetes.io/part-of : "myfs" app.kubernetes.io/managed-by : "rook-ceph-operator" app.kubernetes.io/created-by : "rook-ceph-operator" rook.io/operator-namespace : "rook-ceph" ``` !!! Note A totally unique string for an application can be built up from (a) app.kubernetes.io/component, (b) app.kubernetes.io/part-of, (c) the resource's namespace, (d) app.kubernetes.io/name, and (e) app.kubernetes.io/instance fields. For the example above, we could join those fields with underscore connectors like this: cephclusters.ceph.rook.iorook-cephrook-cephceph-mona. Note that this full spec can easily exceed the 64-character limit imposed on Kubernetes labels.
Project: lxd (Runtime / Container Runtime)
File: daemon-behavior.md

(daemon-behavior)= This specification covers some of the Incus daemon's behavior. On every start, Incus checks that its directory structure exists. If it doesn't, it creates the required directories, generates a key pair and initializes the database. Once the daemon is ready for work, Incus scans the instances table for any instance for which the stored power state differs from the current one. If an instance's power state was recorded as running and the instance isn't running, Incus starts it. For those signals, Incus assumes that it's being temporarily stopped and will be restarted at a later time to continue handling the instances. The instances will keep running and Incus will close all connections and exit cleanly. Indicates to Incus that the host is going down. Incus will attempt a clean shutdown of all the instances. After 30 seconds, it kills any remaining instance. The instance `power_state` in the instances table is kept as it was so that Incus can restore the instances as they were after the host is done rebooting. Write a memory profile dump to the file specified with `--memprofile`.