cwielenb/CNCF-Dataset huggingface dataset:
Project: Firecracker (Runtime / Container Runtime)
File: MAINTAINERS.md

Firecracker is maintained by a dedicated team within Amazon: Alexandra Iordache <aghecen@amazon.com> Babis Chalios <bchalios@amazon.com> Diana Popa <dpopa@amazon.com> Egor Lazarchuk <yegorlz@amazon.co.uk> Jonathan Woollett-Light <jcawl@amazon.com> Marco Cali <xmarcalx@amazon.com> Nikita Kalyazin <kalyazin@amazon.com> Pablo Barbachano <pablob@amazon.com> Patrick Roy <roypat@amazon.com> Sudan Landge <sudanl@amazon.com> Takahiro Itazuri <itazur@amazon.com>
Project: lxd (Runtime / Container Runtime)
File: SUPPORT.md

<!-- Include start release --> Incus maintains different release branches in parallel: Long term support (LTS) releases: 6.0 Feature releases: Incus 0.x <!-- Include end release --> The Incus 6.0 LTS release will be supported until June 2029. The first 2 years of support will include bug and security fixes as well as minor usability improvements. The remaining 3 years of support (following Incus 7.0 LTS' release) will only feature security updates. Feature releases are pushed out about monthly and contain new features as well as bugfixes. The normal support length for those releases is until the next release comes out. Some Linux distributions might offer longer support for particular feature releases that they decided to ship. % Include content from ```{include} ../README.md :start-after: <!-- Include start support --> :end-before: <!-- Include end support --> ```
Project: iSulad (Runtime / Container Runtime)
File: rootless.md

| Author | liuhao | | | - | | Date | 2022-10-08 | | Email | liuhao27@huawei.com | `Non-root user` can run `iSulad` based on . If you want to run isulad with a non-root useryou can quickly build the environment by using . Tips: this method is an experimental feature and is not recommended for commercial use Host enabled cgroup V2 `overlayfs` requires a kernel above 5.11 Reference to official documentshttps://github.com/rootless-containers/rootlesskit. For security, files in iSulad remove other permissions and the owner is root, so if you are a non-root user, you need to modify the corresponding permissions. ```bash $ chmod +r /etc/isulad/* $ chmod +r /etc/default/isulad/* $ chmod +r /etc/default/isulad/hooks/* ``` If iSulad has been run on the host before, you need to delete the remaining directories, otherwise iSulad of rootless will not have permission to operate these directories. ```bash $ rm -rf /var/run/isula /var/run/isulad /var/run/lxc ``` ```bash $ cat /etc/isulad/daemon.json { "group": "isula", "default-runtime": "lcr", "graph": "/home/xxxx/rootless", "state": "/run/user/1000/rootlesskit-isulad", "engine": "lcr", "log-level": "ERROR", "pidfile": "/run/user/1000/rootlesskit-isulad/isulad.pid", "log-opts": { "log-file-mode": "0600", "log-path": "/home/xxxx/rootless", "max-file": "1", "max-size": "30KB" }, "log-driver": "file", "container-log": { "driver": "json-file" }, "hook-spec": "/etc/default/isulad/hooks/default.json", "start-timeout": "2m", "storage-driver": "overlay2", "storage-opts": [ "overlay2.overridekernelcheck=true" ], "registry-mirrors": [ ], "insecure-registries": [ ], "pod-sandbox-image": "", "native.umask": "normal", "network-plugin": "", "cni-bin-dir": "", "cni-conf-dir": "", "image-layer-check": false, "use-decrypted-key": true, "insecure-skip-verify-enforce": false, "cri-runtimes": { "kata": "io.containerd.kata.v2" } } ``` ```bash $ rootlesskit --cgroupns --copy-up=/run --copy-up=/usr/local --state-dir=/run/user/1000/rootlesskit-isulad bash $ isulad -H "unix:///run/user/1000/rootlesskit-isulad/isulad.sock" & ``` ```bash $ nsenter -U --preserve-credentials -m -t $(cat /run/user/1000/rootlesskit-isulad/child_pid) $ export ISULAD_HOST="unix:///run/user/1000/rootlesskit-isulad/isulad.sock" $ isula run -tid openeuler-22.03-lts bash ``` List the information about processes associated with 'isula': ```bash $ ps aux |grep isula haozi 79488 0.0 0.0 1228192 8684 pts/5 Sl 17:31 0:00 rootlesskit --cgroupns --copy-up=/run --copy-up=/usr/local --state-dir=/run/user/1000/rootlesskit-isulad bash haozi 79494 0.0 0.0 1228192 7992 pts/5 Sl 17:31 0:00 /proc/self/exe --cgroupns --copy-up=/run --copy-up=/usr/local --state-dir=/run/user/1000/rootlesskit-isulad bash haozi 81279 0.0 0.0 1321272 28892 pts/5 Sl 17:43 0:00 isulad -H unix:///run/user/1000/rootlesskit-isulad/isulad.sock root 83798 0.0 0.0 222300 2164 pts/1 S+ 18:01 0:00 grep --color=auto isula ``` The process owner of isulad and the container are both non-root user haozi. Automated deployment tools. Improve the rootless support of 'oci runtime'.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_policy_import.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Import security policy in JSON format ``` cilium-dbg policy import <path> [flags] ``` ``` cilium-dbg policy import ~/policy.json cilium-dbg policy import ./policies/app/ ``` ``` -h, --help help for import -o, --output string json| yaml| jsonpath='{}' --print Print policy after import --replace Replace existing policy --replace-with-labels strings Replace existing policies that match given 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: Kilo (Runtime / Cloud Native Network)
File: userspace-wireguard.md

It is possible to use a userspace implementation of WireGuard with Kilo. This can make sense in cases where not all nodes in a cluster have WireGuard installed; or nodes are effectively immutable and kernel modules cannot be installed. One example of a userspace implementation of WireGuard is [BoringTun]. In a homogeneous cluster where no node has the WireGuard kernel module, a userspace WireGuard implementation can be made available by deploying a DaemonSet. This DaemonSet creates a WireGuard interface that Kilo will manage. Note: in order to avoid race conditions, `kg` needs to be passed the `--create-interface=false` flag. An example configuration for a K3s cluster with [BoringTun] can be applied with: ```shell kubectl apply -f https://raw.githubusercontent.com/squat/kilo/main/manifests/crds.yaml kubectl apply -f https://raw.githubusercontent.com/squat/kilo/main/manifests/kilo-k3s-userspace.yaml ``` Note: even if some nodes have the WireGuard kernel module, this configuration will cause all nodes to use the userspace implementation of WireGuard. In a heterogeneous cluster where some nodes are missing the WireGuard kernel module, a userspace WireGuard implementation can be provided only to the nodes that need it while enabling the other nodes to leverage WireGuard via the kernel module. An example of such a configuration for a K3s cluster can by applied with: ```shell kubectl apply -f https://raw.githubusercontent.com/squat/kilo/main/manifests/crds.yaml kubectl apply -f https://raw.githubusercontent.com/squat/kilo/main/manifests/kilo-k3s-userspace-heterogeneous.yaml ``` This configuration will deploy as a DaemonSet to label all nodes according to the presence of the WireGuard kernel module. It will also create two different DaemonSets with Kilo: `kilo` without userspace WireGuard; and `kilo-userspace` with [BoringTun] as a sidecar. Note: because Kilo is dependant on nkml, nkml must be run on the host network before CNI is available and requires a kubeconfig in order to access the Kubernetes API.
Project: Kube-OVN (Runtime / Cloud Native Network)
File: ROADMAP.md

This document defines high level goals for Kube-OVN project. We welcome community contributors to discuss and update this Roadmap through Issues. Kube-OVN currently supports two network modes, Overlay and Underlay. We hope to improve the stability, performance, and compatibility with the ecosystem of these two network modes in Kubernetes. Improved Datapath network performance Keeping up with the latest network API features in the community Enhanced network monitoring and visualization capabilities Addition of automated test cases for various scenarios VPC network is a key feature of Kube-OVN, many functions have been used in production environment, and we hope to increase the maturity of these functions and improve the user experiences. Standardize multiple gateway solutions and provide the best egress practice Provide more VPC internal basic network capabilities and solutions, such as DNS, DHCP, LoadBalancer, etc. Simplify VPC operation complexity and provide a more comprehensive CLI Supplement automated test cases for various scenarios Improve the user experience of Kubernetes cni, making container networking simpler, more reliable, and efficient. Helm/Operator to automate daily operations More organized metrics and grafana dashboard Troubleshooting tools that can automatically find known issues Integrated with other projects like kubeaz, kubekey, sealos etc.
Project: Weave Net (Runtime / Cloud Native Network)
File: allocation-multi-ipam.md

title: Automatic Allocation Across Multiple Subnets menu_order: 30 search_type: Documentation IP subnets are used to define or restrict routing. By default, Weave Net puts all containers into a subnet that spans the entire allocation range, so that every Weave-attached container can communicate with every other Weave-attached container. If you want some , you can choose to run containers on different subnets. To request the allocation of an address from a particular subnet, set the `WEAVE_CIDR` environment variable to `net:<subnet>` when creating the container, for example: host1$ docker run -e WEAVE_CIDR=net:10.2.7.0/24 -ti weaveworks/ubuntu You can ask for multiple addresses in different subnets and add in manually-assigned addresses (outside the automatic allocation range), for instance: host1$ docker run -e WEAVE_CIDR="net:10.2.7.0/24 net:10.2.8.0/24 ip:10.3.9.1/24" -ti weaveworks/ubuntu Note: The ".0" and ".-1" addresses in a subnet are not used, as required by ). When working with multiple subnets in this way, it is usually desirable to constrain the default subnet - for example, the one chosen by the allocator when no subnet is supplied - so that it does not overlap with others. You can specify this by using `--ipalloc-default-subnet`: host1$ weave launch --ipalloc-range 10.2.0.0/16 --ipalloc-default-subnet 10.2.3.0/24 `--ipalloc-range` should cover the entire range that you will ever use for allocation, and `--ipalloc-default-subnet` is the subnet that will be used when you don't explicitly specify one. When specifying addresses, the default subnet can be denoted symbolically using `net:default`. Containers can be started using a mixture of automatically-allocated addresses and manually-chosen addresses in the same range. However, you may find that the automatic allocator has already reserved a specific address that you wanted. To reserve a range for manual allocation in the same subnet as the automatic allocator, you can specify an `--ipalloc-range` that is smaller than `--ip-default-subnet`, For example, if you launch weave with: host1$ weave launch --ipalloc-range 10.9.0.0/17 --ipalloc-default-subnet 10.9.0.0/16 then you can run all containers in the 10.9.0.0/16 subnet, with automatic allocation using the lower half, leaving the upper half free for manual allocation. See Also *
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_endpoint_get.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Display endpoint information ``` cilium-dbg endpoint get ( <endpoint identifier> | -l <endpoint labels> ) [flags] ``` ``` cilium-dbg endpoint get 4598 cilium-dbg endpoint get pod-name:default:foobar cilium-dbg endpoint get -l id.baz ``` ``` -h, --help help for get -l, --labels strings list of labels -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 endpoints
Project: Rook (Runtime / Cloud Native Storage)
File: kubectl-plugin.md

title: kubectl Plugin The Rook kubectl plugin is a tool to help troubleshoot your Rook cluster. Here are a few of the operations that the plugin will assist with: Health of the Rook pods Health of the Ceph cluster Create "debug" pods for mons and OSDs that are in need of special Ceph maintenance operations Restart the operator Purge an OSD Run any `ceph` command See the for more details. Install Install Rook plugin ```console kubectl krew install rook-ceph ``` Run any `ceph` command with `kubectl rook-ceph ceph <args>`. For example, get the Ceph status: ```console kubectl rook-ceph ceph status ``` Output: ```console cluster: id: a1ac6554-4cc8-4c3b-a8a3-f17f5ec6f529 health: HEALTH_OK services: mon: 3 daemons, quorum a,b,c (age 11m) mgr: a(active, since 10m) mds: 1/1 daemons up, 1 hot standby osd: 3 osds: 3 up (since 10m), 3 in (since 8d) data: volumes: 1/1 healthy pools: 6 pools, 137 pgs objects: 34 objects, 4.1 KiB usage: 58 MiB used, 59 GiB / 59 GiB avail pgs: 137 active+clean io: client: 1.2 KiB/s rd, 2 op/s rd, 0 op/s wr ``` Reference: Debug mode can be useful when a MON or OSD needs advanced maintenance operations that require the daemon to be stopped. Ceph tools such as `ceph-objectstore-tool`, `ceph-bluestore-tool`, or `ceph-monstore-tool` are commonly used in these scenarios. Debug mode will set up the MON or OSD so that these commands can be run. Start the debug pod for mon b ```console kubectl rook-ceph debug start rook-ceph-mon-b ``` Stop the debug pod for mon b ```console kubectl rook-ceph debug stop rook-ceph-mon-b ``` Reference:
Project: OpenIO (Runtime / Cloud Native Storage)
File: CONTRIBUTING.md

Existing code style may not be consistent everywhere. We provide a configuration file for that should be OK for new files. Be careful when applying it on existing files, ``indent`` may be zealous and modify more lines than expected. The code must comply with . Running ``tox -e pep8`` will tell what is wrong (this will actually run ``flake8``). Running pylint on your code is also a good practice. When using abbreviations, try to be consistent. Here is a list of abbreviation commonly used in the existing code base. acct: account cid: container ID cs: conscience err: error exc: exception m0: meta0 m1: meta1 m2: meta2 ns: namespace req: request reqid: request ID resp: response Pull requests implementing new features should be targeted at the master branch. Pull requests fixing bugs should be targeted at the maintenance branch for the version you are using. Or better, if it applies, targeted at the oldest alive maintenance branch (end-of-life branches have the prefix "eol-"). Old maintenance branches are merged into more recent branches from time to time. OpenIO's maintainers usually rebase and merge pull requests (instead of just merging them). This avoids creating too many merge commits, since pull requests often contain only one commit. When creating the pull request on GitHub, please select "Allow edits from maintainers." so the maintainers can rebase it if needed. If a pull request is still work-in-progress, prefix the title with "[WIP]", and the maintainers won't touch it. There is a bunch of things you can add at the end of ``.git/hooks/pre-commit``: The utility will check for typos. The script will detect any missing or out-of-date copyright mention. Tox' pep8 environment will check for coding style issues in Python files. Copy (or rename) ``.git/hooks/pre-commit.sample`` to ``.git/hooks/pre-commit``, and add this at the end: ```bash MODIFIED_FILES="$(git diff --diff-filter=d --name-only $against | grep -E -e '.py$' -e '.c$' -e '.h$' -e '.sh$' -e '.go$' || true)" MODIFIEDPYFILES="$(git diff --diff-filter=d --name-only $against | grep -E -e '.py$' || true)" if [ -n "$MODIFIED_FILES" ] then typos $MODIFIED_FILES ./tools/oio-check-copyright.sh $MODIFIED_FILES fi if [ -n "$MODIFIEDPYFILES" ] then tox -e pep8 -- $MODIFIEDPYFILES fi ```
Project: Kube-router (Runtime / Cloud Native Network)
File: kubeadm.md

Please follow the to install Kubernetes cluster with Kubeadm, however must specify `--pod-network-cidr` when you run `kubeadm init`. kube-router relies on kube-controller-manager to allocate pod CIDR for the nodes. kube-router provides pod networking, network policy and high perfoming IPVS/LVS based service proxy. Depending on your choice to use kube-router for service proxy you have two options. For the step #3 Installing a Pod network add-on install a kube-router pod network and network policy add-on with the following command: ```sh KUBECONFIG=/etc/kubernetes/admin.conf kubectl apply -f https://raw.githubusercontent.com/cloudnativelabs/kube-router/master/daemonset/kubeadm-kuberouter.yaml ``` For the step #3 Installing a Pod network add-on install a kube-router pod network and network policy add-on with the following command: ```sh KUBECONFIG=/etc/kubernetes/admin.conf kubectl apply -f https://raw.githubusercontent.com/cloudnativelabs/kube-router/master/daemonset/kubeadm-kuberouter-all-features.yaml ``` Now since kube-router provides service proxy as well. Run below commands to remove kube-proxy and cleanup any iptables configuration it may have done. ```sh KUBECONFIG=/etc/kubernetes/admin.conf kubectl -n kube-system delete ds kube-proxy ``` To cleanup kube-proxy we can do this with docker, containerd, or cri-o: ```sh docker run --privileged -v /lib/modules:/lib/modules --net=host registry.k8s.io/kube-proxy-amd64:v1.28.2 kube-proxy --cleanup ``` ```sh ctr images pull k8s.gcr.io/kube-proxy-amd64:v1.28.2 ctr run --rm --privileged --net-host --mount type=bind,src=/lib/modules,dst=/lib/modules,options=rbind:ro \ registry.k8s.io/kube-proxy-amd64:v1.28.2 kube-proxy-cleanup kube-proxy --cleanup ``` ```sh crictl pull registry.k8s.io/kube-proxy-amd64:v1.28.2 crictl run --rm --privileged --net-host --mount type=bind,src=/lib/modules,dst=/lib/modules,options=rbind:ro registry.k8s.io/kube-proxy-amd64:v1.28.2 kube-proxy-cleanup kube-proxy --cleanup ```
Project: Spiderpool (Runtime / Cloud Native Network)
File: swagger_openapi.md

Spiderpool uses go-swagger to generate open api source codes. There are two swagger yaml for 'agent' and 'controller'. Please check with and . source codes. Validate spec Generate C/S codes Verify spec with current source codes Clean codes Use swagger-ui to analyze the given specs. There are two ways for you to get access to the features. Use `makefile`, it's the simplest way. Use shell `swag.sh`. The format usage for 'swag.sh' is `swag.sh $ACTION $SPEC_DIR`. Validate the current spec just give the second parameter with the spec directory. ```shell ./tools/scripts/swag.sh validate ./api/v1/agent ``` Or you can use `makefile` to validate the spiderpool agent and controller with the following command. ```shell make openapi-validate-spec ``` To generate agent source codes: ```shell ./tools/scripts/swag.sh generate ./api/v1/agent ``` Or you can use `makefile` to generate for both of agent and controller two: ```shell make openapi-code-gen ``` To verify the given spec whether valid or not: ```shell ./tools/scripts/swag.sh verify ./api/v1/agent ``` Or you can use `makefile` to verify for both of agent and controller two: ```shell make openapi-verify ``` To clean the generated agent codes: ```shell ./tools/scripts/swag.sh verify ./api/v1/agent ``` Or you can use `makefile` to clean for both of agent and controller two: ```shell make clean-openapi-code ``` To analyze the defined specs in your local environment with docker: ```shell make openapi-ui ``` Then you can visit the web with port 8080. Switch the yaml with './agent-swagger.yaml' and './controller-swagger.yaml' in the web. Modify the specs: and Validate the modified specs Use swagger-ui to check the effects in your local environment with docker Re-generate the source codes with the modified specs Commit your PR.
Project: Velero (Runtime / Cloud Native Storage)
File: schedule.md

title: "Schedule API Type" layout: docs The `Schedule` API type is used as a repeatable request for the Velero server to perform a backup for a given cron notation. Once created, the Velero Server will start the backup process. It will then wait for the next valid point of the given cron expression and execute the backup process on a repeating basis. Schedule belongs to the API group version `velero.io/v1`. Here is a sample `Schedule` object with each of the fields documented: ```yaml apiVersion: velero.io/v1 kind: Schedule metadata: name: a namespace: velero spec: schedule: 0 7 * template: csiSnapshotTimeout: 10m includedNamespaces: '*' excludedNamespaces: some-namespace includedResources: '*' excludedResources: storageclasses.storage.k8s.io includeClusterResources: null labelSelector: matchLabels: app: velero component: server snapshotVolumes: null storageLocation: aws-primary volumeSnapshotLocations: aws-primary gcp-primary ttl: 24h0m0s defaultVolumesToRestic: true metadata: labels: labelname: somelabelvalue hooks: resources: name: my-hook includedNamespaces: '*' excludedNamespaces: some-namespace includedResources: pods excludedResources: [] labelSelector: matchLabels: app: velero component: server pre: exec: container: my-container command: /bin/uname -a onError: Fail timeout: 10s post: useOwnerReferencesInBackup: false status: phase: "" lastBackup: validationErrors: ```
Project: HwameiStor (Runtime / Cloud Native Storage)
File: release-process.md

This is the process to follow to make a new release. Similar to Version. The project refers to the respective components of this triple as < major >.< minor >.< patch >. The Hwameistor Project's release process is as follows: <span id="Minor"> </span> A minor release is e.g. v0.1.0. A minor release requires 3 steps are as follows: Ensure all issues of `priority/critical-urgent` or `priority/important-soon` label have been resolved. Ensure all PRs about feature which should be included in this version have been merged. Check the latest PeriodCheck based on main branch has passed. SmokeTest (optional) An issue is proposing a new release with a changelog since the latest release. Check out master, ensure it's upto date, and ensure you have a clean working directory. Update `CHANGELOG.md` and create changelog under `changelogs/released/<version>` directory Create a new local release branch from master. Edit file `helm/hwameistor/Chart.yaml` Modify version field to release version Modify appVersion field to release version > NOTE: version and appVersion are consistent by default Commit all changes, push the branch, and PR it into master. Checkout release packages(includes helm packages, images) are generated correctly. Write release notes to explain the changes of this release corresponding to the changelog. <span id="Patch"> </span> A minor release is e.g. v0.1.1. A patch release requires 3 steps are as follows: Ensure all issues of `priority/critical-urgent` or `priority/important-soon` label have been resolved. Check the latest PeriodCheck based on main branch has passed. SmokeTest (optional) An issue is proposing a new release with a changelog since the latest release. Check out master, ensure it's upto date, and ensure you have a clean working directory. Update `CHANGELOG.md` and create changelog under `changelogs/released/<version>` directory Create a new local release branch from master. Edit file `helm/hwameistor/Chart.yaml` Modify version field to release version Modify appVersion field to release version > NOTE: version and appVersion are consistent by default Commit all changes, push the branch, and PR it into master. Checkout release packages(includes helm packages, images) are generated correctly. Write release notes to explain the changes of this release corresponding to the changelog.