cwielenb/CNCF-Dataset huggingface dataset:
Project: Stash by AppsCode (Runtime / Cloud Native Storage)
File: CHANGES.md

v2/callctx:* add new callctx package () () v2:* add BuildHeaders and InsertMetadataIntoOutgoingContext to header () () v2:* add GoVersion package variable () () v2:* handle space in non-devel go version () () update dependencies () () v2:* drop cloud lro test dep () (), refs apierror:* add method to return HTTP status code conditionally () (), refs add ref to usage with clients () (), refs v2:* add WithTimeout option () () v2/apierror:* return Unknown GRPCStatus when err source is HTTP () (), refs update google.golang.org/api to latest () () v2/apierror:* add apierror.FromWrappingError () () v2:* copy DetermineContentType functionality () () v2:* resolve bad genproto pseudoversion in go.mod () () add ExtractProtoMessage to apierror () () v2:* add OnHTTPCodes CallOption () () v2/apierror:* use errors.As in FromError () () v2:* bump release-please processing () ()
Project: Kube-router (Runtime / Cloud Native Network)
File: introduction.md

Welcome to the introduction guide to Kube-router! This guide is the best place to start with Kube-router. We cover what kube-router is, what problems it can solve, how it compares to existing software, and how you can get started using it. If you are familiar with the basics of Kube-router, head over to the next sections that provide a more detailed reference of available features. If you are not familiar with Kubernetes networking model it is recommended to familiarize with Kubernetes . So essentially Kubernetes expects: all containers can communicate with all other containers without NAT all nodes can communicate with all containers (and vice-versa) without NAT the IP that a container sees itself as is the same IP that others see it as Kubernetes only prescribes the requirements for the networking model but does not provide any default implementation. For a functional Kubernetes cluster one has to deploy what is called as CNI or pod networking solution that provides the above functionality. Any non-trivial containerized application will end up running multiple pods and exposing different services. abstraction in Kubernetes is an essential building block that helps in service discovery and load balancing. A layer-4 service proxy must be deployed to the Kubernetes cluster that provides the load-balancing for the services exposed by the pods. Once you have pod-to-pod networking established and have a service proxy that provides load-balancing, you need a way to secure your pods. Kubernetes provide a specfication to secure pods. You need to deploy a solution that implements network policy specification and provides security for your pods. If you utilize services in your cluster, then you need to deploy a solution that will allocate and manage your LoadBalancer IP address space. Kube-router is a turnkey solution for Kubernetes networking that provides all the above essential functionality in one single elegant package. Network is hard. You have multiple Kubernetes networking solutions that provide pod networking or network policy etc. But when you deploy indiviudal solution for each functionality you end up with lot of moving parts making it difficult to operate and troubleshoot. Kube-router is a lean yet powerful all-in-one alternative to several network components used in typical Kubernetes clusters. All this from a single DaemonSet/Binary. It doesn't get any easier. Kube-router also uses best-of-breed low-level kernel solutions for maximum performance. Kube-router uses IPVS/LVS for service proxying and provides direct routing between the nodes. Kube-router also provides very unique and advanced functionalities like DSR (Direct Server Return), ECMP based network load balancing etc.
Project: Lima (Runtime / Container Runtime)
File: _index.md

title: Colima (third-party project) weight: 0 is a third-party project that wraps Lima to provide an alternative user experience for launching containers. The key difference is that Colima launches Docker by default, while Lima launches containerd by default. | Container | Lima | Colima | ||--|-| | containerd | `limactl start` | `colima start --runtime=containerd` | | Docker | `limactl start template://docker` | `colima start` | | Podman | `limactl start template://podman` | - | | Kubernetes | `limactl start template://k8s` | `colima start --kubernetes` | The `colima` CLI is similar to the `limactl` CLI, but there are subtle differences: | Configuration | Lima | Colima | |--|--|--| | CPUs | `limactl start --cpus=4` | `colima start --cpu=4` | | Reverse SSHFS | `limactl start --mount-type=reverse-sshfs` | `colima start --mount-type=sshfs` | | Rosetta | `limactl start --rosetta` | `colima start --vz-rosetta` | | Access to VM by IP | `limactl start --network=lima:shared` | `colima start --network-address` |
Project: CubeFS (Runtime / Cloud Native Storage)
File: requirement.md

::: tip Note Before setting up the cluster, please prepare the following components in advance to make your user experience smoother~ ::: | Dependency | Version Requirement | Required | |-||| | gcc-c++ | 4.8.5 or above | Yes | | CMake | 3.1 or above | Yes | | bzip2-devel | 1.0.6 or above | Yes | | zlib-devel | 1.2.7 or above | Yes | | mvn | 3.8.4 or above | Yes | | Go | 1.17 or above | Yes | | kafka | 1.x or above | Yes(Deploying erasure code subsystem) | | consul | 1.1x or above | Yes(Deploying erasure code subsystem) |
Project: Kube-router (Runtime / Cloud Native Network)
File: RELEASE.md

Ensure that the Golang release used is still supported. Definition happens currently in . Ensure that the Alpine version used in container builds is still supported. Definition happens currently in . Ensure that Golang dependencies are updated. `go list -mod=mod -u -m -f '{{.}}{{if .Indirect}} IAMINDIRECT{{end}}' all | grep -v IAMINDIRECT` lists possible updates. Ensure that the GoBGP version is updated. See and GoBGP definition in and . Ensure that the Kubernetes object definitions do not contain deprecated object types. Definition currently is in kube-router's folder. Create a branch named v$MAJOR.$MINOR from the default branch (currently: master) Create a new tag with the release tag v$MAJOR.$MINOR.0 ```sh git tag <tag_name> git push origin <tag_name> ``` Note: your remote for the main kube-router repo may not be origin, please correct it to whatever you have called the official kube-router remote. Change to the `master` branch Use `git log` to identify which commits you want to bring to the new patch release Change to the major/minor release branch that was created for this release Cherry-Pick the changes from the `master` branch into the release branch Create a new tag from the v$MAJOR.$MINOR release branch with the release tag v$MAJOR.$MINOR.$PATCH Example: ```sh git checkout master git log --color --pretty=format:'%h - %s (%cr) <%an>' --abbrev-commit --decorate git checkout <release_branch> git cherry-pick <commithashfromabovelog> git tag <tag_name> git push origin <tag_name> ``` Note: your remote for the main kube-router repo may not be origin, please correct it to whatever you have called the official kube-router remote. Follow above instructions and ensure that the tag contains `-rc`. Don't mark the pre-release as a proper release. Once the tag is pushed to GitHub GitHub Actions will be triggered and several things will happen: kube-router will be linted kube-router will be tested The actions will run a test build of the kube-router binary Containers for (see `platforms` section in yaml) will be built and pushed to via the `docker buildx` command will be run and will: Generate a draft release on GitHub where maintainers can later choose to update it and release it Brief release notes will be added to the draft release Build all of the binary releases for and attach them to the draft release on GitHub Go to the Find the draft release Consistent Changelog Syntax can be retrieved by running the following Git command: ```sh git log --format='* %h - %s `<%an>`' <tag>..<tag> ``` Announce the release in on Kubernetes Slack.
Project: Kata Containers (Runtime / Container Runtime)
File: VsockConfig.md

Name | Type | Description | Notes | - | - | - Cid | int64 | Guest Vsock CID | Socket | string | Path to UNIX domain socket, used to proxy vsock connections. | Iommu | Pointer to bool | | [optional] [default to false] PciSegment | Pointer to int32 | | [optional] Id | Pointer to string | | [optional] `func NewVsockConfig(cid int64, socket string, ) *VsockConfig` NewVsockConfig instantiates a new VsockConfig 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 NewVsockConfigWithDefaults() *VsockConfig` NewVsockConfigWithDefaults instantiates a new VsockConfig 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 *VsockConfig) GetCid() int64` GetCid returns the Cid field if non-nil, zero value otherwise. `func (o VsockConfig) GetCidOk() (int64, bool)` GetCidOk returns a tuple with the Cid field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *VsockConfig) SetCid(v int64)` SetCid sets Cid field to given value. `func (o *VsockConfig) GetSocket() string` GetSocket returns the Socket field if non-nil, zero value otherwise. `func (o VsockConfig) GetSocketOk() (string, bool)` GetSocketOk returns a tuple with the Socket field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *VsockConfig) SetSocket(v string)` SetSocket sets Socket field to given value. `func (o *VsockConfig) GetIommu() bool` GetIommu returns the Iommu field if non-nil, zero value otherwise. `func (o VsockConfig) 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 *VsockConfig) SetIommu(v bool)` SetIommu sets Iommu field to given value. `func (o *VsockConfig) HasIommu() bool` HasIommu returns a boolean if a field has been set. `func (o *VsockConfig) GetPciSegment() int32` GetPciSegment returns the PciSegment field if non-nil, zero value otherwise. `func (o VsockConfig) 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 *VsockConfig) SetPciSegment(v int32)` SetPciSegment sets PciSegment field to given value. `func (o *VsockConfig) HasPciSegment() bool` HasPciSegment returns a boolean if a field has been set. `func (o *VsockConfig) GetId() string` GetId returns the Id field if non-nil, zero value otherwise. `func (o VsockConfig) 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 *VsockConfig) SetId(v string)` SetId sets Id field to given value. `func (o *VsockConfig) HasId() bool` HasId returns a boolean if a field has been set.
Project: Velero (Runtime / Cloud Native Storage)
File: zenhub.md

title: "ZenHub" layout: docs As an Open Source community, it is necessary for our work, communication, and collaboration to be done in the open. GitHub provides a central repository for code, pull requests, issues, and documentation. When applicable, we will use Google Docs for design reviews, proposals, and other working documents. While GitHub issues, milestones, and labels generally work pretty well, the Velero team has found that product planning requires some additional tooling that GitHub projects do not offer. In our effort to minimize tooling while enabling product management insights, we have decided to use to overlay product and project tracking on top of GitHub. ZenHub is a GitHub application that provides Kanban visualization, Epic tracking, fine-grained prioritization, and more. It's primary backing storage system is existing GitHub issues along with additional metadata stored in ZenHub's database. If you are a Velero user or Velero Developer, you do not need to use ZenHub for your regular workflow (e.g to see open bug reports or feature requests, work on pull requests). However, if you'd like to be able to visualize the high-level project goals and roadmap, you will need to use the free version of ZenHub. ZenHub can be integrated within the GitHub interface using their . In addition, you can use their dedicated .
Project: CNI-Genie (Runtime / Cloud Native Network)
File: RELEASE.md

The `yaml` Project is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
Project: runc (Runtime / Container Runtime)
File: runc-restore.8.md

% runc-restore "8" runc-restore - restore a container from a previous checkpoint runc restore [option ...] container-id Restores the container instance from a previously performed runc checkpoint. --console-socket path : Path to an AF_UNIX socket which will receive a file descriptor referencing the master end of the console's pseudoterminal. See . --image-path path : Set path to get criu image files to restore from. --work-path path : Set path for saving criu work files and logs. The default is to reuse the image files directory. --tcp-established : Allow checkpoint/restore of established TCP connections. See . --ext-unix-sk : Allow checkpoint/restore of external unix sockets. See . --shell-job : Allow checkpoint/restore of shell jobs. --file-locks : Allow checkpoint/restore of file locks. See . --manage-cgroups-mode soft|full|strict|ignore. : Cgroups mode. Default is soft. See . : In particular, to restore the container into a different cgroup, --manage-cgroups-mode ignore must be used during both checkpoint and restore, and the containerid_ (or cgroupsPath property in OCI config, if set) must be changed. --bundle|-b path : Path to the root of the bundle directory. Default is current directory. --detach|-d : Detach from the container's process. --pid-file path : Specify the file to write the initial container process' PID to. --no-subreaper : Disable the use of the subreaper used to reap reparented processes. --no-pivot : Do not use pivot root to jail process inside rootfs. This should not be used except in exceptional circumstances, and may be unsafe from the security standpoint. --empty-ns namespace : Create a namespace, but don't restore its properties. See . --auto-dedup : Enable auto deduplication of memory images. See . --lazy-pages : Use lazy migration mechanism. This requires a running criu lazy-pages daemon. See . --lsm-profile type:label : Specify an LSM profile to be used during restore. Here type can either be apparamor or selinux, and label is a valid LSM label. For example, --lsm-profile "selinux:system_u:system_r:container_t:s0:c82,c137". By default, the checkpointed LSM profile is used upon restore. --lsm-mount-context context : Specify an LSM mount context to be used during restore. Only mounts with an existing context will have their context replaced. With this option it is possible to change SELinux mount options. Instead of mounting with the checkpointed context, the specified context will be used. For example, --lsm-mount-context "system_u:object_r:container_file_t:s0:c82,c137". criu(8), runc-checkpoint(8), runc(8).
Project: runc (Runtime / Container Runtime)
File: runc-events.8.md

% runc-events "8" runc-events - display container events and statistics. runc events [option ...] container-id The events command displays information about the container. By default, it works continuously, displaying stats every 5 seconds, and container events as they occur. --interval time : Set the stats collection interval. Default is 5s. --stats : Show the container's stats once then exit. runc(8).
Project: rkt (Runtime / Container Runtime)
File: aci-hosting.md

rkt uses as the native packaging format for . To distribute those images, the appc spec defines an that relies on the DNS to implement a federated namespace that facilitates distributed retrieval. Hosting ACI images is as simple as including some templated HTML `meta` tags that point to the image artifacts in a web page living under the DNS name that corresponds to the image to host. This means that, to host ACI images, you only need a web server serving an HTML page with the right `meta` tags and somewhere to host the artifacts. For the `coreos.com/etcd` image, you can find in the source the following `meta` tags: ``` <meta name="ac-discovery" content="coreos.com/etcd https://github.com/coreos/etcd/releases/download/{version}/etcd-{version}-{os}-{arch}.{ext}"> <meta name="ac-discovery-pubkeys" content="coreos.com/etcd https://coreos.com/dist/pubkeys/aci-pubkeys.gpg"> <meta name="ac-discovery-pubkeys" content="coreos.com/etcd https://coreos.com/dist/pubkeys/app-signing-pubkey.gpg"> ``` When a user tries to fetch this image with the command: ``` $ rkt fetch coreos.com/etcd:v2.0.10 ``` These are the steps rkt will do: Go to `coreos.com/etcd` and look for `ac-discovery-pubkeys` tags where the `content` prefix matches `coreos.com/etcd`, fetch the public keys, and prompt the user to trust them if they're not trusted already. Look for an `ac-discovery` tag with matching `content`. The first line of our example tags matches that so, to fetch the artifacts, rkt will perform a simple template substitution: It will substitute `{version}` with `v2.0.10` It will substitute `{os}` with the current OS (for example, `linux`) It will substitute `{arch}` with the current architecture (for example, `amd64`). It will substitute `{ext}` with `aci` for the actual image and `aci.asc` for the image signature. Fetch the image and signature from the resulting URL and verify that the image has a valid and trusted signature. Let's use Python's built-in HTTP server to host an example ACI. We create an minimal `index.html` file with an `ac-discovery` tag: ```html <html> <head> <meta name="ac-discovery" content="localhost/postgres http://localhost/postgres-{version}-{os}-{arch}.{ext}"> </head> </html> ``` Put the ACI file in the same directory and start the server on port 80: ```bash $ cd /tmp/acis $ ls index.html postgres-latest-linux-amd64.aci $ sudo python3 -m http.server 80 Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ... ``` Now we can fetch the image. To make things simple, we'll disable image verification and use HTTP instead of HTTPs: ```bash $ sudo rkt --insecure-options=http,image fetch localhost/postgres Downloading ACI: [=============================================] 7.46 MB/7.46 MB Downloading ACI: [=============================================] 2.65 MB/2.65 MB sha512-f5d991eed255cd081b4ea6e1b378eab4 ```
Project: Spiderpool (Runtime / Cloud Native Network)
File: affinity.md

| Case ID | Title | Priority | Smoke | Status | Other | | - |--| -- | -- | | -- | | L00001 | Successfully run deployment/pod that is bound to an IPPool set with matched `NodeAffinity` | p2 | true | done | | | L00002 | Failed to run deployment/pod that is bound to an IPPool set with no-matched `NodeAffinity` | p3 | | done | | | L00003 | Successfully run deployment/pod that is bound to an IPPool set with matched `NamespaceAffinity` | p2 | true | done | | | L00004 | Failed to run deployment/pod that is bound to an IPPool set with no-matched `NamespaceAffinity` | p3 | | done | | | L00005 | Successfully run deployment/pod that is bound to an IPPool set with matched `PodAffinity` | p2 | true | done | | | L00006 | Failed to run deployment/pod that is bound to an IPPool set with no-matched `PodAffinity` | p3 | | done | | | L00007 | Successfully run daemonSet/pod that is cross-zone daemonSet with matched `NodeAffinity` | p2 | | done | | | L00008 | Successfully restarted statefulSet/pod with matching `PodAffinity`, ip remains the same | p2 | | done | | | L00009 | Multiple IPPools can be used in the same namespace and one IPPool can be used by multiple namespace | p2 | | done | |
Project: Velero (Runtime / Cloud Native Storage)
File: disaster-case.md

title: "Disaster recovery" layout: docs Using Schedules and Read-Only Backup Storage Locations If you periodically back up your cluster's resources, you are able to return to a previous state in case of some unexpected mishap, such as a service outage. Doing so with Velero looks like the following: After you first run the Velero server on your cluster, set up a daily backup (replacing `<SCHEDULE NAME>` in the command as desired): ``` velero schedule create <SCHEDULE NAME> --schedule "0 7 *" ``` This creates a Backup object with the name `<SCHEDULE NAME>-<TIMESTAMP>`. The default backup retention period, expressed as TTL (time to live), is 30 days (720 hours); you can use the `--ttl <DURATION>` flag to change this as necessary. See for more information about backup expiry. A disaster happens and you need to recreate your resources. Update your backup storage location to read-only mode (this prevents backup objects from being created or deleted in the backup storage location during the restore process): ```bash kubectl patch backupstoragelocation <STORAGE LOCATION NAME> \ --namespace velero \ --type merge \ --patch '{"spec":{"accessMode":"ReadOnly"}}' ``` Create a restore with your most recent Velero Backup: ``` velero restore create --from-backup <SCHEDULE NAME>-<TIMESTAMP> ``` When ready, revert your backup storage location to read-write mode: ```bash kubectl patch backupstoragelocation <STORAGE LOCATION NAME> \ --namespace velero \ --type merge \ --patch '{"spec":{"accessMode":"ReadWrite"}}' ```
Project: Velero (Runtime / Cloud Native Storage)
File: ark_version.md

title: "ark version" layout: docs Print the ark version and associated image Print the ark version and associated image ``` ark version [flags] ``` ``` -h, --help help for version ``` ``` --alsologtostderr log to standard error as well as files --kubeconfig string Path to the kubeconfig file to use to talk to the Kubernetes apiserver. If unset, try the environment variable KUBECONFIG, as well as in-cluster configuration --kubecontext string The context to use to talk to the Kubernetes apiserver. If unset defaults to whatever your current-context is (kubectl config current-context) --logbacktraceat traceLocation when logging hits line file:N, emit a stack trace (default :0) --log_dir string If non-empty, write log files in this directory --logtostderr log to standard error instead of files -n, --namespace string The namespace in which Ark should operate (default "heptio-ark") --stderrthreshold severity logs at or above this threshold go to stderr (default 2) -v, --v Level log level for V logs --vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging ``` - Back up and restore Kubernetes cluster resources.