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

A coroutines-based, cooperative multi-tasking framework. Glossary Lifecycle of a synctask Existing usage syncenv is an object that provides access to a pool of worker threads. synctasks execute in a syncenv. synctask can be informally defined as a pair of function pointers, namely _the call and the callback_ (see syncop.h for more details). synctaskfnt - 'the call' synctaskcbkt - 'the callback' synctask has two modes of operation, The calling thread waits for the synctask to complete. The calling thread schedules the synctask and continues. synctask guarantees that the callback is called after the call completes. A synctask could go into the following stages while in execution. CREATED - On calling synctaskcreate/synctasknew. RUNNABLE - synctask is queued in env->runq. RUNNING - When one of syncenv's worker threads calls synctaskswitchto. WAITING - When a synctask calls synctask_yield. DONE - When a synctask has run to completion. +-+ | CREATED | +-+ | | synctasknew/synctaskcreate v +-+ | RUNNABLE (in env->runq) | <+ +-+ | | | | synctaskswitchto | v | ++ on task completion +-+ | | DONE | <-- | RUNNING | | synctask_wake/wake ++ +-+ | | | | synctask_yield/yield | v | +-+ | | WAITING (in env->waitq) | -+ +-+ Note: A synctask is not guaranteed to run on the same thread throughout its lifetime. Every time a synctask yields, it is possible for it to run on a different thread.
Project: Kata Containers (Runtime / Container Runtime)
File: PciDeviceInfo.md

Name | Type | Description | Notes | - | - | - Id | string | | Bdf | string | | `func NewPciDeviceInfo(id string, bdf string, ) *PciDeviceInfo` NewPciDeviceInfo instantiates a new PciDeviceInfo object This constructor will assign default values to properties that have it defined, and makes sure properties required by API are set, but the set of arguments will change when the set of required properties is changed `func NewPciDeviceInfoWithDefaults() *PciDeviceInfo` NewPciDeviceInfoWithDefaults instantiates a new PciDeviceInfo object This constructor will only assign default values to properties that have it defined, but it doesn't guarantee that properties required by API are set `func (o *PciDeviceInfo) GetId() string` GetId returns the Id field if non-nil, zero value otherwise. `func (o PciDeviceInfo) GetIdOk() (string, bool)` GetIdOk returns a tuple with the Id field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *PciDeviceInfo) SetId(v string)` SetId sets Id field to given value. `func (o *PciDeviceInfo) GetBdf() string` GetBdf returns the Bdf field if non-nil, zero value otherwise. `func (o PciDeviceInfo) GetBdfOk() (string, bool)` GetBdfOk returns a tuple with the Bdf field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *PciDeviceInfo) SetBdf(v string)` SetBdf sets Bdf field to given value.
Project: Multus (Runtime / Cloud Native Network)
File: README.md

](https://travis-ci.org/kubernetes-sigs/yaml) kubernetes-sigs/yaml is a permanent fork of . A wrapper around designed to enable a better way of handling YAML when marshaling to and from structs. In short, this library first converts YAML to JSON using go-yaml and then uses `json.Marshal` and `json.Unmarshal` to convert to or from the struct. This means that it effectively reuses the JSON struct tags as well as the custom JSON methods `MarshalJSON` and `UnmarshalJSON` unlike go-yaml. For a detailed overview of the rationale behind this method, . This package uses and therefore supports . Caveat #1: When using `yaml.Marshal` and `yaml.Unmarshal`, binary data should NOT be preceded with the `!!binary` YAML tag. If you do, go-yaml will convert the binary data from base64 to native binary data, which is not compatible with JSON. You can still use binary in your YAML files though - just store them without the `!!binary` tag and decode the base64 in your code (e.g. in the custom JSON methods `MarshalJSON` and `UnmarshalJSON`). This also has the benefit that your YAML and your JSON binary data will be decoded exactly the same way. As an example: ``` BAD: exampleKey: !!binary gIGC GOOD: exampleKey: gIGC ... and decode the base64 data in your code. ``` Caveat #2: When using `YAMLToJSON` directly, maps with keys that are maps will result in an error since this is not supported by JSON. This error will occur in `Unmarshal` as well since you can't unmarshal map keys anyways since struct fields can't be keys. To install, run: ``` $ go get sigs.k8s.io/yaml ``` And import using: ``` import "sigs.k8s.io/yaml" ``` Usage is very similar to the JSON library: ```go package main import ( "fmt" "sigs.k8s.io/yaml" ) type Person struct { Name string `json:"name"` // Affects YAML field names too. Age int `json:"age"` } func main() { // Marshal a Person struct to YAML. p := Person{"John", 30} y, err := yaml.Marshal(p) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(y)) /* Output: age: 30 name: John */ // Unmarshal the YAML back into a Person struct. var p2 Person err = yaml.Unmarshal(y, &p2) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(p2) /* Output: {John 30} */ } ``` `yaml.YAMLToJSON` and `yaml.JSONToYAML` methods are also available: ```go package main import ( "fmt" "sigs.k8s.io/yaml" ) func main() { j := []byte(`{"name": "John", "age": 30}`) y, err := yaml.JSONToYAML(j) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(y)) /* Output: age: 30 name: John */ j2, err := yaml.YAMLToJSON(y) if err != nil { fmt.Printf("err: %v\n", err) return } fmt.Println(string(j2)) /* Output: {"age":30,"name":"John"} */ } ```
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-azure_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-azure completion zsh) To load completions for every new session, execute once: cilium-operator-azure completion zsh > "${fpath[1]}/_cilium-operator-azure" cilium-operator-azure completion zsh > $(brew --prefix)/share/zsh/site-functions/_cilium-operator-azure You will need to start a new shell for this setup to take effect. ``` cilium-operator-azure completion zsh [flags] ``` ``` -h, --help help for zsh --no-descriptions disable completion descriptions ``` - Generate the autocompletion script for the specified shell
Project: Velero (Runtime / Cloud Native Storage)
File: development.md

title: "Development " layout: docs Run `make update` to regenerate files if you make the following changes: Add/edit/remove command line flags and/or their help text Add/edit/remove commands or subcommands Add new API types Add/edit/remove plugin protobuf message or service definitions The following files are automatically generated from the source code: The clientset Listers Shared informers Documentation Protobuf/gRPC types You can run `make verify` to ensure that all generated files (clientset, listers, shared informers, docs) are up to date. You can run `make lint` which executes golangci-lint inside the build image, or `make local-lint` which executes outside of the build image. Both `make lint` and `make local-lint` will only run the linter against changes. Use `lint-all` to run the linter against the entire code base. The default linters are defined in the `Makefile` via the `LINTERS` variable. You can also override the default list of linters by running the command `$ make lint LINTERS=gosec` To run unit tests, use `make test`. If you are developing or using the main branch, note that you may need to update the Velero CRDs to get new changes as other development work is completed. ```bash velero install --crds-only --dry-run -o yaml | kubectl apply -f - ``` NOTE: You could change the default CRD API version (v1beta1 or v1) if Velero CLI can't discover the Kubernetes preferred CRD API version. The Kubernetes version < 1.16 preferred CRD API version is v1beta1; the Kubernetes version >= 1.16 preferred CRD API version is v1.
Project: Kuasar (Runtime / Container Runtime)
File: ROADMAP.md

This document defines a high level roadmap for Kuasar development. Define and develop new Sandbox API with containerd team Containerd (of Kuasar community) Containerd (of Containerd community with kuasar-shim) iSulad Cloud Hypervisor QEMU StratoVirt WasmEdge QuarkContainer Performance testing towards on startup time and memory overhead of kuasar vmm sandbox Containerd (of Containerd community) Wasmtime Runc Support Kubernetes Dynamic Resource Allocation (DRA) and Node Resource Interface (NRI) Support Evented PLEG Support CgroupV2 More observabilities to the project by opentracing Enhancement of sandboxer recovery Complete security vulnerability scanning Building e2e test workflow with more scenarios gVisor Firecracker Support CgroupV2 Running vm on Container OS Container checkpointing In-place Update of Pod Resources Develop CLI tool for operation and maintenance Image distribution eBPF observation
Project: Kilo (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: rkt (Runtime / Container Runtime)
File: enter.md

Given a pod UUID, if you want to enter a running pod to explore its filesystem or see what's running you can use rkt enter. ``` Pod contains multiple apps: redis etcd Unable to determine app name: specify app using "rkt enter --app= ..." No command specified, assuming "/bin/bash" root@rkt-76dc6286-f672-45f2-908c-c36dcd663560:/# ls bin data entrypoint.sh home lib64 mnt proc run selinux sys usr boot dev etc lib media opt root sbin srv tmp var ``` | Flag | Default | Options | Description | | | | | | | `--app` | `` | Name of an app | Name of the app to enter within the specified pod | See the table with .
Project: runc (Runtime / Container Runtime)
File: runc-resume.8.md

% runc-resume "8" runc-resume - resume all processes that have been previously paused runc resume container-id The resume command resumes all processes in the instance of the container identified by container-id. Use runc list to identify instances of containers and their current status. runc-list(8), runc-pause(8), runc(8).
Project: Singularity (Runtime / Container Runtime)
File: README.md

The Scientific Filesystem is well suited for Singularity containers to allow you to build a container that has multiple entrypoints, along with modular environments, libraries, and executables. Here we will review the basic building and using of a Singularity container that implements SCIF. For more quick start tutorials, see the . Build your image ```sh sudo singularity build cowsay.simg Singularity.cowsay ``` What apps are installed? ```console $ singularity apps cowsay.simg cowsay fortune lolcat ``` Ask for help for a specific app! ```console $ singularity help --app fortune cowsay.simg fortune is the best app ``` Run a particular app ```console $ singularity run --app fortune cowsay.simg When I reflect upon the number of disagreeable people who I know who have gone to a better world, I am moved to lead a different life. -- Mark Twain, "Pudd'nhead Wilson's Calendar" ``` Inspect an app ```console $ singularity inspect --app fortune cowsay.img { "SCIF_APPNAME": "fortune", "SCIF_APPSIZE": "1MB" } ```
Project: Container Storage Interface (CSI) (Runtime / Cloud Native Storage)
File: PULL_REQUEST_TEMPLATE.md

What type of PR is this? What this PR does / why we need it: Which issue(s) this PR fixes: <!-- *Automatically closes linked issue when PR is merged. Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. If PR is about `failing-tests or flakes`, please post the related issues/tests in a comment and do not use `Fixes`* --> Fixes # Special notes for your reviewer: Does this PR introduce an API-breaking change?: <!-- 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". --> ```release-note none ```
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_ipcache.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage the IPCache mappings for IP/CIDR <-> Identity ``` -h, --help help for ipcache ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Direct access to local BPF maps - Retrieve identity for an ip - List endpoint IPs (local and remote) and their corresponding security identities
Project: lxd (Runtime / Container Runtime)
File: cluster_config_storage.md

(cluster-config-storage)= All members of a cluster must have identical storage pools. The only configuration keys that may differ between pools on different members are , , , and . See {ref}`clustering-member-config` for more information. Incus creates a default `local` storage pool for each cluster member during initialization. Creating additional storage pools is a two-step process: Define and configure the new storage pool across all cluster members. For example, for a cluster that has three members: incus storage create --target server1 data zfs source=/dev/vdb1 incus storage create --target server2 data zfs source=/dev/vdc1 incus storage create --target server3 data zfs source=/dev/vdb1 size=10GiB ```{note} You can pass only the member-specific configuration keys `source`, `size`, `zfs.poolname`, `lvm.thinpoolname` and `lvm.vg_name`. Passing other configuration keys results in an error. ``` These commands define the storage pool, but they don't create it. If you run , you can see that the pool is marked as "pending". Run the following command to instantiate the storage pool on all cluster members: incus storage create data zfs ```{note} You can add configuration keys that are not member-specific to this command. ``` If you missed a cluster member when defining the storage pool, or if a cluster member is down, you get an error. Also see {ref}`storage-pools-cluster`. Running shows the cluster-wide configuration of the storage pool. To view the member-specific configuration, use the `--target` flag. For example: incus storage show data --target server2 For most storage drivers (all except for Ceph-based storage drivers), storage volumes are not replicated across the cluster and exist only on the member for which they were created. Run to see on which member a certain volume is located. When creating a storage volume, use the `--target` flag to create a storage volume on a specific cluster member. Without the flag, the volume is created on the cluster member on which you run the command. For example, to create a volume on the current cluster member `server1`: incus storage volume create local vol1 To create a volume with the same name on another cluster member: incus storage volume create local vol1 --target server2 Different volumes can have the same name as long as they live on different cluster members. Typical examples for this are image volumes. You can manage storage volumes in a cluster in the same way as you do in non-clustered deployments, except that you must pass the `--target` flag to your commands if more than one cluster member has a volume with the given name. For example, to show information about the storage volumes: incus storage volume show local vol1 --target server1 incus storage volume show local vol1 --target server2
Project: MinIO (Runtime / Cloud Native Storage)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: community, triage assignees: '' If this case is urgent, please subscribe to so that our 24/7 support team may help you faster. <! Provide a general summary of the issue in the Title above --> <! If you're describing a bug, tell us what should happen --> <! If you're suggesting a change/improvement, tell us how it should work --> <! If describing a bug, tell us what happens instead of the expected behavior --> <! If suggesting a change/improvement, explain the difference from current behavior --> <! Not obligatory, but suggest a fix/reason for the bug, --> <! or ideas how to implement the addition or change --> <! Provide a link to a live example, or an unambiguous set of steps to --> <! reproduce this bug. Include code to reproduce, if relevant --> <! and make sure you have followed https://github.com/minio/minio/tree/release/docs/debugging to capture relevant logs --> <! How has this issue affected you? What are you trying to accomplish? --> <! Providing context helps us come up with a solution that is most useful in the real world --> <!-- Is this issue a regression? (Yes / No) --> <!-- If Yes, optionally please include minio version or commit id or PR# that caused this regression, if you have these details. --> <! Include as many relevant details about the environment you experienced the bug in --> Version used (`minio --version`): Server setup and configuration: Operating System and version (`uname -a`):
Project: Velero (Runtime / Cloud Native Storage)
File: ark_delete_schedule.md

title: "ark delete schedule" layout: docs Delete a schedule Delete a schedule ``` ark delete schedule NAME [flags] ``` ``` -h, --help help for schedule ``` ``` --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 ``` - Delete ark resources
Project: CubeFS (Runtime / Cloud Native Storage)
File: writing-docs.md

The sequence diagrams are generated with `seqdiag`: http://blockdiag.com/en/seqdiag/index.html An easy way to work on them is to automatically update the generated files with https://github.com/cespare/reflex : reflex -g 'doc/[^.]*.seq' -- seqdiag -T svg -o '{}.svg' '{}' & reflex -g 'doc/[^.]*.seq' -- seqdiag -T png -o '{}.png' '{}' & The markdown files refer to PNG images because of Github limitations, but the SVG is generally more pleasant to view.
Project: Spiderpool (Runtime / Cloud Native Network)
File: crd-spidersubnet.md

A SpiderSubnet resource represents a collection of IP addresses from which Spiderpool expects SpiderIPPool IPs to be assigned. For details on using this CRD, please read the . ```yaml apiVersion: spiderpool.spidernet.io/v2beta1 kind: SpiderSubnet metadata: name: default-v4-subnet spec: ipVersion: 4 ips: 172.22.40.2-172.22.40.254 subnet: 172.22.0.0/16 excludeIPs: 172.22.40.10-172.22.40.20 gateway: 172.22.40.1 ``` | Field | Description | Schema | Validation | |-|-|--|| | name | the name of this SpiderSubnet resource | string | required | This is the SpiderSubnet spec for users to configure. | Field | Description | Schema | Validation | Values | Default | |-||-|||| | ipVersion | IP version of this subnet | int | optional | 4,6 | | | subnet | subnet of this resource | string | required | IPv4 or IPv6 CIDR.<br/>Must not overlap | | | ips | IP ranges for this resource to use | list of strings | optional | array of IP ranges and single IP address | | | excludeIPs | isolated IP ranges for this resource to filter | list of strings | optional | array of IP ranges and single IP address | | | gateway | gateway for this resource | string | optional | an IP address | | | vlan | vlan ID(deprecated) | int | optional | [0,4094] | 0 | | routes | custom routes in this resource | list of | optional | | | The Subnet status is a subresource that processed automatically by the system to summarize the current state. | Field | Description | Schema | |-|-|--| | controlledIPPools | current IP allocations in this subnet resource | string | | totalIPCount | total IP addresses counts of this subnet resource to use | int | | allocatedIPCount | current allocated IP addresses counts | int |
Project: Ceph (Runtime / Cloud Native Storage)
File: prometheus_adapter.md

This directory contains an example `prometheus_adapter.lua` on how to use to push metrics from the RGW requests to , specifically to collect information on object sizes. As every single run of a lua script is short-lived, so should be used as an intermediate service to enable Prometheus to scrape data from RGW. Install and run Pushgateway using docker: ```bash docker pull prom/pushgateway docker run -p 9091:9091 -it prom/pushgateway ``` Install and run Prometheus using docker: ```bash docker pull prom/prometheus docker run --network host -v ${CEPH_DIR}/examples/lua/config/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus ``` Upload the script: ```bash radosgw-admin script put --infile=prometheus_adapter.lua --context=postRequest ``` Add the packages used in the script: ```bash radosgw-admin script-package add --package='luasocket' --allow-compilation ``` Restart radosgw. Send a request: ```bash s3cmd --host=localhost:8000 --host-bucket="localhost:8000/%(bucket)" --accesskey=0555b35654ad1656d804 --secretkey=h7GhxuBLTrlhVUyxSPUKUV8r/2EI4ngqJxD7iBdBYLhwluN30JaT3Q== mb s3://mybucket s3cmd --host=localhost:8000 --host-bucket="localhost:8000/%(bucket)" --accesskey=0555b35654ad1656d804 --secretkey=h7GhxuBLTrlhVUyxSPUKUV8r/2EI4ngqJxD7iBdBYLhwluN30JaT3Q== put -P /etc/hosts s3://mybucket curl http://localhost:8000/mybucket/hosts ``` Open `http://localhost:9090` by browser and search for `rgwrequestcontent_length` Lua 5.3 or higher
Project: Antrea (Runtime / Cloud Native Network)
File: proposal.md

name: Proposal about: Describe a feature you are planning to implement title: '' labels: kind/design assignees: '' Describe what you are trying to solve <!-- A description of the current limitation/problem/challenge that you are experiencing. --> Describe the solution you have in mind <!-- A clear and concise description of what you want to happen. --> Describe how your solution impacts user flows <!-- Does your solution impact how users interact with Antrea? If your proposal introduces a new user-facing feature, describe how it can be consumed. --> Describe the main design/architecture of your solution <!-- A clear and concise description of what does your solution look like. Rich text and diagrams are preferred. --> Alternative solutions that you considered <!-- A list of the alternative solutions that you considered, and why they fell short. You can list the pros and cons of each solution. --> Test plan <!-- Describe what kind of tests you plan on adding to exercise your changes. --> Additional context <!-- Any other relevant information.-->