cwielenb/CNCF-Dataset huggingface dataset:
Project: Longhorn (Runtime / Cloud Native Storage)
File: 20230601-forcibly-activate-a-restoring-dr-volume.md

When users try to activate a restoring/DR volume with some replicas failed for some reasons, the volume will be stuck in attaching state and users can not do anything except deleting the volume. However the volume still can be rebuilt back to be normal as long as there is a healthy replica. To improve user experience, Longhorn should forcibly activate a restoring/DR volume if there is a healthy replica and users allow the creation of a degraded volume. https://github.com/longhorn/longhorn/issues/1512 Allow users to activate a restoring/DR volume as long as there is a healthy replica and the volume works well. `None` Forcibly activate a restoring/DR volume if there is a healthy replica and users enable the global setting `allow-volume-creation-with-degraded-availability`. Users can activate a restoring/DR volume by the CLI `kubectl` or Longhorn UI and the volume could work well. Set up two Kubernetes clusters. These will be called cluster A and cluster B. Install Longhorn on both clusters, and set the same backup target on both clusters. In the cluster A, make sure the original volume X has a backup created or has recurring backups scheduled. In backup page of cluster B, choose the backup volume X, then create disaster recovery volume Y. User set `volume.spec.Standby` to `false` by editing the volume CR or the manifest creating the volume to activate the volume. UI has click `Activate Disaster Recovery Volume` button in `Volume` or `Volume Details` pages to activate the volume. `None` Check if `volume.Spec.Standby` is set to `false` Get the global setting `allow-volume-creation-with-degraded-availability` Activate the DR volume if `allow-volume-creation-with-degraded-availability` is set to `true` and there are one or more ready replicas. Create a DR volume Set the global setting `concurrent-replica-rebuild-per-node-limit` to be 0 Failed some replicas Check if there is at least one healthy replica Call the API `activate` The volume could be activated Attach the volume to a node and check if data is correct `None` `None`
Project: K8up (Runtime / Cloud Native Storage)
File: OWNERS.md

This page lists all active members of the steering committee, as well as maintainers and reviewers for this repository. Each repository in the will list their repository maintainers and reviewers in their own `OWNERS.md` file. Please see for governance guidelines and responsibilities for the steering committee, maintainers, and reviewers. See for automatic PR assignment. This will be built up when time comes. Tobias Brunner <tobias.brunner@vshn.ch> () Simon Beck <simon.beck@vshn.ch> () Nicolas Bigler <nicolas.bigler@vshn.ch> () ukasz Widera <lukasz.widera@vshn.ch> () Gabriel Saratura <gabriel.saratura@vshn.ch> () We also document the list of maintainers in the . We currently do not have nominated reviewers, we'll build them up when time comes. As of today, we don't have any emeritus maintainers yet.
Project: DatenLord (Runtime / Cloud Native Storage)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: enhancement assignees: '' Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: SmartOS (Runtime / Container Runtime)
File: sdc-factoryreset.1.md

`sdc-factoryreset [-h | --help]` This command resets a machine to its originally installed state. Specifically, it reboots the machine, imports all ZFS pools, and destroys them individually. It does this by setting a ZFS user property on the system pool. If this command is invoked unintentionally, an administrator can prevent the system from resetting itself by booting in rescue mode (noimport=true as a GRUB boot option) and clearing the smartdc:factoryreset property from the var dataset. If the system is booting without the noimport=true GRUB option, the only way to stop the pending factory reset is to power cycle the machine, and boot again into rescue mode. The service which does the actual factory reset starts well before an administrator would be able to login to the box, even if that administrator has console access. `-h` Show the help and usage mesage sdc-factoryreset Copyright (c) 2014, Joyent, Inc.
Project: Rook (Runtime / Cloud Native Storage)
File: PULL_REQUEST_TEMPLATE.md

<!-- Thank you for contributing to Rook! --> <!-- STEPS TO FOLLOW: Add a description of the changes (frequently the same as the commit description) Enter the issue number next to "Resolves #" below (if there is no tracking issue resolved, remove that section) Review our Contributing documentation at https://rook.io/docs/rook/latest/Contributing/development-flow/ Follow the steps in the checklist below, starting with the Commit Message Formatting. --> <!-- Uncomment this section with the issue number if an issue is being resolved Issue resolved by this Pull Request: Resolves # > Checklist: . updated with breaking and/or notable changes for the next minor release. [ ] Documentation has been updated, if necessary. [ ] Unit tests have been added, if necessary. [ ] Integration tests have been added, if necessary.
Project: Spiderpool (Runtime / Cloud Native Network)
File: plugin-ipam.md

Here is an example of IPAM configuration. ```json { "cniVersion":"0.3.1", "name":"macvlan-pod-network", "plugins":[ { "name":"macvlan-pod-network", "type":"macvlan", "master":"ens256", "mode":"bridge", "mtu":1500, "ipam":{ "type":"spiderpool", "logfilepath":"/var/log/spidernet/spiderpool.log", "logfilemax_size":"100", "logfilemax_age":"30", "logfilemax_count":7, "log_level":"INFO", "defaultipv4ippool": ["default-ipv4-pool1","default-ipv4-pool2"], "defaultipv6ippool": ["default-ipv6-pool1","default-ipv6-pool2"] } } ] } ``` `logfilepath` (string, optional): Path to log file of IPAM plugin, default to `"/var/log/spidernet/spiderpool.log"`. `logfilemax_size` (string, optional): Max size of each rotated file, default to `"100"`(unit MByte). `logfilemax_age` (string, optional): Max age of each rotated file, default to `"30"`(unit Day). `logfilemax_count` (string, optional): Max number of rotated file, default to `"7"`. `log_level` (string, optional): Log level, default to `"INFO"`. It could be `"INFO"`, `"DEBUG"`, `"WARN"`, `"ERROR"`. `defaultipv4ippool` (string array, optional): Default IPAM IPv4 Pool to use. `defaultipv6ippool` (string array, optional): Default IPAM IPv6 Pool to use.
Project: K8up (Runtime / Cloud Native Storage)
File: ADOPTERS.md

This list captures the set of organizations that are using K8up within their environments. If you are an adopter of K8up and not yet on this list, we encourage you to add your organization here as well! The goal for this list is to be the complete and authoritative source for the entire community of K8up adopters, and give inspiration to others that are earlier in their K8up journey. Contributing to this list is a small effort that has a big impact to the project's growth, maturity, and momentum. Thank you to all adopters and contributors of the K8up project! To add your organization to this list, to directly update this list, or directly in GitHub. This list is sorted in the order that organizations were added to it. | Organization | Contact | Description of Use | | -- | - | - | | | | K8up was born at VSHN because at that time there was no other mature enough backup operator around. Today, K8up is integral part of the service offering and protects precious data every day. | | | | We use K8up as an integral part of our Disaster Recovery procedures. | | | | We've adopted K8up within . This keeps the data of all Lagoon customers safe and restorable. | | | | We use K8up as Backup Operator in our Kubernetes Management product.|
Project: gVisor (Runtime / Container Runtime)
File: style.md

These guidelines are new and may change. This note will be removed when consensus is reached. Not all existing code will comply with this style guide, but new code should. Further, it is a goal to eventually update all existing code to be in compliance. All code, unless it substantially increases the line count or complexity, should use early exits from loops and functions where possible. All Go code should comply with the and guides, as well as the additional guidelines described below. Mutexes should be named mu or xxxMu. Mutexes as a general rule should not be exported. Instead, export methods which use the mutexes to avoid leaky abstractions. Mutexes should be sibling fields to the fields that they protect. Mutexes should not be declared as global variables, instead use a struct (anonymous ok, but naming conventions still apply). Mutexes should be ordered before the fields that they protect. Mutexes should have a comment on their declaration explaining any ordering requirements (or pointing to where this information can be found), if applicable. There is no need for a comment explaining which fields are protected. Each field or variable protected by a mutex should state as such in a comment on the field or variable declaration. Functions with special entry conditions (e.g., a lock must be held) should state these conditions in a `Preconditions:` comment block. One condition per line; multiple conditions are specified with a bullet (`*`). Functions with notable exit conditions (e.g., a `Done` function must eventually be called by the caller) can similarly have a `Postconditions:` block. Unused returns should be explicitly ignored with underscores. If there is a function which is commonly used without using its return(s), a wrapper function should be declared which explicitly ignores the returns. That said, in many cases, it may make sense for the wrapper to check the returns. Built-in types should use their associated verbs (e.g. %d for integral types), but other types should use a %v variant, even if they implement fmt.Stringer. The built-in `error` type should use %w when formatted with `fmt.Errorf`, but only then. Comments should be wrapped at 80 columns with a 2 space tab size. Code does not need to be wrapped, but if wrapping would make it more readable, it should be wrapped with each subcomponent of the thing being wrapped on its own line. For example, if a struct is split between lines, each field should be on its own line. ```go _ = exec.Cmd{ Path: "/foo/bar", Args: []string{"-baz"}, } ``` C++ code should conform to the and the guidelines described for tests.
Project: Zenko (Runtime / Cloud Native Storage)
File: CONTRIBUTING.md

This document contains and defines the rules that have to be followed by any contributor to the Zenko CTST test suite. CTST pulls from the repo to provide APIs for AWS Standards, usable in the 'Steps' of the test framework. Beyond usual Cucumber.js practice of using worlds, steps and features, this test suite has some specifics to consider: The tests must be idempotent: they must not conflict with each other, here by using random bucket/object names. It should be possible to rerun the tests after the end of the CTST test suite: tests should not be dependant on environment.
Project: CRI-O (Runtime / Container Runtime)
File: PULL_REQUEST_TEMPLATE.md

<!-- Thanks for sending a pull request! Please be aware that we're following the Kubernetes guidelines of contributing to this project. This means that we have to use this mandatory template for all of our pull requests. Please also make sure you've read and understood our contributing guidelines (https://github.com/cri-o/cri-o/blob/main/CONTRIBUTING.md) as well as ensuring that all your commits are signed with `git commit -s`. Here are some additional tips for you: If this is your first time, please read our contributor guidelines: https://git.k8s.io/community/contributors/guide#your-first-contribution and developer guide https://git.k8s.io/community/contributors/devel/development.md#development-guide Please label this pull request according to what type of issue you are addressing, especially if this is a release targeted pull request. For reference on required PR/issue labels, read here: https://git.k8s.io/community/contributors/devel/sig-release/release.md#issuepr-kind-label If you want faster PR reviews, read how: https://git.k8s.io/community/contributors/guide/pull-requests.md#best-practices-for-faster-reviews If the PR is unfinished, see how to mark it: https://git.k8s.io/community/contributors/guide/pull-requests.md#marking-unfinished-pull-requests --> <!-- Uncomment only one `/kind <>` line, hit enter to put that in a new line, and remove leading whitespace from that line: --> <!-- /kind api-change /kind bug /kind ci /kind cleanup /kind dependency-change /kind deprecation /kind design /kind documentation /kind failing-test /kind feature /kind flake /kind other --> <!-- Automatically closes linked issue when PR is merged. Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. --> <!-- Fixes # or None --> <!-- If no, just write `None` in the release-note block below. If yes, a release note is required: Enter your extended release note in the block below. If the PR requires additional action from users switching to the new release, include the string "action required". For more information on release notes see: https://git.k8s.io/community/contributors/guide/release-notes.md --> ```release-note ```
Project: iSulad (Runtime / Container Runtime)
File: build_guide_with_docker_image.md

This guide is mainly about how to use the image to quickly build the development environment of iSulad. Reduce the cost of environmental preparation. Take the docker image of openEuler-21.03 as an example. First download the image from the official website: `wget https://repo.openeuler.org/openEuler-21.03/dockerimg/x8664/openEuler-docker.x86_64.tar.xz` Prepare to build the base image with the provided by the docs ```bash $ mkdir -p ./build-home $ cp docs/dockerfiles/isuladbuildin_openeuler.Dockerfile ./build-home $ pushd build-home $ docker build -t isuladbuild:v1 -f isuladbuildinopeneuler.Dockerfile . $ popd ``` ```bash $ docker run -itd -v /root/tmp/:/var/lib/isulad -v /sys/fs/cgroup/:/sys/fs/cgroup -v /lib/modules:/lib/modules --tmpfs /tmp:exec,mode=777 --tmpfs /run:exe c,mode=777 --privileged isulad_build:v1 sh ``` Note A host directory must be mounted to the container for isulad's working directory; Requires privileged permission; Must be linked to the modules directory; ```bash git clone https://gitee.com/src-openeuler/lxc.git pushd lxc rm -rf lxc-4.0.3 ./apply-patches || exit 1 pushd lxc-4.0.3 ./autogen.sh && ./configure || exit 1 make -j $(nproc) || exit 1 make install popd popd ``` ```bash ldconfig git clone https://gitee.com/openeuler/lcr.git pushd lcr rm -rf build mkdir build pushd build cmake -DDEBUG=ON -DCMAKESKIPRPATH=TRUE ../ || exit 1 make -j $(nproc) || exit 1 make install popd popd ``` ```bash ldconfig git clone https://gitee.com/openeuler/clibcni.git pushd clibcni rm -rf build mkdir build pushd build cmake -DDEBUG=ON ../ || exit 1 make -j $(nproc) || exit 1 make install popd popd ``` ```bash mkdir -p ~/.cargo touch ~/.cargo/config echo "[source.crates-io]" >> ~/.cargo/config echo "[source.local-registry]" >> ~/.cargo/config echo "directory = \"vendor\"" >> ~/.cargo/config ldconfig rm -rf lib-shim-v2 git clone https://gitee.com/src-openeuler/lib-shim-v2.git pushd lib-shim-v2 tar -zxf lib-shim-v2-0.0.1.tar.gz pushd lib-shim-v2-0.0.1 make lib || exit 1 make install popd popd ``` ```bash ldconfig rm -rf iSulad git clone https://gitee.com/openeuler/iSulad.git pushd iSulad rm -rf build mkdir build pushd build cmake -DDEBUG=ON -DENABLEUT=ON -DENABLESHIM_V2=ON ../ || exit 1 make -j $(nproc) || exit 1 make install ctest -V || exit 1 popd popd ```
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_identity.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage security identities ``` -h, --help help for identity ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI - Retrieve information about an identity - List identities
Project: Spiderpool (Runtime / Cloud Native Network)
File: MAINTAINERS.md

See the to learn how to level up through the project. Please see the file for the full list of contributors to the project | Maintainer | Emplolyer | ||| | | Daocloud | | | Daocloud | | | Daocloud | | | Daocloud | | | Daocloud | | | Daocloud | | | Computer Power team |
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_prefilter_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List CIDR filters ``` cilium-dbg prefilter list [flags] ``` ``` -h, --help help for list -o, --output string json| yaml| jsonpath='{}' ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage XDP CIDR filters
Project: Velero (Runtime / Cloud Native Storage)
File: ark_describe_restores.md

title: "ark describe restores" layout: docs Describe restores Describe restores ``` ark describe restores [NAME1] [NAME2] [NAME...] [flags] ``` ``` -h, --help help for restores -l, --selector string only show items matching this label selector --volume-details display details of restic volume restores ``` ``` --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 ``` - Describe ark resources
Project: Longhorn (Runtime / Cloud Native Storage)
File: PULL_REQUEST_TEMPLATE.md

<!-- Use `Issue #<issue number>` or `Issue longhorn/longhorn#<issue number>` or `Issue (paste link of issue)`. DON'T use `Fixes #<issue number>` or `Fixes (paste link of issue)`, as it will automatically close the linked issue when the PR is merged. --> Issue #
Project: Kanister (Runtime / Cloud Native Storage)
File: SECURITY.md

Current known vulnerabilities are listed in the section for the repo. You can report a new vulnerability using tool. Alternatively you can report it via kanisterio google group "Contact owners and managers" button: https://groups.google.com/g/kanisterio/about The maintainers will help diagnose the severity of the issue and determine how to address the issue. Issues deemed to be non-critical will be filed as GitHub issues. Critical issues will receive immediate attention and be fixed as quickly as possible. The maintainers will then coordinate a release date with you. When serious security problems in Kanister are discovered and corrected, the maintainers issue a security advisory, describing the problem and containing a pointer to the fix. These will be announced on the Kanister's mailing list and websites and be visible in . Security issues are fixed as soon as possible, and the fixes are propagated to the stable branches as fast as possible. However, when a vulnerability is found during a code audit, or when several other issues are likely to be spotted and fixed in the near future, the maintainers may delay the release of a Security Advisory, so that one unique, comprehensive Security Advisory covering several vulnerabilities can be issued. Communication with vendors and other distributions shipping the same code may also cause these delays.
Project: HwameiStor (Runtime / Cloud Native Storage)
File: CONDUCT.md

Cobra will follow a steady release cadence. Non breaking changes will be released as minor versions quarterly. Patch bug releases are at the discretion of the maintainers. Users can expect security patch fixes to be released within relatively short order of a CVE becoming known. For more information on security patch fixes see the CVE section below. Releases will follow . Users tracking the Master branch should expect unpredictable breaking changes as the project continues to move forward. For stability, it is highly recommended to use a release. We will maintain two major releases in a moving window. The N-1 release will only receive bug fixes and security updates and will be dropped once N+1 is released. Deprecation of Go versions or dependent packages will only occur in major releases. To reduce the change of this taking users by surprise, any large deprecation will be preceded by an announcement in the and an Issue on Github. Maintainers will make every effort to release security patches in the case of a medium to high severity CVE directly impacting the library. The speed in which these patches reach a release is up to the discretion of the maintainers. A low severity CVE may be a lower priority than a high severity one. Cobra maintainers will use GitHub issues and the as the primary means of communication with the community. This is to foster open communication with all users and contributors. Breaking changes are generally allowed in the master branch, as this is the branch used to develop the next release of Cobra. There may be times, however, when master is closed for breaking changes. This is likely to happen as we near the release of a new version. Breaking changes are not allowed in release branches, as these represent minor versions that have already been released. These version have consumers who expect the APIs, behaviors, etc, to remain stable during the lifetime of the patch stream for the minor release. Examples of breaking changes include: Removing or renaming exported constant, variable, type, or function. Updating the version of critical libraries such as `spf13/pflag`, `spf13/viper` etc... Some version updates may be acceptable for picking up bug fixes, but maintainers must exercise caution when reviewing. There may, at times, need to be exceptions where breaking changes are allowed in release branches. These are at the discretion of the project's maintainers, and must be carefully considered before merging. Maintainers will ensure the Cobra test suite utilizes the current supported versions of Golang. Changes to this document and the contents therein are at the discretion of the maintainers. None of the contents of this document are legally binding in any way to the maintainers or the users.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-aws_completion_zsh.md

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> Generate the autocompletion script for zsh Generate the autocompletion script for the zsh shell. If shell completion is not already enabled in your environment you will need to enable it. You can execute the following once: echo "autoload -U compinit; compinit" >> ~/.zshrc To load completions in your current shell session: source <(cilium-operator-aws completion zsh) To load completions for every new session, execute once: cilium-operator-aws completion zsh > "${fpath[1]}/_cilium-operator-aws" cilium-operator-aws completion zsh > $(brew --prefix)/share/zsh/site-functions/_cilium-operator-aws You will need to start a new shell for this setup to take effect. ``` cilium-operator-aws completion zsh [flags] ``` ``` -h, --help help for zsh --no-descriptions disable completion descriptions ``` - Generate the autocompletion script for the specified shell