cwielenb/CNCF-Dataset huggingface dataset:
Project: Kata Containers (Runtime / Container Runtime)
File: centos-installation-guide.md

Install the Kata Containers components with the following commands: ```bash $ sudo -E dnf install -y centos-release-advanced-virtualization $ sudo -E dnf module disable -y virt:rhel $ source /etc/os-release $ cat <<EOF | sudo -E tee /etc/yum.repos.d/kata-containers.repo [kata-containers] name=Kata Containers baseurl=http://mirror.centos.org/\$contentdir/\$releasever/virt/\$basearch/kata-containers enabled=1 gpgcheck=1 skipifunavailable=1 EOF $ sudo -E dnf install -y kata-containers ``` Decide which container manager to use and select the corresponding link that follows:
Project: CNI-Genie (Runtime / Cloud Native Network)
File: README.md

](https://travis-ci.org/ghodss/yaml) A wrapper around designed to enable a better way of handling YAML when marshaling to and from structs. In short, this library first converts YAML to JSON using go-yaml and then uses `json.Marshal` and `json.Unmarshal` to convert to or from the struct. This means that it effectively reuses the JSON struct tags as well as the custom JSON methods `MarshalJSON` and `UnmarshalJSON` unlike go-yaml. For a detailed overview of the rationale behind this method, . This package uses and therefore supports . Caveat #1: When using `yaml.Marshal` and `yaml.Unmarshal`, binary data should NOT be preceded with the `!!binary` YAML tag. If you do, go-yaml will convert the binary data from base64 to native binary data, which is not compatible with JSON. You can still use binary in your YAML files though - just store them without the `!!binary` tag and decode the base64 in your code (e.g. in the custom JSON methods `MarshalJSON` and `UnmarshalJSON`). This also has the benefit that your YAML and your JSON binary data will be decoded exactly the same way. As an example: ``` BAD: exampleKey: !!binary gIGC GOOD: exampleKey: gIGC ... and decode the base64 data in your code. ``` Caveat #2: When using `YAMLToJSON` directly, maps with keys that are maps will result in an error since this is not supported by JSON. This error will occur in `Unmarshal` as well since you can't unmarshal map keys anyways since struct fields can't be keys. To install, run: ``` $ go get github.com/ghodss/yaml ``` And import using: ``` import "github.com/ghodss/yaml" ``` Usage is very similar to the JSON library: ```go package main import ( "fmt" "github.com/ghodss/yaml" ) type Person struct { Name string `json:"name"` // Affects YAML field names too. Age int `json:"age"` } func main() { // Marshal a Person struct to YAML. p := Person{"John", 30} y, err := yaml.Marshal(p) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(y)) /* Output: age: 30 name: John */ // Unmarshal the YAML back into a Person struct. var p2 Person err = yaml.Unmarshal(y, &p2) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(p2) /* Output: {John 30} */ } ``` `yaml.YAMLToJSON` and `yaml.JSONToYAML` methods are also available: ```go package main import ( "fmt" "github.com/ghodss/yaml" ) func main() { j := []byte(`{"name": "John", "age": 30}`) y, err := yaml.JSONToYAML(j) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(y)) /* Output: name: John age: 30 */ j2, err := yaml.YAMLToJSON(y) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(j2)) /* Output: {"age":30,"name":"John"} */ } ```
Project: rkt (Runtime / Container Runtime)
File: dependencies.md

For the most part the codebase is self-contained (e.g. all dependencies are vendored), but assembly of the stage1 requires some other tools to be installed on the system. GNU Make Go 1.5.3 or later autoconf aclocal (usually a part of automake) bash git glibc development headers the rkt binary links against the library gofmt (usually distributed with Go) govet (usually distributed with Go) TrouSerS (only when TPM is enabled, see for details) development headers the rkt binary links against the library libsystemd-journal development headers gpg (when running functional tests) glibc development headers the stage1 binaries link against the static library libdl development headers the stage1 binaries link against the library libacl development headers C compiler cat comm cpio gzip md5sum mktemp sort unsquashfs wget gpg (optional, required when downloading the CoreOS Container Linux PXE image during the build) patch tar xz * bc binutils openssl build dependencies for lkvm and/or qemu build dependencies for systemd Linux 3.18+ (ideally 4.9+ to avoid the issues listed in the ), with the following options configured: CONFIG_CGROUPS CONFIG_NAMESPACES CONFIGUTSNS CONFIGIPCNS CONFIGPIDNS CONFIGNETNS CONFIGOVERLAYFS (nice to have) libacl the library is optional (it is dlopened inside the stage1) bash systemd >= v222 systemctl systemd-shutdown systemd systemd-journald
Project: Rook (Runtime / Cloud Native Storage)
File: OWNERS.md

This page lists all active contributors and their areas of expertise. This can be used for routing PRs, questions, etc. to the right place. See for general contribution guidelines. See for governance guidelines and steering committee and maintainer responsibilities. Steering committee members will be added according to the in the . | Name | Represents | GitHub | | | -- || | Travis Nielsen <tnielsen@redhat.com> | Ceph | | | Jared Watts <jared@upbound.io> | Independent | | Maintainers will be added according to the in the . Travis Nielsen <tnielsen@redhat.com> () Jared Watts <jared@upbound.io> () Alexander Trost <galexrt@googlemail.com> () Sebastien Han <shan@redhat.com> () Blaine Gardner <blaine.gardner@redhat.com> () Satoru Takeuchi <satoru.takeuchi@gmail.com> () Subham Rai <srai@redhat.com> () Santosh Pillai <sapillai@redhat.com> () This list will be updated according to the in the . Bassam Tabbara <bassam@upbound.io> () Dmitry Yusupov <dmitry.yusupov@gmail.com> () Yannis Zarkadas <yanniszarkadas@gmail.com> () Code owners, as described in the of the governance, can be found in files. We are grateful for the countless members of the community who contribute to Rook, whether reporting issues in GitHub or Slack or submitting code or documentation PRs. Thank you for helping this project to grow and mature!
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-generic_completion.md

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> Generate the autocompletion script for the specified shell Generate the autocompletion script for cilium-operator-generic for the specified shell. See each sub-command's help for details on how to use the generated script. ``` -h, --help help for completion ``` - Run cilium-operator-generic - Generate the autocompletion script for bash - Generate the autocompletion script for fish - Generate the autocompletion script for powershell - Generate the autocompletion script for zsh
Project: Velero (Runtime / Cloud Native Storage)
File: CHANGELOG-0.4.md

- https://github.com/heptio/ark/tree/v0.4.0 Snapshotting and restoring volumes is now enabled by default The --namespaces flag for 'ark restore create' has been replaced by --include-namespaces and --exclude-namespaces Support for S3 SSE with KMS Cloud provider configurations are validated at startup The persistentVolumeProvider is now optional Restore objects are garbage collected Each backup now has an associated log file, viewable via 'ark backup logs' Each restore now has an associated log file, viewable via 'ark restore logs' Add --include-resources/--exclude-resources for restores Only save/use iops for io1 volumes on AWS When restoring, try to retrieve the Backup directly from object storage if it's not found When syncing Backups from object storage to Kubernetes, don't return at the first error encountered More closely match how kubectl performs kubeconfig resolution Increase default Azure API request timeout to 2 minutes Update Azure diskURI to match diskName
Project: rkt (Runtime / Container Runtime)
File: status.md

Given a pod UUID, you can get the exit status of its apps. Note that the apps are prefixed by `app-`. ``` $ rkt status 66ceb509 state=exited created=2016-01-26 14:23:34.631 +0100 CET started=2016-01-26 14:23:34.744 +0100 CET pid=16964 exited=true app-redis=0 app-etcd=0 ``` Note that `pid` may not be available shortly after `rkt run`, or `rkt run-prepared`, even when `state=running`. The `--wait` flags below can be used to wait for a Pod to be running with its pid captured. If the pod is still running, you can wait for it to finish and then get the status with `rkt status --wait UUID`. To wait for the pod to become ready, execute `rkt status --wait-ready`. Both options also accept a duration. To wait up to 10 seconds until the pod is finished, execute `rkt status --wait=10s UUID`. | Flag | Default | Options | Description | | | | | | | `--wait` | `false` | `true` or `false` or duration | Toggle waiting for the pod to finish. | | `--wait-ready` | `false` | `true` or `false` or duration | Toggle waiting until the pod is ready. | | `--uuid-file` | "" | UUID file | UUID of the pod. | See the table with .
Project: Velero (Runtime / Cloud Native Storage)
File: ark_get_backups.md

title: "ark get backups" layout: docs Get backups Get backups ``` ark get backups [flags] ``` ``` -h, --help help for backups --label-columns stringArray a comma-separated list of labels to be displayed as columns -o, --output string Output display format. For create commands, display the object but do not send it to the server. Valid formats are 'table', 'json', and 'yaml'. (default "table") -l, --selector string only show items matching this label selector --show-labels show labels in the last column ``` ``` --alsologtostderr log to standard error as well as files --kubeconfig string Path to the kubeconfig file to use to talk to the Kubernetes apiserver. If unset, try the environment variable KUBECONFIG, as well as in-cluster configuration --kubecontext string The context to use to talk to the Kubernetes apiserver. If unset defaults to whatever your current-context is (kubectl config current-context) --logbacktraceat traceLocation when logging hits line file:N, emit a stack trace (default :0) --log_dir string If non-empty, write log files in this directory --logtostderr log to standard error instead of files -n, --namespace string The namespace in which Ark should operate (default "heptio-ark") --stderrthreshold severity logs at or above this threshold go to stderr (default 2) -v, --v Level log level for V logs --vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging ``` - Get ark resources
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_prefilter_delete.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Delete CIDR filters ``` cilium-dbg prefilter delete [flags] ``` ``` --cidr strings List of CIDR prefixes to delete -h, --help help for delete --revision uint Update revision ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage XDP CIDR filters
Project: Singularity (Runtime / Container Runtime)
File: ISSUE_TEMPLATE.md

What version of Singularity are you using? Run: ``` $ singularity --version ``` <!-- please include command-line output in a code block --> What did you expect to see when you do...? What actually happend? Why was it incorrect? <!-- if this is a feature request, you can ignore this next part --> How can others reproduce this issue/problem? ``` $ cat /etc/os-release ``` Write here how you installed Singularity. Eg. RPM, source.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_node_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List nodes ``` cilium-dbg node list [flags] ``` ``` -h, --help help for list -o, --output string json| yaml| jsonpath='{}' ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage cluster nodes
Project: Kata Containers (Runtime / Container Runtime)
File: background.md

The following sections explain some of the background concepts required to understand the . This document uses the term rootfs to refer to a root filesystem which is mounted as the top-level directory ("`/`") and often referred to as slash. It is important to understand this term since the overall system uses multiple different rootfs's (as explained in the section. In the the user has specified the type of container they wish to run via the container image name: `ubuntu`. This image name corresponds to a container image that can be used to create a container with an Ubuntu Linux environment. Hence, in our , the `sh(1)` command will be run inside a container which has an Ubuntu rootfs. Note: The term container image is confusing since the image in question is not a container: it is simply a set of files (an image) that can be used to create a container. The term _container template would be more accurate but the term container image_ is commonly used so this document uses the standard term. For the purposes of this document, the most important part of the is the container image the user has requested. Normally, the container manager will pull (download) a container image from a remote site and store a copy locally. This local container image is used by the container manager to create an which will form the environment the container will run in. After creating the OCI bundle, the container manager launches a which will create the container using the provided OCI bundle. To understand what follows, it is important to know at a high level how an OCI () compatible container is created. An OCI compatible container is created by taking a and converting the embedded rootfs into an , or more simply, an OCI bundle. An OCI bundle is a `tar(1)` archive normally created by a container manager which is passed to an OCI which converts it into a full container rootfs. The bundle contains two assets: A container image This is simply a directory of files that will be used to represent the rootfs for the container. For the , the directory will contain the files necessary to create a minimal Ubuntu root filesystem. An This is a JSON file called `config.json`. The container manager will create this file so that: The `root.path` value is set to the full path of the specified container rootfs. In this value will be `ubuntu`. The `process.args` array specifies the list of commands the user wishes to run. This is known as the . In the workload is `sh(1)`.
Project: HwameiStor (Runtime / Cloud Native Storage)
File: overview.md

sidebar_position: 1 sidebar_label: "Overview" HwameiStor provisions two kind of local volumes: LVM and Disk. As a component of HwameiStor, Local Storage provisions two types of local LVM volumes, such as HA and non-HA. For the non-HA local LVM volume, it's the best solution for data persistency in the following use cases: Database with HA capability, such as MongoDB, etc. Messaging system with HA capability, such as Kafka, RabbitMQ, etc. Key-value store with HA capability, such as Redis, etc. Others with HA capability For the HA local LVM volume, it's the best solution for data persistency in the following use cases: Database, such as MySQL, PostgreSQL, etc. Other applications which requires the data with HA features. It guarantees with raid 5, which can tolerate a set of disk failures. Control flow is independent of data flow to ensure the stability of data access. It provides protection with raid 5 + active/standby mechanism. The dce-storage, a dedicated network logical interface for HA, is designed to synchronize storage traffic between nodes. It can synchronously replicate data across nodes to guarantee a hot backup of data. Balanced placement of data in the cluster is achieved through data volume migration technology. Move data online to nodes with more storage space. In order to support some special scenarios, a single-replica volume is allowed to be changed to multiple replicas, and inter-node hot backup is supported.
Project: Submariner (Runtime / Cloud Native Network)
File: bug-report.md

name: Bug Report about: Report a bug in Submariner labels: bug <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately to the Submariner Owners: https://github.com/orgs/submariner-io/teams/submariner-core --> What happened: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Diagnose information (use `subctl diagnose all`): Gather information (use `subctl gather`): Cloud provider or hardware configuration: Install tools: Others:
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_policy_selectors.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Display cached information about selectors ``` cilium-dbg policy selectors [flags] ``` ``` -h, --help help for selectors -o, --output string json| yaml| jsonpath='{}' -v, --verbose Show the full labels ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage security policies
Project: Weave Net (Runtime / Cloud Native Network)
File: manual-ip-address.md

title: Manually Specifying the IP Address of a Container menu_order: 20 search_type: Documentation Containers are automatically allocated an IP address that is unique across the Weave network. You can see which address was allocated by running, : host1$ weave ps a1 a7aee7233393 7a:44:d3:11:10:70 10.32.0.2/12 Weave Net detects when a container has exited and releases its allocated addresses so they can be re-used by the network. See the and also an explanation of for further details. Instead of allowing Weave Net to allocate IP addresses automatically (using IPAM), there may be instances where you need to control a particular container or a cluster by setting an IP address for it. The way to do this varies according to how containers are attached to Weave Net. The software making a call to CNI has to specify an allocator that allows static IPs. For instance the (At the time of writing there is no straightforward way to ask Kubernetes to do this.) Docker has a flag `--ip` to specify an address, e.g.: $ docker run --network=mynetwork --ip=172.18.0.22 ... You can specify an IP address and a network explicitly, using Classless Inter-Domain Routing or . For example, we can launch a couple of containers on `$HOST1` and `$HOST2`, respectively, with specified IP addresses, as follows... On `$HOST1`: host1$ docker run -e WEAVE_CIDR=10.2.1.1/24 -ti weaveworks/ubuntu root@7ca0f6ecf59f:/# And `$HOST2`: host2$ docker run -e WEAVE_CIDR=10.2.1.2/24 -ti weaveworks/ubuntu root@04c4831fafd3:/# Then test that the container on `$HOST2` can be reached from the container on `$HOST1`: root@7ca0f6ecf59f:/# ping -c 1 -q 10.2.1.2 PING 10.2.1.2 (10.2.1.2): 48 data bytes 10.2.1.2 ping statistics 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.048/1.048/1.048/0.000 ms And in the other direction... root@04c4831fafd3:/# ping -c 1 -q 10.2.1.1 PING 10.2.1.1 (10.2.1.1): 48 data bytes 10.2.1.1 ping statistics 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.034/1.034/1.034/0.000 ms The IP addresses and netmasks can be set to anything, but ensure they dont conflict with any of the IP ranges in use on the hosts or with IP addresses used by any external services to which the hosts or containers may need to connect. Individual IP addresses given to containers must, of course, be unique. If you pick an address that the automatic allocator has already assigned a warning appears. See Also *
Project: Carina (Runtime / Cloud Native Storage)
File: pvc-bcache.md

When carina-node starts up, it automatically loads kernel module `bcache` using `modprobe bcache`. If it's not supported by kernel, then cache tiering will not be enabled. Creating storageclass using `kubectl apply -f storageclass.yaml` ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: csi-carina-sc provisioner: carina.storage.io parameters: csi.storage.k8s.io/fstype: xfs carina.storage.io/backend-disk-group-name: hdd carina.storage.io/cache-disk-group-name: ssd carina.storage.io/cache-disk-ratio: "50" carina.storage.io/cache-policy: writethrough reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer mountOptions: ``` `csi.storage.k8s.io/fstype`: the filesystem formation `carina.storage.io/backend-disk-group-name`: the cold tier `carina.storage.io/cache-disk-group-name`: the hot tier `carina.storage.io/cache-disk-ratio`: percentage of hot/cold, ranging (0-100) `carina.storage.io/cache-policy`: `writethrough|writeback|writearound` Creating PVC using `kubectl apply -f pvc.yaml` ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: csi-carina-pvc namespace: carina spec: accessModes: ReadWriteOnce resources: requests: storage: 7Gi storageClassName: csi-carina-sc volumeMode: Filesystem ``` After PVC been created, carina-controller will create an LogicVolume internally and then carina-node will create local volume. For PVC using cache-tiering, carina will create two local volumes, one hot volume and one cold volume, and setup cache tiering using bcache. ```shell $ kubectl get lv NAME SIZE GROUP NODE STATUS pvc-319c5deb-f637-423b-8b52-42ecfcf0d3b7 7Gi carina-vg-hdd 10.20.9.154 Success cache-9c5deb-f637-423b-8b52-42ecfcf0d3b7 3Gi carina-vg-ssd 10.20.9.154 Success ``` Creating one deployment using that PVC `kubectl apply -f deployment.yaml` ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: carina-deployment namespace: carina labels: app: web-server spec: replicas: 1 selector: matchLabels: app: web-server template: metadata: labels: app: web-server spec: containers: name: web-server image: nginx:latest imagePullPolicy: "IfNotPresent" volumeMounts: name: mypvc mountPath: /var/lib/www/html volumes: name: mypvc persistentVolumeClaim: claimName: csi-carina-pvc readOnly: false ```
Project: runc (Runtime / Container Runtime)
File: PRINCIPLES.md

In the design and development of runc and libcontainer we try to follow these principles: (Work in progress) Don't try to replace every tool. Instead, be an ingredient to improve them. Less code is better. Fewer components are better. Do you really need to add one more class? 50 lines of straightforward, readable code is better than 10 lines of magic that nobody can understand. Don't do later what you can do now. "//TODO: refactor" is not acceptable in new code. When hesitating between two options, choose the one that is easier to reverse. "No" is temporary; "Yes" is forever. If you're not sure about a new feature, say no. You can change your mind later. Containers must be portable to the greatest possible number of machines. Be suspicious of any change which makes machines less interchangeable. The fewer moving parts in a container, the better. Don't merge it unless you document it. Don't document it unless you can keep it up-to-date. Don't merge it unless you test it! Everyone's problem is slightly different. Focus on the part that is the same for everyone, and solve that.