cwielenb/CNCF-Dataset huggingface dataset:
Project: WasmEdge Runtime (Runtime / Container Runtime)
File: ROADMAP.md

This document should serve as a reference point for WasmEdge users and contributors to understand where the project is heading, and help determine if a contribution could be conflicting with a longer term plan. Discussion on the roadmap can take place in threads under . Please open and comment on an issue if you want to give suggestions and feedback to items in the roadmap. Please review the roadmap to avoid potential duplicated efforts. Please open an issue to track any initiative on the roadmap of WasmEdge (Usually driven by new feature requests). We will work with and rely on our community to focus our efforts to improve WasmEdge. The following table includes the current roadmap for WasmEdge. If you have any questions or would like to contribute to WasmEdge, please create an issue to discuss with our team. If you don't know where to start, we are always looking for contributors that will help us reduce technical, automation, and documentation debt. Please take the timelines & dates as proposals and goals. Priorities and requirements change based on community feedback, roadblocks encountered, community contributions, etc. Last Updated: Mar 2023 | Theme | Description | Timeline | | | | | | Proposal | Function reference proposal | Q2 / 2023 | | Proposal | Exception handling proposal | Q2 / 2023 | | Proposal | Typed continuation proposal | Q2 / 2023 | | Proposal | Stack-switch proposal | Q2 / 2023 | | Proposal | GC proposal | Q2 / 2023 | | Feature | WasmEdge unified tool | Q2 / 2023 | | Feature | WASM serialization/deserialization | Q2 / 2023 | | Proposal | WASI signature proposal | Q3 / 2023 | | Feature | Enhance info/debug logging, provide verbose mode (wasmedge a.wasm verbose=3) | Q3 / 2023 | | Feature | Wasm coredump | Q3 / 2023 | | Proposal | WASM C API proposal | Q4 / 2023 | | Proposal | WASM memory64 proposal | Q4 / 2023 | | Feature | WASI-NN training extension | Q4 / 2023 | | Feature | DWARF symbol | Q4 / 2023 | | Proposal | Component model proposal | ?? / 2023 | | Languages Bindings | | ?? / 2023 | | Feature | Enable PaddlePaddle backend for WASI-NN | ?? / 2023 | | Open Source Collaboration | Eventmesh, Krustlet, APISIX, Dapr, MOSN, KubeEdge, OpenYurt, Fedora, SuperEdge, UDF for SaaS and Databases, Substrate, ParaState, Filecoin | long term work |
Project: lxd (Runtime / Container Runtime)
File: cluster_manage_instance.md

(cluster-manage-instance)= In a cluster setup, each instance lives on one of the cluster members. You can operate each instance from any cluster member, so you do not need to log on to the cluster member on which the instance is located. (cluster-target-instance)= When you launch an instance, you can target it to run on a specific cluster member. You can do this from any cluster member. For example, to launch an instance named `c1` on the cluster member `server2`, use the following command: incus launch images:ubuntu/22.04 c1 --target server2 You can launch instances on specific cluster members or on specific {ref}`cluster groups <howto-cluster-groups>`. If you do not specify a target, the instance is assigned to a cluster member automatically. See {ref}`clustering-instance-placement` for more information. To check on which member an instance is located, list all instances in the cluster: incus list The location column indicates the member on which each instance is running. You can move an existing instance to another cluster member. For example, to move the instance `c1` to the cluster member `server1`, use the following commands: incus stop c1 incus move c1 --target server1 incus start c1 See {ref}`move-instances` for more information. To move an instance to a member of a cluster group, use the group name prefixed with `@` for the `--target` flag. For example: incus move c1 --target @group1
Project: OpenEBS (Runtime / Cloud Native Storage)
File: quick-start-with-vim-go.md

Let us assume that you already have a working Go environment. You need to make sure that your `$GOPATH/bin` is included in your PATH. ``` sudo apt-get install vim ``` The following link has detailed instructions on setting up `vim-go` on your system and using the shortcuts. https://github.com/fatih/vim-go-tutorial#quick-setup The following is an extract of the command required to install on Ubuntu. ``` curl -fLo ~/.vim/autoload/plug.vim --create-dirs https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim git clone https://github.com/fatih/vim-go.git ~/.vim/plugged/vim-go ``` Create `~/.vimrc` with following content: ``` call plug#begin() Plug 'fatih/vim-go', { 'do': ':GoInstallBinaries' } call plug#end() ``` Launch vim. In the vim editor, type the following: ``` :PlugInstall ``` The above should show a window that Plugins are installed. Now, run the following in the same vim editor: ``` :GoInstallBinaries ``` You should see the dependent go binaries downloaded and installed in your `GOPATH/bin`. The `vim-go` repository provides a large number of additional plugins and shortcuts that can be added to the `.vimrc`. However, with the default `.vimrc` use above, you can already get going: Initiate the build `:GoBuild`. Navigate to the definition `ctrl-{`. Navigate back `ctrl-o`.
Project: Velero (Runtime / Cloud Native Storage)
File: migrating-to-velero.md

title: "Migrating from Heptio Ark to Velero" layout: docs As of v0.11.0, Heptio Ark has become Velero. This means the following changes have been made: The `ark` CLI client is now `velero`. The default Kubernetes namespace and ServiceAccount are now named `velero` (formerly `heptio-ark`). The container image name is now `gcr.io/heptio-images/velero` (formerly `gcr.io/heptio-images/ark`). CRDs are now under the new `velero.io` API group name (formerly `ark.heptio.com`). The following instructions will help you migrate your existing Ark installation to Velero. Ark v0.10.x installed. See the v0.10.x to upgrade from older versions. `kubectl` installed. `cluster-admin` permissions. At a high level, the migration process involves the following steps: Scale down the `ark` deployment, so it will not process schedules, backups, or restores during the migration period. Create a new namespace (named `velero` by default). Apply the new CRDs. Migrate existing Ark CRD objects, labels, and annotations to the new Velero equivalents. Recreate the existing cloud credentials secret(s) in the velero namespace. Apply the updated Kubernetes deployment and daemonset (for restic support) to use the new container images and namespace. Remove the existing Ark namespace (which includes the deployment), CRDs, and ClusterRoleBinding. These steps are provided in a script here: ```bash kubectl scale --namespace heptio-ark deployment/ark --replicas 0 OS=$(uname | tr '[:upper:]' '[:lower:]') # Determine if the OS is Linux or macOS ARCH="amd64" curl -L https://github.com/vmware-tanzu/velero/releases/download/v0.11.0/velero-v0.11.0-${OS}-${ARCH}.tar.gz --output velero-v0.11.0-${OS}-${ARCH}.tar.gz tar xvf velero-v0.11.0-${OS}-${ARCH}.tar.gz kubectl apply -f config/common/00-prereqs.yaml curl -L https://github.com/vmware/crd-migration-tool/releases/download/v1.0.0/crd-migration-tool-v1.0.0-${OS}-${ARCH}.tar.gz --output crd-migration-tool-v1.0.0-${OS}-${ARCH}.tar.gz tar xvf crd-migration-tool-v1.0.0-${OS}-${ARCH}.tar.gz ./crd-migrator \ --from ark.heptio.com/v1 \ --to velero.io/v1 \ --label-mappings ark.heptio.com:velero.io,ark-schedule:velero.io/schedule-name \ --annotation-mappings ark.heptio.com:velero.io \ --namespace-mappings heptio-ark:velero kubectl get secret --namespace heptio-ark cloud-credentials --export -o yaml | kubectl apply --namespace velero -f - ./velero get backup ./velero get restore kubectl delete namespace heptio-ark kubectl delete crds -l component=ark kubectl delete clusterrolebindings -l component=ark ```
Project: Kata Containers (Runtime / Container Runtime)
File: NumaDistance.md

Name | Type | Description | Notes | - | - | - Destination | int32 | | Distance | int32 | | `func NewNumaDistance(destination int32, distance int32, ) *NumaDistance` NewNumaDistance instantiates a new NumaDistance 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 NewNumaDistanceWithDefaults() *NumaDistance` NewNumaDistanceWithDefaults instantiates a new NumaDistance 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 *NumaDistance) GetDestination() int32` GetDestination returns the Destination field if non-nil, zero value otherwise. `func (o NumaDistance) GetDestinationOk() (int32, bool)` GetDestinationOk returns a tuple with the Destination field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *NumaDistance) SetDestination(v int32)` SetDestination sets Destination field to given value. `func (o *NumaDistance) GetDistance() int32` GetDistance returns the Distance field if non-nil, zero value otherwise. `func (o NumaDistance) GetDistanceOk() (int32, bool)` GetDistanceOk returns a tuple with the Distance field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *NumaDistance) SetDistance(v int32)` SetDistance sets Distance field to given value.
Project: Kata Containers (Runtime / Container Runtime)
File: networking.md

Containers typically live in their own, possibly shared, networking namespace. At some point in a container lifecycle, container engines will set up that namespace to add the container to a network which is isolated from the host network. In order to setup the network for a container, container engines call into a networking plugin. The network plugin will usually create a virtual ethernet (`veth`) pair adding one end of the `veth` pair into the container networking namespace, while the other end of the `veth` pair is added to the host networking namespace. This is a very namespace-centric approach as many hypervisors or VM Managers (VMMs) such as `virt-manager` cannot handle `veth` interfaces. Typically, interfaces are created for VM connectivity. To overcome incompatibility between typical container engines expectations and virtual machines, Kata Containers networking transparently connects `veth` interfaces with `TAP` ones using : With a TC filter rules in place, a redirection is created between the container network and the virtual machine. As an example, the network plugin may place a device, `eth0`, in the container's network namespace, which is one end of a VETH device. Kata Containers will create a tap device for the VM, `tap0_kata`, and setup a TC redirection filter to redirect traffic from `eth0`'s ingress to `tap0_kata`'s egress, and a second TC filter to redirect traffic from `tap0_kata`'s ingress to `eth0`'s egress. Kata Containers maintains support for MACVTAP, which was an earlier implementation used in Kata. With this method, Kata created a MACVTAP device to connect directly to the `eth0` device. TC-filter is the default because it allows for simpler configuration, better CNI plugin compatibility, and performance on par with MACVTAP. Kata Containers has deprecated support for bridge due to lacking performance relative to TC-filter and MACVTAP. Kata Containers supports both and for networking management. Kata Containers has developed a set of network sub-commands and APIs to add, list and remove a guest network endpoint and to manipulate the guest route table. The following diagram illustrates the Kata Containers network hotplug workflow.
Project: Velero (Runtime / Cloud Native Storage)
File: ark_delete.md

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

Welcome to Kubernetes. We are excited about the prospect of you joining our ! The Kubernetes community abides by the CNCF . Here is an excerpt: As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities. We have full documentation on how to get started contributing here: <! If your repo has certain guidelines for contribution, put them here ahead of the general k8s resources --> Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests - Main contributor documentation, or you can just jump directly to the - Common resources for existing developers - We have a diverse set of mentorship programs available that are always looking for volunteers! <! Custom Information - if you're copying this template for the first time you can add custom content here, for example: - Replace `kubernetes-users` with your slack channel string, this will send users directly to your channel. --> ontributor-cheatsheet) - Common resources for existing developers You can reach the maintainers of this project via the . - We have a diverse set of mentorship programs available that are always looking for volunteers!
Project: kube-vip (Runtime / Cloud Native Network)
File: architecture.md

This brief document is largely for my own notes about how this functionality is added to `kube-vip`. New Flags Startup Secret(s) A `--wireguard` flag or `vip_wireguard` environment variable will determine if the Wireguard mode is enabled, if this is the case then it will start the wireguard manager process. This will require `kube-vip` starting as a daemonset as it will need to read existing data (secrets) from inside the cluster. Create a private key for the cluster: ``` PRIKEY=$(wg genkey) PUBKEY=$(echo $PRIKEY | wg pubkey) PEERKEY=$(sudo wg show wg0 public-key) echo "kubectl create -n kube-system secret generic wireguard --from-literal=privateKey=$PRIKEY --from-literal=peerPublicKey=$PEERKEY --from-literal=peerEndpoint=192.168.0.179" sudo wg set wg0 peer $PUBKEY allowed-ips 10.0.0.0/8 ```
Project: Rook (Runtime / Cloud Native Storage)
File: external-management.md

Target version: 0.9 Some tools want to use Rook to run containers, but not manage the logical Ceph resources like Pools. We should make Rook's pool management optional. Currently in Rook 0.8, creating and destroying a Filesystem (or ObjectStore) in a Ceph cluster also creates and destroys the associated Ceph filesystem and pools. The current design works well when the Ceph configuration is within the scope of what Rook can configure itself, and the user does not modify the Ceph configuration of pools out of band. The current model is problematic in some cases: A user wants to use Ceph functionality outside of Rook's subset, and therefore create their pools by hand before asking Rook to run the daemon containers for a filesystem. A user externally modifies the configuration of a pool (such as the number of replicas), they probably want that new configuration, rather than for Rook to change it back to match the Rook Filesystem settings. A risk-averse user wants to ensure that mistaken edits to their Rook config cannot permanently erase Ceph pools (i.e. they want to only delete pools through an imperative interface with confirmation prompts etc). In FilesystemSpec (and ObjectStoreSpec), when the metadata and data pool fields are left empty, Rook will not do any management of logical Ceph resources (Ceph pools and Ceph filesystems) for the filesystem. The pools may be initially non-nil, and later modified to be nil. In this case, while Rook may have created the logical resources for the filesystem, it will not remove them when the Rook filesystem is removed. If either of the metadata/data fields are non-nil, then they both must be non-nil: Rook will not partially manage the pools for a given filesystem or object store. ```yaml apiVersion: ceph.rook.io/v1 kind: Filesystem metadata: name: myfs namespace: rook-ceph spec: metadataPool: replicated: size: 3 dataPools: erasureCoded: dataChunks: 2 codingChunks: 1 metadataServer: activeCount: 1 activeStandby: true ``` In this example, the pools are omitted. Rook will not create any pools or a Ceph filesystem. A filesystem named ``myfs`` should already exist in Ceph, otherwise Rook will not start any MDS pods. ```yaml apiVersion: ceph.rook.io/v1 kind: Filesystem metadata: name: myfs namespace: rook-ceph spec: metadataServer: activeCount: 1 activeStandby: true ``` Rook Operator: add logic to skip logical resource management when pools are omitted in FilesystemSpec or ObjectStoreSpec Migration: none required. Existing filesystems and objectstores always have pools set explicitly, so will continue to have these managed by Rook.
Project: Singularity (Runtime / Container Runtime)
File: LICENSE.md

Copyright (c) 2015-2017, Gregory M. Kurtzer. All rights reserved. Copyright (c) 2016-2017, The Regents of the University of California. All right reserved. Copyright (c) 2017, SingularityWare, LLC. All rights reserved. Copyright (c) 2018-2019, Sylabs, Inc. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Project: Velero (Runtime / Cloud Native Storage)
File: ark_restic_server.md

title: "ark restic server" layout: docs Run the ark restic server Run the ark restic server ``` ark restic server [flags] ``` ``` -h, --help help for server --log-level the level at which to log. Valid values are debug, info, warning, error, fatal, panic. (default info) ``` ``` --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 ``` - Work with restic
Project: CubeFS (Runtime / Cloud Native Storage)
File: email-templates.md

This is a collection of email templates to handle various situations the security team encounters. ``` Subject: Upcoming security release of CubeFS $VERSION To: security@cubefs.groups.io Hello CubeFS Community, The CubeFS Product Security Committee and maintainers would like to announce the forthcoming release of CubeFS $VERSION. This release will be made available on the $ORDINALDAY of $MONTH $YEAR at $PDTHOUR PDT ($GMTHOUR GMT). This release will fix $NUMDEFECTS security defect(s). The highest rated security defect is considered $SEVERITY severity. No further details or patches will be made available in advance of the release. Thanks Thanks to $REPORTER, $DEVELOPERS, and the $RELEASELEADS for the coordination is making this release. Thanks, $PERSON on behalf of the CubeFS Product Security Committee and maintainers ``` ``` Subject: Security release of CubeFS $VERSION is now available To: security@cubefs.groups.io Hello CubeFS Community, The Product Security Committee and maintainers would like to announce the availability of CubeFS $VERSION. This addresses the following CVE(s): CVE-YEAR-ABCDEF (CVSS score $CVSS): $CVESUMMARY ... Upgrading to $VERSION is encouraged to fix these issues. Am I vulnerable? Run `cfs-server -v` and if it indicates a base version of $OLDVERSION or older that means it is a vulnerable version. <!-- Provide details on features, extensions, configuration that make it likely that a system is vulnerable in practice. --> How do I mitigate the vulnerability? <!-- [This is an optional section. Remove if there are no mitigations.] --> How do I upgrade? Follow the upgrade instructions at https://cubefs.io/docs/master/overview/introduction.html Vulnerability Details <!-- [For each CVE] --> *CVE-YEAR-ABCDEF* $CVESUMMARY This issue is filed as $CVE. We have rated it as ($CVSS, $SEVERITY) Thanks Thanks to $REPORTER, $DEVELOPERS, and the $RELEASELEADS for the coordination in making this release. Thanks, $PERSON on behalf of the CubeFS Product Security Committee and maintainers ```
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_vtep.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage the VTEP mappings for IP/CIDR <-> VTEP MAC/IP ``` -h, --help help for vtep ``` ``` --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 - Delete vtep entries - List VTEP CIDR and their corresponding VTEP MAC/IP - Update vtep entries
Project: Kilo (Runtime / Cloud Native Network)
File: RELEASE.md

The `yaml` Project is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`