cwielenb/CNCF-Dataset huggingface dataset:
Project: runc (Runtime / Container Runtime)
File: runc-update.8.md

% runc-update "8" runc-update - update running container resource constraints runc update [option ...] container-id runc update -r resources.json|- container-id The update command change the resource constraints of a running container instance. The resources can be set using options, or, if -r is used, parsed from JSON provided as a file or from stdin. In case -r is used, the JSON format is like this: { "memory": { "limit": 0, "reservation": 0, "swap": 0, "kernel": 0, "kernelTCP": 0 }, "cpu": { "shares": 0, "quota": 0, "burst": 0, "period": 0, "realtimeRuntime": 0, "realtimePeriod": 0, "cpus": "", "mems": "" }, "blockIO": { "blkioWeight": 0 } } --resources|-r resources.json : Read the new resource limits from resources.json. Use - to read from stdin. If this option is used, all other options are ignored. --blkio-weight weight : Set a new io weight. --cpu-period num : Set CPU CFS period to be used for hardcapping (in microseconds) --cpu-quota num : Set CPU usage limit within a given period (in microseconds). --cpu-burst num : Set CPU burst limit within a given period (in microseconds). --cpu-rt-period num : Set CPU realtime period to be used for hardcapping (in microseconds). --cpu-rt-runtime num : Set CPU realtime hardcap limit (in usecs). Allowed cpu time in a given period. --cpu-share num : Set CPU shares (relative weight vs. other containers). --cpuset-cpus list : Set CPU(s) to use. The list can contain commas and ranges. For example: 0-3,7. --cpuset-mems list : Set memory node(s) to use. The list format is the same as for --cpuset-cpus. --memory num : Set memory limit to num bytes. --memory-reservation num : Set memory reservation, or soft limit, to num bytes. --memory-swap num : Set total memory + swap usage to num bytes. Use -1 to unset the limit (i.e. use unlimited swap). --pids-limit num : Set the maximum number of processes allowed in the container. --l3-cache-schema value : Set the value for Intel RDT/CAT L3 cache schema. --mem-bw-schema value : Set the Intel RDT/MBA memory bandwidth schema. runc(8).
Project: Curve (Runtime / Cloud Native Storage)
File: monitor_en.md

CURVE monitoring system includes three aspects: indicators collection, indicators storage, and indicators display. For indicators collection, use built-in ; the open source monitoring system is used for indicators storage; is used for indicators display. is a counter library in a multi-threaded environment, which is convenient for recording and viewing various types of user numerical value in program. bvar data can be exported and queried via web portal on the port of the brpc server service, also can view historical trends, statistics and quantile values; bvar also has a built-in prometheus conversion module to convert collected indicators into a format supported by prometheus. The bvar data models used in CURVE are: `bvar::Adder<T>` : counterdefault 0varname << N is equivalent to varname += N. `bvar::Maxer<T>` : maximum valuedefault std::numeric_limits::min()varname << N is equivalent to varname = max(varname, N). `bvar::Miner<T>` : minimum valuedefault std::numeric_limits::max()varname << N is equivalent to varname = min(varname, N). `bvar::IntRecorder` : the average value since use. Note that the attributive here is not "in a period of time". Generally, the average value in the time window is derived through Window. `bvar::Window<VAR>`: the accumulated value of a bvar in a period of time. Window is derived from the existing bvar and will be updated automatically. `bvar::PerSecond<VAR>`: the average accumulated value of a bvar per second in a period of time. PerSecond is also a derivative variable that is automatically updated. `bvar::LatencyRecorder`: to recording latency and qps. Input delay, average delay/maximum delay/qps/total times are all available. The specific usage of bvar in CURVE can be viewed: CURVE cluster monitoring uses Prometheus to collect data and Grafana to display. Monitoring content includes: Client, Mds, Chunkserver, Etcd, and machine nodes. The configuration of the monitoring target uses the prometheus file-based service automatic discovery function. The monitoring component is deployed in docker and docker-compose is used for orchestration. The deployment related scripts are in the . <img src="../images/monitor.png" alt="monitor" width="800" /> ```Promethethus``` regularly pulls corresponding data from Brpc Server in MDS, ETCD, Snapshotcloneserver, ChunkServer, and Client. ```docker compose``` is used to orchestrate the configuration of docker components, including Prometheus, Grafana and Repoter. ```python``` scripts. is used to generate the monitoring target configuration that prometheus service discovery depends on. The generated file is in json format and the script depends on to obtain mds, etcd information from the configuration. is used to export the data information required by the daily reporter from Grafana. <img src="../images/grafana-example-1.png" alt="monitor" width="1000" /> <img src="../images/grafana-example-3.png" alt="monitor" width="1000" /> <img src="../images/grafana-example-2.png" alt="monitor" width="1000" /> <img src="../images/grafana-reporter.png" alt="monitor" width="800" />
Project: Velero (Runtime / Cloud Native Storage)
File: ark_client_config.md

title: "ark client config" layout: docs Get and set client configuration file values Get and set client configuration file values ``` -h, --help help for config ``` ``` --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 ``` - Ark client related commands - Get client configuration file values - Set client configuration file values
Project: Longhorn (Runtime / Cloud Native Storage)
File: README.md

Install Longhorn. Install Longhorn stack. ```bash ./install.sh ``` Sample output: ```shell secret/influxdb-creds created persistentvolumeclaim/influxdb created deployment.apps/influxdb created service/influxdb created Deployment influxdb is running. Cloning into 'upgrade-responder'... remote: Enumerating objects: 1077, done. remote: Counting objects: 100% (1076/1076), done. remote: Compressing objects: 100% (454/454), done. remote: Total 1077 (delta 573), reused 1049 (delta 565), pack-reused 1 Receiving objects: 100% (1077/1077), 55.01 MiB | 18.10 MiB/s, done. Resolving deltas: 100% (573/573), done. Release "longhorn-upgrade-responder" does not exist. Installing it now. NAME: longhorn-upgrade-responder LAST DEPLOYED: Thu May 11 00:42:44 2023 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: Get the Upgrade Responder server URL by running these commands: export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=upgrade-responder,app.kubernetes.io/instance=longhorn-upgrade-responder" -o jsonpath="{.items[0].metadata.name}") kubectl port-forward $POD_NAME 8080:8314 --namespace default echo "Upgrade Responder server URL is http://127.0.0.1:8080" Deployment longhorn-upgrade-responder is running. persistentvolumeclaim/grafana-pvc created deployment.apps/grafana created service/grafana created Deployment grafana is running. [Upgrade Checker] URL : http://longhorn-upgrade-responder.default.svc.cluster.local:8314/v1/checkupgrade [InfluxDB] URL : http://influxdb.default.svc.cluster.local:8086 Database : longhornupgraderesponder Username : root Password : root [Grafana] Dashboard : http://1.2.3.4:30864 Username : admin Password : admin ```
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_preflight_validate-cnp.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Validate Cilium Network Policies deployed in the cluster Before upgrading Cilium it is recommended to run this validation checker to make sure the policies deployed are valid. The validator will verify if all policies deployed in the cluster are valid, in case they are not, an error is printed and the has an exit code 1 is returned. ``` cilium-dbg preflight validate-cnp [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 validate-cnp --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 ``` ``` --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: Spiderpool (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: MinIO (Runtime / Cloud Native Storage)
File: feature_request.md

name: Feature request about: Suggest an idea for this project title: '' labels: community, triage 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: Velero (Runtime / Cloud Native Storage)
File: CHANGELOG-0.3.md

- https://github.com/heptio/ark/tree/v0.3.3 Treat the first field in a schedule's cron expression as minutes, not seconds https://github.com/heptio/ark/tree/v0.3.2 Add client-go auth provider plugins for Azure, GCP, OIDC https://github.com/heptio/ark/tree/v0.3.1 Fix Makefile VERSION https://github.com/heptio/ark/tree/v0.3.0 Initial Release
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_lb.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Load-balancing configuration ``` -h, --help help for lb ``` ``` --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 - List load-balancing configuration - Maglev lookup table
Project: Flannel (Runtime / Cloud Native Network)
File: PULL_REQUEST_TEMPLATE.md

<!-- A few sentences describing the overall goals of the pull request's commits. Please include the type of fix - (e.g. bug fix, new feature, documentation) some details on why this PR should be merged the details of the testing you've done on it (both manual and automated) which components are affected by this PR --> [ ] Tests [ ] Documentation [ ] Release note <!-- Writing a release note: By default, no release note action is required. If you're unsure whether or not your PR needs a note, ask your reviewer for guidance. If this PR requires a release note, update the block below to include a concise note describing the change and any important impacts this PR may have. --> ```release-note None required ```
Project: Kata Containers (Runtime / Container Runtime)
File: VmRemoveDevice.md

Name | Type | Description | Notes | - | - | - Id | Pointer to string | | [optional] `func NewVmRemoveDevice() *VmRemoveDevice` NewVmRemoveDevice instantiates a new VmRemoveDevice 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 NewVmRemoveDeviceWithDefaults() *VmRemoveDevice` NewVmRemoveDeviceWithDefaults instantiates a new VmRemoveDevice 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 *VmRemoveDevice) GetId() string` GetId returns the Id field if non-nil, zero value otherwise. `func (o VmRemoveDevice) 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 *VmRemoveDevice) SetId(v string)` SetId sets Id field to given value. `func (o *VmRemoveDevice) HasId() bool` HasId returns a boolean if a field has been set.
Project: MinIO (Runtime / Cloud Native Storage)
File: PULL_REQUEST_TEMPLATE.md

All community contributions in this pull request are licensed to the project maintainers under the terms of the . By creating this pull request I represent that I have the right to license the contributions to the project maintainers under the Apache 2 license. [ ] Bug fix (non-breaking change which fixes an issue) [ ] New feature (non-breaking change which adds functionality) [ ] Optimization (provides speedup with no functional changes) [ ] Breaking change (fix or feature that would cause existing functionality to change) [ ] Fixes a regression (If yes, please add `commit-id` or `PR #` here) [ ] Unit tests added/updated [ ] Internal documentation updated
Project: gVisor (Runtime / Container Runtime)
File: compatibility.md

[TOC] gVisor implements a large portion of the Linux surface and while we strive to make it broadly compatible, there are (and always will be) unimplemented features and bugs. The only real way to know if it will work is to try. If you find a container that doesnt work and there is no known issue, please indicating the full command you used to run the image. You can view open issues related to compatibility . If you're able to provide the , the problem likely to be fixed much faster. The following applications/images have been tested: elasticsearch golang httpd java8 jenkins mariadb memcached mongo mysql nginx node php postgres prometheus python redis registry rust tomcat wordpress Most common utilities work. Note that: Some tools, such as `tcpdump` and old versions of `ping`, require explicitly enabling raw sockets via the unsafe `--net-raw` runsc flag. In case of tcpdump the following invocations will work tcpdump -i any tcpdump -i \<device-name\> -p (-p disables promiscuous mode) Different Docker images can behave differently. For example, Alpine Linux and Ubuntu have different `ip` binaries. Specific tools include: <!-- mdformat off(don't wrap the table) --> | Tool | Status | | :--: | :--: | | apt-get | Working. | | bundle | Working. | | cat | Working. | | curl | Working. | | dd | Working. | | df | Working. | | dig | Working. | | drill | Working. | | env | Working. | | find | Working. | | gcore | Working. | | gdb | Working. | | gosu | Working. | | grep | Working. | | ifconfig | Works partially, like ip. Full support . | | ip | Some subcommands work (e.g. addr, route). Full support . | | less | Working. | | ls | Working. | | lsof | Working. | | mount | Works in readonly mode. gVisor doesn't currently support creating new mounts at runtime. | | nc | Working. | | nmap | Not working. | | netstat | . | | nslookup | Working. | | ping | Working. | | ps | Working. | | route | Working. | | ss | . | | sshd | Partially working. Job control . | | strace | Working. | | tar | Working. | | tcpdump | Working , . | | top | Working. | | uptime | Working. | | vim | Working. | | wget | Working. | <!-- mdformat on -->
Project: Flannel (Runtime / Cloud Native Network)
File: upgrade.md

Flannel upgrade/downgrade procedure There are different ways of changing flannel version in the running cluster: Pros: Cleanest way of managing resources of the flannel deployment and no manual validation required as long as no additional resources was created by administrators/operators Cons: Massive networking outage within a cluster during the version change Delete all the flannel resources using kubectl ```bash kubectl -n kube-flannel delete daemonset kube-flannel-ds kubectl -n kube-flannel delete configmap kube-flannel-cfg kubectl -n kube-flannel delete serviceaccount flannel kubectl delete clusterrolebinding.rbac.authorization.k8s.io flannel kubectl delete clusterrole.rbac.authorization.k8s.io flannel kubectl delete namespace kube-flannel ``` Install the newer version of flannel and reboot the nodes Pros: Less disruptive way of changing flannel version, easier to do Cons: Some version may have changes which can't be just replaced and may need resources cleanup and/or rename, manual resources comparison required If the update is done from newer version as 0.20.2 it can be done using kubectl ```bash kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml ``` In case of error on the labeling follow the previous way. From version 0.21.4 flannel is deployed on an helm repository at `https://flannel-io.github.io/flannel/` it will be possible to manage the update directly with helm. ```bash helm upgrade flannel --set podCidr="10.244.0.0/16" --namespace kube-flannel flannel/flannel ```
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_egress_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List egress policy entries List egress policy entries. ``` cilium-dbg bpf egress 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 the egress routing rules
Project: CNI-Genie (Runtime / Cloud Native Network)
File: GettingStarted.md

Linux box with We tested on Ubuntu 14.04 & 16.04 Docker installed Kubernetes cluster running with CNI enabled One easy way to bring up a cluster is to use : We tested on Kubernetes 1.5, 1.6, 1.7, 1.8 Till 1.7 version: ``` $ kubeadm init --use-kubernetes-version=v1.7.0 --pod-network-cidr=10.244.0.0/16 ``` Version 1.8 onwards: ``` $ kubeadm init --pod-network-cidr=10.244.0.0/16 ``` Next steps: ``` $ mkdir -p $HOME/.kube $ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config $ sudo chown $(id -u):$(id -g) $HOME/.kube/config ``` To schedule pods on the master, e.g. for a single-machine Kubernetes cluster, Till 1.7 version, run: ``` $ kubectl taint nodes --all dedicated- ``` Version 1.8 onwards, run: ``` $ kubectl taint nodes --all node-role.kubernetes.io/master- ``` One (or more) CNI plugin(s) installed, e.g., Calico, Weave, Flannel Use this to install Calico Use this to install Weave Use this to install Flannel We install genie as a Docker Container on every node Till Kubernetes 1.7 version: ``` $ kubectl apply -f https://raw.githubusercontent.com/cni-genie/CNI-Genie/master/conf/1.5/genie.yaml ``` Kubernetes 1.8 version onwards: ``` $ kubectl apply -f https://raw.githubusercontent.com/cni-genie/CNI-Genie/master/releases/v2.0/genie.yaml ``` Note that you should install genie first before making changes to the source. This ensures genie conf file is generated successfully. After making changes to source, build genie binary by running: ``` $ make all ``` Place "genie" binary from dest/ into /opt/cni/bin/ directory. ``` $ cp dist/genie /opt/cni/bin/genie ``` To run ginkgo tests for CNI-Genie run the following command: If Kubernetes cluster is 1.7+ ``` $ make test testKubeVersion=1.7 testKubeConfig=/root/admin.conf ``` If Kubernetes cluster is 1.5.x ``` $ make test testKubeVersion=1.5 ``` For now Genie logs are stored in /var/log/syslog To see the logs: ``` $ cat /dev/null > /var/log/syslog $ tail -f /var/log/syslog | grep 'CNI' ``` Note: one a single node cluster, after your Kubernetes master is initialized successfully, make sure you are able to schedule pods on the master by running: ``` $ kubectl taint nodes --all node-role.kubernetes.io/master- ``` Note: most plugins use differenet installation files for Kuberenetes 1.5, 1.6, 1.7 & 1.8. Make sure you use the right one!