cwielenb/CNCF-Dataset huggingface dataset:
Project: Kanister (Runtime / Cloud Native Storage)
File: api-examples.md

outline: deep This page demonstrates usage of some of the runtime APIs provided by VitePress. The main `useData()` API can be used to access site, theme, and page data for the current page. It works in both `.md` and `.vue` files: ```md <script setup> import { useData } from 'vitepress' const { theme, page, frontmatter } = useData() </script> <pre>{{ theme }}</pre> <pre>{{ page }}</pre> <pre>{{ frontmatter }}</pre> ``` <script setup> import { useData } from 'vitepress' const { site, theme, page, frontmatter } = useData() </script> <pre>{{ theme }}</pre> <pre>{{ page }}</pre> <pre>{{ frontmatter }}</pre> Check out the documentation for the .
Project: Kata Containers (Runtime / Container Runtime)
File: VmCoredumpData.md

Name | Type | Description | Notes | - | - | - DestinationUrl | Pointer to string | | [optional] `func NewVmCoredumpData() *VmCoredumpData` NewVmCoredumpData instantiates a new VmCoredumpData object This constructor will assign default values to properties that have it defined, and makes sure properties required by API are set, but the set of arguments will change when the set of required properties is changed `func NewVmCoredumpDataWithDefaults() *VmCoredumpData` NewVmCoredumpDataWithDefaults instantiates a new VmCoredumpData object This constructor will only assign default values to properties that have it defined, but it doesn't guarantee that properties required by API are set `func (o *VmCoredumpData) GetDestinationUrl() string` GetDestinationUrl returns the DestinationUrl field if non-nil, zero value otherwise. `func (o VmCoredumpData) GetDestinationUrlOk() (string, bool)` GetDestinationUrlOk returns a tuple with the DestinationUrl field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *VmCoredumpData) SetDestinationUrl(v string)` SetDestinationUrl sets DestinationUrl field to given value. `func (o *VmCoredumpData) HasDestinationUrl() bool` HasDestinationUrl returns a boolean if a field has been set.
Project: WasmEdge Runtime (Runtime / Container Runtime)
File: SECURITY.md

For all WasmEdge security-related defects, please send an email to security@secondstate.io. You will receive an acknowledgement mail within 24 hours. After that, we will give a detailed response about the subsequent process within 48 hours. Please do not submit security vulnerabilities directly as Github Issues. For known public security vulnerabilities, we will disclose the disclosure as soon as possible after receiving the report. Vulnerabilities discovered for the first time will be disclosed in accordance with the following process: The received security vulnerability report shall be handed over to the security team for follow-up coordination and repair work. After the vulnerability is confirmed, we will create a draft Security Advisory on Github that lists the details of the vulnerability. Invite related personnel to discuss about the fix. Fork the temporary private repository on Github, and collaborate to fix the vulnerability. After the fix code is merged into all supported versions, the vulnerability will be publicly posted in the GitHub Advisory Database.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_egress.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage the egress routing rules ``` -h, --help help for egress ``` ``` --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 egress policy entries
Project: MinIO (Runtime / Cloud Native Storage)
File: SECURITY.md

We always provide security updates for the . Whenever there is a security update you just need to upgrade to the latest version. All security bugs in (or other minio/* repositories) should be reported by email to security@min.io. Your email will be acknowledged within 48 hours, and you'll receive a more detailed response to your email within 72 hours indicating the next steps in handling your report. Please, provide a detailed explanation of the issue. In particular, outline the type of the security issue (DoS, authentication bypass, information disclose, ...) and the assumptions you're making (e.g. do you need access credentials for a successful exploit). If you have not received a reply to your email within 48 hours or you have not heard from the security team for the past five days please contact the security team directly: Primary security coordinator: aead@min.io Secondary coordinator: harsha@min.io If you receive no response: dev@min.io MinIO uses the following disclosure process: Once the security report is received one member of the security team tries to verify and reproduce the issue and determines the impact it has. A member of the security team will respond and either confirm or reject the security report. If the report is rejected the response explains why. Code is audited to find any potential similar problems. Fixes are prepared for the latest release. On the date that the fixes are applied a security advisory will be published on <https://blog.min.io>. Please inform us in your report email whether MinIO should mention your contribution w.r.t. fixing the security issue. By default MinIO will not publish this information to protect your privacy. This process can take some time, especially when coordination is required with maintainers of other projects. Every effort will be made to handle the bug in as timely a manner as possible, however it's important that we follow the process described above to ensure that disclosures are handled consistently.
Project: WasmEdge Runtime (Runtime / Container Runtime)
File: serverless_saas.md

WasmEdge can support customized SaaS extensions or applications using serverless functions instead of traditional network APIs. That dramatically improves SaaS users' and developers' productivity. WasmEdge could be embedded into SaaS products to execute user-defined functions. In this scenario, the WasmEdge function API replaces the SaaS web API. The embedded WasmEdge functions are much faster, safer, and easier to use than RPC functions over the web. Edge servers could provide WasmEdge-based containers to interact with existing SaaS or PaaS APIs without requiring the user to run his own servers (eg callback servers). The serverless API services can be co-located in the same networks as the SaaS to provide optimal performance and security. The examples below showcase how WasmEdge-based serverless functions connect together SaaS APIs from different services, and process data flows across those SaaS APIs according each user's business logic. It is also known as `` aka the Chinese Slack. It is created by Byte Dance, the parent company of Tiktok.
Project: JuiceFS (Runtime / Cloud Native Storage)
File: usage_tracking.md

title: Usage Tracking sidebar_position: 4 JuiceFS by default collects and reports anonymous usage data. It only collects core metrics (e.g. version number, file system size), no user or any sensitive data will be collected. You could review related code . These data help us understand how the community is using this project. You could disable reporting easily by command line option `--no-usage-report`: ``` juicefs mount --no-usage-report ```
Project: CRI-O (Runtime / Container Runtime)
File: deprecating_process.md

Configuration options encompass settings that provide control over various aspects of CRIO's behavior and functionality. These options allow for the customization of operational parameters, shaping how CRI-O operates within a Kubernetes cluster. In CRI-O, configuration options undergo deprecation exclusively during major and minor version changes. Removals are not implemented abruptly within patch releases, ensuring a seamless transition for users adapting to evolving configurations. A configuration option is labeled as deprecated for a minimum of one release cycle before its actual removal. This period serves as a warning, offering users an opportunity to adjust their configurations in preparation for upcoming changes. The deprecation is communicated through various channels, including documentation revisions, notifications indicating the deprecation of configuration options in the CRI-O CLI help text, and a corresponding log entry within CRI-O itself. In the domain of system configurations, options are typically excluded when they are no longer considered essential or have been superseded by alternatives, particularly those within the Kubelet. The management of runtime containers has shifted towards the Kubelet, leading to the replacement of several CRI-O configuration options by the Kubelet. Runtime Management, previously handled with the "runtime_path" configuration option, has been replaced with the "--container-runtime" flag in Kubelet. Pod PIDs Limit, formerly set with the "pids_limit" configuration option, has been replaced with the "--pods_pids-limit" flag in Kubelet. Image Pull Timeout, initially defined by the "imagepulltimeout" configuration option, has been replaced with the "--image-pull-progress-deadline" flag in Kubelet. CRI-O configuration files are composed in TOML. Typically, TOML libraries used by CRI-O ignore unfamiliar or unacknowledged configuration parameters. While these unacknowledged values are generally accepted, any unfamiliar flags in the Command Line Interface (CLI) might result in a failure in CRI-O. In specific cases, a Command Line Interface (CLI) flag designated for removal may be retained for an additional release; however, it will be deactivated during this period. This extension is provided to users, granting them additional time to update their configurations and scripts before the flag is ultimately eliminated in subsequent releases.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_fqdn_cache.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage fqdn proxy cache ``` cilium-dbg fqdn cache [flags] ``` ``` -h, --help help for cache ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage fqdn proxy - Clean fqdn cache - List fqdn cache contents
Project: containerd (Runtime / Container Runtime)
File: 2017-03-24.md

https://github.com/containerd/containerd/pull/646 We merged a PR to add our first pass of container level metrics to our prometheus output in containerd. We still have to review the metric names and structure before having something we are all comfortable supporting in the long run but we now have comprehensive metrics for all containers running on containerd. After hitting a major milestone of getting a proof of concept for end to end pull and run, this week the focus was on getting that code in the right place and figure out where the implementation gaps are. https://github.com/containerd/containerd/pull/660 We merged support for getting an image config that was pulled off of a registry and generating a spec based on the image properties in the `ctr` command. This will let you pull images off of a registry and run them based on the config and how the image was built. Its very simple at the moment but will will be porting over the default spec and generation code from Docker soon into a package that can be easily consumed by clients of containerd. You can test this by running: ```console bash sudo dist pull docker.io/library/redis:alpine sudo ctr run --id redis -t docker.io/library/redis:alpine ``` https://github.com/containerd/containerd/pull/638 We refactored the fetch command into a more generic image handler interface. As we look forward to supporting the full oci image spec as well as the Docker distribution specifications, we are removing any opinionated code to make distribution as generalized and efficient as possible. ```console $ dist images REF TYPE DIGEST SIZE docker.io/library/redis:latest application/vnd.docker.distribution.manifest.v2+json sha256:1b358a2b0dc2629af3ed75737e2f07e5b3408eabf76a8fa99606ec0c276a93f8 71.0 MiB ``` https://github.com/containerd/containerd/pull/635 The `overlay` and `btrfs` driver implementations are now fully implemented and share an implementation for metadata storage. This new metadata storage package allows not only making snapshot drivers easier, but allow us to focus on making our existing drivers more resilient and stable once.
Project: Kanister (Runtime / Cloud Native Storage)
File: overview.md

|](<https://goreportcard.com/report/github.com/kanisterio/kanister>)|](<https://github.com/kanisterio/kanister/actions>)| |-|--| The design of Kanister was driven by the following main goals: Application-Centric: Given the increasingly complex and distributed nature of cloud-native data services, there is a growing need for data management tasks to be at the application level. Experts who possess domain knowledge of a specific application\'s needs should be able to capture these needs when performing data operations on that application. API Driven: Data management tasks for each specific application may vary widely, and these tasks should be encapsulated by a well-defined API so as to provide a uniform data management experience. Each application expert can provide an application-specific pluggable implementation that satisfies this API, thus enabling a homogeneous data management experience of diverse and evolving data services. Extensible: Any data management solution capable of managing a diverse set of applications must be flexible enough to capture the needs of custom data services running in a variety of environments. Such flexibility can only be provided if the solution itself can easily be extended. Follow the instructions in the section to get section to get Kanister up and running on your Kubernetes cluster. Then see Kanister in action by going through the walkthrough under . The section provides architectural insights into how things work. We recommend that you take a look at it.
Project: Kata Containers (Runtime / Container Runtime)
File: Upgrading.md

This document outlines the options for upgrading from a to a . Kata Containers 2.x is the new focus for the Kata Containers development community. Although Kata Containers 1.x releases will continue to be published for a period of time, once a stable release for Kata Containers 2.x is published, Kata Containers 1.x stable users should consider switching to the Kata 2.x release. To display the current Kata Containers version, run one of the following: ```bash $ kata-runtime --version $ containerd-shim-kata-v2 --version ``` Kata Containers 2.x releases are published on the . Alternatively, if you are using Kata Containers version 1.12.0 or newer, you can check for newer releases using the command line: ```bash $ kata-runtime check --check-version-only ``` There are various other related options. Run `kata-runtime check --help` for further details. The is compatible with the . However, if you have created a local configuration file (`/etc/kata-containers/configuration.toml`), this will mask the newer Kata Containers 2.x configuration file. Since Kata Containers 2.x introduces a number of new options and changes some default values, we recommend that you disable the local configuration file (by moving or renaming it) until you have reviewed the changes to the official configuration file and applied them to your local file if required. As shown in the , Kata Containers provide binaries for popular distributions in their native packaging formats. This allows Kata Containers to be upgraded using the standard package management tools for your distribution. Note: Users should prefer the distribution packaged version of Kata Containers unless they understand the implications of a manual installation. Note: Unless you are an advanced user, if you are using a static installation of Kata Containers, we recommend you remove it and install a instead. If the following command displays the output "static", you are using a static version of Kata Containers: ```bash $ ls /opt/kata/bin/kata-runtime &>/dev/null && echo static ``` Static installations are installed in `/opt/kata/`, so to uninstall simply remove this directory. If you understand the implications of using a static installation, to upgrade first , then . See the for details on how to automatically install and configuration a static release with containerd. Note: This section only applies to advanced users who have built their own guest kernel or image. If you are using custom , you must upgrade them to work with Kata Containers 2.x since Kata Containers 1.x assets will not work. See the following for further details: The official assets are packaged meaning they are automatically included in new releases.
Project: containerd (Runtime / Container Runtime)
File: containerd-config.8.md

containerd-config - information on the containerd config containerd config [command] The containerd config command has one subcommand, named default, which will display on standard output the default containerd config for this version of the containerd daemon. This output can be piped to a containerd-config.toml(5) file and placed in /etc/containerd to be used as the configuration for containerd on daemon startup. The configuration can be placed in any filesystem location and used with the --config option to the containerd daemon as well. See containerd-config.toml(5) for more information on the containerd configuration options. default : This subcommand will output the TOML formatted containerd configuration to standard output Please file any specific issues that you encounter at https://github.com/containerd/containerd. Phil Estes <estesp@gmail.com> ctr(8), containerd(8), containerd-config.toml(5)
Project: Firecracker (Runtime / Container Runtime)
File: snapshot-editor.md

The `snapshot-editor` is a program for modification of Firecracker snapshots. Firecracker snapshot consists of 2 files: `vmstate` file: file with Firecracker internal data such as vcpu states, devices states etc. `memory` file: file with guest memory. This command is used to merge a `diff` snapshot memory file on top of a base memory file. Note You can also use `rebase-snap` (deprecated) tool for this. Arguments: `MEMORY_PATH` - path to the `memory` file `DIFF_PATH` - path to the `diff` file Usage: ```bash snapshot-editor edit-memory rebase \ --memory-path <MEMORY_PATH> \ --diff-path <DIFF_PATH> ``` Example: ```bash snapshot-editor edit-memory rebase \ --memory-path ./memory_file \ --diff-path ./diff_file ``` This command is used to remove specified registers from vcpu states inside vmstate snapshot file. Arguments: `VMSTATE_PATH` - path to the `vmstate` file `OUTPUT_PATH` - path to the file where the output will be placed `[REGS]` - set of u32 values representing registers ids as they are defined in KVM. Can be both in decimal and in hex formats. Usage: ```bash snapshot-editor edit-vmstate remove-regs \ --vmstate-path <VMSTATE_PATH> \ --output-path <OUTPUT_PATH> \ [REGS]... ``` Example: ```bash ./snapshot-editor edit-vmstate remove-regs \ --vmstate-path ./vmstate_file \ --output-path ./newvmstatefile \ 0x1 0x2 ``` This command is used to print version of the provided vmstate file. Arguments: `VMSTATE_PATH` - path to the `vmstate` file Usage: ```bash snapshot-editor info-vmstate version --vmstate-path <VMSTATE_PATH> ``` Example: ```bash ./snapshot-editor info-vmstate version --vmstate-path ./vmstate_file ``` This command is used to print the vCPU states inside vmstate snapshot file. Arguments: `VMSTATE_PATH` - path to the `vmstate` file Usage: ```bash snapshot-editor info-vmstate vcpu-states --vmstate-path <VMSTATE_PATH> ``` Example: ```bash ./snapshot-editor info-vmstate vcpu-states --vmstate-path ./vmstate_file ``` This command is used to print the vmstate of snapshot file in readable format thus, making it easier to compare vmstate of 2 snapshots. Arguments: `VMSTATE_PATH` - path to the `vmstate` file Usage: ```bash snapshot-editor info-vmstate vm-state --vmstate-path <VMSTATE_PATH> ``` Example: ```bash ./snapshot-editor info-vmstate vm-state --vmstate-path ./vmstate_file ```
Project: Spiderpool (Runtime / Cloud Native Network)
File: certificate.md

Spiderpool-controller needs TLS certificates to run webhook server. You can configure it in several ways. Use Helm's template function to generate TLS certificates. This is the simplest and most common way to configure: ```bash helm install spiderpool spiderpool/spiderpool --namespace kube-system \ --set spiderpoolController.tls.method=auto ``` Note that the default value of parameter `spiderpoolController.tls.method` is `auto`. If you want to run spiderpool-controller with a self-signed certificate, `provided` would be a good choice. You can use OpenSSL to generate certificates, or run the following script: ```bash wget https://raw.githubusercontent.com/spidernet-io/spiderpool/main/tools/cert/generateCert.sh ``` Generate the certificates: ```bash chmod +x generateCert.sh && ./generateCert.sh "/tmp/tls" CA=`cat /tmp/tls/ca.crt | base64 -w0 | tr -d '\n'` SERVER_CERT=`cat /tmp/tls/server.crt | base64 -w0 | tr -d '\n'` SERVER_KEY=`cat /tmp/tls/server.key | base64 -w0 | tr -d '\n'` ``` Then, deploy Spiderpool in the `provided` mode: ```bash helm install spiderpool spiderpool/spiderpool --namespace kube-system \ --set spiderpoolController.tls.method=provided \ --set spiderpoolController.tls.provided.tlsCa=${CA} \ --set spiderpoolController.tls.provided.tlsCert=${SERVER_CERT} \ --set spiderpoolController.tls.provided.tlsKey=${SERVER_KEY} ``` It is not recommended to use this mode directly, because the Spiderpool requires the TLS certificates provided by cert-manager, while the cert-manager requires the IP address provided by Spiderpool (cycle reference). Therefore, if possible, you must first using other IPAM CNI in the Kubernetes cluster, and then deploy Spiderpool. ```bash helm install spiderpool spiderpool/spiderpool --namespace kube-system \ --set spiderpoolController.tls.method=certmanager \ --set spiderpoolController.tls.certmanager.issuerName=${CERTMANAGERISSUER_NAME} ```
Project: Velero (Runtime / Cloud Native Storage)
File: extend.md

title: "Extend Velero" layout: docs Velero includes mechanisms for extending the core functionality to meet your individual backup/restore needs: allow you to specify commands to be executed within running pods during a backup. This is useful if you need to run a workload-specific command prior to taking a backup (for example, to flush disk buffers or to freeze a database). allow you to develop custom object/block storage back-ends or per-item backup/restore actions that can execute arbitrary logic, including modifying the items being backed up/restored. Plugins can be used by Velero without needing to be compiled into the core Velero binary.