cwielenb/CNCF-Dataset huggingface dataset:
Project: StratoVirt (Runtime / Container Runtime)
File: cpu_hotplug.md

StratoVirt support to hot(un)plug CPU to a running VM. This feature supports dynamic adjustment of CPU resources of VM. Currently, only standard VM with x86_64 architecture is supported, and NUMA architecture is not supported. First, we create a StratoVirt VM. ```shell $ ./stratovirt \ -machine q35 \ -smp [cpus=]<n>,maxcpus=<max_cpus> \ -m 512 \ -kernel path/to/kernel \ -append "console=ttyS0 root=/dev/vda reboot=k panic=1" \ -drive file=path/to/OVMF_CODE.fd,if=pflash,unit=0,readonly=true \ -device pcie-root-port,port=0x0,addr=0x1.0x0,bus=pcie.0,id=pcie.1 \ -drive file=path/to/rootfs,id=rootfs,readonly=true \ -device virtio-blk-pci,drive=rootfs,bus=pcie.1,addr=0x0.0x0,id=blk-0 \ -qmp unix:path/to/api/socket,server,nowait \ -serial stdio ``` `cpus`: Set the number of CPUs to 'n' (default: 1). The number of `cpus` will all online after VM booted, and can't be hotunplugged. `maxcpus`: Set the number of total CPUs, including online and offline CPUs. The number of offline CPUs is also the number of CPUs that support hotplug. The number of `maxcpus` should not less than `cpus`. After the VM boot up, hotplug CPU with QMP: ```shell $ ncat -U path/to/api/socket {"QMP":{"version":{"qemu":{"micro":1,"minor":0,"major":5},"package":"StratoVirt-2.4.0"},"capabilities":[]}} -> {"execute": "device_add","arguments": { "id": "device-id", "driver": "generic-x86-cpu", "cpu-id": cpuid }} <- {"return":{}} <- {"event":"CPU_RESIZE","data":{},"timestamp":{"seconds":seconds, "microseconds":microseconds}} ``` `id`: The ID of the CPU device, which should be a globally unique string. `cpu-id`: The number of the CPU, which can be an integer in the range of [`cpus`, `maxcpus`) hotunplug CPU with QMP: ```shell $ ncat -U path/to/api/socket {"QMP":{"version":{"qemu":{"micro":1,"minor":0,"major":5},"package":"StratoVirt-2.4.0"},"capabilities":[]}} -> {"execute": "device_del", "arguments": { "id": "device-id"}} <- {"return":{}} <- {"event":"CPU_RESIZE","data":{},"timestamp":{"seconds":seconds, "microseconds":microseconds}} ``` CPU hot(un)plug support machine type: `q35` (on x86_64 platform) Some devices and feature don't support to be CPU hotplug yet: `numa`
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_service_get.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Display service information ``` cilium-dbg service get <service id> [flags] ``` ``` -h, --help help for get -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 services & loadbalancers
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_preflight_migrate-identity.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Migrate KVStore-backed identities to kubernetes CRD-backed identities migrate-identity allows migrating to CRD-backed identities while minimizing connection interruptions. It will allocate a CRD-backed identity, with the same numeric security identity, for each cilium security identity defined in the kvstore. When cilium-agents are restarted with identity-allocation-mode set to CRD the numeric identities will then be equivalent between new instances and not-upgraded ones. In cases where the numeric identity is already in-use by a different set of labels, a new numeric identity is created. ``` cilium-dbg preflight migrate-identity [flags] ``` ``` --enable-k8s Enable the k8s clientset (default true) --enable-k8s-api-discovery Enable discovery of Kubernetes API groups and resources with the discovery API -h, --help help for migrate-identity --k8s-api-server string Kubernetes API server URL --k8s-client-burst int Burst value allowed for the K8s client --k8s-client-qps float32 Queries per second limit for the K8s client --k8s-heartbeat-timeout duration Configures the timeout for api-server heartbeat, set to 0 to disable (default 30s) --k8s-kubeconfig-path string Absolute path of the kubernetes kubeconfig file --kvstore string Key-value store type --kvstore-opt map Key-value store options e.g. etcd.address=127.0.0.1:4001 ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Cilium upgrade helper
Project: Kata Containers (Runtime / Container Runtime)
File: RateLimiterConfig.md

Name | Type | Description | Notes | - | - | - Bandwidth | Pointer to | | [optional] Ops | Pointer to | | [optional] `func NewRateLimiterConfig() *RateLimiterConfig` NewRateLimiterConfig instantiates a new RateLimiterConfig 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 NewRateLimiterConfigWithDefaults() *RateLimiterConfig` NewRateLimiterConfigWithDefaults instantiates a new RateLimiterConfig 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 *RateLimiterConfig) GetBandwidth() TokenBucket` GetBandwidth returns the Bandwidth field if non-nil, zero value otherwise. `func (o RateLimiterConfig) GetBandwidthOk() (TokenBucket, bool)` GetBandwidthOk returns a tuple with the Bandwidth field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *RateLimiterConfig) SetBandwidth(v TokenBucket)` SetBandwidth sets Bandwidth field to given value. `func (o *RateLimiterConfig) HasBandwidth() bool` HasBandwidth returns a boolean if a field has been set. `func (o *RateLimiterConfig) GetOps() TokenBucket` GetOps returns the Ops field if non-nil, zero value otherwise. `func (o RateLimiterConfig) GetOpsOk() (TokenBucket, bool)` GetOpsOk returns a tuple with the Ops field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *RateLimiterConfig) SetOps(v TokenBucket)` SetOps sets Ops field to given value. `func (o *RateLimiterConfig) HasOps() bool` HasOps returns a boolean if a field has been set.
Project: WasmEdge Runtime (Runtime / Container Runtime)
File: concurrent_fib.md

In this example, we will demonstrate how to use the objects and the APIs defined in `wasmedge-sys` to compute Fibonacci numbers concurrently. we creates two child threads, `threada` and `threadb`, which are responsible for compute `Fib(4)` and `Fib(5)` by calling the host function `fib`, respectively. After that, the main thread computes `Fib(6)` by adding the numbers returned by `threada` and `threadb`. The code in the example is verified on wasmedge-sys v0.10.0 wasmedge-types v0.3.0 ```rust // create a Config context let mut config = Config::create()?; config.bulkmemoryoperations(true); // create a Store context let mut store = Store::create()?; // create a Vm context with the given Config and Store let mut vm = Vm::create(Some(config), Some(&mut store))?; // register a wasm module from a wasm file let file = std::path::PathBuf::from(env!("WASMEDGE_DIR")) .join("bindings/rust/wasmedge-sys/tests/data/fibonacci.wasm"); vm.registerwasmfrom_file("extern", file)?; ``` ```rust let vm = Arc::new(Mutex::new(vm)); // compute fib(4) by a child thread let vm_cloned = Arc::clone(&vm); let handle_a = thread::spawn(move || { let vmchildthread = vm_cloned.lock().expect("fail to lock vm"); let returns = vmchildthread .runregisteredfunction("extern", "fib", [WasmValue::from_i32(4)]) .expect("fail to compute fib(4)"); let fib4 = returns[0].to_i32(); println!("fib(4) by child thread: {}", fib4); fib4 }); // compute fib(5) by a child thread let vm_cloned = Arc::clone(&vm); let handle_b = thread::spawn(move || { let vmchildthread = vm_cloned.lock().expect("fail to lock vm"); let returns = vmchildthread .runregisteredfunction("extern", "fib", [WasmValue::from_i32(5)]) .expect("fail to compute fib(5)"); let fib5 = returns[0].to_i32(); println!("fib(5) by child thread: {}", fib5); fib5 }); ``` ```Rust let fib4 = handle_a.join().unwrap(); let fib5 = handle_b.join().unwrap(); // compute fib(6) println!("fib(6) = fib(5) + fib(1) = {}", fib5 + fib4); ``` The final result of the code above should be printed on the screen like below: ```bash fib(4) by child thread: 5 fib(5) by child thread: 8 fib(6) = fib(5) + fib(1) = 13 ``` The complete code in this demo can be found in .
Project: Stash by AppsCode (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: kube-vip (Runtime / Cloud Native Network)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: '' 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: lxd (Runtime / Container Runtime)
File: network_sriov.md

(network-sriov)= <!-- Include start SR-IOV intro --> {abbr}`SR-IOV (Single root I/O virtualization)` is a hardware standard that allows a single network card port to appear as several virtual network interfaces in a virtualized environment. <!-- Include end SR-IOV intro --> The `sriov` network type allows to specify presets to use when connecting instances to a parent interface. In this case, the instance NICs can simply set the `network` option to the network they connect to without knowing any of the underlying configuration details. (network-sriov-options)= The following configuration key namespaces are currently supported for the `sriov` network type: `user` (free-form key/value for user metadata) ```{note} {{noteipaddresses_CIDR}} ``` The following configuration options are available for the `sriov` network type: Key | Type | Condition | Default | Description :-- | :-- | :-- | :-- | :-- `mtu` | integer | - | - | The MTU of the new interface `parent` | string | - | - | Parent interface to create `sriov` NICs on `vlan` | integer | - | - | The VLAN ID to attach to `user.*` | string | - | - | User-provided free-form key/value pairs
Project: CRI-O (Runtime / Container Runtime)
File: EXTENDING.md

`go-git` was built in a highly extensible manner, which enables some of its functionalities to be changed or extended without the need of changing its codebase. Here are the key extensibility features: Dot git storers are the components responsible for storing the Git internal files, including objects and references. The built-in storer implementations include and . The `memory` storer stores all the data in memory, and its use look like this: ```go r, err := git.Init(memory.NewStorage(), nil) ``` The `filesystem` storer stores the data in the OS filesystem, and can be used as follows: ```go r, err := git.Init(filesystem.NewStorage(osfs.New("/tmp/foo")), nil) ``` New implementations can be created by implementing the . Git repository worktrees are managed using a filesystem abstraction based on . The Git operations will take place against the specific filesystem implementation. Initialising a repository in Memory can be done as follows: ```go fs := memfs.New() r, err := git.Init(memory.NewStorage(), fs) ``` The same operation can be done against the OS filesystem: ```go fs := osfs.New("/tmp/foo") r, err := git.Init(memory.NewStorage(), fs) ``` New filesystems (e.g. cloud based storage) could be created by implementing `go-billy`'s . Git supports various transport schemes, including `http`, `https`, `ssh`, `git`, `file`. `go-git` defines the to represent them. The built-in implementations can be replaced by calling `client.InstallProtocol`. An example of changing the built-in `https` implementation to skip TLS could look like this: ```go customClient := &http.Client{ Transport: &http.Transport{ TLSClientConfig: &tls.Config{InsecureSkipVerify: true}, }, } client.InstallProtocol("https", githttp.NewClient(customClient)) ``` Some internal implementations enables code reuse amongst the different transport implementations. Some of these may be made public in the future (e.g. `plumbing/transport/internal/common`). Several different operations across `go-git` lean on caching of objects in order to achieve optimal performance. The caching functionality is defined by the . Two built-in implementations are `cache.ObjectLRU` and `cache.BufferLRU`. However, the caching functionality can be customized by implementing the interface `cache.Object` interface. `go-git` uses the `crypto.Hash` interface to represent hash functions. The built-in implementations are `github.com/pjbgf/sha1cd` for SHA1 and Go's `crypto/SHA256`. The default hash functions can be changed by calling `hash.RegisterHash`. ```go func init() { hash.RegisterHash(crypto.SHA1, sha1.New) } ``` New `SHA1` or `SHA256` hash functions that implement the `hash.RegisterHash` interface can be registered by calling `RegisterHash`.
Project: Spiderpool (Runtime / Cloud Native Network)
File: spiderpool-agent.md

This page describes CLI options and ENV of spiderpool-agent. Run the spiderpool agent daemon. ``` --config-dir string config file path (default /tmp/spiderpool/config-map) --ipam-config-dir string config file for ipam plugin ``` | env | default | description | |-||-| | SPIDERPOOLLOGLEVEL | info | Log level, optional values are "debug", "info", "warn", "error", "fatal", "panic". | | SPIDERPOOLENABLEDMETRIC | false | Enable/disable metrics. | | SPIDERPOOLHEALTHPORT | 5710 | Metric HTTP server port. | | SPIDERPOOLMETRICHTTP_PORT | 5711 | Spiderpool-agent backend HTTP server port. | | SPIDERPOOLGOPSLISTEN_PORT | 5712 | Port that gops is listening on. Disabled if empty. | | SPIDERPOOLUPDATECRMAXRETRIES | 3 | Max retries to update k8s resources. | | SPIDERPOOLWORKLOADENDPOINTMAXHISTORYRECORDS | 100 | Max historical IP allocation information allowed for a single Pod recorded in WorkloadEndpoint. | | SPIDERPOOLIPPOOLMAXALLOCATEDIPS | 5000 | Max number of IP that a single IP pool can provide. | | SPIDERPOOLENABLEDRELEASECONFLICTIPS | true | Enable/disable release conflict IPs. | Notify of stopping the spiderpool-agent daemon. Get local metrics. ``` --port string http server port of local metric (default to 5711) ```
Project: Vineyard (Runtime / Cloud Native Storage)
File: MAINTAINERS.md

This file lists the maintainers of the Vineyard project. The responsibilities of maintainers are listed in the file. | Name | GitHub ID | Affiliation | Email | | | -- | -- | - | | Ye Cao | | Alibaba | | | Tao He | | Alibaba | | | Xiaojian Luo | | Alibaba | | | Ke Meng | | Alibaba | | | Wenyuan Yu | | Alibaba | | | Weibin Zeng | | Alibaba | | | Siyuan Zhang | | Alibaba | | | Diwen Zhu | | Alibaba | | | Shumin Yuan | | Alibaba | | | Denghao Li | | PingAn Tech | | | Name | GitHub ID | Affiliation | Email | | -| -- | -- | - | | Lihong Lin | | PKU | | | Pei Li | | CMU | |
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_metrics_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List all metrics ``` cilium-dbg metrics list [flags] ``` ``` -h, --help help for list -p, --match-pattern string Show only metrics whose names match matchpattern -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 ``` - Access metric status
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bgp_route-policies.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List configured route policies List route policies configured in the underlying routing daemon ``` cilium-dbg bgp route-policies [vrouter <asn>] [flags] ``` ``` -h, --help help for route-policies -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 ``` - Access to BGP control plane
Project: CubeFS (Runtime / Cloud Native Storage)
File: yaml_docs.md

Generating yaml files from a cobra command is incredibly easy. An example is as follows: ```go package main import ( "log" "github.com/spf13/cobra" "github.com/spf13/cobra/doc" ) func main() { cmd := &cobra.Command{ Use: "test", Short: "my test program", } err := doc.GenYamlTree(cmd, "/tmp") if err != nil { log.Fatal(err) } } ``` That will get you a Yaml document `/tmp/test.yaml` This program can actually generate docs for the kubectl command in the kubernetes project ```go package main import ( "io/ioutil" "log" "os" "k8s.io/kubernetes/pkg/kubectl/cmd" cmdutil "k8s.io/kubernetes/pkg/kubectl/cmd/util" "github.com/spf13/cobra/doc" ) func main() { kubectl := cmd.NewKubectlCommand(cmdutil.NewFactory(nil), os.Stdin, ioutil.Discard, ioutil.Discard) err := doc.GenYamlTree(kubectl, "./") if err != nil { log.Fatal(err) } } ``` This will generate a whole series of files, one for each command in the tree, in the directory specified (in this case "./") You may wish to have more control over the output, or only generate for a single command, instead of the entire command tree. If this is the case you may prefer to `GenYaml` instead of `GenYamlTree` ```go out := new(bytes.Buffer) doc.GenYaml(cmd, out) ``` This will write the yaml doc for ONLY "cmd" into the out, buffer. Both `GenYaml` and `GenYamlTree` have alternate versions with callbacks to get some control of the output: ```go func GenYamlTreeCustom(cmd *Command, dir string, filePrepender, linkHandler func(string) string) error { //... } ``` ```go func GenYamlCustom(cmd Command, out bytes.Buffer, linkHandler func(string) string) error { //... } ``` The `filePrepender` will prepend the return value given the full filepath to the rendered Yaml file. A common use case is to add front matter to use the generated documentation with : ```go const fmTemplate = ` date: %s title: "%s" slug: %s url: %s ` filePrepender := func(filename string) string { now := time.Now().Format(time.RFC3339) name := filepath.Base(filename) base := strings.TrimSuffix(name, path.Ext(name)) url := "/commands/" + strings.ToLower(base) + "/" return fmt.Sprintf(fmTemplate, now, strings.Replace(base, "_", " ", -1), base, url) } ``` The `linkHandler` can be used to customize the rendered internal links to the commands, given a filename: ```go linkHandler := func(name string) string { base := strings.TrimSuffix(name, path.Ext(name)) return "/commands/" + strings.ToLower(base) + "/" } ```
Project: CubeFS (Runtime / Cloud Native Storage)
File: upgrade.md

::: warning Note Please refer to the release notes for the upgrade steps of each version. ::: Obtain the code of the specified version from https://github.com/cubeFS/cubefs/releases, and compile to generate the binary. ``` $ cfs-cli cluster freeze true ``` During the freeze period, new data partitions cannot be created for the volume, but it does not affect ongoing business processes. Confirm the startup configuration file and do not change important information such as the data directory and port in the configuration file. For other parameter modifications in the configuration file, refer to the configuration instructions, release notes, etc. Upgrade order of each component, refer to the corresponding version If there are no special requirements, the components can generally be upgraded in the order of datanode->metanode->master->client. The following describes the upgrade process for datanode. Stop the old datanode process. Start the new datanode process. After starting, check the node status. Upgrade the next machine after it is displayed as active. ``` $ cfs-cli datanode info 192.168.0.33:17310 [Data node info] ID : 9 Address : 192.168.0.33:17310 Carry : 0.06612836801123345 Used ratio : 0.0034684352702178426 Used : 96 GB Available : 27 TB Total : 27 TB Zone : default IsActive : Active Report time : 2020-07-27 10:23:20 Partition count : 16 Bad disks : [] Persist partitions : [2 3 5 7 8 10 11 12 13 14 15 16 17 18 19 20] ``` Similar to DataNode. Stop the old master process. Start the new master process. Observe whether the monitoring is normal. Check whether the corresponding raft status of the master is normal. As follows, check whether the commit corresponding to the restarted master ID is consistent with other replicas, and whether the raft has a leader. ```shell curl 192.168.0.1:17010/get/raftStatus | python -m json.tool { "code": 0, "data": { "AppQueue": 0, "Applied": 25168073, "Commit": 25168074, "ID": 1, "Index": 25168074, "Leader": 2, "NodeID": 2, "Replicas": { "1": { "Active": true, "Commit": 25168074, "Match": 25168074, "Next": 25168075, }, "2": { "Active": true, "Commit": 25168074, "Match": 25168074, "Next": 25168075, "Paused": false, }, "3": { "Active": true, "Commit": 25168074, "Match": 25168074, "Next": 25168075, } }, "RestoringSnapshot": false, "State": "StateLeader", "Stopped": false, "Term": 292, "Vote": 2 }, "msg": "success" } ``` Stop business read and write operations. Unmount the mount point. If the following error occurs, execute `umount -l mount point`. ``` umount: /xxx/mnt: target is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1) ``` If the client process exists, stop it. Start the new client process. Use `df -h` to check whether the upgrade is successful.