cwielenb/CNCF-Dataset huggingface dataset:
Project: Kube-router (Runtime / Cloud Native Network)
File: CONTRIBUTING.md

This document covers how to contribute to the kube-router project. Kube-router uses github PRs to manage contributions (could be anything from documentation, bug fixes, manifests etc.). Please read and for the functionality and internals of kube-router. If you have a question about Kube-router or have a problem using it, please start with contacting us on for quick help. If that doesn't answer your questions, or if you think you found a bug, please . Navigate to: and fork the repository. Follow these steps to setup a local repository for working on Kube-router: ``` bash $ git clone https://github.com/YOUR_ACCOUNT/kube-router.git $ cd kube-router $ git remote add upstream https://github.com/cloudnativelabs/kube-router $ git checkout master $ git fetch upstream $ git rebase upstream/master ``` Create a new branch to make changes on and that branch. ``` bash $ git checkout -b feature_x (make your changes) $ git status $ git add . $ git commit -a -m "descriptive commit message for your changes" ``` get update from upstream ``` bash $ git checkout master $ git fetch upstream $ git rebase upstream/master $ git checkout feature_x $ git rebase master ``` Now your `feature_x` branch is up-to-date with all the code in `upstream/master`, so push to your fork ``` bash $ git push origin master $ git push origin feature_x ``` Now that the `feature_x` branch has been pushed to your GitHub repository, you can initiate the pull request.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_recorder_update.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Update individual pcap recorder ``` cilium-dbg recorder update [flags] ``` ``` --caplen uint Capture Length (0 is full capture) --filters strings List of filters ('<srcCIDR> <srcPort> <dstCIDR> <dstPort> <proto>') -h, --help help for update --id uint Identifier ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Introspect or mangle pcap recorder
Project: OpenEBS (Runtime / Cloud Native Storage)
File: bugs.md

<!-- This is for fixing bugs! For pull requesting new features, improvements and changes use https://github.com/openebs/openebs/compare/?template=features.md --> <!-- Don't forget to follow code style, and update documentation and tests if needed --> <!-- If you can't answer some sections, please delete them --> <!-- Describe your changes in detail --> <!-- Why is this change required? What problem does it solve? --> <!-- If it fixes an open issue, please link to the issue here --> <!-- Please describe in detail how you tested your changes --> <!-- Include details of your testing environment, and the tests you ran to see how your change affects other areas of the code, etc.--> <!-- Will your changes brake backward compatibility or not? --> <!-- Add screenshots of your changes -->
Project: Rook (Runtime / Cloud Native Storage)
File: documentation.md

title: Documentation We are using with the . Thanks to the MkDocs Material theme we have certain "markdown syntax extensions" available: And .. For a whole list of features . To locally preview the documentation, you can run the following command (in the root of the repository): ```console make docs-preview ``` When previewing, now you can navigate your browser to to open the preview of the documentation. !!! hint Should you encounter a `command not found` error while trying to preview the docs for the first time on a machine, you probably need to install the dependencies for MkDocs and extensions used: `pip3 install -r build/release/requirements_docs.txt`. Make sure that your Python binary path is included in your `PATH`. is a tool that generates the documentation for a helm chart automatically. If there are changes in the helm chart, the developer needs to run `make docs` (to run helm-docs) and check in the resulting autogenerated files. To make it easy to check locally for uncommitted changes generated by `make docs`, an additional `make` target exists: simply running `make check-docs` will run the docs auto-generation and will complain if this produces uncommitted changes to doc files. It is therefore a good habit to always run `make check-docs` locally before creating or updating a PR.
Project: Stash by AppsCode (Runtime / Cloud Native Storage)
File: dependencies.md

This file lists the dependencies used in this repository. | Dependency | License | |-|-| | Go | BSD 3-Clause "New" or "Revised" License | | golang.org/x/crypto v0.3.0 | BSD 3-Clause "New" or "Revised" License | | golang.org/x/net v0.2.0 | BSD 3-Clause "New" or "Revised" License | | golang.org/x/sys v0.2.0 | BSD 3-Clause "New" or "Revised" License | | golang.org/x/term v0.2.0 | BSD 3-Clause "New" or "Revised" License | | golang.org/x/text v0.4.0 | BSD 3-Clause "New" or "Revised" License |
Project: HwameiStor (Runtime / Cloud Native Storage)
File: fast_failover.md

sidebar_position: 9 sidebar_label: "Fast Failover" When the stateful application (i.e. Pod with HwameiStor volume) runs into a problem, especially caused by the node issue, it's important to reschedule the Pod to another healthy node and keep running. However, due to the design of the Kubernetes' StatefulSet and Deployment, it will wait a long time (e.g. 5 mins) before rescheduling the Pod. Especially, it will never reschedule the Pod automatically for the StatefulSet Pod. This will cause the application stop, and even cause a huge business loss. HwameiStor provides a feature of fast failover to solve this problem. When identifying the application issue, it will reschedule the Pod immediately without waiting for a very long time. HwameiStor will fail the Pod over to another healthy node, and ensure the required data volumes are also located at the node. So, the application can continue to work. HwameiStor provides the fast failover considering the two cases: Node Failure When a node fails, all the Pods on this node can't work any moreAs to the Pod using HwameiStor volume it's necessary to reschedule to another healthy node with the associated data volume replica. You can trigger the fast failover for this node by: Add a label to this node: ```bash kubectl label node <nodeName> hwameistor.io/failover=start ``` When the fast failover completes, the label will be modified as: ```console hwameistor.io/failover=completed ``` Pod Failure When a Pod fails, you can trigger the fast failover for it by adding a lable to this Pod: ```bash kubectl label pod <podName> hwameistor.io/failover=start ``` When the fast failover completes, the old Pod will be deleted and then the new one will be created on a new node.
Project: Velero (Runtime / Cloud Native Storage)
File: plugin-release-instructions.md

title: Releasing Velero plugins layout: docs toc: "true" Velero plugins maintained by the core maintainers do not have any shipped binaries, only container images, so there is no need to invoke a GoReleaser script. Container images are built via a CI job on git push. Plugins the Velero core team is responsible include all those listed in except the vSphere plugin. Update the README.md file to update the compatibility matrix and `velero install` instructions with the expected version number and open a PR. Determining the version number is based on semantic versioning and whether the plugin uses any newly introduced, changed, or removed methods or variables from Velero. Roll all unreleased changelogs into a new `CHANGELOG-v<version>.md` file and delete the content of the `unreleased` folder. Edit the new changelog file as needed. Once the PR is merged, checkout the upstream `main` branch. Your local upstream might be named `upstream` or `origin`, so use this command: `git checkout <upstream-name>/main`. Tag the git version - `git tag v<version>`. Push the git tag - `git push --tags <upstream-name>` to trigger the image build. Wait for the container images to build. You may check the progress of the GH action that triggers the image build at `https://github.com/vmware-tanzu/<plugin-name>/actions` Verify that an image with the new tag is available at `https://hub.docker.com/repository/docker/velero/<plugin-name>/`. Run the Velero using the new image. Until it is made configurable, you will have to edit the in the test. If all e2e tests pass, go to the GitHub release page of the plugin (`https://github.com/vmware-tanzu/<plugin-name>/releases`) and manually create a release for the new tag. Copy and paste the content of the new changelog file into the release description field.
Project: Weave Net (Runtime / Cloud Native Network)
File: managing-entries-weavedns.md

title: Managing Domain Entries menu_order: 40 search_type: Documentation The following topics are discussed: If you want to give the container a name in DNS other than its hostname, you can register it using the `dns-add` command. For example: ``` $ C=$(docker run -ti weaveworks/ubuntu) $ weave dns-add $C -h pingme2.weave.local ``` You can also use `dns-add` to add the container's configured hostname and domain simply by omitting `-h <fqdn>`, or specify additional IP addresses to be registered against the container's hostname e.g. `weave dns-add 10.2.1.27 $C`. The inverse operation can be carried out using the `dns-remove` command: ``` $ weave dns-remove $C ``` By omitting the container name it is possible to add/remove DNS records that associate names in the weaveDNS domain with IP addresses that do not belong to containers, e.g. non-weave addresses of external services: ``` $ weave dns-add 192.128.16.45 -h db.weave.local ``` Note that such records get removed when stopping the weave peer on which they were added. You can resolve entries from any host running weaveDNS with `weave dns-lookup`: host1$ weave dns-lookup pingme 10.40.0.1 If you would like to deploy a new version of a service, keep the old one running because it has active connections but make all new requests go to the new version, then you can simply start the new server container and then the entry for the old server container. Later, when all connections to the old server have terminated, stop the container as normal. By default, weaveDNS specifies a TTL of 30 seconds in responses to DNS requests. However, you can force a different TTL value by launching weave with the `--dns-ttl` argument: ``` $ weave launch --dns-ttl=10 ``` This will shorten the lifespan of answers sent to clients, so you will be effectively reducing the probability of them having stale information, but you will also be increasing the number of request this weaveDNS instance will receive. See Also *
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_map.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Access userspace cached content of BPF maps ``` -h, --help help for map ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI - Display cached list of events for a BPF map - Display cached content of given BPF map - List all open BPF maps
Project: Virtual Kubelet (Runtime / Container Runtime)
File: usage.md

title: Usage description: Run a Virtual Kubelet either on or external to a Kubernetes cluster weight: 2 You can Virtual Kubelet either or to a Kubernetes cluster using the command-line tool. If you run Virtual Kubelet on a Kubernetes cluster, you can also deploy it using . For `virtual-kubelet` installation instructions, see the guide. To run Virtual Kubelet external to a Kubernetes cluster (not on the Kubernetes cluster you are connecting it to), run the binary with your chosen . Here's an example: ```bash virtual-kubelet --provider aws ``` Once Virtual Kubelet is deployed, run `kubectl get nodes` and you should see a `virtual-kubelet` node (unless you've named it something else using the flag). <!-- The CLI docs are generated using the shortcode in layouts/shortcodes/cli.html and the YAML config in data/cli.yaml --> {{< cli >}} It's possible to run the Virtual Kubelet as a Kubernetes Pod in a or Kubernetes cluster. At this time, automation of this deployment is supported only for the provider. In order to deploy the Virtual Kubelet, you need to install , a Kubernetes development tool. You also need to make sure that your current is either `minikube` or `docker-for-desktop` (depending on which Kubernetes platform you're using). First, clone the Virtual Kubelet repository: ```bash git clone https://github.com/virtual-kubelet/virtual-kubelet cd virtual-kubelet ``` Then: ```bash make skaffold ``` By default, this will run Skaffold in , which will make Skaffold watch and its dependencies for changes and re-deploy the Virtual Kubelet when changes happen. It will also make Skaffold stream logs from the Virtual Kubelet Pod. Alternative, you can run Skaffold outside of development modeif you aren't concerned about continuous deployment and log streamingby running: ```bash make skaffold MODE=run ``` This will build and deploy the Virtual Kubelet and return. {{< info >}} is a package manager that enables you to easily deploy complex systems on Kubernetes using configuration bundles called . {{< /info >}} You can use the Virtual Kubelet to deploy Virtual Kubelet on Kubernetes. First, add the Chart repository (the Chart is currently hosted on ): ```bash helm repo add virtual-kubelet \ https://raw.githubusercontent.com/virtual-kubelet/virtual-kubelet/master/charts ``` {{< success >}} You can check to make sure that the repo is listed amongst your current repos using `helm repo list`. {{< /success >}} Now you can install Virtual Kubelet using `helm install`. Here's an example command: ```bash helm install virtual-kubelet/virtual-kubelet \ --name virtual-kubelet-azure \ --namespace virtual-kubelet \ --set provider=azure ``` This would install the in the `virtual-kubelet` namespace. To verify that Virtual Kubelet has been installed, run this command, which will list the available nodes and watch for changes: ```bash kubectl get nodes \ --namespace virtual-kubelet \ --watch ```
Project: HwameiStor (Runtime / Cloud Native Storage)
File: MIGRATION_GUIDE.md

Starting from , the import path will be: "github.com/golang-jwt/jwt/v4" The `/v4` version will be backwards compatible with existing `v3.x.y` tags in this repo, as well as `github.com/dgrijalva/jwt-go`. For most users this should be a drop-in replacement, if you're having troubles migrating, please open an issue. You can replace all occurrences of `github.com/dgrijalva/jwt-go` or `github.com/golang-jwt/jwt` with `github.com/golang-jwt/jwt/v4`, either manually or by using tools such as `sed` or `gofmt`. And then you'd typically run: ``` go get github.com/golang-jwt/jwt/v4 go mod tidy ``` The original migration guide for older releases can be found at https://github.com/dgrijalva/jwt-go/blob/master/MIGRATION_GUIDE.md.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_bandwidth_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List BPF datapath bandwidth settings ``` cilium-dbg bpf bandwidth 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 ``` - BPF datapath bandwidth settings
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_lrp.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage local redirect policies ``` -h, --help help for lrp ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI - List local redirect policies
Project: OpenEBS (Runtime / Cloud Native Storage)
File: proposal-openebs-volume-volume-mounts.md

OpenEBS Volumes (storage controller) functionality is delivered through containers (say OVCs). Each OpenEBS Volume can comprise of a single or multiple OVCs depending on the redundancy requirements etc. Each of these OVCs will persist data to the attached volume-mounts. The volume-mounts attached to OVCs can range from local directory, a single disk, mirrored (lvm) disk to cloud disks. The volume-mounts also can vary in terms of their performance characteristics like - SAS, SSD or Cache OVCs are designed to run (in hyperconverged) mode on any Container Orchestrators. Maya - will provide the functionality to abstract the different types of storage (also called henceforth as "Raw Storage") and convert them into a "Storage Backend" that can be associated to the OVCs as Volumes. In case of Kubernetes, the Maya will convert the Storage Backends into Persistent Volumes and associate them with OVC (Pod).
Project: Krustlet (Runtime / Container Runtime)
File: README.md

This directory contains the config for CSI RBAC (necessary if you are using KinD). Required binaries for the test are downloaded automatically when you use the `justfile`. Right now we only run these things on Linux because the Registrar is still missing [MacOS support](https://github.com/kubernetes-csi/node-driver-registrar/pull/133) and the mock driver would need to handle Windows, which would reuse our ugly code. It may be worth making some sort of more fully featured and separate mock driver in the future Those would work here for our e2e tests since we are running a KinD node. However, we want these tests to reflect more real world usage and there is no guarantee that a Krustlet node will have a container runtime (nor do we want to require one). There is also the additional benefit of having this be some simple instructions of how you can build some of the key components to get CSI running for a Real World cluster. (https://github.com/jedisct1/as-wasi) dependency, which is a helpful set of wrappers around the low level WASI bindings provided in AssemblyScript. If you are interested in starting your own AssemblyScript project, visit the AssemblyScript . If you don't have Krustlet with the WASI provider running locally, see the instructions in the for running locally. Run: ```shell $ npm install && npm run asbuild ``` Detailed instructions for pushing a module can be found in the .
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_recorder_delete.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Delete individual pcap recorder ``` cilium-dbg recorder delete <recorder id> [flags] ``` ``` -h, --help help for delete ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Introspect or mangle pcap recorder
Project: K8up (Runtime / Cloud Native Storage)
File: PULL_REQUEST_TEMPLATE.md

Short summary of what's included in the PR Give special note to breaking changes: List the exact changes or provide links to documentation. [ ] Categorize the PR by setting a good title and adding one of the labels: `bug`, `enhancement`, `documentation`, `change`, `breaking`, `dependency` as they show up in the changelog [ ] PR contains the label `area:operator` [ ] Link this PR to related issues [ ] I have not made any changes in the `charts/` directory. [ ] Categorize the PR by setting a good title and adding one of the labels: `bug`, `enhancement`, `documentation`, `change`, `breaking`, `dependency` as they show up in the changelog [ ] PR contains the label `area:chart` [ ] PR contains the chart label, e.g. `chart:k8up` . [ ] Chart Version bumped if immediate release after merging is planned [ ] I have run `make chart-docs` [ ] Link this PR to related code release or other issues. <!-- NOTE: Do not mix code changes with chart changes, it will break the release process. Delete the checklist section that doesn't apply to the change. NOTE: These things are not required to open a PR and can be done afterwards, while the PR is open. -->
Project: iSulad (Runtime / Container Runtime)
File: devicemapper_environmental_preparation.md

Install the lvm logical volume management package: ```shell ``` View available block devices on the host: ```shell ``` Use `isuladlvmconf.sh` to configure isulad-thinpool ```sh ``` The contents of `isuladlvmconf.sh` are as follows: ```shell current_dir=$(cd `dirname $0` && pwd) disk="/dev/$1" rm -rf /var/lib/isulad/* dmsetup remove_all lvremove -f isulad/thinpool lvremove -f isulad/thinpoolmeta vgremove -f isulad pvremove -f $disk mount | grep $disk | grep /var/lib/isulad if [ x"$?" == x"0" ];then umount /var/lib/isulad fi echo y | mkfs.ext4 $disk touch /etc/lvm/profile/isulad-thinpool.profile cat > /etc/lvm/profile/isulad-thinpool.profile <<EOF activation { thinpoolautoextend_threshold=80 thinpoolautoextend_percent=20 } EOF pvcreate -y $disk vgcreate isulad $disk echo y | lvcreate --wipesignatures y -n thinpool isulad -l 80%VG echo y | lvcreate --wipesignatures y -n thinpoolmeta isulad -l 1%VG lvconvert -y --zero n -c 512K --thinpool isulad/thinpool --poolmetadata isulad/thinpoolmeta lvchange --metadataprofile isulad-thinpool isulad/thinpool lvs -o+seg_monitor exit 0 ``` Configure `isulad` Configure the `storage-driver` and `storage-opts` in `/etc/isulad/daemon.json`: ```txt "storage-driver": "devicemapper", "storage-opts": [ "dm.thinpooldev=/dev/mapper/isulad-thinpool", "dm.fs=ext4", "dm.minfreespace=10%" ], ``` Restart `isulad`. ```bash $ sudo systemctl restart isulad ```
Project: Firecracker (Runtime / Container Runtime)
File: boot-protocol.md

Firecracker makes certain modifications to the guest's registers regardless of whether a CPU template is used to comply with the boot protocol. If a CPU template is used the boot protocol settings are performed after the CPU template is applied. That means that if the CPU template configures CPUID bits used in the boot protocol settings, they will be overwritten. See also: On x86_64, the following MSRs are set to `0`: MSRIA32SYSENTER_CS MSRIA32SYSENTER_ESP MSRIA32SYSENTER_EIP MSR_STAR MSR_CSTAR MSRKERNELGS_BASE MSRSYSCALLMASK MSR_LSTAR MSRIA32TSC and MSRIA32MISC_ENABLE is set to `1`. On aarch64, the following registers are set: PSTATE to PSRMODEEL1h | PSRABIT | PSRFBIT | PSRIBIT | PSRDBIT PC to kernel load address (vCPU0 only) X0 to DTB/FDT address (vCPU0 only)