cwielenb/CNCF-Dataset huggingface dataset:
Project: Cilium (Runtime / Cloud Native Network)
File: README.md

](https://pkg.go.dev/sigs.k8s.io/json) This library is a subproject of . It provides case-sensitive, integer-preserving JSON unmarshaling functions based on `encoding/json` `Unmarshal()`. The `UnmarshalCaseSensitivePreserveInts()` function behaves like `encoding/json#Unmarshal()` with the following differences: JSON object keys are treated case-sensitively. Object keys must exactly match json tag names (for tagged struct fields) or struct field names (for untagged struct fields). JSON integers are unmarshaled into `interface{}` fields as an `int64` instead of a `float64` when possible, falling back to `float64` on any parse or overflow error. Syntax errors do not return an `encoding/json` `*SyntaxError` error. Instead, they return an error which can be passed to `SyntaxErrorOffset()` to obtain an offset. The `UnmarshalStrict()` function decodes identically to `UnmarshalCaseSensitivePreserveInts()`, and also returns non-fatal strict errors encountered while decoding: Duplicate fields encountered Unknown fields encountered You can reach the maintainers of this project via the . Participation in the Kubernetes community is governed by the . tails. Example ```Go package main import ( "fmt" "log" "gopkg.in/yaml.v2" ) var data = ` a: Easy! b: c: 2 d: [3, 4] ` // Note: struct fields must be public in order for unmarshal to // correctly populate the data. type T struct { A string B struct { RenamedC int `yaml:"c"` D []int `yaml:",flow"` } } func main() { t := T{} err := yaml.Unmarshal([]byte(data), &t) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" t:\n%v\n\n", t) d, err := yaml.Marshal(&t) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" t dump:\n%s\n\n", string(d)) m := make(map[interface{}]interface{}) err = yaml.Unmarshal([]byte(data), &m) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" m:\n%v\n\n", m) d, err = yaml.Marshal(&m) if err != nil { log.Fatalf("error: %v", err) } fmt.Printf(" m dump:\n%s\n\n", string(d)) } ``` This example will generate the following output: ``` t: {Easy! {2 [3 4]}} t dump: a: Easy! b: c: 2 d: [3, 4] m: map[a:Easy! b:map[c:2 d:[3 4]]] m dump: a: Easy! b: c: 2 d: 3 4 ```
Project: lxd (Runtime / Container Runtime)
File: architectures.md

(architectures)= Incus can run on just about any architecture that is supported by the Linux kernel and by Go. Some entities in Incus are tied to an architecture, for example, the instances, instance snapshots and images. The following table lists all supported architectures including their unique identifier and the name used to refer to them. The architecture names are typically aligned with the Linux kernel architecture names. ID | Kernel name | Description | Personalities : | : | :- | : 1 | `i686` | 32bit Intel x86 | 2 | `x86_64` | 64bit Intel x86 | `x86` 3 | `armv7l` | 32bit ARMv7 little-endian | 4 | `aarch64` | 64bit ARMv8 little-endian | `armv7l` (optional) 5 | `ppc` | 32bit PowerPC big-endian | 6 | `ppc64` | 64bit PowerPC big-endian | `powerpc` 7 | `ppc64le` | 64bit PowerPC little-endian | 8 | `s390x` | 64bit ESA/390 big-endian | 9 | `mips` | 32bit MIPS | 10 | `mips64` | 64bit MIPS | `mips` 11 | `riscv32` | 32bit RISC-V little-endian | 12 | `riscv64` | 64bit RISC-V little-endian | 13 | `armv6l` | 32bit ARMv6 little-endian | 14 | `armv8l` | 32bit ARMv8 little-endian | 15 | `loongarch64` | 64bit Loongarch | ```{note} Incus cares only about the kernel architecture, not the particular userspace flavor as determined by the toolchain. That means that Incus considers ARMv7 hard-float to be the same as ARMv7 soft-float and refers to both as `armv7l`. If useful to the user, the exact userspace ABI may be set as an image and container property, allowing easy query. ``` Incus only supports running virtual-machines on the following host architectures: `x86_64` `aarch64` `ppc64le` `s390x` The virtual machine guest architecture can usually be the 32bit personality of the host architecture, so long as the virtual machine firmware is capable of booting it.
Project: Kanister (Runtime / Cloud Native Storage)
File: install.md

Kanister can be easily installed and managed with . You will need to configure your `kubectl` CLI tool to target the Kubernetes cluster you want to install Kanister on. Start by adding the Kanister repository to your local setup: ``` bash helm repo add kanister <https://charts.kanister.io/> ``` Use the `helm install` command to install Kanister in the `kanister` namespace: ``` bash helm -n kanister upgrade \--install kanister \--create-namespace kanister/kanister-operator ``` Confirm that the Kanister workloads are ready: ``` bash kubectl -n kanister get po ``` You should see the operator pod in the `Running` state: ``` bash NAME READY STATUS RESTARTS AGE kanister-kanister-operator-85c747bfb8-dmqnj 1/1 Running 0 15s ``` ::: tip NOTE Kanister is guaranteed to work with the 3 most recent versions of Kubernetes. For example, if the latest version of Kubernetes is 1.24, Kanister will work with 1.24, 1.23, and 1.22. Support for older versions is provided on a best-effort basis. If you are using an older version of Kubernetes, please consider upgrading to a newer version. ::: Use the `helm show values` command to list the configurable options: ``` bash helm show values kanister/kanister-operator ``` For example, you can use the `image.tag` value to specify the Kanister version to install. The source of the `values.yaml` file can be found on . The default RBAC settings in the Helm chart permit Kanister to manage and auto-update its own custom resource definitions, to ease the user\'s operation burden. If your setup requires the removal of these settings, you will have to install Kanister with the `--set controller.updateCRDs=false` option: ``` bash helm -n kanister upgade \--install kanister \--create-namespace kanister/kanister-operator \--set controller.updateCRDs=false ``` This option lets Helm manage the CRD resources. Kanister installation also creates a validating admission webhook server that is invoked each time a new Blueprint is created. By default the Helm chart is configured to automatically generate a self-signed certificates for Admission Webhook Server. If your setup requires custom certificates to be configured, you will have to install kanister with `--set bpValidatingWebhook.tls.mode=custom` option along with other certificate details. Create a Secret that stores the TLS key and certificate for webhook admission server: ``` bash kubectl create secret tls my-tls-secret \--cert /path/to/tls.crt \--key /path/to/tls.key -n kanister ``` Install Kanister, providing the PEM-encoded CA bundle and the [tls]{.title-ref} secret name like below: ``` bash helm upgrade \--install kanister kanister/kanister-operator \--namespace kanister \--create-namespace \--set bpValidatingWebhook.tls.mode=custom \--set bpValidatingWebhook.tls.caBundle=\$(cat /path/to/ca.pem \| base64 -w 0) \--set bpValidatingWebhook.tls.secretName=tls-secret ``` Follow the instructions in the `BUILD.md` file in the [Kanister GitHub repository](https://github.com/kanisterio/kanister/blob/master/BUILD.md) to build Kanister from source code.
Project: HwameiStor (Runtime / Cloud Native Storage)
File: lvm_volumes.md

sidebar_position: 1 sidebar_label: "LVM Volume" HwameiStor provides LVM-based data volumes, which offer read and write performance comparable to that of native disks. These data volumes also provide advanced features such as data volume expansion, migration, high availability, and more. The following steps demonstrate how to create a simple non-HA type data volume. Prepare LVM Storage Node Ensure that the storage node has sufficient available capacity. If there is not enough capacity, please refer to . Check for available capacity using the following command: ```console $ kubectl get localstoragenodes k8s-worker-2 -oyaml | grep freeCapacityBytes freeCapacityBytes: 10523508736 ``` Prepare StorageClass Create a StorageClass named `hwameistor-storage-lvm-ssd` using the following command: ```console $ cat << EOF | kubectl apply -f - apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: hwameistor-storage-lvm-ssd parameters: convertible: "false" csi.storage.k8s.io/fstype: xfs poolClass: SSD poolType: REGULAR replicaNumber: "1" striped: "true" volumeKind: LVM provisioner: lvm.hwameistor.io reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true EOF ``` Create Volume Create a PVC named `hwameistor-lvm-volume` using the following command: ```console $ cat << EOF | kubectl apply -f - apiVersion: v1 kind: PersistentVolumeClaim metadata: name: hwameistor-lvm-volume spec: accessModes: ReadWriteOnce resources: requests: storage: 1Gi storageClassName: hwameistor-storage-lvm-ssd EOF ```
Project: HwameiStor (Runtime / Cloud Native Storage)
File: uninstall.md

sidebar_position: 5 sidebar_label: "Uninstall" To ensure data security, it is strongly recommended not to uninstall the HwameiStor system in a production environment. This section introduces two uninstallation scenarios for testing environments. If you want to uninstall the HwameiStor components, but still keep the existing data volumes working with the applications, perform the following steps: ```console $ kubectl get cluster.hwameistor.io NAME AGE cluster-sample 21m $ kubectl delete clusters.hwameistor.io hwameistor-cluster ``` Finally, all the HwameiStor's components (i.e. Pods) will be deleted. Check by: ```bash kubectl -n hwameistor get pod ``` :::danger Before you start to perform actions, make sure you reallly want to delete all your data. ::: If you confirm to delete your data volumes and uninstall HwameiStor, perform the following steps: Clean up stateful applications. Delete stateful applications. Delete PVCs. The relevant PVs, LVs, LVRs, LVGs will also been deleted. Clean up HwameiStor components. Delete HwameiStor components. ```bash kubectl delete clusters.hwameistor.io hwameistor-cluster ``` Delete hwameistor namespace. ```bash kubectl delete ns hwameistor ``` Delete CRD, Hook, and RBAC. ```bash kubectl get crd,mutatingwebhookconfiguration,clusterrolebinding,clusterrole -o name \ | grep hwameistor \ | xargs -t kubectl delete ``` Delete StorageClass. ```bash kubectl get sc -o name \ | grep hwameistor-storage-lvm- \ | xargs -t kubectl delete ``` Delete hwameistor-operator. ```bash helm uninstall hwameistor-operator -n hwameistor ``` Finally, you still need to clean up the LVM configuration on each node, and also data on the disks by tools like . ```bash wipefs -a /dev/sdx blkid /dev/sdx ```
Project: Velero (Runtime / Cloud Native Storage)
File: ark_plugin.md

title: "ark plugin" layout: docs Work with plugins Work with plugins ``` -h, --help help for plugin ``` ``` --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 ``` - Back up and restore Kubernetes cluster resources. - Add a plugin - Remove a plugin
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_multicast_subscriber_delete.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Delete a subscriber from the multicast group. Delete a subscriber from the given multicast group. To delete remote subscriber, following information is required: group: multicast group address from which subscriber is deleted. subscriber-address: subscriber IP address ``` cilium-dbg bpf multicast subscriber delete <group> <subscriber-address> [flags] ``` ``` To delete a remote node 10.100.0.1 from multicast group 229.0.0.1, use the following command: cilium-dbg bpf multicast subscriber delete 229.0.0.1 10.100.0.1 ``` ``` -h, --help help for delete ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage the multicast subscribers.
Project: CubeFS (Runtime / Cloud Native Storage)
File: dentry.md

``` bash curl -v 'http://10.196.59.202:17210/getDentry?pid=100&name="aa.txt"&parentIno=1024' ``` | Parameter | Type | Description | |--||| | pid | integer | meta partition id | | name | string | directory or file name | | parentIno | integer | parent directory inode id | ``` bash curl -v 'http://10.196.59.202:17210/getDirectory?pid=100&parentIno=1024' ``` | Parameter | Type | Description | |--||--| | pid | integer | partition id | | ino | integer | inode id | ``` bash curl -v 'http://10.196.59.202:17210/getAllDentry?pid=100' ``` | Parameter | Type | Description | |--||--| | pid | integer | partition id |
Project: Alluxio (Runtime / Cloud Native Storage)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: type-bug assignees: '' Alluxio Version: What version of Alluxio are you using? Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior (as minimally and precisely as possible) Expected behavior A clear and concise description of what you expected to happen. Urgency Describe the impact and urgency of the bug. Are you planning to fix it Please indicate if you are already working on a PR. Additional context Add any other context about the problem here.
Project: HwameiStor (Runtime / Cloud Native Storage)
File: lda_controller.md

sidebar_position: 9 sidebar_label: "LDA Controller" The LDA controller provides a separate CRD - `LocalDiskAction`, which is used to match the localdisk and execute the specified action. Its yaml definition is as follows: ```yaml apiVersion: hwameistor.io/v1alpha1 kind: LocalDiskAction metadata: name: forbidden-1 spec: action: reserve rule: minCapacity: 1024 devicePath: /dev/rbd* apiVersion: hwameistor.io/v1alpha1 kind: LocalDiskAction metadata: name: forbidden-2 spec: action: reserve rule: maxCapacity: 1048576 devicePath: /dev/sd* ``` The above yaml indicates: Localdisks smaller than 1024 bytes and whose devicePath meets the `/dev/rbd*` matching condition will be reserved Localdisks larger than 1048576 bytes and whose devicePath meets the `/dev/sd*` matching condition will be reserved Note that the currently supported actions are only reserve.
Project: Velero (Runtime / Cloud Native Storage)
File: overview-plugins.md

title: "Velero plugin system" layout: docs Velero uses storage provider plugins to integrate with a variety of storage systems to support backup and snapshot operations. For server installation, Velero requires that at least one plugin is added (with the `--plugins` flag). The plugin will be either of the type object store or volume snapshotter, or a plugin that contains both. An exception to this is that when the user is not configuring a backup storage location or a snapshot storage location at the time of install, this flag is optional. Any plugin can be added after Velero has been installed by using the command `velero plugin add <registry/image:version>`. Example with a dockerhub image: `velero plugin add velero/velero-plugin-for-aws:v1.0.0`. In the same way, any plugin can be removed by using the command `velero plugin remove <registry/image:version>`. Anyone can add integrations for any platform to provide additional backup and volume storage without modifying the Velero codebase. To write a plugin for a new backup or volume storage platform, take a look at our and at our documentation for . After you publish your plugin on your own repository, open a PR that adds a link to it under the appropriate list of page in our documentation. You can also add the to your repo, and it will be shown under the aggregated list of repositories automatically.
Project: Kube-router (Runtime / Cloud Native Network)
File: load-balancer-allocator.md

The load balancer allocator controller looks for services with the type LoadBalancer and tries to allocate addresses for it if needed. The controller doesn't enable any announcement of the addresses by default, so `--advertise-loadbalancer-ip` should be set to true and BGP peers configured. By default the controller allocates addresses for all LoadBalancer services with the where `loadBalancerClass` is empty or set to one of "default" or "kube-router". If `--loadbalancer-default-class` is set to false, the controller will only handle services with the class set to "kube-router". The controller needs some extra permissions to get, create and update leases for leader election and to update services with allocated addresses. Example permissions: ```yaml kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: kube-router namespace: kube-system rules: apiGroups: "coordination.k8s.io" resources: leases verbs: get create update apiGroups: "" resources: services/status verbs: update ``` The controller uses the environment variable `POD_NAME` as the identify for the lease used for leader election. Using the kubernetes downward api to set `POD_NAME` to the pod name the lease identify will match the current leader. ```yaml apiVersion: apps/v1 kind: DaemonSet metadata: labels: k8s-app: kube-router tier: node name: kube-router namespace: kube-system spec: ... template: metadata: .... spec: ... env: name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name ... ``` The environment variable `POD_NAMESPACE` can also be specified to set the namespace used for the lease. By default the namespace is looked up from within the pod using `/var/run/secrets/kubernetes.io/serviceaccount/namespace`. When running the controller outside a pod, both `PODNAME` and `PODNAMESPACE` must set for the controller to work. `POD_NAME` should be unique per instance, so using for example the hostname of the machine might be a good idea. `POD_NAMESPACE` must be the same across all instances running in the same cluster. It's not possible to specify the addresses for the load balancer services. A externalIP service can be used instead.
Project: JuiceFS (Runtime / Cloud Native Storage)
File: upgrade.md

sidebar_position: 9 Upgrade methods vary with different JuiceFS clients. The JuiceFS client only has one binary file. So to upgrade the new version, you only need to replace the old one with the new one. Use pre-compiled client: Refer to for details. Manually compile client: You can pull the latest source code and recompile it to overwrite the old version of the client. Please refer to for details. :::caution For the file system that has been mounted using the old version of JuiceFS client, you need to , and then re-mount it with the new version of JuiceFS client. When unmounting the file system, make sure that no application is accessing it. Otherwise the unmount will fail. Do not forcibly unmount the file system, as it may cause the application unable to continue to access it as expected. ::: Please refer to to learn how to upgrade JuiceFS CSI Driver. Like , upgrading S3 Gateway is to replace the old version with the new version. If it is , you need to upgrade according to the specific deployment method, which is described in detail below. Download and modify the `juicedata/juicefs-csi-driver` image tag in S3 Gateway to the version you want to upgrade (see for a detailed description of all versions), and then run the following command: ```shell kubectl apply -f ./juicefs-s3-gateway.yaml ``` Please run the following commands in sequence to upgrade the S3 Gateway: ```shell helm repo update helm upgrade juicefs-s3-gateway juicefs-s3-gateway/juicefs-s3-gateway -n kube-system -f ./values.yaml ``` Please refer to to learn how to install the new version of the Hadoop Java SDK, and then follow steps in to redeploy the new version of the client to complete the upgrade. :::note Some components must be restarted to use the new version of the Hadoop Java SDK. Please refer to the for details. :::
Project: Kanister (Runtime / Cloud Native Storage)
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 listed in the file. 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/
Project: Ceph (Runtime / Cloud Native Storage)
File: MAINTAINERS.md

Maintainers are the default assignee for related tracker issues and pull requests. | Component | Name | ||| | auth, STS | Pritha Srivastava | | bucket index, resharding | J. Eric Ivancich | | bucket notifications | Yuval Lifshitz | | data caching | Mark Kogan | | garbage collection | Pritha Srivastava | | http frontends | Casey Bodley | | lifecycle | Matt Benjamin | | lua scripting | Yuval Lifshitz | | multisite | Casey Bodley | | object i/o | Casey Bodley | | rgw orchestration, admin APIs | Ali Maredia | | radosgw-admin | Daniel Gryniewicz | | rest ops | Daniel Gryniewicz | | rgw-nfs | Matt Benjamin | | performance | Mark Kogan | | s3 select | Gal Salomon | | storage abstraction layer | Daniel Gryniewicz | security (crypto, SSE, CVEs) swift api
Project: StratoVirt (Runtime / Container Runtime)
File: mk_initrd.md

``` shell wget https://busybox.net/downloads/busybox-1.36.1.tar.bz2 tar -xjf busybox-1.36.1.tar.bz2 ``` ``` shell make defconfig make menuconfig ``` NoticeCheck Build static binary, can build binary without dependence library. ```text Settings > [*] Build static binary (no shared libs) ``` Install the compiled BusyBox to default path: `_install`. ``` shell make install ``` ```shell cd _install mkdir proc sys dev etc etc/init.d touch etc/init.d/rcS cat >etc/init.d/rcS<<EOF mount -t proc none /proc mount -t sysfs none /sys /sbin/mdev -s EOF chmod +x etc/init.d/rcS ``` ```shell cd _install find . | cpio -o --format=newc > /tmp/StratoVirt-initrd ``` ```shell $ ./stratovirt \ -machine microvm \ -kernel /path/to/kernel \ -append "console=ttyS0 reboot=k panic=1 root=/dev/ram rdinit=/bin/sh" \ -initrd /tmp/StratoVirt-initrd \ -qmp unix:/path/to/socket,server,nowait \ -serial stdio ```