cwielenb/CNCF-Dataset huggingface dataset:
Project: Kube-router (Runtime / Cloud Native Network)
File: health.md

kube-router currently has basic health checking in form of heartbeats sent from each controller to the healthcontroller each time the main loop completes successfully. The health port is by default 20244 but can be changed with the startup option. The health path is `/healthz` ```sh --health-port=<port number> ``` If port is set to 0 (zero) no HTTP endpoint will be made available but the health controller will still run and print out any missed heartbeats to STDERR of kube-router If a controller does not send a heartbeat within controllersynctime + 5 seconds the component will be flagged as unhealthy. If any of the running components is failing the whole kube-router state will be marked as failed in the /healthz endpoint For example, if kube-router is started with ```sh --run-router=true --run-firewall=true --run-service-proxy=true --run-loadbalancer=true ``` If the route controller, policy controller or service controller exits it's main loop and does not publish a heartbeat the `/healthz` endpoint will return a error 500 signaling that kube-router is not healthy.
Project: Carina (Runtime / Cloud Native Storage)
File: disk-manager.md

```yaml apiVersion: v1 kind: ConfigMap metadata: name: carina-csi-config namespace: kube-system labels: class: carina data: config.json: |- { "diskSelector": [ { "name": "carina-vg-ssd", "re": ["loop2+"], "policy": "LVM", "nodeLabel": "kubernetes.io/hostname" }, { "name": "carina-raw-hdd", "re": ["vdb+", "sd+"], "policy": "RAW", "nodeLabel": "kubernetes.io/hostname" } ], "diskScanInterval": "300", # disk scan interval in seconds "diskGroupPolicy": "type", # the policy to group local disks "schedulerStrategy": "spreadout" # binpack or spreadout } ``` Each carina-node will scan local disks and group them into different groups. ```shell $ kubectl exec -it csi-carina-node-cmgmm -c csi-carina-node -n kube-system bash $ pvs PV VG Fmt Attr PSize PFree /dev/vdc carina-vg-hdd lvm2 a-- <80.00g <79.95g /dev/vdd carina-vg-hdd lvm2 a-- <80.00g 41.98g $ vgs VG #PV #LV #SN Attr VSize VFree carina-vg-hdd 2 10 0 wz--n- 159.99g <121.93g ``` With `"diskSelector": ["loop+", "vd+"]`and `diskGroupPolicy: LVM`, carina will create below VG: ```shell $ kubectl exec -it csi-carina-node-cmgmm -c csi-carina-node -n kube-system bash $ pvs PV VG Fmt Attr PSize PFree /dev/loop0 carina-vg-hdd lvm2 a-- <80.00g <79.95g /dev/loop1 carina-vg-hdd lvm2 a-- <80.00g 79.98g $ vgs VG #PV #LV #SN Attr VSize VFree carina-vg-hdd 2 10 0 wz--n- 159.99g <121.93g ``` If changing diskSelector to `"diskSelector": ["loop0", "vd+"]`, then carina will automatically remove related disks. ```shell $ kubectl exec -it csi-carina-node-cmgmm -c csi-carina-node -n kube-system bash $ pvs PV VG Fmt Attr PSize PFree /dev/loop0 carina-vg-hdd lvm2 a-- <80.00g <79.95g $ vgs VG #PV #LV #SN Attr VSize VFree carina-vg-hdd 1 10 0 wz--n- 79.99g <79.93g ```
Project: Flannel (Runtime / Cloud Native Network)
File: code-of-conduct.md

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. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a project maintainer, Brandon Philips <brandon.philips@coreos.com>, and/or Rithu John <rithu.john@coreos.com>. This Code of Conduct is adapted from the Contributor Covenant (http://contributor-covenant.org), version 1.2.0, available at http://contributor-covenant.org/version/1/2/0/ CoreOS events are working conferences intended for professional networking and collaboration in the CoreOS community. Attendees are expected to behave according to professional standards and in accordance with their employers policies on appropriate workplace behavior. While at CoreOS events or related social networking opportunities, attendees should not engage in discriminatory or offensive speech or actions including but not limited to gender, sexuality, race, age, disability, or religion. Speakers should be especially aware of these concerns. CoreOS does not condone any statements by speakers contrary to these standards. CoreOS reserves the right to deny entrance and/or eject from an event (without refund) any individual found to be engaging in discriminatory or offensive speech or actions. Please bring any concerns to the immediate attention of designated on-site staff, Brandon Philips <brandon.philips@coreos.com>, and/or Rithu John <rithu.john@coreos.com>.
Project: Gluster (Runtime / Cloud Native Storage)
File: brickmux-thread-reduction.md

Each brick is regresented with a graph of translators in a brick process. Each translator in the graph has its own set of threads and mem pools and other system resources allocations. Most of the times all these resources are not put to full use. Reducing the resource consumption of each brick is a problem in itself that needs to be addressed. The other aspect to it is, sharing of resources across brick graph, this becomes critical in brick multiplexing scenario. In this document we will be discussing only about the threads. If a brick mux process hosts 50 bricks there are atleast 600+ threads created in that process. Some of these are global threads that are shared by all the brick graphs, and others are per translator threads. The global threads like synctask threads, timer threads, sigwaiter, poller etc. are configurable and do not needs to be reduced. The per translator threads keeps growing as the number of bricks in the process increases. Each brick spawns atleast 10+ threads: io-threads posix threads: Janitor Fsyncer Helper aio-thread changelog and bitrot threads(even when the features are not enabled) io-threads should be made global to the process, having 16+ threads for each brick does not make sense. But io-thread translator is loaded in the graph, and the position of io-thread translator decides from when the fops will be parallelised across threads. We cannot entirely move the io-threads to libglusterfs and say the multiplexing happens from the primary translator or so. Hence, the io-thread orchestrator code is moved to libglusterfs, which ensures there is only one set of io-threads that is shared among the io-threads translator in each brick. This poses performance issues due to lock-contention in the io-threds layer. This also shall be addressed by having multiple locks instead of one global lock for io-threads. Most of the posix threads execute tasks in a timely manner, hence it can be replaced with a timer whose handler register a task to synctask framework, once the task is complete, the timer is registered again. With this we can eliminate the need of one thread for each task. The problem with using synctasks is the performance impact it will have due to make/swapcontext. For task that does not involve network wait, we need not do makecontext, instead the task function with arg can be stored and executed when a synctask thread is free. We need to implement an api in synctask to execute atomic tasks(no network wait) without the overhead of make/swapcontext. This will solve the performance impact associated with using synctask framework. And the other challenge, is to cancel all the tasks pending from a translator. This is important to cleanly detach brick. For this, we need to implement an api in synctask that can cancel all the tasks from a given translator. For future, this will be replced to use global thread-pool(once implemented). In the initial implementation, the threads are not created if the feature is not enabled. We need to share threads across changelog instances if we plan to enable these features in brick mux scenario.
Project: CRI-O (Runtime / Container Runtime)
File: kubeadm.md

This tutorial assumes you've already installed and setup CRI-O. If you have not, start . It also assumes you've set up your system to use kubeadm. If you haven't done so, kubeadm expects a POD Network CIDR (`--pod-network-cidr`) to be defined when you install the cluster. The value of `--pod-network-cidr` depends on which CNI plugin you choose. <!-- markdownlint-disable MD013 --> | CNI Plugin | CIDR | Notes | | -- | - | -- | | Bridge plugin (default) | 10.85.0.0/16 | The default bridge plugin is defined . This is only suitable when your cluster has a single node. | | Flannel | 10.244.0.0/16 | This is a good choice for clusters with multiple nodes. | <!-- markdownlint-enable MD013 --> For example, to use the script below with the bridge plugin, run `export CIDR=10.85.0.0/16`. A list of CNI plugins can be found in the Kubernetes documentation. Each plugin will define its own default CIDR. Given you've set CIDR, and assuming you've set the `cgroup_driver` in your CRI-O configuration as `systemd` (which is the default value), all you need to do is start crio (as defined ), and run: `kubeadm init --pod-network-cidr=$CIDR --cri-socket=unix:///var/run/crio/crio.sock` We will assume that the user has installed CRI-O and all necessary packages. We will also assume that all necessary components are configured and everything is working as expected. The user should have a private repo where the container images are pushed. An example of container images for Kubernetes version 1.18.2: ```bash $ kubeadm config images list --image-repository user.private.repo --kubernetes-version=v1.18.2 user.private.repo/kube-apiserver:v1.18.2 user.private.repo/kube-controller-manager:v1.18.2 user.private.repo/kube-scheduler:v1.18.2 user.private.repo/kube-proxy:v1.18.2 user.private.repo/pause:3.2 user.private.repo/etcd:3.4.3-0 user.private.repo/coredns:1.6.7 ``` The user needs to configure the file. Sample of configurations: ```bash $ cat /etc/containers/registries.conf unqualified-search-registries = ["user.private.repo"] [[registry]] prefix = "registry.k8s.io" insecure = false blocked = false location = "registry.k8s.io" [[registry.mirror]] location = "user.private.repo" ``` Next the user should reload and restart the CRI-O service to load the configurations.
Project: lxd (Runtime / Container Runtime)
File: instance_properties.md

(instance-properties)= Instance properties are set when the instance is created. They cannot be part of a {ref}`profile <profiles>`. The following instance properties are available: ```{list-table} :header-rows: 1 :widths: 2 1 4 - Property Read-only Description - `name` yes Instance name (see {ref}`instance-name-requirements`) - `architecture` no Instance architecture ``` (instance-name-requirements)= The instance name can be changed only by renaming the instance with the command. Valid instance names must fulfill the following requirements: The name must be between 1 and 63 characters long. The name must contain only letters, numbers and dashes from the ASCII table. The name must not start with a digit or a dash. The name must not end with a dash. The purpose of these requirements is to ensure that the instance name can be used in DNS records, on the file system, in various security profiles and as the host name of the instance itself.
Project: HwameiStor (Runtime / Cloud Native Storage)
File: adopters.md

HwameiStor have been used by a number of organizations and users both at PROD or UAT environments. The following is a list that have used HwameiStor. The actual names cannot be made public due to privacy policies: | Organization | Stateful Workloads | Environment | | :-- | :-- | :- | | A bank in SouthWest China | ElasticSearch, MySQL, Prometheus, Registry | PROD, UAT | | A multinational retailer | ElasticSearch, MySQL, Prometheus, PostgresDB, Registry | PROD, UAT | | A retailer in South China | Prometheus, PostgresDB, Registry | PROD | | A IIoT in East China | ElasticSearch, MySQL, Prometheus, Registry | PROD | | A bank in Central China | ElasticSearch, MySQL, Prometheus, PostgresDB, Registry | PROD | | A bank in East China | ElasticSearch, MySQL, Prometheus, PostgresDB, Registry | UAT | | A media in North China | ElasticSearch, MySQL, Prometheus, Registry | PROD | | An IT company in East China | ElasticSearch, MySQL, Prometheus, PostgresDB, Registry | PROD | PROD: production environment UAT: user acceptance testing environment
Project: lxd (Runtime / Container Runtime)
File: index.md

Incus is a modern, secure and powerful system container and virtual machine manager. % Include content from ```{include} ../README.md :start-after: <!-- Include start Incus intro --> :end-before: <!-- Include end Incus intro --> ``` % Include content from ```{include} ../README.md :start-after: <!-- Include start security --> :end-before: <!-- Include end security --> ``` See for detailed information. ````{important} % Include content from ```{include} ../README.md :start-after: <!-- Include start security note --> :end-before: <!-- Include end security note --> ``` ```` Incus is free software and developed under the . Its an open source project that warmly welcomes community projects, contributions, suggestions, fixes and constructive feedback. (see if needed) ```{toctree} :hidden: :titlesonly: self Getting Started </tutorial/first_steps> General </general> Client </client> Server </server> Instances </instances> Storage </storage> Networks </networks> Images </images> Projects </projects> Clustering </clustering> API </api> Security </security> Internals </internals> External resources </external_resources> ```
Project: lxd (Runtime / Container Runtime)
File: standard_devices.md

(standard-devices)= Incus provides each instance with the basic devices that are required for a standard POSIX system to work. These devices aren't visible in the instance or profile configuration, and they may not be overridden. The standard devices are: | Device | Type of device | |:|:| | `/dev/null` | Character device | | `/dev/zero` | Character device | | `/dev/full` | Character device | | `/dev/console` | Character device | | `/dev/tty` | Character device | | `/dev/random` | Character device | | `/dev/urandom` | Character device | | `/dev/net/tun` | Character device | | `/dev/fuse` | Character device | | `lo` | Network interface | Any other devices must be defined in the instance configuration or in one of the profiles used by the instance. The default profile typically contains a network interface that becomes `eth0` in the instance.
Project: CubeFS (Runtime / Cloud Native Storage)
File: UPDATE.md

add batch consume kafka msg for scheduler, to solve handle blob delete msg too slow. remove kafka client manage offset local, let kafka server manage offset. upgrade action 1.Back up old version stop switch check status get current kafka offset ``` shell curl -XPOST --header 'Content-Type: application/json' http://$ip:$port/config/set -d '{"key":"blob_delete", "value":"false"}' curl -XPOST --header 'Content-Type: application/json' http://$ip:$port/config/set -d '{"key":"shard_repair", "value":"false"}' curl http://$ip:$port/config/get?key=blob_delete curl $ip2:$port2/metrics | grep kafkatopicpartitionoffset | grep consume > metricoffset.log ``` e.g. metric_offset.log: It has 4 kafka partitions kafkatopicpartitionoffset{clusterid="102",modulename="SCHEDULER",partition="1",topic="blobdelete_102",type="consume"} 1.2053985e+07 kafkatopicpartitionoffset{clusterid="102",modulename="SCHEDULER",partition="2",topic="blobdelete_102",type="consume"} 1.2051438e+07 kafkatopicpartitionoffset{clusterid="102",modulename="SCHEDULER",partition="3",topic="blobdelete_102",type="consume"} 1234 kafkatopicpartitionoffset{clusterid="102",modulename="SCHEDULER",partition="4",topic="blobdelete_102",type="consume"} 1025 2.Set kafka offset batch set kafka offset ``` shell DIR="/xxx/kafka_2.12-2.3.1-host/bin" # kafka path EXEC="kafka-consumer-groups.sh" HOST="192.168.0.3:9095" # kafka host TOPIC="blobdelete102" GROUP="SCHEDULER-$TOPIC" arrayoffset=(12053985 12051438 1234 1025) # From the file above(metricoffset.log) echo "set consumer offset... ${TOPIC} ${GROUP}" cd $DIR for i in {0..63} # number of kafka partitions do echo " $i : ${array_offset[$i]}" ./$EXEC --bootstrap-server $HOST --reset-offsets --topic ${TOPIC}:$i --group ${GROUP} --to-offset ${array_offset[$i]} --execute done echo "all done..." cd - ``` 3.update new version config file stop old version, and install new version open switch ``` json { "blob_delete": { "maxbatchsize": 10, # batch consumption size of kafka messages, default is 10. If the batch is full or the time interval is reached, consume the Kafka messages accumulated during this period "batchintervals": 2, # time interval for consuming kafka messages, default is 2s "messageslowdowntimes": 3, # slow down when overload, default is 3s } } ``` ``` shell curl -XPOST --header 'Content-Type: application/json' http://$ip:$port/config/set -d '{"key":"blob_delete", "value":"true"}' curl -XPOST --header 'Content-Type: application/json' http://$ip:$port/config/set -d '{"key":"shard_repair", "value":"true"}' curl http://$ip:$port/config/get?key=blob_delete ```
Project: CRI-O (Runtime / Container Runtime)
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, education, socio-economic status, 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 urfave-governance@googlegroups.com, a members-only group that is world-postable. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and 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 https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
Project: Rook (Runtime / Cloud Native Storage)
File: operator-chart.gotmpl.md

title: Ceph Operator Helm Chart {{ template "generatedDocsWarning" . }} Installs to create, configure, and manage Ceph clusters on Kubernetes. This chart bootstraps a deployment on a cluster using the package manager. Kubernetes 1.22+ Helm 3.x See the for more details. The Ceph Operator helm chart will install the basic components necessary to create a storage platform for your Kubernetes cluster. Install the Helm chart . The `helm install` command deploys rook on the Kubernetes cluster in the default configuration. The section lists the parameters that can be configured during installation. It is recommended that the rook operator be installed into the `rook-ceph` namespace (you will install your clusters into separate namespaces). Rook currently publishes builds of the Ceph operator to the `release` and `master` channels. The release channel is the most recent release of Rook that is considered stable for the community. ```console helm repo add rook-release https://charts.rook.io/release helm install --create-namespace --namespace rook-ceph rook-ceph rook-release/rook-ceph -f values.yaml ``` For example settings, see the next section or The following table lists the configurable parameters of the rook-operator chart and their default values. {{ template "chart.valuesTable" . }} To deploy from a local build from your development environment: Build the Rook docker image: `make` Copy the image to your K8s cluster, such as with the `docker save` then the `docker load` commands Install the helm chart: ```console cd deploy/charts/rook-ceph helm install --create-namespace --namespace rook-ceph rook-ceph . ``` To see the currently installed Rook chart: ```console helm ls --namespace rook-ceph ``` To uninstall/delete the `rook-ceph` deployment: ```console helm delete --namespace rook-ceph rook-ceph ``` The command removes all the Kubernetes components associated with the chart and deletes the release. After uninstalling you may want to clean up the CRDs as described on the .
Project: iSulad (Runtime / Container Runtime)
File: README.md

This user manual is made to assist users in using iSulad. `iSulad` can be integrated with kubernetes through the CRI interface. For integrating with kubernetes, please refer to . Device Mapper is a kernel-based framework that underpins many advanced volume management technologies on Linux. For devicemapper environment preparation, please refer to . If you want to use native network in iSulad, please refer to . If you want to Setup bridge network for Container, please refer to . If you want to run iSulad with a non-root user, please refer to . If you want to use isula search, please refer to .