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

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> Generate the autocompletion script for powershell Generate the autocompletion script for powershell. To load completions in your current shell session: cilium-operator-aws completion powershell | Out-String | Invoke-Expression To load completions for every new session, add the output of the above command to your powershell profile. ``` cilium-operator-aws completion powershell [flags] ``` ``` -h, --help help for powershell --no-descriptions disable completion descriptions ``` - Generate the autocompletion script for the specified shell
Project: kube-vip (Runtime / Cloud Native Network)
File: ROADMAP.md

This document outlines the roadmap for the kube-vip project and only covers the technologies within this particular project, other projects that augment or provide additional functionality (such as cloud-providers) may have their own roadmaps in future. The functionality for kube-vip has grown either been developed organically or through real-world needs, and this is the first attempt to put into words a plan for the future of kube-vip and will additional evolve over time. This means that items listed or detailed here are not necessarily set in stone and the roadmap can grow/shrink as the project matures. We definitely welcome suggestions and ideas from everyone about the roadmap and kube-vip features. Reach us through Issues, Slack or email <catch-all>@kube-vip.io. The kube-vip project attempts to follow a tick-tock release cycle, this typically means that one release will come packed with new features where the following release will come with fixes, code sanitation and performance enhancements. The kube-vip project offers two main areas of functionality: HA Kubernetes clusters through a control-plane VIP Kubernetes `service type:LoadBalancer` Whilst both of these functions share underlying technologies and code they will have slightly differing roadmaps. Re-implement LoadBalancing - due to a previous request the HTTP loadbalancing was removed leaving just HA for the control plane. This functionality will be re-implemented either through the original round-robin HTTP requests or utilising IPVS. Utilise the Kubernetes API to determine additional Control Plane members - Once a single node cluster is running kube-vip could use the API to determine the additional members, at this time a Cluster-API provider needs to drop a static manifest per CP node. Re-evaluate raft - kube-vip is mainly designed to run within a Kubernetes cluster, however it's original design was a raft cluster external to Kubernetes. Unfortunately given some of the upgrade paths identified in things like CAPV moving to leaderElection within Kubernetes became a better idea. `ARP` LeaderElection per loadBalancer - Currently only one pod that is elected leader will field all traffic for a VIP.. extending this to generate a leaderElection token per service would allow services to proliferate across all pods across the cluster Aligning of `service` and `manager` - The move to allow hybrid (be both HA control plane and offer load-balancer services at the same time) introduced a duplicate code path.. these need to converge as it's currently confusing for contributors. Improved metrics - At this time the scaffolding for monitoring exists, however this needs drastically extending to provide greater observability to what is happening within kube-vip Windows support - The Go SDK didn't support the capability for low-levels sockets for ARP originally, this should be revisited. Additional BGP features : Communities BFD
Project: Velero (Runtime / Cloud Native Storage)
File: ark.md

title: "ark" layout: docs Back up and restore Kubernetes cluster resources. Heptio Ark is a tool for managing disaster recovery, specifically for Kubernetes cluster resources. It provides a simple, configurable, and operationally robust way to back up your application state and associated data. If you're familiar with kubectl, Ark supports a similar model, allowing you to execute commands such as 'ark get backup' and 'ark create schedule'. The same operations can also be performed as 'ark backup get' and 'ark schedule create'. ``` --alsologtostderr log to standard error as well as files -h, --help help for ark --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 ``` - Work with backups - Ark client related commands - Output shell completion code for the specified shell (bash or zsh) - Create ark resources - Delete ark resources - Describe ark resources - Get ark resources - Work with plugins - Work with restic - Work with restores - Work with schedules - Run the ark server - Print the ark version and associated image
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_lb_maglev_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List Maglev lookup tables ``` cilium-dbg bpf lb maglev 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 ``` - Maglev lookup table
Project: Singularity (Runtime / Container Runtime)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project leader (gmkurtzer@gmail.com). All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers, contributors and users who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions with their involvement in the project as determined by the project's leader(s). This Code of Conduct is adapted from the , version 1.4, available at
Project: Spiderpool (Runtime / Cloud Native Network)
File: SECURITY.md

Join the [kubernetes-security-announce] group for security and vulnerability announcements. You can also subscribe to an RSS feed of the above using . Instructions for reporting a vulnerability can be found on the [Kubernetes Security and Disclosure Information] page. Information about supported Kubernetes versions can be found on the [Kubernetes version and version skew support policy] page on the Kubernetes website.
Project: Stash by AppsCode (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: Spiderpool (Runtime / Cloud Native Network)
File: VERSIONING.md

We follow the , and use the corresponding tooling. For the purposes of the aforementioned guidelines, controller-runtime counts as a "library project", but otherwise follows the guidelines exactly. For release branches, we generally tend to support backporting one (1) major release (`release-{X-1}` or `release-0.{Y-1}`), but may go back further if the need arises and is very pressing (e.g. security updates). Note the . Particularly: We DO guarantee Kubernetes REST API compatibility -- if a given version of controller-runtime stops working with what should be a supported version of Kubernetes, this is almost certainly a bug. We DO NOT guarantee any particular compatibility matrix between kubernetes library dependencies (client-go, apimachinery, etc); Such compatibility is infeasible due to the way those libraries are versioned.
Project: lxd (Runtime / Container Runtime)
File: devices_usb.md

(devices-usb)= ```{note} The `usb` device type is supported for both containers and VMs. It supports hotplugging for both containers and VMs. ``` USB devices make the specified USB device appear in the instance. For performance issues, avoid using devices that require high throughput or low latency. For containers, only `libusb` devices (at `/dev/bus/usb`) are passed to the instance. This method works for devices that have user-space drivers. For devices that require dedicated kernel drivers, use a or a instead. For virtual machines, the entire USB device is passed through, so any USB device is supported. When a device is passed to the instance, it vanishes from the host. `usb` devices have the following device options: % Include content from ```{include} ../config_options.txt :start-after: <!-- config group devices-usb start --> :end-before: <!-- config group devices-usb end --> ```
Project: Longhorn (Runtime / Cloud Native Storage)
File: task.md

name: Task about: Create a general task title: "[TASK] " labels: kind/task assignees: '' <!--A clear and concise description of what the task is.--> <!-- Please use a task list for items on a separate line with a clickable checkbox https://docs.github.com/en/issues/tracking-your-work-with-issues/about-task-lists [ ] `item 1` --> <!--Add any other context or screenshots about the task request here.-->
Project: CRI-O (Runtime / Container Runtime)
File: tutorial.md

To install CRI-O, check out our . Our is a good way to quickly get started running simple pods and containers. If you're more comfortable with kubeadm, use our . To transfer a cluster from old tools, see our . To enable support for image decryption, see our . For instructions on how to use CRI-O's experimental userns annotation, see the .
Project: Spiderpool (Runtime / Cloud Native Network)
File: uninstall.md

English | This uninstall guide is intended for Spiderpool running on Kubernetes. If you have questions, feel free to ping us on . Read the full uninstall guide to understand all the necessary steps before performing them. Understand the running application and understand the impact that uninstalling Spiderpool may have on other related components (such as middleware). Please make sure you fully understand the risks before starting the uninstallation steps. Query the Spiderpool installed in the cluster through `helm ls` ```bash helm ls -A | grep -i spiderpool ``` Uninstall Spiderpool via `helm uninstall` ```bash helm uninstall <spiderpool-name> --namespace <spiderpool-namespace> ``` Replace `<spiderpool-name>` with the name of the Spiderpool you want to uninstall and `<spiderpool-namespace>` with the namespace of the Spiderpool. The function of automatically cleaning Spiderpool resources was introduced after v0.10.0. It is enabled through the `spiderpoolController.cleanup.enabled` configuration item. The value defaults to `true`. You can verify whether the number of resources related to Spiderpool is automatically cleared as follows. ```bash kubectl get spidersubnets.spiderpool.spidernet.io -o name | wc -l kubectl get spiderips.spiderpool.spidernet.io -o name | wc -l kubectl get spiderippools.spiderpool.spidernet.io -o name | wc -l kubectl get spiderreservedips.spiderpool.spidernet.io -o name | wc -l kubectl get spiderendpoints.spiderpool.spidernet.io -o name | wc -l kubectl get spidercoordinators.spiderpool.spidernet.io -o name | wc -l ``` In versions lower than v0.10.0, Some CR resources having prevents complete cleanup via `helm uninstall`. You can download the cleaning script below to perform the necessary cleanup and avoid any unexpected errors during future deployments of Spiderpool. ```bash wget https://raw.githubusercontent.com/spidernet-io/spiderpool/main/tools/scripts/cleanCRD.sh chmod +x cleanCRD.sh && ./cleanCRD.sh ```
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-alibabacloud_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-alibabacloud 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-alibabacloud - 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: HwameiStor (Runtime / Cloud Native Storage)
File: scheduler.md

sidebar_position: 4 sidebar_label: "Scheduler" The Scheduler is used to automatically schedule the Pod to the correct node which is associated with the HwameiStor volume. With the scheduler, the Pod does not need the NodeAffinity or NodeSelector field to select the node. A scheduler will work for both LVM and Disk volumes. The Scheduler should be deployed with the HA mode in the cluster, which is a best practice for production.
Project: containerd (Runtime / Container Runtime)
File: ROADMAP.md

containerd uses the issues and milestones to define its roadmap. `ROADMAP.md` files are common in open source projects, but we find they quickly become out of date. We opt for an issues and milestone approach that our maintainers and community can keep up-to-date as work is added and completed. Issues tagged with the `roadmap` label are high level roadmap items. They are tasks and/or features that the containerd community wants completed. Smaller issues and pull requests can reference back to the main roadmap issue that is tagged to help detail progress towards the overall goal. Milestones define when an issue, pull request, and/or roadmap item is to be completed. Issues are the what, milestones are the when. Development is complex therefore roadmap items can move between milestones depending on the remaining development and testing required to release a change. To find the roadmap items currently planned for containerd you can filter on the `roadmap` label. After searching for roadmap items you can view what milestone they are scheduled to be completed in along with the progress.
Project: Velero (Runtime / Cloud Native Storage)
File: debugging-deletes.md

title: "Ark version 0.7.0 and later: issue with deleting namespaces and backups " layout: docs Version 0.7.0 introduced the ability to delete backups. However, you may encounter an issue if you try to delete the `heptio-ark` namespace. The namespace can get stuck in a terminating state, and you cannot delete your backups. To fix: If you don't have it, . Run: ```bash bash <(kubectl -n heptio-ark get backup -o json | jq -c -r $'.items[] | "kubectl -n heptio-ark patch backup/" + .metadata.name + " -p \'" + (({metadata: {finalizers: ( (.metadata.finalizers // []) - ["gc.ark.heptio.com"]), resourceVersion: .metadata.resourceVersion}}) | tostring) + "\' --type=merge"') ``` This command retrieves a list of backups, then generates and runs another list of commands that look like: ``` kubectl -n heptio-ark patch backup/my-backup -p '{"metadata":{"finalizers":[],"resourceVersion":"461343"}}' --type=merge kubectl -n heptio-ark patch backup/some-other-backup -p '{"metadata":{"finalizers":[],"resourceVersion":"461718"}}' --type=merge ``` If you encounter errors that tell you patching backups is not allowed, the Ark CustomResourceDefinitions (CRDs) might have been deleted. To fix, recreate the CRDs using `examples/common/00-prereqs.yaml`, then follow the steps above. In Ark version 0.7.1, the default configuration runs the Ark server in a different namespace from the namespace for backups, schedules, restores, and the Ark config. We strongly recommend that you keep this configuration. This approach can help prevent issues with deletes. The Ark team added the ability to delete backups by adding a finalizer to each backup. When you request the deletion of an object that has at least one finalizer, Kubernetes sets the object's deletion timestamp, which indicates that the object is marked for deletion. However, it does not immediately delete the object. Instead, the object is deleted only when it no longer has any finalizers. This means that something -- in this case, Ark -- must process the backup and then remove the Ark finalizer from it. Ark versions earlier than v0.7.1 place the Ark server pod in the same namespace as backups, restores, schedules, and the Ark config. If you try to delete the namespace, with `kubectl delete namespace/heptio-ark`, the Ark server pod might be deleted before the backups, because the order of deletions is arbitrary. If this happens, the remaining bacukps are stuck in a deleting state, because the Ark server pod no longer exists to remove their finalizers.
Project: Cilium (Runtime / Cloud Native Network)
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: Piraeus Datastore (Runtime / Cloud Native Storage)
File: 3-remove-operator-v1.md

Migrating to the new Piraeus Operator deployment requires temporarily removing the existing deployment. After this step no new volumes can be created and no existing volume can be attached or detached, until the new deployment is rolled out. This is the third step when migrating Piraeus Operator from version 1 (v1) to version 2 (v2). . To prevent modification of the existing cluster, scale down the existing Piraeus Operator deployment. ``` $ helm upgrade piraeus-op ./charts/piraeus --set operator.replicas=0 $ kubectl rollout status -w deploy/piraeus-op-operator deployment "piraeus-op-operator" successfully rolled out ``` The Operator sets Finalizers on the resource it controls. This prevents the deletion of these resources when the Operator is not running. Remove the Finalizers by applying a patch: ``` $ kubectl patch linstorsatellitesets piraeus-op-ns --type merge --patch '{"metadata": {"finalizers": []}}' linstorsatelliteset.piraeus.linbit.com/piraeus-op-ns patched $ kubectl patch linstorcontrollers piraeus-op-cs --type merge --patch '{"metadata": {"finalizers": []}}' linstorcontroller.piraeus.linbit.com/piraeus-op-cs patched ``` Having removed the Finalizers, you can delete the Piraeus Resources. This will stop the LINSTOR Cluster, and no new volumes can be created, and existing volumes will not attach or detach. Volumes already attached to a Pod will continue to replicate. ``` $ kubectl delete linstorcsidrivers/piraeus-op $ kubectl delete linstorsatellitesets/piraeus-op-ns $ kubectl delete linstorcontrollers/piraeus-op-cs ``` As a last step, you can completely remove the helm deployment, deleting additional resources such as service accounts and RBAC resources. In addition, also clean up the Custom Resource Definitions: ``` $ helm uninstall piraeus-op $ kubectl delete crds linstorcsidrivers.piraeus.linbit.com linstorsatellitesets.piraeus.linbit.com linstorcontrollers.piraeus.linbit.com ``` If you have deployed additional components from Piraeus, such as the HA Controller or LINSTOR Affinity Controller, you will need to remove them, too. After completing the migration, you can install them again, if needed. ``` $ helm uninstall piraeus-ha-controller $ helm uninstall linstor-affinity-controller ```