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

sidebar_position: 7 sidebar_label: "PV and PVC" The PersistentVolume subsystem provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed. To do this, we introduce two new API resources: PersistentVolume (PV) and PersistentVolumeClaim (PVC). A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes. It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system. A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory). Claims can request specific size and access modes (e.g., they can be mounted ReadWriteOnce, ReadOnlyMany or ReadWriteMany, see AccessModes). While PersistentVolumeClaims allow a user to consume abstract storage resources, it is common that users need PersistentVolumes with varying properties, such as performance, for different problems. Cluster administrators need to be able to offer a variety of PersistentVolumes that differ in more ways than size and access modes, without exposing users to the details of how those volumes are implemented. For these needs, there is the StorageClass resource. It is used to mark storage resources and performance, and dynamically provision appropriate PV resources based on PVC demand. After the mechanism of StorageClass and dynamic provisioning developed for storage resources, the on-demand creation of volumes is realized, which is an important step in the automatic management process of shared storage. See also the official documentation provided by Kubernetes:
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_policy.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage policy related BPF maps ``` -h, --help help for policy ``` ``` --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 - Add/update policy entry - Delete a policy entry - Get contents of a policy BPF map - Dump all policy maps
Project: Kilo (Runtime / Cloud Native Network)
File: vpn-server.md

The cluster VPN created by Kilo can also be used by peers as a gateway to access the Internet. In order configure a local machine to use the cluster VPN as a gateway to the Internet, first register the local machine as a peer of the cluster following the steps in the . Once the machine is registered, generate the configuration for the local peer: ```shell PEER=squat # name of the registered peer kgctl showconf peer $PEER > peer.ini ``` Next, the WireGuard configuration must be modified to enable routing traffic for any IP via a node in the cluster. To do so, open the WireGuard configuration in an editor, select a node in the cluster, and set the `AllowedIPs` field of that node's corresponding `peer` section to `0.0.0.0/0, ::/0`: ```shell $EDITOR peer.ini ``` The configuration should now look something like: ```ini [Peer] PublicKey = 2/xU029dz/WtvMZAbnSzmhicl8U1/Y3NYmunRr8EJ0Q= AllowedIPs = 0.0.0.0/0, ::/0 Endpoint = 108.61.142.123:51820 ``` The configuration can then be applied to the local WireGuard interface, e.g. `wg0`: ```shell IFACE=wg0 sudo wg setconf $IFACE peer.ini ``` Next, add routes for the public IPs of the WireGuard peers to ensure that the packets encapsulated by WireGuard are sent through a real interface: ```shell default=$(ip route list all | grep default | awk '{$1=""; print $0}') for ip in $(sudo wg | grep endpoint | awk '{print $2}' | sed 's/\(.\+\):[0-9]\+/\1/'); do sudo ip route add $ip $default done ``` Finally, the local machine can be configured to use the WireGuard interface as the device for the default route: ```shell sudo ip route delete default sudo ip route add default dev $IFACE ``` The local machine is now using the selected node as its Internet gateway and the connection can be verified. For example, try finding the local machine's external IP address: ```shell curl https://icanhazip.com ```
Project: Velero (Runtime / Cloud Native Storage)
File: ark_plugin_remove.md

title: "ark plugin remove" layout: docs Remove a plugin Remove a plugin ``` ark plugin remove [NAME | IMAGE] [flags] ``` ``` -h, --help help for remove ``` ``` --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 ``` - Work with plugins
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_ipmasq_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List ip-masq-agent CIDRs List ip-masq-agent CIDRs. Packets sent from pods to IPs from these CIDRs avoid masquerading. ``` cilium-dbg bpf ipmasq 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 ``` - ip-masq-agent CIDRs
Project: CubeFS (Runtime / Cloud Native Storage)
File: metanode.md

Get information of all metaNodes, including ID, address, read/write status, and survival status. ```bash cfs-cli metanode list ``` Show basic information of the metaNode, including status, usage, and the ID of the partition it carries. ```bash cfs-cli metanode info [Address] ``` Decommission the metaNode. The partitions on this node will be automatically transferred to other available nodes. ```bash cfs-cli metanode decommission [Address] ``` Transfer the meta partition on the source metaNode to the target metaNode. ```bash cfs-cli metanode migrate [srcAddress] [dstAddress] ```
Project: containerd (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: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-generic_completion_powershell.md

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> Generate the autocompletion script for powershell Generate the autocompletion script for powershell. To load completions in your current shell session: cilium-operator-generic completion powershell | Out-String | Invoke-Expression To load completions for every new session, add the output of the above command to your powershell profile. ``` cilium-operator-generic completion powershell [flags] ``` ``` -h, --help help for powershell --no-descriptions disable completion descriptions ``` - Generate the autocompletion script for the specified shell
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_ip_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List IP addresses in the userspace IPcache ``` cilium-dbg ip list [flags] ``` ``` -h, --help help for list -n, --numeric Print numeric identities -o, --output string json| yaml| jsonpath='{}' -v, --verbose Print all fields of ipcache ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage IP addresses and associated information
Project: Spiderpool (Runtime / Cloud Native Network)
File: contributing.md

Welcome to Kubernetes. We are excited about the prospect of you joining our ! The Kubernetes community abides by the CNCF . Here is an excerpt: 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 have full documentation on how to get started contributing here: <! If your repo has certain guidelines for contribution, put them here ahead of the general k8s resources --> Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests - Main contributor documentation, or you can just jump directly to the - Common resources for existing developers - We have a diverse set of mentorship programs available that are always looking for volunteers! <! Custom Information - if you're copying this template for the first time you can add custom content here, for example: - Replace `kubernetes-users` with your slack channel string, this will send users directly to your channel. -->
Project: Kube-router (Runtime / Cloud Native Network)
File: architecture.md

Kube-router is built around concept of watchers and controllers. Watchers use Kubernetes watch API to get notification on events related to create, update, delete of Kubernetes objects. Each watcher gets notification related to a particular API object. On receiving an event from API server, watcher broadcasts events. Controller registers to get event updates from the watchers and act up on the events. Kube-router consists of 3 core controllers and multiple watchers as depicted in below diagram. Each of the follows below structure: ```go func Run() { for { Sync() // control loop that runs for ever and perfom sync at periodic interval } } func OnUpdate() { Sync() // on receiving update of a watched API object (namespace, node, pod, network policy etc) } Sync() { //re-concile any state changes } Cleanup() { // cleanup any changes (to iptables, ipvs, network etc) done to the system } ```
Project: CubeFS (Runtime / Cloud Native Storage)
File: HELM.md

The repository can help you deploy CubeFS cluster quickly in containers orchestrated by kubernetes. Kubernetes 1.12+ and Helm 3 are required. cubefs-helm has already integrated CubeFS CSI plugin ``` $ git clone https://github.com/cubefs/cubefs-helm $ cd cubefs-helm ``` CubeFS CSI driver will use client-go to connect the Kubernetes API Server. First you need to copy the kubeconfig file to `cubefs-helm/cubefs/config/` directory, and rename to kubeconfig ``` $ cp ~/.kube/config cubefs/config/kubeconfig ``` Create a `cubefs.yaml` file, and put it in a user-defined path. Suppose this is where we put it. ``` $ cat ~/cubefs.yaml ``` ``` yaml path: data: /cubefs/data log: /cubefs/log datanode: disks: /data0:21474836480 /data1:21474836480 metanode: total_mem: "26843545600" provisioner: kubelet_path: /var/lib/kubelet ``` Note that `cubefs-helm/cubefs/values.yaml` shows all the config parameters of CubeFS. The parameters `path.data` and `path.log` are used to store server data and logs, respectively. You should tag each Kubernetes node with the appropriate labels accorindly for server node and CSI node of CubeFS. ``` kubectl label node <nodename> cubefs-master=enabled kubectl label node <nodename> cubefs-metanode=enabled kubectl label node <nodename> cubefs-datanode=enabled kubectl label node <nodename> cubefs-csi-node=enabled ``` ``` $ helm install cubefs ./cubefs -f ~/cubefs.yaml ```
Project: Multus (Runtime / Cloud Native Network)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_ipcache_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List endpoint IPs (local and remote) and their corresponding security identities List endpoint IPs (local and remote) and their corresponding security identities. ``` cilium-dbg bpf ipcache 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 IPCache mappings for IP/CIDR <-> Identity
Project: Velero (Runtime / Cloud Native Storage)
File: upgrade-to-1.8.md

title: "Upgrading to Velero 1.8" layout: docs Velero installed. If you're not yet running at least Velero v1.6, see the following: Before upgrading, check the to make sure your version of Kubernetes is supported by the new version of Velero. Install the Velero v1.8 command-line interface (CLI) by following the . Verify that you've properly installed it by running: ```bash velero version --client-only ``` You should see the following output: ```bash Client: Version: v1.8.0 Git commit: <git SHA> ``` Update the Velero custom resource definitions (CRDs) to include schema changes across all CRDs that are at the core of the new features in this release: ```bash velero install --crds-only --dry-run -o yaml | kubectl apply -f - ``` NOTE: Since velero v1.8.0 only v1 CRD will be supported during installation, therefore, the v1.8.0 will only work on kubernetes version >= v1.16 Update the container image used by the Velero deployment and, optionally, the restic daemon set: ```bash kubectl set image deployment/velero \ velero=velero/velero:v1.8.0 \ --namespace velero kubectl set image daemonset/restic \ restic=velero/velero:v1.8.0 \ --namespace velero ``` Confirm that the deployment is up and running with the correct version by running: ```bash velero version ``` You should see the following output: ```bash Client: Version: v1.8.0 Git commit: <git SHA> Server: Version: v1.8.0 ``` We have deprecated the way to indicate the default backup storage location. Previously, that was indicated according to the backup storage location name set on the velero server-side via the flag `velero server --default-backup-storage-location`. Now we configure the default backup storage location on the velero client-side. Please refer to the on how to indicate which backup storage location is the default one. After upgrading, if there is a previously created backup storage location with the name that matches what was defined on the server side as the default, it will be automatically set as the `default`.
Project: Velero (Runtime / Cloud Native Storage)
File: 01-google-cloud-platform.md

title: Google Cloud Platform (GCP) link: https://github.com/vmware-tanzu/velero-plugin-for-gcp objectStorage: true volumesnapshotter: true supportedByVeleroTeam: true This repository contains an object store plugin and a volume snapshotter plugin to support running Velero on Google Cloud Platform.
Project: lxd (Runtime / Container Runtime)
File: network_macvlan.md

(network-macvlan)= <!-- Include start macvlan intro --> Macvlan is a virtual {abbr}`LAN (Local Area Network)` that you can use if you want to assign several IP addresses to the same network interface, basically splitting up the network interface into several sub-interfaces with their own IP addresses. You can then assign IP addresses based on the randomly generated MAC addresses. <!-- Include end macvlan intro --> The `macvlan` 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. ```{note} If you are using a `macvlan` network, communication between the Incus host and the instances is not possible. Both the host and the instances can talk to the gateway, but they cannot communicate directly. ``` (network-macvlan-options)= The following configuration key namespaces are currently supported for the `macvlan` network type: `user` (free-form key/value for user metadata) ```{note} {{noteipaddresses_CIDR}} ``` The following configuration options are available for the `macvlan` network type: Key | Type | Condition | Default | Description :-- | :-- | :-- | :-- | :-- `gvrp` | bool | - | `false` | Register VLAN using GARP VLAN Registration Protocol `mtu` | integer | - | - | The MTU of the new interface `parent` | string | - | - | Parent interface to create `macvlan` NICs on `vlan` | integer | - | - | The VLAN ID to attach to `user.*` | string | - | - | User-provided free-form key/value pairs
Project: StratoVirt (Runtime / Container Runtime)
File: README.md

Hydropper is a lightweight test framework based on pytest. It encapsulates virtualization-related test atoms and is used for stratovirt black-box tests.Hydropper has provided some testcases for lightweight virtualization and standard virtualization to help Developers find and locate Stratovirt problems. Ensure that python3 has been installed on your openEuler system. The requirements.txt file contains the Python3 dependency package. pytest>5.0.0 aexpect>1.5.0 retrying You can install these packages by running the following commands: ```sh $ pip3 install -r requirements.txt ``` Network dependency package: ```sh $ yum install nmap $ yum install iperf3 $ yum install bridge-utils ``` Network configurationtemplate ```sh brctl addbr strato_br0 ip link set strato_br0 up ip address add 1.1.1.1 dev strato_br0 ``` For details about how to build a test image, see docs/IMAGE_BUILD.md. Set parameters and corresponding paths in the config/config.ini. Generally, the kernel and rootfs must be configured for test cases. ```ini [env.params] ... VM_USERNAME = <usrname> VM_PASSWORD = <passwd> ... [stratovirt.params] ... STRATOVIRT_VMLINUX = /path/to/kernel STRATOVIRT_ROOTFS = /path/to/rootfs ... ``` Configure IPPREFIX and IP3RD in the "config.ini" file, which indicate the first 24 bits of the VM IPv4 address, The last 8 bits are automatically configured by the hydropper. Note that the VM and the host must be in the same network segment. ```ini [network.params] IP_PREFIX = 1.1 IP_3RD = 1 ``` You can run the following commands in the hydroper directory to execute cases: ```sh $ pytest $ pytest -k microvm $ pytest testcases/microvm/functional/testmicrovmcmdline.py $ pytest testcases/microvm/functional/testmicrovmcmdline.py::testmicrovmwithout_daemonize ``` Add customized cases to the microvm directory under testcases.You can add a python file or add a function to an existing python file.The file name and function name must be in the format of test_*. ```python testmicrovmxxx.py def testmicrovmxxx() ``` We have preset some virtual machine objects. You can test the virtual machine by generating their instances ```python def testmicrovmxxx(microvm): test_vm = microvm test_vm.launch() ``` In addition, Fixture is useful to write testcases.You can use Fixture in the following ways: ```python @pytest.mark.system def testmicrovmxxx(microvm): test_vm = microvm test_vm.launch() ``` Now you can use the pytest -m system command to run all the "system" cases. You can use the basic_config() function to configure VM parameters ```python def testmicrovmxxx(microvm): test_vm = microvm testvm.basicconfig(vcpucount=4, memsize='4G') test_vm.launch() ``` pytest default log path: /var/log/pytest.log stratovirt default log path: /var/log/stratovirt
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_sha_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List BPF template objects. ``` cilium-dbg bpf sha 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 compiled BPF template objects