cwielenb/CNCF-Dataset huggingface dataset:
Project: Multus (Runtime / Cloud Native Network)
File: bug-report.md

name: Bug Report about: Report a bug encountered <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--> What happend: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Multus version image path and image ID (from 'docker images') Kubernetes version (use `kubectl version`): Primary CNI for Kubernetes cluster: OS (e.g. from /etc/os-release): File of '/etc/cni/net.d/' File of '/etc/cni/multus/net.d' NetworkAttachment info (use `kubectl get net-attach-def -o yaml`) Target pod yaml info (with annotation, use `kubectl get pod <podname> -o yaml`) Other log outputs (if you use multus logging)
Project: Alluxio (Runtime / Cloud Native Storage)
File: NFS.md

layout: global title: NFS This guide describes the instructions to configure {:target="_blank"} as Alluxio's under storage system. Network File System (NFS) is a distributed file system protocol that allows a client computer to access files over a network as if they were located on its local storage. NFS enables file sharing and remote file access between systems in a networked environment. You'll need to have a configured and running installation of NFS for the rest of this guide. If you need to get your own NFS installation up and running, we recommend taking a look at the {:target="_blank"}. If you haven't already, please see before you get started. Make sure that you have a version of {:target="_blank"} installed. Turn on remote login service so that `ssh localhost` can succeed. To avoid the need to repeatedly input the password, you can add the public SSH key for the host into `~/.ssh/authorizedkeys`. See {:target="blank"} for more details. Before Alluxio master and workers can access the NFS server, mount points to the NFS server need to be created. Typically, all the machines will have the NFS shares located at the same path, such as `/mnt/nfs`. NFS client cache can interfere with the correct operation of Alluxio, specifically if Alluxio master creates a file on the NFS but the NFS client on the Alluxio worker continue to use the cached file listing, it will not see the newly created file. Thus we highly recommend setting the attribute cache timeout to 0. Please mount your nfs share like this. ```shell $ sudo mount -o actimeo=0 nfshost:/nfsdir /mnt/nfs ``` To use NFS as the UFS of Alluxio root mount point, you need to configure Alluxio to use under storage systems by modifying `conf/alluxio-site.properties`. If it does not exist, create the configuration file from the template. ```shell $ cp conf/alluxio-site.properties.template conf/alluxio-site.properties ``` Assume we have mounted NFS share at `/mnt/nfs` on all Alluxio masters and workers, modify `conf/alluxio-site.properties` to include: ```properties alluxio.master.hostname=localhost alluxio.dora.client.ufs.root=/mnt/nfs ``` Once you have configured Alluxio to NFS, try to see that everything works. Visit your NFS volume at `/mnt/nfs` to verify the files and directories created by Alluxio exist. For this test, you should see files named: ``` /mnt/nfs/defaulttestsfiles/BASICCACHETHROUGH ```
Project: Curve (Runtime / Cloud Native Storage)
File: CONTRIBUTING.md

Ensure the bug was not already reported by searching on GitHub under . If you're unable to find an open issue addressing the problem, . Be sure to include a title and clear description, as much relevant information as possible, and a code sample or an executable test case demonstrating the expected behavior that is not occurring. Check if you're using the latest version of Curve. If you're unable to find an open issue addressing the problem, . Please follow Write Test Code. Make sure you pass the Unit test and Integration test. The test lines coverage rate must 80% abovebranches coverage rate must 70% above. Please create pull request to opencurve/curve master branch. Please follow these steps to have your contribution considered by the maintainers: Follow all instructions in the template Follow the styleguides After you submit your pull request, verify that all status checks are passing While the prerequisites above must be satisfied prior to having your pull request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted.
Project: Spiderpool (Runtime / Cloud Native Network)
File: TROUBLESHOOTING.md

The most common reason for this issue is improper use of struct tags (eg. `yaml` or `json`). Viper uses under the hood for unmarshaling values which uses `mapstructure` tags by default. Please refer to the library's documentation for using other struct tags. Viper installation seems to fail a lot lately with the following (or a similar) error: ``` cannot find package "github.com/hashicorp/hcl/tree/hcl1" in any of: /usr/local/Cellar/go/1.15.7_1/libexec/src/github.com/hashicorp/hcl/tree/hcl1 (from $GOROOT) /Users/user/go/src/github.com/hashicorp/hcl/tree/hcl1 (from $GOPATH) ``` As the error message suggests, Go tries to look up dependencies in `GOPATH` mode (as it's commonly called) from the `GOPATH`. Viper opted to use to manage its dependencies. While in many cases the two methods are interchangeable, once a dependency releases new (major) versions, `GOPATH` mode is no longer able to decide which version to use, so it'll either use one that's already present or pick a version (usually the `master` branch). The solution is easy: switch to using Go Modules. Please refer to the on how to do that. tl;dr* `export GO111MODULE=on` This is a YAML 1.1 feature according to . Potential solutions are: Quoting values resolved as boolean Upgrading to YAML v3 (for the time being this is possible by passing the `viper_yaml3` tag to your build)
Project: Ligato (Runtime / Cloud Native Network)
File: CONTRIBUTING.md

Contributions to VPP-Agent are welcome. We use the standard pull request model. You can either pick an open issue and assign it to yourself or open a new issue and discuss your feature. In any case, before submitting your pull request please check the and cover the newly added code with tests and documentation. The dependencies are managed using Go modules. On any change of dependencies, run `go mod tidy` to update `go.mod`/`go.sum` files. We follow the .
Project: Ceph (Runtime / Cloud Native Storage)
File: README.md

Installation ============ The LTTng libraries that ship with Ubuntu 12.04 have been very buggy, and the generated header files using `lttng-gen-tp` have needed to be fixed just to compile in the Ceph tree. The packages available in Ubuntu 14.04 seem to work alright, and for older versions please install LTTng from the LTTng PPA. https://launchpad.net/~lttng/+archive/ppa Then install as normal apt-get install lttng-tools liblttng-ust-dev Add/Update Provider =================== Add tracepoint definitions for the provider into a `.tp` file. Documentation on defining a tracepoint can be found in `man lttng-ust`. By convention files are named according to the logical sub-system they correspond to (e.g. `mutex.tp`, `pg.tp`). And add a C source file to be compiled into the tracepoint provider shared object, in which `TRACEPOINT_DEFINE` should be defined. See for details. Place the `.tp` and the `.c` files into the `src/tracing` directory and modify the CMake file `src/tracing/CMakeLists.txt` accordingly. Function Instrumentation ======================== Ceph supports instrumentation using GCC's `-finstrument-functions` flag. Supported CMake flags are: `-DWITHOSDINSTRUMENT_FUNCTIONS=ON`: instrument OSD code Note that this instrumentation adds an extra function call on each function entry and exit of Ceph code. This option is currently only supported with GCC. Using it with Clang has no effect. The only function tracing implementation at the moment is done using LTTng UST. In order to use it, Ceph needs to be configured with LTTng using `-DWITH_LTTNG=ON`. can be used to generate flame charts/graphs and other metrics. It is also possible to use to write custom analysis. The entry and exit tracepoints are called `lttngustcygprofile:funcenter` and `lttngustcygprofile:funcexit` respectively. The payload variable `addr` holds the address of the function called and the payload variable `call_site` holds the address where it is called. `nm` can be used to resolve function addresses (`addr` to function name).
Project: CRI-O (Runtime / Container Runtime)
File: debugging.md

Below is a non-comprehensive document on some tips and tricks for troubleshooting/debugging/inspecting the behavior of CRI-O. Often with a long-running process, it can be useful to know what that process is up to. CRI-O has built-in functionality to print the go routine stacks to provide such information. All one has to do is send SIGUSR1 to CRI-O, either with `kill` or `systemctl` (if running CRI-O as a systemd unit): ```shell kill -USR1 $crio-pid systemctl kill -s USR1 crio.service ``` CRI-O will catch the signal, and write the routine stacks to `/tmp/crio-goroutine-stacks-$timestamp.log` You may have a need to manually run Go garbage collection for CRI-O. To force garbage collection, send CRI-O SIGUSR2 using `kill` or `systemctl` (if running CRI-O as a systemd unit). ```shell kill -s SIGUSR2 $crio-pid systemctl kill -s USR2 crio.service ```
Project: Rook (Runtime / Cloud Native Storage)
File: ceph-config-via-cluster-crd.md

Adding the ability to configure the Ceph config options via the CephCluster CRD. The goal is not to replace the `rook-config-override` ConfigMap since it is still needed in some scenarios such as if mons need settings applied at first launch. Users need to update the `rook-config-override` and add their custom options, e.g., for setting a custom OSD scrubbing schedule (). Adding a new structure to the CephCluster CRD under `.spec` named `cephConfig:`. The `cephConfig` structure will be structured in a way of `Target -> Options` (target being the service to set the options for, e.g., whole cluster `global`, specific OSD `osd.3`). ```yaml spec: cephConfig: global: osdmaxscrubs: "5" osdpooldefault_size: "1" monwarnonpoolno_redundancy: "false" bdevflockretry: "20" bluefsbufferedio: "false" mondataavail_warn: "10" "osd.3": bluestorecacheautotune: "false" ``` This structure would be equal to a `ceph.conf` like this: ```console [global] osdmaxscrubs = 5 osdpooldefault_size = 1 monwarnonpoolno_redundancy = false bdevflockretry = 20 bluefsbufferedio = false mondataavail_warn = 10 [osd.3] bluestorecacheautotune = false ``` The operator will use the Ceph config store (that is accessed via `ceph config assimilate-conf`) to apply the config options to the Ceph cluster (just after the MONs have been created and have formed quorum, before anything else is created). The operator won't be unsetting any previously set config options or restore config options to their default value. The operator will ignore a few vital config options, such as `fsid`, `keyring` and `mon_host`.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_statedb_l2-announce.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Show contents of table "l2-announce" ``` cilium-dbg statedb l2-announce [flags] ``` ``` -h, --help help for l2-announce -w, --watch duration Watch for new changes with the given interval (e.g. --watch=100ms) ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Inspect StateDB
Project: Sysbox (Runtime / Container Runtime)
File: README.md

This directory contains tests that verify the functionality of K8s pods deployed with Sysbox. The tests use crictl + CRI-O + Sysbox to create and manage the pods. They do not use K8s itself to create them (as we've not yet implemented support for run K8s inside the test container; we could use K8s.io KinD or Minikube in the future, but not sure if this will work). The test container comes with crictl + CRI-O pre-installed and configured to use Sysbox, so the tests need only issue crictl commands to generate the pods. ch is just KinD with sysbox containers).
Project: Gluster (Runtime / Cloud Native Storage)
File: mem-alloc-list.md

While statedumps provide stats of the number of allocations, size etc for a particular mem type, there is no easy way to examine all the allocated objects of that type in memory.Being able to view this information could help with determining how an object is used, and if there are any memory leaks. The memacctrec structures have been updated to include lists to which the allocated object is added. These can be examined in gdb using simple scripts. `gdb> plist xl->memacct.rec[$type]->objlist` will print out the pointers of all allocations of $type. These changes are primarily targeted at developers and need to enabled at compile-time using `configure --enable-debug`.
Project: WasmEdge Runtime (Runtime / Container Runtime)
File: README.md

platforms;android-31 build-tools;31.0.0 cmake;3.22.1 ndk;23.1.7779620 You could deploy these components via or command line tool. Setup environment variable `ANDROID_HOME=path/to/your/android/sdk` Run Command `./gradlew assembleRelease` Sign your APK file with `apksigner` > apk file location `./app/build/outputs/apk/release` > `apksigner` location `$ANDROID_HOME/build-tools/$VERSION/apksigner` Open this folder with 2020.3.1 or later For Release APK, click `Menu -> Build -> Generate Signed Bundle/APK`, select APK, setup keystore configuration and wait for build finished.
Project: lxd (Runtime / Container Runtime)
File: devices_pci.md

(devices-pci)= ```{note} The `pci` device type is supported for VMs. It does not support hotplugging. ``` PCI devices are used to pass raw PCI devices from the host into a virtual machine. They are mainly intended to be used for specialized single-function PCI cards like sound cards or video capture cards. In theory, you can also use them for more advanced PCI devices like GPUs or network cards, but it's usually more convenient to use the specific device types that Incus provides for these devices ( or ). `pci` devices have the following device options: Key | Type | Default | Required | Description :-- | :-- | :-- | :-- | :-- `address` | string | - | yes | PCI address of the device
Project: JuiceFS (Runtime / Cloud Native Storage)
File: how_to_use_mutate_test.md

Mutation testing (or Mutation analysis or Program mutation) is used to design new software tests and evaluate the quality of existing software tests. Mutation testing involves modifying a program in small ways. Each mutated version is called a mutant and tests detect and reject mutants by causing the behavior of the original version to differ from the mutant. This is called killing the mutant. Test suites are measured by the percentage of mutants that they kill. New tests can be designed to kill additional mutants. there are several kind of mutants: killed mutants: the mutants which is killed by the unit test. which is identified by "tests passed -> FAIL" in the log failed or escaped mutants: the mutants which pass the unit test. which is identified by "tests failed -> PASS" in the log skipped mutants: the mutants may skipped because of 1. out of coverage code. 2. in the black list, 3. skipped by comment. other exception cases. open the github action workflow page. click "run mutate test" step. search "tests passed " keyword, all the "tests passed -> FAIL" mutants are failed. you can try here: https://github.com/juicedata/juicefs/actions/runs/3565436367/jobs/5990603552 open the github action workflow page. click "run mutate test" step. search "tests passed " keyword, all the "tests passed -> FAIL" mutants are failed. find which line is changed by mutation. copy the changed line to .go source file run all the tests in corresponding go test file, all the tests should passed. you should add test case to make the test failed, which kill this mutant. find the checksum from the github action log, like FAIL "/tmp/go-mutesting-1324412688/pkg/chunk/prefetch.go.0" with checksum bb9e9497f17e191adf89b5a2ef6764eb add a line //checksum: bb9e9497f17e191adf89b5a2ef6764eb in the go test file. For example: //checksum 9cb13bb28aa7918edaf4f0f4ca92eea5 //checksum 05debda2840d31bac0ab5c20c5510591 func TestMin(t *testing.T) { assertEqual(t, Min(1, 2), 1) assertEqual(t, Min(-1, -2), -2) assertEqual(t, Min(0, 0), 0) } Add "//skip mutate" to the end of the line you don't want to mutate in the source file. For example: if err != nil { //skip mutate return "", fmt.Errorf("failed to execute command `lsb_release`: %s", err) } if you don't want to run a specific test case, you can add "//skip mutate" after the test case function. For example: func TestRandomWrite(t *testing.T) {//skip mutate ... } if the mutants of the target source file is more than 200, we will use 4 github jobs to run it. otherwise we will use 1 job to run. you can customize it in your test file with adding "//mutatetestjobnumber: number", eg: //mutatetestjobnumber: 8 add //mutate:disable in the *_test.go file to disable the mutate test.
Project: CNI-Genie (Runtime / Cloud Native Network)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: Weave Net (Runtime / Cloud Native Network)
File: systemd.md

title: Using Weave with Systemd menu_order: 40 search_type: Documentation Having installed Weave Net as per , you might find it convenient to configure the init daemon to start Weave on boot. Most recent Linux distribution releases ship with . The information below provides you with some initial guidance on getting a Weave Net service configured on a systemd-based OS. A regular service unit definition for Weave Net is shown below. This file is normally placed in `/etc/systemd/system/weave.service`. [Unit] Description=Weave Network Documentation=http://docs.weave.works/weave/latest_release/ Requires=docker.service After=docker.service [Service] EnvironmentFile=-/etc/sysconfig/weave ExecStartPre=/usr/local/bin/weave launch --no-restart $PEERS ExecStart=/usr/bin/docker attach weave ExecStop=/usr/local/bin/weave stop [Install] WantedBy=multi-user.target To specify the addresses or names of other Weave hosts to join the network, create the `/etc/sysconfig/weave` environment file using the following format: PEERS="HOST1 HOST2 .. HOSTn" You can also use the command to add participating hosts dynamically. Additionally, if you want to enable specify a password using `WEAVE_PASSWORD="wfvAwt7sj"` in the `/etc/sysconfig/weave` environment file, and it will get picked up by Weave Net on launch. Recommendations for choosing a suitably strong password can be found . You can now launch Weave Net using sudo systemctl start weave To ensure Weave Net launches after reboot, run: sudo systemctl enable weave For more information on systemd, please refer to the documentation supplied with your distribution of Linux. If your OS has SELinux enabled and you want to run Weave Net as a systemd unit, then follow the instructions below. These instructions apply to CentOS and RHEL as of 7.0. On Fedora 21, there is no need to do this. Once `weave` is installed in `/usr/local/bin`, set its execution context with the commands shown below. You will need to have the `policycoreutils-python` package installed. sudo semanage fcontext -a -t unconfinedexect -f f /usr/local/bin/weave sudo restorecon /usr/local/bin/weave See Also * *
Project: Kanister (Runtime / Cloud Native Storage)
File: MAINTAINERS.md

This document provides information on who the Kanister maintainers are, and their responsibilities. If you're interested in contributing, see the guide. These are the current Kanister maintainers: Tom Manville @tdmanv Pavan Navarathna @pavannd1 Prasad Ghangal @PrasadG193 Vivek Singh @viveksinghggits Daniil Fedotov @hairyhum Eugen Sumin @e-sumin Maintainers are active and visible members of the community. They have a lot of experience with the project and are expected to have the knowledge and insight to lead its growth and improvement. This section describes their responsibilities. Uphold the values and behavior set forward by the to ensure a safe and welcoming community. Prioritize reported security vulnerabilities and ensure that they are addressed before features or bugs. See the project's . Review pull requests regularly with comments, suggestions, decision to reject, merge or close them. Accept only high quality pull requests. Provide code reviews and guidance on incoming pull requests to adhere to established standards, best practices and guidelines. Review issues regularly to determine their priority and relevance, with proper labeling to identify milestones, blockers, complexity, entry-level issues etc. Respond to Slack messages, enhancement requests, and forum posts. Allocate time to reviewing and commenting on issues and conversations as they come in. Maintain healthy test coverage and code quality report score. Avoid dependency bloat. Mitigate breaking changes. Make frequent project releases to the community. Keep the release branch at production quality at all times. Backport features as needed. Cut release branches and tags to enable future patches. Regularly promote and attend the recurring Kanister community meetings.
Project: Longhorn (Runtime / Cloud Native Storage)
File: CHANGELOG-1.5.1.md

Longhorn v1.5.1 is the latest version of Longhorn 1.5. This release introduces bug fixes as described below about 1.5.0 upgrade issues, stability, troubleshooting and so on. Please try it and 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.1. Longhorn supports 3 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.1 from v1.4.x/v1.5.0, which are only supported source versions. Follow the upgrade instructions . N/A Please follow up on about any outstanding issues found after this release. ) - @PhanLe1010 ) - @derekbit @c3y1huang @roger-ryao ) - @derekbit @roger-ryao ) - @yangchiu @PhanLe1010 @ejweber ) - @yangchiu @ejweber ) - @derekbit @roger-ryao ) - @c3y1huang @chriscchien ) - @ChanYiLin @roger-ryao ) - @ChanYiLin @chriscchien ) - @yangchiu @derekbit ) - @derekbit @chriscchien ) - @ChanYiLin @chriscchien ) - @ChanYiLin @chriscchien @ChanYiLin @PhanLe1010 @c3y1huang @chriscchien @derekbit @ejweber @innobead @roger-ryao @yangchiu