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

, 2023-05-23, Chi He , May 9, 2023, Storage Team@0PP0 , April 25, 2023Storage Team @OPPO , April 18, 2023Storage Team @OPPO , March 31, 2023, Storage Team @OPPO , March 7, 2023, Storage Team @OPPO , February 7, 2023, Hu Weicai @Beike , July 26, 2022, Storage Team @OPPO , June 28, 2022, Storage Team @OPPO 2023-7-28Yuan Zeng 2023-07-20Rui Zhang 2023-07-13Chao Yang , 2023-06-06, Ke Zhang 2023-05-16Liangliang Tang , May 5, 2023, Bingxing Liu@BIGO , March 30, 2023, Storage Team @OPPO , December 15, 2022, Storage Team @OPPO , November 29, 2022, Storage Team @OPPO , September 1, 2022, Storage Team @OPPO , August 9, 2022, Storage Team @OPPO 2023-09-01Chenyang Zhao 2023-08-22Chenyang Zhao 2023-07-04Tianyue Peng 2023-06-15Huocheng Wu , 2023-05-31, Tianjiong,Zhang 2023-05-25Huocheng Wu ,April 13, 2023Storage Team @OPPO , April 6, 2023Storage Team @OPPO , March 23, 2023, Storage Team @OPPO , January 4, 2023, Storage Team @OPPO , December 22, 2022, Storage Team @OPPO , November 4, 2022, Storage Team @OPPO , October 13, 2022, Storage Team @OPPO , September 16, 2022, Storage Team @OPPO , July 21, 2022, Storage Team @OPPO
Project: Submariner (Runtime / Cloud Native Network)
File: support.md

name: Support Request about: Support request or question relating to Submariner labels: support <!-- GitHub may not be the right place for support requests. You can also post your question on the [Submariner Slack](https://kubernetes.slack.com/archives/C010RJV694M) or the Submariner or mailing lists. If the matter is security related, please disclose it privately to the Submariner Owners: https://github.com/orgs/submariner-io/teams/submariner-core -->
Project: Rook (Runtime / Cloud Native Storage)
File: feature_request.md

name: Feature request about: Suggest an idea/feature for this project labels: feature <!-- Are you in the right place? For issues or feature requests, please create an issue in this repository. For general technical and non-technical questions, we are happy to help you on our . Did you already search the existing open issues for anything similar? --> Is this a bug report or feature request? Feature Request What should the feature do: What is use case behind this feature: Environment: <!-- Specific environment information that helps with the feature request -->
Project: MinIO (Runtime / Cloud Native Storage)
File: SIZING.md

Capacity constrained environments, MinIO will work but not recommended for production. | servers | drives (per node) | stripe_size | parity chosen (default) | tolerance for reads (servers) | tolerance for writes (servers) | |--:|:|:|:|:|-:| | 1 | 1 | 1 | 0 | 0 | 0 | | 1 | 4 | 4 | 2 | 0 | 0 | | 4 | 1 | 4 | 2 | 2 | 1 | | 5 | 1 | 5 | 2 | 2 | 2 | | 6 | 1 | 6 | 3 | 3 | 2 | | 7 | 1 | 7 | 3 | 3 | 3 | | servers | drives (per node) | stripe_size | parity chosen (default) | tolerance for reads (servers) | tolerance for writes (servers) | |--:|:|:|:|:|-:| | 4 | 2 | 8 | 4 | 2 | 1 | | 5 | 2 | 10 | 4 | 2 | 2 | | 6 | 2 | 12 | 4 | 2 | 2 | | 7 | 2 | 14 | 4 | 2 | 2 | | 8 | 1 | 8 | 4 | 4 | 3 | | 8 | 2 | 16 | 4 | 2 | 2 | | 9 | 2 | 9 | 4 | 4 | 4 | | 10 | 2 | 10 | 4 | 4 | 4 | | 11 | 2 | 11 | 4 | 4 | 4 | | 12 | 2 | 12 | 4 | 4 | 4 | | 13 | 2 | 13 | 4 | 4 | 4 | | 14 | 2 | 14 | 4 | 4 | 4 | | 15 | 2 | 15 | 4 | 4 | 4 | | 16 | 2 | 16 | 4 | 4 | 4 | If one or more drives are offline at the start of a PutObject or NewMultipartUpload operation the object will have additional data protection bits added automatically to provide the regular safety for these objects up to 50% of the number of drives. This will allow normal write operations to take place on systems that exceed the write tolerance. This means that in the examples above the system will always write 4 parity shards at the expense of slightly higher disk usage.
Project: WasmEdge Runtime (Runtime / Container Runtime)
File: js_or_dsl_runtime.md

In order for WebAssembly to be widely adopted by developers as a runtime, it must support "easy" languages like JavaScript. Or, better yet, through its advanced compiler toolchain, WasmEdge could support high performance DSLs (Domain Specific Languages), which are low code solutions designed for specific tasks. WasmEdge can act as a cloud-native JavaScript runtime by embedding a JS execution engine or interpreter. It is faster and lighter than running a JS engine inside Docker. WasmEdge supports JS APIs to access native extension libraries such as network sockets, tensorflow, and user-defined shared libraries. It also allows embedding JS into other high-performance languages (eg, Rust) or using Rust / C to implement JS functions. Tutorials * * The image classification DSL is a YAML format that allows the user to specify a tensorflow model and its parameters. WasmEdge takes an image as the input of the DSL and outputs the detected item name / label. Example: A chatbot DSL function takes an input string and responds with a reply string. The DSL specifies the internal state transitions of the chatbot, as well as AI models for language understanding. This work is in progress.
Project: Velero (Runtime / Cloud Native Storage)
File: upgrade-to-1.5.md

title: "Upgrading to Velero 1.5" layout: docs Velero , or installed. If you're not yet running at least Velero v1.4, 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.5 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.5.3 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: 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 and, optionally, the restic daemon set: ```bash kubectl set image deployment/velero \ velero=velero/velero:v1.5.3 \ --namespace velero kubectl set image daemonset/restic \ restic=velero/velero:v1.5.3 \ --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.5.3 Git commit: <git SHA> Server: Version: v1.5.3 ```
Project: Kata Containers (Runtime / Container Runtime)
File: vexxhost-installation-guide.md

Kata Containers on VEXXHOST use nested virtualization to provide an identical installation experience to Kata on your preferred Linux distribution. This guide assumes you have an OpenStack public cloud account set up and tools to remotely connect to your virtual machine (SSH). All regions support nested virtualization using the V2 flavors (those prefixed with v2). The recommended machine type for container workloads is `v2-highcpu` range. Follow distribution specific .
Project: lxd (Runtime / Container Runtime)
File: instances_troubleshoot.md

(instances-troubleshoot)= If your instance fails to start and ends up in an error state, this usually indicates a bigger issue related to either the image that you used to create the instance or the server configuration. To troubleshoot the problem, complete the following steps: Save the relevant log files and debug information: Instance log : Enter the following command to display the instance log: incus info <instance_name> --show-log Console log : Enter the following command to display the console log: incus console <instance_name> --show-log Reboot the machine that runs your Incus server. Try starting your instance again. If the error occurs again, compare the logs to check if it is the same error. If it is, and if you cannot figure out the source of the error from the log information, open a question in the . Make sure to include the log files you collected. In this example, let's investigate a RHEL 7 system in which `systemd` cannot start. ```{terminal} :input: incus console --show-log systemd Console log: Failed to insert module 'autofs4' Failed to insert module 'unix' Failed to mount sysfs at /sys: Operation not permitted Failed to mount proc at /proc: Operation not permitted [!!!!!!] Failed to mount API filesystems, freezing. ``` The errors here say that `/sys` and `/proc` cannot be mounted - which is correct in an unprivileged container. However, Incus mounts these file systems automatically if it can. The {doc}`container requirements <../container-environment>` specify that every container must come with an empty `/dev`, `/proc` and `/sys` directory, and that `/sbin/init` must exist. If those directories don't exist, Incus cannot mount them, and `systemd` will then try to do so. As this is an unprivileged container, `systemd` does not have the ability to do this, and it then freezes. So you can see the environment before anything is changed, and you can explicitly change the init system in a container using the `raw.lxc` configuration parameter. This is equivalent to setting `init=/bin/bash` on the Linux kernel command line. incus config set systemd raw.lxc 'lxc.init.cmd = /bin/bash' Here is what it looks like: ```{terminal} :input: incus config set systemd raw.lxc 'lxc.init.cmd = /bin/bash' :input: incus start systemd :input: incus console --show-log systemd Console log: [root@systemd /]# ``` Now that the container has started, you can check it and see that things are not running as well as expected: ```{terminal} :input: incus exec systemd -- bash [root@systemd ~]# ls [root@systemd ~]# mount mount: failed to read mtab: No such file or directory [root@systemd ~]# cd / [root@systemd /]# ls /proc/ sys [root@systemd /]# exit ``` Because Incus tries to auto-heal, it created some of the directories when it was starting up. Shutting down and restarting the container fixes the problem, but the original cause is still there - the template does not contain the required files.
Project: lxd (Runtime / Container Runtime)
File: devices.md

(devices)= Devices are attached to an instance (see {ref}`instances-configure-devices`) or to a profile (see {ref}`profiles-edit`). They include, for example, network interfaces, mount points, USB and GPU devices. These devices can have instance device options, depending on the type of the instance device. Incus supports the following device types: | ID (database) | Name | Condition | Description | |:--|:|:-|:--| | 0 | | - | Inheritance blocker | | 1 | | - | Network interface | | 2 | | - | Mount point inside the instance | | 3 | | container | Unix character device | | 4 | | container | Unix block device | | 5 | | - | USB device | | 6 | | - | GPU device | | 7 | | container | InfiniBand device | | 8 | | container | Proxy device | | 9 | | container | Unix hotplug device | | 10 | | - | TPM device | | 11 | | VM | PCI device | Each instance comes with a set of {ref}`standard-devices`. ```{toctree} :maxdepth: 1 :hidden: ../reference/standard_devices.md ../reference/devices_none.md ../reference/devices_nic.md ../reference/devices_disk.md ../reference/devicesunixchar.md ../reference/devicesunixblock.md ../reference/devices_usb.md ../reference/devices_gpu.md ../reference/devices_infiniband.md ../reference/devices_proxy.md ../reference/devicesunixhotplug.md ../reference/devices_tpm.md ../reference/devices_pci.md ```
Project: Carina (Runtime / Cloud Native Storage)
File: development.md

pull code ```shell $ git clone https://github.com/carina-io/carina.git ``` golang 1.17 compiling carina-controller / carina-node ```shell $ make docker-build $ make release VERSION=v0.9 ``` compiling carina-scheduler. Carina-scheduler is an independent projectwhich is just placed under carina for now. ```shell $ cd scheduler $ make docker-build $ make release VERSION=v0.9 ``` how to run e2e test cases? For local volume projects, it's not ideal to run e2e tests via KIND clusters. It's recommended to test carina on physical or virtual nodes. ```shell $ cd test/e2e $ make e2e ```
Project: Flannel (Runtime / Cloud Native Network)
File: building.md

The most reliable way to build flannel is by using Docker. To build flannel in a container run `make dist/flanneld-amd64`. You will now have a `flanneld-amd64` binary in the `dist` directory. If you're not running `amd64` then you need to manually set `ARCH` before running `make`. For example, to produce a `flanneld-s390x` binary and image, run ARCH=s390x make image If you want to cross-compile for a different platform (e.g. you're running `amd64` but you want to produce `arm` binaries) then you need the qemu-static binaries to be present in `/usr/bin`. They can be installed on Ubuntu with `sudo apt-get install qemu-user-static` Then you should be able to set the ARCH as above ARCH=arm make image To build the multi-arch image of flannel locally, you need to install . Then you can use the following target: ``` make build-multi-arch ``` If you don't already have a builder running locally, you can this target to start it: ``` make buildx-create-builder ``` See the for more details. To run the end-to-end tests locally, you need to installl . Make sure you have required dependencies installed on your machine. On Ubuntu, run `sudo apt-get install linux-libc-dev golang gcc`. If the golang version installed is not 1.7 or higher. Download the newest golang and install manually. To build the flannel.exe on windows, mingw-w64 is also needed. Run command `sudo apt-get install mingw-w64` On Fedora/Redhat, run `sudo yum install kernel-headers golang gcc glibc-static`. Git clone the flannel repo. It MUST be placed in your GOPATH under `github.com/flannel-io/flannel`: `cd $GOPATH/src; git clone https://github.com/flannel-io/flannel.git` Run the build script, ensuring that `CGOENABLED=1`: `cd flannel; CGOENABLED=1 make dist/flanneld` for linux usage. Run the build script, ensuring that `CGOENABLED=1`: `cd flannel; CGOENABLED=1 make dist/flanneld.exe` for windows usage.
Project: rkt (Runtime / Container Runtime)
File: config.md

The `config` subcommand prints the configuration of each rkt stage in JSON on the standard output. The general structure is a simple hierarchy consisting of the following top-level element: ``` { "stage0": [...] } ``` The entry "stage0" refers to stage-specific configuration; "stage1" is currently left out intentionally because its configuration subsystem is subject to change. The generated output are valid configuration entries as specified in the configuration documentation. The "stage0" entry contains subentries of rktKind "auth", "dockerAuth", "paths", and "stage1". Note that the `config` subcommand will output separate entries per "auth" domain and separate entries per "dockerAuth" registry. While it is possible to specify an array of strings in the input configuration rkt internally merges configuration state from different directories potentially creating multiple entries. Consider the following system configuration: ``` $ cat /etc/rkt/auth.d/basic.json { "rktKind": "auth", "rktVersion": "v1", "domains": [ "foo.com", "bar.com", "baz.com" ], "type": "basic", "credentials": { "user": "sysUser", "password": "sysPassword" } } ``` And the following user configuration: ``` $ ~/.config/rkt/auth.d/basic.json { "rktKind": "auth", "rktVersion": "v1", "domains": [ "foo.com" ], "type": "basic", "credentials": { "user": "user", "password": "password" } } ``` The `config` subcommand would generate the following separate merged entries: ``` { "stage0": [ { "rktVersion": "v1", "rktKind": "auth", "domains": [ "bar.com" ], "type": "basic", "credentials": { "user": "sysUser", "password": "sysPassword" } }, { "rktVersion": "v1", "rktKind": "auth", "domains": [ "baz.com" ], "type": "basic", "credentials": { "user": "sysUser", "password": "sysPassword" } }, { "rktVersion": "v1", "rktKind": "auth", "domains": [ "foo.com" ], "type": "basic", "credentials": { "user": "user", "password": "password" } } ] } ``` In the example given above the user configuration entry for the domain "foo.com" overrides the system configuration entry leaving the entries "bar.com" and "baz.com" unchanged. The `config` subcommand output creates three separate entries for "foo.com", "bar.com", and "baz.com". Note: While the "bar.com", and "baz.com" entries in the example given above could be merged into one entry they are still being printed separate. This behavior is subject to change, future implementations may provide a merged output. ``` $ rkt config { "stage0": [ { "rktVersion": "v1", "rktKind": "auth", "domains": [ "bar.com" ], "type": "oauth", "credentials": { "token": "someToken" } }, { "rktVersion": "v1", "rktKind": "auth", "domains": [ "foo.com" ], "type": "basic", "credentials": { "user": "user", "password": "userPassword" } }, { "rktVersion": "v1", "rktKind": "paths", "data": "/var/lib/rkt", "stage1-images": "/usr/lib/rkt" }, { "rktVersion": "v1", "rktKind": "stage1", "name": "coreos.com/rkt/stage1-coreos", "version": "0.15.0+git", "location": "/usr/libexec/rkt/stage1-coreos.aci" } ] } ```
Project: Container Network Interface (CNI) (Runtime / Cloud Native Network)
File: GOVERNANCE.md

This document defines project governance for the project. The CNI project employs "organization voting" to ensure no single organization can dominate the project. Individuals not associated with or employed by a company or organization are allowed one organization vote. Each company or organization (regardless of the number of maintainers associated with or employed by that company/organization) receives one organization vote. In other words, if two maintainers are employed by Company X, two by Company Y, two by Company Z, and one maintainer is an un-affiliated individual, a total of four "organization votes" are possible; one for X, one for Y, one for Z, and one for the un-affiliated individual. Any maintainer from an organization may cast the vote for that organization. For formal votes, a specific statement of what is being voted on should be added to the relevant github issue or PR, and a link to that issue or PR added to the maintainers meeting agenda document. Maintainers should indicate their yes/no vote on that issue or PR, and after a suitable period of time, the votes will be tallied and the outcome noted. New maintainers are proposed by an existing maintainer and are elected by a 2/3 majority organization vote. Maintainers can be removed by a 2/3 majority organization vote. Non-specification-related PRs may be merged after receiving at least two organization votes. Changes to the CNI Specification also follow the normal PR approval process (eg, 2 organization votes), but any maintainer can request that the approval require a 2/3 majority organization vote. Maintainers will be added to the containernetworking GitHub organization and added to the GitHub cni-maintainers team, and made a GitHub maintainer of that team. After 6 months a maintainer will be made an "owner" of the GitHub organization. All changes in Governance require a 2/3 majority organization vote. Unless specified above, all other changes to the project require a 2/3 majority organization vote. Additionally, any maintainer may request that any change require a 2/3 majority organization vote.
Project: Piraeus Datastore (Runtime / Cloud Native Storage)
File: index.md

The following document guides you through the upgrade process for Piraeus Operator from version 1 ("v1") to version 2 ("v2"). Piraeus Operator v2 offers improved convenience and customization. This however made it necessary to make significant changes to the way Piraeus Operator manages Piraeus Datastore. As such, upgrading from v1 to v2 is a procedure requiring manual oversight. Upgrading Piraeus Operator is done in four steps: [Step 1]: (Optional) Migrate the LINSTOR database to use the `k8s` backend. [Step 2]: Collect information about the current deployment. [Step 3]: Remove the Piraeus Operator v1 deployment, keeping existing volumes untouched. [Step 4]: Deploy Piraeus Operator v2 using the information gathered in step 2. This guide assumes: You used Helm to create the original deployment and are familiar with upgrading Helm deployments. Your Piraeus Datastore deployment is up-to-date with the latest v1 release. Check the releases . You have the following command line tools available: - You are familiar with the `linstor` command line utility, specifically to verify the cluster state. The resources `LinstorController`, `LinstorSatelliteSet` and `LinstorCSIDriver` have been replaced by and . The default deployment runs the LINSTOR Satellite in the . The migration script will propose changing to the host network. In Operator v1, all labels on the Kubernetes node resource were replicated on the satellite, making them usable in the `replicasOnSame` and `replicasOnDifferent` parameters on the storage class. In Operator v2, only the following labels are automatically synchronized. `kubernetes.io/hostname` `topology.kubernetes.io/region` `topology.kubernetes.io/zone` Use to synchronize additional labels. The following settings are applied by Operator v2 cluster-wide: DrbdOptions/Net/rr-conflict: retry-connect DrbdOptions/Resource/on-suspended-primary-outdated: force-secondary DrbdOptions/Resource/on-no-data-accessible: suspend-io DrbdOptions/auto-quorum: suspend-io Operator v2 also includes a deployment to prevent stuck nodes caused by suspended DRBD devices.
Project: Kube-router (Runtime / Cloud Native Network)
File: observability.md

See for more information Traffic that gets rejected due to network policy enforcements gets logged by kube-route using iptables NFLOG target under the group 100. Simplest way to observe the dropped packets by kube-router is by running tcpdump on `nflog:100` interface for e.g. `tcpdump -i nflog:100 -n`. You can also configure ulogd to monitor dropped packets in desired output format. Please see for an example configuration to setup a stack to log packets.
Project: Project Calico (Runtime / Cloud Native Network)
File: adding-an-api.md

Calico uses Kubernetes style APIs. To add a new API to Calico, or to add a new field to an existing API, use the following steps. For most cases, a new API field on an existing API is all that is needed. To add a new API field: Update the structures in the Run `make generate` to update generated code and CRDs. Add the new logic for your field, including . Add unit tests for your field. Start by opening a GitHub issue or design document to design the feature. Consider the following: What component(s) need to know about this resource? What is the correct abstraction for this feature? Is there an existing API that makes sense for this feature instead? Agree on a design for the new API. Read and follow the for new APIs. Get your proposed API reviewed. Add the new structure to the in its own go file. Include kubebuilder where appropriate. Run code and CRD generation - `make generate` Add client code to libcalico-go for the new API, using existing resources as a template. https://github.com/projectcalico/calico/tree/master/libcalico-go/lib/clientv3 https://github.com/projectcalico/calico/blob/master/libcalico-go/lib/backend/k8s/k8s.go Add unit tests for the API, using existing ones as a template. Add CRUD commands and tests to calicoctl using existing ones as a template. If felix or confd needs the new resource, add it to either the or respectively.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_srv6_policy.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List SRv6 policy entries List SRv6 policy entries. ``` cilium-dbg bpf srv6 policy [flags] ``` ``` -h, --help help for policy -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