cwielenb/CNCF-Dataset huggingface dataset:
Project: Stash by AppsCode (Runtime / Cloud Native Storage)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at i@dario.im. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at
Project: Inclavare Containers (Runtime / Container Runtime)
File: terminology.md

Essentially, it is init process inside container. In runc, init process eventually executes the entrypoint of container defined in config.json. In rune, init process never call execve() syscall. Instead, it serves for the communications between Enclave Runtime PAL and the host side through Enclave Runtime PAL API. init-runelet is created by `rune create`, and runelet process on behalf of enclave application is created by `rune exec`. This API defines the function calls between Enclave Runtime PAL and init-runelet. The implementer of Enclave Runtime PAL API, on behalf of Enclave Runtime. The implementer of enclave. Occlum, Graphene-SGX and WAMR (WebAssembly Micro Runtime) are all the so-called Enclave Runtime. The actual running entity inside Enclave Runtime. A new class of container managed by OCI Runtime `rune`.
Project: Longhorn (Runtime / Cloud Native Storage)
File: improvement.md

name: Improvement request about: Suggest an improvement of an existing feature title: "[IMPROVEMENT] " labels: ["kind/improvement", "require/doc", "require/manual-test-plan", "require/backport"] assignees: '' <!--A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]--> <!--A clear and concise description of what you want to happen.--> <!--A clear and concise description of any alternative solutions or features you've considered.--> <!--Add any other context or screenshots about the feature request here.-->
Project: Velero (Runtime / Cloud Native Storage)
File: pv-cloning.md

Status: Approved Velero supports restoring resources into different namespaces than they were backed up from. This enables a user to, among other things, clone a namespace within a cluster. However, if the namespace being cloned uses persistent volume claims, Velero cannot currently create a second copy of the original persistent volume when restoring. This limitation is documented in detail in . This document proposes a solution that allows new copies of persistent volumes to be created during a namespace clone. Enable persistent volumes to be cloned when using `velero restore create --namespace-mappings ...` to create a second copy of a namespace within a cluster. Cloning of persistent volumes in any scenario other than when using `velero restore create --namespace-mappings ...` flag. . (Omitted, see introduction) During a restore, Velero will detect that it needs to assign a new name to a persistent volume being restored if and only if both of the following conditions are met: the persistent volume is claimed by a persistent volume claim in a namespace that's being remapped using `velero restore create --namespace-mappings ...` a persistent volume already exists in the cluster with the original name If these conditions exist, Velero will give the persistent volume a new arbitrary name before restoring it. It will also update the `spec.volumeName` of the related persistent volume claim. In `pkg/restore/restore.go`, around , Velero has special-case code for persistent volumes. This code will be updated to check for the two preconditions described in the previous section. If the preconditions are met, the object will be given a new name. The persistent volume will also be annotated with the original name, e.g. `velero.io/original-pv-name=NAME`. Importantly, the name change will occur before , where Velero checks to see if it should restore the persistent volume. Additionally, the old and new persistent volume names will be recorded in a new field that will be added to the `context` struct, `renamedPVs map[string]string`. In the special-case code for persistent volume claims starting on , Velero will check to see if the claimed persistent volume has been renamed by looking in `ctx.renamedPVs`. If so, Velero will update the persistent volume claim's `spec.volumeName` to the new name. One alternative approach is to add a new CLI flag and API field for restores, e.g. `--clone-pvs`, that a user could provide to indicate they want to create copies of persistent volumes. This approach would work fine, but it does require the user to be aware of this flag/field and to properly specify it when needed. It seems like a better UX to detect the typical conditions where this behavior is needed, and to automatically apply it. Additionally, the design proposed here does not preclude such a flag/field from being added later, if it becomes necessary to cover other use cases. N/A
Project: Rook (Runtime / Cloud Native Storage)
File: ceph-toolbox.md

title: Toolbox The Rook toolbox is a container with common tools used for rook debugging and testing. The toolbox is based on CentOS, so more tools of your choosing can be easily installed with `yum`. The toolbox can be run in two modes: : Start a toolbox pod where you can connect and execute Ceph commands from a shell : Run a script with Ceph commands and collect the results from the job log !!! hint Before running the toolbox you should have a running Rook cluster deployed (see the ). !!! note The toolbox is not necessary if you are using to execute Ceph commands. The rook toolbox can run as a deployment in a Kubernetes cluster where you can connect and run arbitrary Ceph commands. Launch the rook-ceph-tools pod: ```console kubectl create -f deploy/examples/toolbox.yaml ``` Wait for the toolbox pod to download its container and get to the `running` state: ```console kubectl -n rook-ceph rollout status deploy/rook-ceph-tools ``` Once the rook-ceph-tools pod is running, you can connect to it with: ```console kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash ``` All available tools in the toolbox are ready for your troubleshooting needs. Example: `ceph status` `ceph osd status` `ceph df` `rados df` When you are done with the toolbox, you can remove the deployment: ```console kubectl -n rook-ceph delete deploy/rook-ceph-tools ``` If you want to run Ceph commands as a one-time operation and collect the results later from the logs, you can run a script as a Kubernetes Job. The toolbox job will run a script that is embedded in the job spec. The script has the full flexibility of a bash script. In this example, the `ceph status` command is executed when the job is created. Create the toolbox job: ```console kubectl create -f deploy/examples/toolbox-job.yaml ``` After the job completes, see the results of the script: ```console kubectl -n rook-ceph logs -l job-name=rook-ceph-toolbox-job ```
Project: WasmEdge Runtime (Runtime / Container Runtime)
File: CODE_OF_CONDUCT.md

As a CNCF project, WasmEdge follows the . In addition to this code of conduct, we have also implemented guidelines for the use of other developers' open-source work in your code. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the WasmEdge team via <WasmEdge@googlegroups.com>. 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 are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality. Examples of unacceptable behavior by participants include: The use of sexualized language or imagery Personal attacks Trolling or insulting/derogatory comments Public or private harassment Publishing others' private information, such as physical or electronic addresses, without explicit permission Other unethical or unprofessional conduct. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team. This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. In addition to the CNCF code of conduct, we would like to introduce a new code of conduct that demonstrates respect for open-source contributors. If you plan to use other developers' open-source work in your code, please make sure that the license of the original repository allows this. For instance, the Apache 2.0 license allows for free use of the code, provided that authors receive proper credit for their contributions. In order to appropriately recognize and acknowledge others' work, we kindly request that you add the following messages before you raise a PR or show your work in public: At the top of any files you use, please include: "This file is licensed under Apache 2.0 and was originally developed by [the author name]." Include a statement in the README like "This work was made possible by [the author name]." See a best practice .
Project: Soda Foundation (Runtime / Cloud Native Storage)
File: ceph_driver.md

.. This work is licensed under a Creative Commons Attribution 4.0 International License. .. http://creativecommons.org/licenses/by/4.0 http://creativecommons.org/licenses/by/3.0/legalcode ====================================== OpenSDS SourthBound Ceph Driver Design ====================================== Problem description =================== As a SDS controller, it's essential for OpenSDS to build its eco-system of sourthbound interface. At the first stage, our strategy is to quickly make up for our lack with the help of OpenStack(Cinder, Manila). Now it's time to move to next stage where we should build our own eco-system competitive. After a careful consideration, we plan to select Ceph as the first OpenSDS native sourthbound backend driver. The reasons are as follows: 1) Ceph is one of the most popular distributed storage systems in the world and it holds a large number of users. 2) Ceph has a good performance in IO stream and data high availability. 3) It's open-source and has a large number of active contributors. This proposal is launched mainly for the design of OpenSDS sourthbound Ceph driver. With this standalone driver, OpenSDS can directly manage resources in Ceph cluster and provide these storage resources for bare metals, VMs and containers. Proposed Change =============== Since OpenSDS repo has OpenSDS-plugins, Controller and Dock these three parts, most of the work will be done in Dock module. we found that Ceph maintains an official project "go-ceph", and we can manage resources of Ceph(pools, images and so on) in Golang.The main jobs are as follows: 1) We need to implement CreateVolume, GetVolume, ListVolumes, DeleteVolume, AttachVolume, DetachVolume, MountVolume and UnmountVolume in Ceph driver. Here is the standardized interface: type VolumeDriver interface { //Any initialization the volume driver does while starting. Setup() //Any operation the volume driver does while stoping. Unset() CreateVolume(name string, volType string, size int32) (string, error) GetVolume(volID string) (string, error) GetAllVolumes(allowDetails bool) (string, error) DeleteVolume(volID string) (string, error) AttachVolume(volID string) (string, error) DetachVolume(device string) (string, error) MountVolume(mountDir, device, fsType string) (string, error) UnmountVolume(mountDir string) (string, error) } 2) From step 1 we can find that the return value is string type, which does not seem to be a standardized description. And at the second step, what we are going to do is that we will leverage Ceph and Cinder and design a new unified sourthbound interface. 3) After those two steps, we will start to draft the V0.01 Spec of OpenSDS sourthbound interface. Data model impact -- Add ceph_driver element in Backends description. REST API impact None Security impact None Other end user impact None Performance impact None Other deployer impact None Dependencies ============ None Testing ======= None Documentation Impact ==================== None References ========== https://github.com/noahdesu/go-ceph
Project: Cilium (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: runc (Runtime / Container Runtime)
File: runc-list.8.md

% runc-list "8" runc-list - lists containers runc list [option ...] The list commands lists containers. Note that a global --root option can be specified to change the default root. For the description of --root, see runc(8). --format|-f table|json : Specify the format. Default is table. The json format provides more details. --quiet|-q : Only display container IDs. To list containers created with the default root: To list containers in a human-readable JSON (with the help of jq(1) utility): To list containers created with the root of /tmp/myroot: runc(8).
Project: Cilium (Runtime / Cloud Native Network)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at oss-conduct@uber.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at .
Project: rkt (Runtime / Container Runtime)
File: getting-started-guide.md

The following guide will show you how to build and run a self-contained Go app using rkt, the reference implementation of the . If you're not on Linux, you should do all of this inside . For a more complex example, please check the . ```go package main import ( "log" "net/http" ) func main() { http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { log.Printf("request from %v\n", r.RemoteAddr) w.Write([]byte("hello\n")) }) log.Fatal(http.ListenAndServe(":5000", nil)) } ``` Next we need to build our application. We are going to statically link our app so we can ship an App Container Image with no external dependencies. With Go 1.9: ``` $ CGO_ENABLED=0 go build -ldflags '-extldflags "-static"' ``` Note that if you use , the command is instead: ``` $ go build -compiler gccgo -gccgoflags '-static' ``` Before proceeding, verify that the produced binary is statically linked: ``` $ file hello hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped $ ldd hello not a dynamic executable ``` To create the image, we can use , which can be downloaded via one of the . The following commands will create an ACI containing our application and important metadata. ```bash acbuild begin acbuild set-name example.com/hello acbuild copy hello /bin/hello acbuild set-exec /bin/hello acbuild port add www tcp 5000 acbuild label add version 0.0.1 acbuild label add arch amd64 acbuild label add os linux acbuild annotation add authors "Carly Container <carly@example.com>" acbuild write hello-0.0.1-linux-amd64.aci acbuild end ``` ``` ``` Note that `--insecure-options=image` is required because, by default, rkt expects our images to be signed. See the for more details. At this point our hello app is running and ready to handle HTTP requests. To stop the container, pass three escape characters (`^]^]^]`), which is generated by `Ctrl-]` on a US keyboard. You can also . By default, rkt will assign the running container an IP address. Use `rkt list` to discover what it is: ``` UUID APP IMAGE NAME STATE NETWORKS 885876b0 hello example.com/hello:0.0.1 running default:ip4=172.16.28.2 ``` Then you can `curl` that IP on port 5000: ``` $ curl 172.16.28.2:5000 hello ```