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

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List local redirect policies ``` cilium-dbg lrp 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 ``` - Manage local redirect policies
Project: Longhorn (Runtime / Cloud Native Storage)
File: 20230821-customize-maximum-recurring-job-retain-number.md

Hardcoding the `MaxRecurringJobRetain` to be 100 may be inadequate in some cases such as that users try to keep 125 backups onn the remote backup target. This feature will make the `MaxRecurringJobRetain` to be customizable by users. NOTE: Having more snapshots will consume disk storage capacity. The maximum number of snapshots is 250. It will be failed if recurring job start to create a new snapshot after the number of snapshots is up to 250. 1 and 2 might cause volume rebuilding/taking a snapshot/taking a backup unstable. Add a global setting and users will be able to customize the retain number of a recurring job. Retain number can exceed 250. Users can customize the maximum retain number when creating a recurring job to keep more snapshots or backups or restrict resources consumption especially disk storage capacity. Users can customize maximum retain number of the recurring job and maximum retain number cannot be exceeded when creating a recurring job. In will help users handle the snapshot space management but user sill need to consider the total disk storage capacity as well as the size and number of volumes to determine the retain number. User can set the global setting `recurring-job-max-retention` value to be a customized number under 250. ```txt kubectl -n longhorn-system edit setting recurring-job-max-retention -- apiVersion: longhorn.io/v1beta2 kind: Setting metadata: annotations: longhorn.io/configmap-resource-version: "6789" creationTimestamp: "2023-08-21T00:00:00Z" generation: 1 name: recurring-job-max-retention namespace: longhorn-system resourceVersion: "87651" uid: ab1f01cf-xxxx-45ab-9999-8ca1ebf61xxx value: "200" ``` User can set `recurringJobMaxRetain` value to be a customized number under 250 such as: ```bash helm upgrade longhorn longhorn/longhorn --set defaultSettings.recurringJobMaxRetain=200 ``` There is a global setting named `Recurring Job Maximum Retain Number` on the `Setting`/`General` page of UI. Users can fill out the retain number under 250 and save the setting. `None` Add the global setting `recurring-job-max-retention` and default value is `100`. The number of global setting `recurring-job-max-retention` cannot be exceeded `250` because of the maximum number of snapshots for a volume. Set the global setting `recurring-job-max-retention` to be 251 and it will fail. Set the global setting `recurring-job-max-retention` to be 50 and it will success. Create a recurring job with retain number 50 and it will success. Create a recurring job with retain number 51 and it will fail. `None`
Project: Longhorn (Runtime / Cloud Native Storage)
File: CHANGELOG-1.5.3.md

This release focuses on resolving a regression issue from v1.5.2 related to volume encryption, along with a few other fixes and improvements. Please try it and provide feedback. Thanks for all the contributions! For the definition of stable or latest release, please check . Please ensure your Kubernetes cluster is at least v1.21 before installing v1.5.3. Longhorn supports three installation ways including Rancher App Marketplace, Kubectl, and Helm. Follow the installation instructions . Please read the first and ensure your Kubernetes cluster is at least v1.21 before upgrading to Longhorn v1.5.3 from v1.4.x/v1.5.x, which are only supported source versions. Follow the upgrade instructions . N/A Please follow up on about any outstanding issues found after this release. - @mantissahz @roger-ryao @antoninferrand - @yangchiu @ejweber - @yangchiu @derekbit - @ChanYiLin @nitendra-suse - @derekbit @nitendra-suse - @yangchiu @derekbit - @derekbit @ChanYiLin @antoninferrand @derekbit @ejweber @innobead @mantissahz @nitendra-suse @roger-ryao @yangchiu
Project: Spiderpool (Runtime / Cloud Native Network)
File: performance.md

Continuous CI performance testing in e2e. In the CI performance report, data is split into two groups with `|`. The former represents the performance data of SpiderIPPool. The latter represents IPAM performance data for SpiderSubnet. The first data represents the time it takes for an application with 40 replicas to run from creation to run. The second data represents the time it takes for an application with 40 replicas to recover from rebuild to run. The third data represents the time it took for an application with 40 replicas to be completely deleted. The second group separated by "|" is performance data based on SpiderSubnet assigning IP addresses to applications. The numbers correspond to creation, reconstruction, and deletion respectively. Its specifications and configuration are the same as SpiderIPPool mentioned above.
Project: Triton Object Storage (Runtime / Cloud Native Storage)
File: commands-reference.md

This document lists the command-line interface (CLI) tools available from the Manta . See the [Getting Started](./#getting-started) notes for installing. - Lists directory contents - Uploads data to an object - Downloads an object from the service - show HTTP headers for a Manta object - Walks a hierarchy to find names of objects by name, size, or type - Make directories - Remove objects or directories - Remove empty directories - Create a signed URL to a object stored in the service - Create a directory hierarchy from a tar file - Change object role tags - Change object attributes
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_debuginfo.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Request available debugging information from agent ``` cilium-dbg debuginfo [flags] ``` ``` -f, --file Redirect output to file(s) --file-per-command Generate a single file per command -h, --help help for debuginfo --output strings markdown| html| json| jsonpath='{}' --output-directory string directory for files (if specified will use directory in which this command was ran) ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI
Project: Velero (Runtime / Cloud Native Storage)
File: proxy.md

title: "Behind Proxy" layout: docs toc: "true" This document explains how to make Velero work behind proxy. The procedures described in this document are concluded from the scenario that Velero is deployed behind proxy, and Velero needs to connect to a public MinIO server as storage location. Maybe other scenarios' configurations are not exactly the same, but basically they should share most parts. Specify the proxy server address by environment variables in Velero deployment and node-agent DaemonSet. Take the following as an example: ``` yaml ... spec: containers: args: server --features=EnableCSI command: /velero env: ... name: HTTP_PROXY value: <proxy_address> name: HTTPS_PROXY value: <proxy_address> name: NO_PROXY value: <addresslistnotuseproxy> ``` In some cases, the proxy requires certificate to connect. Set the certificate in the BSL's `Spec.ObjectStorage.CACert`. It's possible that the object storage also requires certificate, and it's also set in `Spec.ObjectStorage.CACert`, then set both certificates in `Spec.ObjectStorage.CACert` field. The following is an example file contains two certificates, then encode its content with base64, and set the encode result in the BSL. ``` bash cat certs --BEGIN CERTIFICATE-- certificates first content --END CERTIFICATE-- --BEGIN CERTIFICATE-- certificates second content --END CERTIFICATE-- cat certs | base64 LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCmNlcnRpZmljYXRlcyBmaXJzdCBjb250ZW50Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0KCi0tLS0tQkVHSU4gQ0VSVElGSUNBVEUtLS0tLQpjZXJ0aWZpY2F0ZXMgc2Vjb25kIGNvbnRlbnQKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo= ``` ``` yaml apiVersion: velero.io/v1 kind: BackupStorageLocation ... spec: ... default: true objectStorage: bucket: velero caCert: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCmNlcnRpZmljYXRlcyBmaXJzdCBjb250ZW50Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0KCi0tLS0tQkVHSU4gQ0VSVElGSUNBVEUtLS0tLQpjZXJ0aWZpY2F0ZXMgc2Vjb25kIGNvbnRlbnQKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo= ... ```
Project: Lima (Runtime / Container Runtime)
File: ROADMAP.md

Instead of using a static text file, Lima uses the `roadmap` label on GitHub issues to designate features or bug fixes that we plan to implement. Issues are tagged with the `roadmap` label when at least one maintainer or contributor has declared intent to work on or help with the implementation. There are no commitments or timelines attached to the label, and the label may be removed again from an abandoned issue at any time. Non-roadmap issues are kept open (as long as they fit the scope of the project) in case a volunteer one day appears and offers to work on them. To find the items currently planned for Lima you can filter on .
Project: OpenEBS (Runtime / Cloud Native Storage)
File: RELEASE.md

OpenEBS follows a quarterly release cadence. The process is as follows: The scope of the release is determined by: contributor availability, pending items listed in the and the . The release scope is published and tracked using . To maintain monthly release cadence, the project tracker is setup with indicative milestones leading up to freezing the feature development in the 3rd week, the remaining days are used to run e2e and fix any issues found by e2e or community. At the start of the release cycle, one of the contributors takes on the role of release manager and works with the OpenEBS Maintainers to co-ordinate the release activities. Contributors sync-up over to close on the release tasks. Release manager runs the community calls for a given release. In the community call, the risks are identified and mitigated by seeking additional help or by pushing the task to next release. The various release management tasks are explained in the . OpenEBS release is made via GitHub. Once all the components are released, Change Summary is published along with release tag. OpenEBS release is announced on . The release tracker GitHub project is closed.
Project: gVisor (Runtime / Container Runtime)
File: containerd_11.md

WARNING: containerd 1.1 and shim v1 is no longer supported. The instructions below is kept just for reference in case you're dealing with an old version. It's highly recommended upgrading to the latest version. This document describes how to install and run the `gvisor-containerd-shim` using the untrusted workload CRI extension. This requires `containerd` 1.1 or later. *Note: The untrusted workload CRI extension is deprecated by containerd and `gvisor-containerd-shim` is maintained on a best-effort basis. If you are using containerd 1.2+, please see the and use `containerd-shim-runsc-v1`.* runsc and gvisor-containerd-shim: See the . containerd: See the for information on how to install containerd. Create the configuration for the gvisor shim in `/etc/containerd/gvisor-containerd-shim.toml`: ```shell cat <<EOF | sudo tee /etc/containerd/gvisor-containerd-shim.toml runc_shim = "/usr/local/bin/containerd-shim" EOF ``` Update `/etc/containerd/config.toml`. Be sure to update the path to `gvisor-containerd-shim` and `runsc` if necessary: ```shell cat <<EOF | sudo tee /etc/containerd/config.toml disabled_plugins = ["restart"] [plugins.linux] shim = "/usr/local/bin/gvisor-containerd-shim" shim_debug = true [plugins.cri.containerd.untrustedworkloadruntime] runtime_type = "io.containerd.runtime.v1.linux" runtime_engine = "/usr/local/bin/runsc" runtime_root = "/run/containerd/runsc" EOF ``` Restart `containerd`: ```shell sudo systemctl restart containerd ``` You can run containers in gVisor via containerd's CRI. Download and install the `crictl` binary: ```shell { wget https://github.com/kubernetes-sigs/cri-tools/releases/download/v1.13.0/crictl-v1.13.0-linux-amd64.tar.gz tar xf crictl-v1.13.0-linux-amd64.tar.gz sudo mv crictl /usr/local/bin } ``` Write the `crictl` configuration file: ```shell cat <<EOF | sudo tee /etc/crictl.yaml runtime-endpoint: unix:///run/containerd/containerd.sock EOF ``` Pull the nginx image: ```shell sudo crictl pull nginx ``` Create the sandbox creation request: ```shell cat <<EOF | tee sandbox.json { "metadata": { "name": "nginx-sandbox", "namespace": "default", "attempt": 1, "uid": "hdishd83djaidwnduwk28bcsb" }, "annotations": { "io.kubernetes.cri.untrusted-workload": "true" }, "linux": { }, "log_directory": "/tmp" } EOF ``` Create the pod in gVisor: ```shell SANDBOX_ID=$(sudo crictl runp sandbox.json) ``` Create the nginx container creation request: ```shell cat <<EOF | tee container.json { "metadata": { "name": "nginx" }, "image":{ "image": "nginx" }, "log_path":"nginx.0.log", "linux": { } } EOF ``` Create the nginx container: ```shell CONTAINERID=$(sudo crictl create ${SANDBOXID} container.json sandbox.json) ``` Start the nginx container: ```shell sudo crictl start ${CONTAINER_ID} ``` Inspect the created pod: ```shell sudo crictl inspectp ${SANDBOX_ID} ``` Inspect the nginx container: ```shell sudo crictl inspect ${CONTAINER_ID} ``` Verify that nginx is running in gVisor: ```shell sudo crictl exec ${CONTAINER_ID} dmesg | grep -i gvisor ```
Project: lxd (Runtime / Container Runtime)
File: performance_tuning.md

(performance-tuning)= When you are ready to move your Incus setup to production, you should take some time to optimize the performance of your system. There are different aspects that impact performance. The following steps help you to determine the choices and settings that you should tune to improve your Incus setup. Incus provides a benchmarking tool to evaluate the performance of your system. You can use the tool to initialize or launch a number of containers and measure the time it takes for the system to create the containers. By running the tool repeatedly with different Incus configurations, system settings or even hardware setups, you can compare the performance and evaluate which is the ideal configuration. See {ref}`benchmark-performance` for instructions on running the tool. % Include content from ```{include} ../metrics.md :start-after: <!-- Include start metrics intro --> :end-before: <!-- Include end metrics intro --> ``` You should regularly monitor the metrics to evaluate the resources that your instances use. The numbers help you to determine if there are any spikes or bottlenecks, or if usage patterns change and require updates to your configuration. See {ref}`metrics` for more information about metrics collection. The default kernel settings for most Linux distributions are not optimized for running a large number of containers or virtual machines. Therefore, you should check and modify the relevant server settings to avoid hitting limits caused by the default settings. Typical errors that you might see when you encounter those limits are: `Failed to allocate directory watch: Too many open files` `<Error> <Error>: Too many open files` `failed to open stream: Too many open files in...` `neighbour: ndisc_cache: neighbor table overflow!` See {ref}`server-settings` for a list of relevant server settings and suggested values. If you have a lot of local activity between instances or between the Incus host and the instances, or if you have a fast internet connection, you should consider increasing the network bandwidth of your Incus setup. You can do this by increasing the transmit and receive queue lengths. See {ref}`network-increase-bandwidth` for instructions.
Project: Kube-OVN (Runtime / Cloud Native Network)
File: SECURITY.md

Please use the below process to report a vulnerability to the project: Email: Email the Emails should contain: description of the problem precise and detailed steps (include screenshots) that created the problem the affected version(s) any possible mitigations, if known You will receive a reply from one of the maintainers within 3 days acknowledging receipt of the email. You may be contacted by a maintainer to further discuss the reported item. Please bear with us as we seek to understand the breadth and scope of the reported problem, recreate it, and confirm if there is a vulnerability present.
Project: SmartOS (Runtime / Container Runtime)
File: pkgsrc-setup.1.md

`pkgsrc-setup [--clean]` This command installs pkgsrc-tools for the global zone to /opt/tools. `--clean` This option will re-bootstrap the pkgsrc-tools installation by removing /opt/tools and reinstalling all currently installed packages. Re-bootstrapping is generally not necessary, but can be used to "reset" the installation without having to manually reinstall all packages. pkgsrc-setup Copyright 2022 MNX Cloud, Inc.
Project: CubeFS (Runtime / Cloud Native Storage)
File: ADOPTERS.md

This page contains a list of organizations who are using CubeFS in production or at stages of testing. If you'd like to be included here, please send a pull request which modifies this file. : after serving in the production environment in 2018, CubeFS is supporting more than 3,000 businesses and manages more than 50 petabytes of data. The production environment cluster scale exceeds 5000 servers. Service scenarios of online business data includes advertising, clickstreams, search, AI training platform. It also served as the default storage for applications deployed in the large scale internal container platform. : OPPO uses CubeFS as the backend storage for its AI platform which provides model training services for diverse and innovative algorithms. The AI platform is built based on Kubernetes, and CubeFS is a great choice to decouple computing and storage resources and is a reliable shared storage solution providing high availability, scalability and high performance. : CubeFS is mainly used as the backend storage for its Elasticsearch service in production environment. At present, the total data of its CubeFS cluster is more than 2 petabytes. : Meizu uses CubeFS as its basic storage solution to manage business production data. At present, the data scale managed by its CubeFS cluster is hundreds of terabytes. : BEIKE uses CubeFS to support its AI platform storing tons of model and material files. And more and more internal customers are migrating their data to CubeFS clusters. : LinkSure uses CubeFS to store application logs running inside container environments as well as nginx logs. Also, they use CubeFS as the backend storage for Elasticsearch. : Reconova uses CubeFS to store massive small files in the production environment. It currently uses one CubeFS volume to store more than 80 million small files and each file around 40 kilobytes in size. : BIGO uses CubeFS to store logs for AI platform applications that running in the container environment, because CubeFS have excellent concurrent processing capability. : Cubefs is used in the offline hybrid deployment scenario of YARN on Kubernetes.After some adjustments, it has become quite stable. | Organization | Status | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Project: Velero (Runtime / Cloud Native Storage)
File: upgrade-to-1.7.md

title: "Upgrading to Velero 1.7" layout: docs Velero installed. If you're not yet running at least Velero v1.6, see the following: Before upgrading, check the to make sure your version of Kubernetes is supported by the new version of Velero. Install the Velero v1.7 command-line interface (CLI) by following the . Verify that you've properly installed it by running: ```bash velero version --client-only ``` You should see the following output: ```bash Client: Version: v1.7.0 Git commit: <git SHA> ``` Update the Velero custom resource definitions (CRDs) to include schema changes across all CRDs that are at the core of the new features in this release: ```bash velero install --crds-only --dry-run -o yaml | kubectl apply -f - ``` NOTE: You could change the default CRD API version (v1beta1 or v1) if Velero CLI can't discover the Kubernetes preferred CRD API version. The Kubernetes version < 1.16 preferred CRD API version is v1beta1; the Kubernetes version >= 1.16 preferred CRD API version is v1. NOTE: If you are upgrading Velero in Kubernetes 1.14.x or earlier, you will need to use `kubectl apply`'s `--validate=false` option when applying the CRD configuration above. See and for more context. Update the container image used by the Velero deployment, plugin and, optionally, the restic daemon set: ```bash kubectl set image deployment/velero \ velero=velero/velero:v1.7.0 \ velero-plugin-for-aws=velero/velero-plugin-for-aws:v1.3.0 \ --namespace velero kubectl set image daemonset/restic \ restic=velero/velero:v1.7.0 \ --namespace velero ``` Confirm that the deployment is up and running with the correct version by running: ```bash velero version ``` You should see the following output: ```bash Client: Version: v1.7.0 Git commit: <git SHA> Server: Version: v1.7.0 ``` We have deprecated the way to indicate the default backup storage location. Previously, that was indicated according to the backup storage location name set on the velero server-side via the flag `velero server --default-backup-storage-location`. Now we configure the default backup storage location on the velero client-side. Please refer to the on how to indicate which backup storage location is the default one. After upgrading, if there is a previously created backup storage location with the name that matches what was defined on the server side as the default, it will be automatically set as the `default`.
Project: Weave Net (Runtime / Cloud Native Network)
File: launching-without-proxy.md

title: Launching Containers With Weave Run (without the Proxy) menu_order: 60 search_type: Documentation In prior versions of Weave Net, we supported a command `weave run` which would run a container and attach it to the Weave Network. This command always had limitations, and now we have Docker plugins and the Weave Net Docker API Proxy which do not have those limitations, we have removed `weave run`. If you have scripts using `weave run`, you can achieve exactly the same effect by combining `docker run` and `weave attach`; see [Dynamically Attaching and Detaching Containers](/site/tasks/manage/dynamically-attach-containers.md) for details. The `weave start` and `weave restart` commands have also been removed, for the same reasons.