cwielenb/CNCF-Dataset huggingface dataset:
Project: CubeFS (Runtime / Cloud Native Storage)
File: overview.md

Using the command-line interface tool (CLI) can achieve convenient and fast cluster management. With this tool, you can view the status of the cluster and each node, and manage each node, volume, and user. ::: tip Note With the continuous improvement of the CLI, 100% coverage of the interface functions of each node in the cluster will eventually be achieved. ::: After downloading the CubeFS source code, run the `build.sh` file in the `cubefs/cli` directory to generate the `cfs-cli` executable. At the same time, a configuration file named `.cfs-cli.json` will be generated in the `root` directory. Modify the master address to the master address of the current cluster. You can also use the `./cfs-cli config info` and `./cfs-cli config set` commands to view and set the configuration file. In the `cubefs/cli` directory, run the command `./cfs-cli --help` or `./cfs-cli -h` to get the CLI help document. The CLI is mainly divided into some types of management commands: | Command | Description | |--|| | cfs-cli cluster | Cluster management | | cfs-cli metanode | MetaNode management | | cfs-cli datanode | DataNode management | | cfs-cli datapartition | Data Partition management | | cfs-cli metapartition | Meta Partition management | | cfs-cli config | Configuration management | | cfs-cli volume, vol | Volume management | | cfs-cli user | User management | | cfs-cli nodeset | Nodeset management | | cfs-cli quota | Quota management |
Project: Spiderpool (Runtime / Cloud Native Network)
File: reliability.md

| Case ID | Title | Priority | Smoke | Status | Other | |||-|-|--|-| | R00001 | Successfully run a pod when the Spiderpool controller is restarting | p2 | | done | | | R00002 | Successfully run a pod when the ETCD is restarting | p3 | | done | | | R00003 | Successfully run a pod when the API-server is restarting | p2 | | done | | | R00004 | Successfully run a pod when the Spiderpool agent is restarting | p2 | | done | | | R00005 | Successfully run a pod when the coreDns is restarting | p3 | | done | | | R00006 | Successfully recover a pod whose original node is power-off | p2 | | done | | | R00007 | Spiderpool Controller active/standby switching is normal | p2 | | done | |
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_srv6_vrf.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List SRv6 VRF mappings List SRv6 VRF mappings. ``` cilium-dbg bpf srv6 vrf [flags] ``` ``` -h, --help help for vrf -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 the SRv6 routing rules
Project: Spiderpool (Runtime / Cloud Native Network)
File: USERS.md

Sharing experiences and learning from other users is essential. If you are using Spiderpool or it is integrated into your product, service, or platform, please consider adding yourself as a user with a quick description of your use case by opening a pull request to this file and adding a section describing your usage of Spiderpool. | orgnization | description | ||| | a bank in ShangHai, China | a cluster with a size of 2000+ pods, production environment | | a bank in SiChuan, China | about 80 clusters , not more thant 100 nodes for each cluster | | a broker in ShangHai, China | a cluster with a size of about 50 nodes | | a broker in ShangHai, China | a cluster with a size of about 50 nodes | | VIVO, a smart phone vendor in China | leverage Spiderpool in AI clusters for LLM | | a telcom company of Beijing branch, China | leverage Spiderpool in development environment | | a telcom company of Suzhou branch, China | leverage Spiderpool in development environment |
Project: rkt (Runtime / Container Runtime)
File: list.md

You can list all rkt pods. ``` $ rkt list UUID APP IMAGE NAME STATE CREATED STARTED NETWORKS 5bc080ca redis redis running 2 minutes ago 41 seconds ago default:ip4=172.16.28.7 etcd coreos.com/etcd:v2.0.9 3089337c nginx nginx exited 9 minutes ago 2 minutes ago ``` You can view the full UUID as well as the image's ID by using the `--full` flag. ``` $ rkt list --full UUID APP IMAGE NAME IMAGE ID STATE CREATED STARTED NETWORKS 5bc080cav-9e03-480d-b705-5928af396cc5 redis redis sha512-91e98d7f1679 running 2016-01-25 17:42:32.563 +0100 CET 2016-01-25 17:44:05.294 +0100 CET default:ip4=172.16.28.7 etcd coreos.com/etcd:v2.0.9 sha512-a03f6bad952b 3089337c4-8021-119b-5ea0-879a7c694de4 nginx nginx sha512-32ad6892f21a exited 2016-01-25 17:36:40.203 +0100 CET 2016-01-25 17:42:15.1 +0100 CET ``` | Flag | Default | Options | Description | | | | | | | `--full` | `false` | `true` or `false` | Use long output format | | `--no-legend` | `false` | `true` or `false` | Suppress a legend with the list | See the table with .
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_status.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Display status of daemon ``` cilium-dbg status [flags] ``` ``` --all-addresses Show all allocated addresses, not just count --all-clusters Show all clusters --all-controllers Show all controllers, not just failing --all-health Show all health status, not just failing --all-nodes Show all nodes, not just localhost --all-redirects Show all redirects --brief Only print a one-line status message -h, --help help for status -o, --output string json| yaml| jsonpath='{}' --timeout duration Sets the timeout to use when querying for health (default 30s) --verbose Equivalent to --all-addresses --all-controllers --all-nodes --all-redirects --all-clusters --all-health ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI
Project: FabEdge (Runtime / Cloud Native Network)
File: uninstall.md

English | Delete helm release ``` $ helm uninstall fabedge -n fabedge ``` Delete other resources ``` $ kubectl -n fabedge delete cm --all $ kubectl -n fabedge delete pods --all $ kubectl -n fabedge delete secret --all $ kubectl -n fabedge delete job.batch --all ``` Delete namespace ``` $ kubectl delete namespace fabedge ``` Delete all FabeEdge configuration file from all edge nodes ``` $ rm -f /etc/cni/net.d/fabedge.* ``` Delete all fabedge images on all nodes ``` $ docker images | grep fabedge | awk '{print $3}' | xargs -I{} docker rmi {} ``` Delete CustomResourceDefinition ``` $ kubectl delete CustomResourceDefinition "clusters.fabedge.io" $ kubectl delete CustomResourceDefinition "communities.fabedge.io" $ kubectl delete ClusterRole "fabedge-operator" $ kubectl delete ClusterRoleBinding "fabedge-operator" ```
Project: Longhorn (Runtime / Cloud Native Storage)
File: CHANGELOG-1.5.5.md

This latest stable version of Longhorn 1.5 introduces several improvements and bug fixes that are intended to improve system quality, resilience, and stability. The Longhorn team appreciates your contributions and anticipates receiving feedback regarding this release. [!NOTE] For more information about release-related terminology, see . [!IMPORTANT] Ensure that your cluster is running Kubernetes v1.21 or later before installing Longhorn v1.5.5. You can install Longhorn using a variety of tools, including Rancher, Kubectl, and Helm. For more information about installation methods and requirements, see in the Longhorn documentation. [!IMPORTANT] Ensure that your cluster is running Kubernetes v1.21 or later before upgrading from Longhorn v1.4.x or v1.5.x (< v1.5.5) to v1.5.5. Longhorn only allows upgrades from supported versions. For more information about upgrade paths and procedures, see in the Longhorn documentation. For information about important changes, including feature incompatibility, deprecation, and removal, see in the Longhorn documentation. For information about issues identified after this release, see . - @PhanLe1010 @chriscchien - @derekbit @chriscchien - @shuo-wu @chriscchien - @james-munson @chriscchien - @c3y1huang @roger-ryao - @james-munson @roger-ryao Security issues in latest longhorn docker images - @c3y1huang @chriscchien - @derekbit @chriscchien - @yangchiu @ejweber - @shuo-wu @chriscchien - @ChanYiLin @chriscchien - @ejweber @roger-ryao - @mantissahz @roger-ryao - @ejweber @roger-ryao - @ejweber @chriscchien - @Vicente-Cheng @roger-ryao - @james-munson @chriscchien - @ChanYiLin @chriscchien - @ejweber @roger-ryao - @james-munson @roger-ryao - @c3y1huang @roger-ryao - @ChanYiLin - @ChanYiLin @roger-ryao @ChanYiLin @PhanLe1010 @Vicente-Cheng @c3y1huang @chriscchien @derekbit @ejweber @innobead @james-munson @mantissahz @roger-ryao @shuo-wu @yangchiu
Project: Firecracker (Runtime / Container Runtime)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '[Feature Request] Title' labels: '' assignees: '' `[Author TODO: Why is this feature request important? What are the use cases? Please describe.]` `[Author TODO: A clear and concise description of how you would like the feature to work.]` `[Author TODO: A clear and concise description of any alternative solutions or features you have considered.]` `[Author TODO: How do you work around not having this feature?]` `[Author TODO: Add additional context about this feature request here.]` [ ] Have you searched the Firecracker Issues database for similar requests? [ ] Have you read all the existing relevant Firecracker documentation? [ ] Have you read and understood Firecracker's core tenets?
Project: Inclavare Containers (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 team at teamgingonic@gmail.com. The project team will review and investigate all complaints, and will respond in a way that it deems 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 who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at
Project: Spiderpool (Runtime / Cloud Native Network)
File: system-requirements.md

English | x86-64, arm64 The system kernel version must be greater than 4.2 when using `ipvlan` as the cluster's CNI We test Spiderpool against the following Kubernetes versions v1.22.7 v1.23.5 v1.24.4 v1.25.3 v1.26.2 v1.27.1 v1.28.0 The feature requires a minimum version of `v1.21`. | ENV Configuration | Port/Protocol | Description | Is Optional | |--||--|| | SPIDERPOOLHEALTHPORT | 5710/tcp | `spiderpool-agent` pod health check port for kubernetes | must | | SPIDERPOOLMETRICHTTP_PORT | 5711/tcp | `spiderpool-agent` metrics port | optional(default disable) | | SPIDERPOOLGOPSLISTEN_PORT | 5712/tcp | `spiderpool-agent` gops port for debug | optional(default enable) | | SPIDERPOOLHEALTHPORT | 5720/tcp | `spiderpool-controller` pod health check port for kubernetes | must | | SPIDERPOOLMETRICHTTP_PORT | 5711/tcp | `spiderpool-controller` metrics port for openTelemetry | optional(default disable) | | SPIDERPOOLWEBHOOKPORT | 5722/tcp | `spiderpool-controller` webhook port for kubernetes | must | | SPIDERPOOLGOPSLISTEN_PORT | 5724/tcp | `spiderpool-controller` gops port for debug | optional(default enable) |
Project: Rook (Runtime / Cloud Native Storage)
File: configuration.md

title: Configuration For most any Ceph cluster, the user will want to--and may need to--change some Ceph configurations. These changes often may be warranted in order to alter performance to meet SLAs or to update default data resiliency settings. !!! warning Modify Ceph settings carefully, and review the before making any changes. Changing the settings could result in unhealthy daemons or even data loss if used incorrectly. Rook and Ceph both strive to make configuration as easy as possible, but there are some configuration options which users are well advised to consider for any production cluster. The number of PGs and PGPs can be configured on a per-pool basis, but it is advised to set default values that are appropriate for your Ceph cluster. Appropriate values depend on the number of OSDs the user expects to have backing each pool. These can be configured by declaring pgnum and pgpnum parameters under CephBlockPool resource. For determining the right value for pg_num please refer [placement group sizing](ceph-configuration.md#placement-group-sizing) In this example configuration, 128 PGs are applied to the pool: ```yaml apiVersion: ceph.rook.io/v1 kind: CephBlockPool metadata: name: ceph-block-pool-test namespace: rook-ceph spec: deviceClass: hdd replicated: size: 3 spec: parameters: pg_num: '128' # create the pool with a pre-configured placement group number pgpnum: '128' # this should at least match `pgnum` so that all PGs are used ``` Ceph provide detailed information about how to tune these parameters. Nautilus capable of automatically managing PG and PGP values for pools. Please see for more information about this module. The `pg_autoscaler` module is enabled by default. To disable this module, in the : ```yaml spec: mgr: modules: name: pg_autoscaler enabled: false ``` With that setting, the autoscaler will be enabled for all new pools. If you do not desire to have the autoscaler enabled for all new pools, you will need to use the Rook toolbox to enable the module and on individual pools. The most recommended way of configuring Ceph is to set Ceph's configuration directly. The first method for doing so is to use Ceph's CLI from the Rook toolbox pod. Using the toolbox pod is detailed . From the toolbox, the user can change Ceph configurations, enable manager modules, create users and pools, and much more. The Ceph Dashboard, examined in more detail , is another way of setting some of Ceph's configuration directly. Configuration by the Ceph dashboard is recommended with the same priority as configuration via the Ceph CLI (above). Setting configs via Ceph's CLI requires that at least one mon be available for the configs to be set, and setting configs via dashboard requires at least one mgr to be available. Ceph may also have a small number of very advanced settings that aren't able to be modified easily via CLI or dashboard. The least recommended method for configuring Ceph is intended as a last-resort fallback in situations like these. This is covered in detail .
Project: Velero (Runtime / Cloud Native Storage)
File: basic-install.md

title: "Basic Install" layout: docs Use this doc to get a basic installation of Velero. Refer to customize your installation. Access to a Kubernetes cluster, v1.16 or later, with DNS and container networking enabled. For more information on supported Kubernetes versions, see the Velero . `kubectl` installed locally Velero uses object storage to store backups and associated artifacts. It also optionally integrates with supported block storage systems to snapshot your persistent volumes. Before beginning the installation process, you should identify the object storage provider and optional block storage provider(s) you'll be using from the list of . Velero supports storage providers for both cloud-provider environments and on-premises environments. For more details on on-premises scenarios, see the . Velero does not officially support Windows. In testing, the Velero team was able to backup stateless Windows applications only. The restic integration and backups of stateful applications or PersistentVolumes were not supported. If you want to perform your own testing of Velero on Windows, you must deploy Velero as a Windows container. Velero does not provide official Windows images, but its possible for you to build your own Velero Windows container image to use. Note that you must build this image on a Windows node. On macOS, you can use to install the `velero` client: ```bash brew install velero ``` Download the 's tarball for your client platform. Extract the tarball: ```bash tar -xvf <RELEASE-TARBALL-NAME>.tar.gz ``` Move the extracted `velero` binary to somewhere in your `$PATH` (`/usr/local/bin` for most users). On Windows, you can use to install the client: ```powershell choco install velero ``` There are two supported methods for installing the Velero server components: the `velero install` CLI command the Velero uses storage provider plugins to integrate with a variety of storage systems to support backup and snapshot operations. The steps to install and configure the Velero server components along with the appropriate plugins are specific to your chosen storage provider. To find installation instructions for your chosen storage provider, follow the documentation link for your provider at our page Note: if your object storage provider is different than your volume snapshot provider, follow the installation instructions for your object storage provider first, then return here and follow the instructions to . Please refer to .
Project: Weave Net (Runtime / Cloud Native Network)
File: ipam-proxy.md

title: Automatic IP Allocation and the Weave Proxy menu_order: 30 search_type: Documentation If is enabled in Weave Net (by default IPAM is enabled), then containers started via the proxy are automatically assigned an IP address, *without having to specify any special environment variables or any other options*. host1$ docker run -ti weaveworks/ubuntu To use a specific subnet, you can pass a `WEAVE_CIDR` to the container, for example: host1$ docker run -ti -e WEAVE_CIDR=net:10.32.2.0/24 weaveworks/ubuntu To start a container without connecting it to the Weave network, pass `WEAVE_CIDR=none`, for example: host1$ docker run -ti -e WEAVE_CIDR=none weaveworks/ubuntu If you do not want an IP to be assigned by default, the proxy needs to be passed the `--no-default-ipalloc` flag, for example: host1$ weave launch --no-default-ipalloc In this configuration, containers using no `WEAVE_CIDR` environment variable are not connected to the Weave network. Containers started with a `WEAVE_CIDR` environment variable are handled as before. To automatically assign an address in this mode, start the container with a blank `WEAVE_CIDR`, for example: host1$ docker run -ti -e WEAVE_CIDR="" weaveworks/ubuntu See Also *
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_nodeid.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage the node IDs ``` -h, --help help for nodeid ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Direct access to local BPF maps - List node IDs and their IP addresses
Project: Velero (Runtime / Cloud Native Storage)
File: feature-enhancement-request.md

name: Feature enhancement request about: Suggest an idea for this project Describe the problem/challenge you have <!--A description of the current limitation/problem/challenge that you are experiencing.--> Describe the solution you'd like <!--A clear and concise description of what you want to happen.--> Anything else you would like to add: <!--Miscellaneous information that will assist in solving the issue.--> Environment: Velero version (use `velero version`): Kubernetes version (use `kubectl version`): Kubernetes installer & version: Cloud provider or hardware configuration: OS (e.g. from `/etc/os-release`): Vote on this issue! This is an invitation to the Velero community to vote on issues, you can see the project's . Use the "reaction smiley face" up to the right of this comment to vote. :+1: for "The project would be better with this feature added" :-1: for "This feature will not enhance the project in a meaningful way"
Project: Velero (Runtime / Cloud Native Storage)
File: ark_create.md

title: "ark create" layout: docs Create ark resources Create ark resources ``` -h, --help help for create ``` ``` --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. - Create a backup - Create a restore - Create a schedule
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_post-uninstall-cleanup.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Remove system state installed by Cilium at runtime Clean up CNI configurations, CNI binaries, attached BPF programs, bpffs, tc filters, routes, links and named network namespaces. Running this command might be necessary to get the worker node back into working condition after uninstalling the Cilium agent. ``` cilium-dbg post-uninstall-cleanup [flags] ``` ``` --all-state Remove all cilium state --bpf-state Remove BPF state -f, --force Skip confirmation -h, --help help for post-uninstall-cleanup ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI