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

For most of the local storage projects, once pod has been scheduled to node and the pod will use the local pv from that node. That means the pod has been nailed to that node and if node fails, the pod will not migrate to other nodes. With carina, user can allow the pod to migrate in such case with one annotation. Using LVM backend engine, checking current LV first. ```shell $ kubectl get lv NAME SIZE GROUP NODE STATUS pvc-177854eb-f811-4612-92c5-b8bb98126b94 5Gi carina-vg-hdd 10.20.9.154 Success pvc-1fed3234-ff89-4c58-8c65-e21ca338b099 5Gi carina-vg-hdd 10.20.9.153 Success pvc-527b5989-3ac3-4d7a-a64d-24e0f665788b 10Gi carina-vg-hdd 10.20.9.154 Success pvc-b987d27b-39f3-4e74-9465-91b3e6b13837 3Gi carina-vg-hdd 10.20.9.154 Success $ kubectl delete node 10.20.9.154 $ kubectl get lv NAME SIZE GROUP NODE STATUS pvc-177854eb-f811-4612-92c5-b8bb98126b94 5Gi carina-vg-hdd 10.20.9.153 Success pvc-1fed3234-ff89-4c58-8c65-e21ca338b099 5Gi carina-vg-hdd 10.20.9.153 Success pvc-527b5989-3ac3-4d7a-a64d-24e0f665788b 10Gi carina-vg-hdd 10.20.9.153 Success pvc-b987d27b-39f3-4e74-9465-91b3e6b13837 3Gi carina-vg-hdd 10.20.9.153 Success ``` LV has one:one mapping with local volume. Carina will delete local volume if it does't have an associated LV every 600s. Carina will delete LV if it doesn't have an associated PV every 600s. If node been deleted, all volumes will be rebuild on other nodes. Carina will track each node's status. If node enters NotReady state, carina will trigger pod migration policy. Carina will allow pod to migrate if it has annotation `carina.storage.io/allow-pod-migration-if-node-notready` with value of `true`. Carina will not copy data from failed node to other node. So the newly borned pod will have an empty PV. The middleware layer should trigger data migration. For example, master-slave mysql cluster should trigger master-slave replication.
Project: Project Calico (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 links to issues that this PR addresses --> <!-- If appropriate, include a link to the issue this fixes. fixes <ISSUE LINK> If appropriate, add links to any number of PRs documented by this PR documents <PR LINK> --> [ ] 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 TBD ``` Make sure that this PR has the correct labels and milestone set. Every PR needs one `docs-*` label. `docs-pr-required`: This change requires a change to the documentation that has not been completed yet. `docs-completed`: This change has all necessary documentation completed. `docs-not-required`: This change has no user-facing impact and requires no docs. Every PR needs one `release-note-*` label. `release-note-required`: This PR has user-facing changes. Most PRs should have this label. `release-note-not-required`: This PR has no user-facing changes. Other optional labels: `cherry-pick-candidate`: This PR should be cherry-picked to an earlier release. For bug fixes only. `needs-operator-pr`: This PR is related to install and requires a corresponding change to the operator.
Project: Velero (Runtime / Cloud Native Storage)
File: ark_create_restore.md

title: "ark create restore" layout: docs Create a restore Create a restore ``` ark create restore [RESTORENAME] --from-backup BACKUPNAME [flags] ``` ``` ark restore create restore-1 --from-backup backup-1 ark restore create --from-backup backup-1 ``` ``` --exclude-namespaces stringArray namespaces to exclude from the restore --exclude-resources stringArray resources to exclude from the restore, formatted as resource.group, such as storageclasses.storage.k8s.io --from-backup string backup to restore from -h, --help help for restore --include-cluster-resources optionalBool[=true] include cluster-scoped resources in the restore --include-namespaces stringArray namespaces to include in the restore (use '' for all namespaces) (default ) --include-resources stringArray resources to include in the restore, formatted as resource.group, such as storageclasses.storage.k8s.io (use '*' for all resources) --label-columns stringArray a comma-separated list of labels to be displayed as columns --labels mapStringString labels to apply to the restore --namespace-mappings mapStringString namespace mappings from name in the backup to desired restored name in the form src1:dst1,src2:dst2,... -o, --output string Output display format. For create commands, display the object but do not send it to the server. Valid formats are 'table', 'json', and 'yaml'. --restore-volumes optionalBool[=true] whether to restore volumes from snapshots -l, --selector labelSelector only restore resources matching this label selector (default <none>) --show-labels show labels in the last column ``` ``` --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 ``` - Create ark resources
Project: iSulad (Runtime / Container Runtime)
File: k8s_websockets_problem.md

| Author | Ilya Kuksenok | | | - | | Date | 2022-12-19 | | Email | | Right now in Kubectl supports only , protocol for cp and port forwarding. SPDY was deprecated a few years ago and now should be switched to something else, for example or . Visual representation of the problem As you can see on this diagram, SPDY is widely used in communication between all necessary components. Desired communication diagram. This section should help you to understand why websockets approach still wasn't implemented in current k8s implementation. Is this issue community trying to deside is it ok to use HTTP/2 or no and generaly speaking, this is not a best idea because websockets are already used in some parts of k8s, like in kubelet. In this case if HTTP/2 will be implemented consistency in the project will be broken . and nevertheless looks like all faced problems until now have been resolved, but now they dont have any sort of consesus about HTTP/2 or other possible ways of SPDY deprecation. In the issue Kubernetes team discussing faced problems related to SPDY -> websockets migration. As for now, Websockets are highly used in API server and kubelet, for example, starting from version release-1.19, look for details. Right now some big parts of k8s are already using websockets; if you look closely to the source code you will find that main websocket library is a part of standard package , also you can find gorilla/websockets package. In other words, the k8s community is actively trying to remove SPDY. This package uses SPDY for container control and communication, for example . There were several tryouts about untroducing websockets into kubetcl, for example: 1) Protocol related issue 2) will be by the . Lets discuss these problems in a more detailed manner. Problem definition: Websocket protocol does not support half-close feature look at , exactly to and for more detailed info, but at the same time SPDY it. In case of SPDY this behavior is defined by FLAG_FIN, in case of websockets we dont have same possibility out of the box. According to to have some sort of half-close feature implementation would be very useful, for more details please look and . Based on this are required, this will allow to fix existing issues, like half-closed connections without big troubles, and in future it will prevent other possible websocket relaterd issues. 1) Break backward compatibility with old clients 2) Huge amount of refactoring (current implementation is hardly tired to SPDY) As I have already mentioned, already archived, and we or anyone else should not use it in any production scenario, even in case of MEDIUM CVE (described in paragraph 4 table 12 of ) or any other CVE, we cant get a fix from the package developer and we will have to fix it on our end which is bad in terms of user and developer experience. Because of declared issues K8S developers community finally made a decision to drop SPDY and move to websockets , but new protocol still in development stage, as for now development process looks frozen and no concrete plan of development was introduced, but at least process started.
Project: HwameiStor (Runtime / Cloud Native Storage)
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: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_config_get.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Retrieve cilium configuration ``` cilium-dbg config get <config name> [flags] ``` ``` -h, --help help for get -o, --output string json| yaml| jsonpath='{}' ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Cilium configuration options
Project: Velero (Runtime / Cloud Native Storage)
File: ark_backup_get.md

title: "ark backup get" layout: docs Get backups Get backups ``` ark backup get [flags] ``` ``` -h, --help help for get --label-columns stringArray a comma-separated list of labels to be displayed as columns -o, --output string Output display format. For create commands, display the object but do not send it to the server. Valid formats are 'table', 'json', and 'yaml'. (default "table") -l, --selector string only show items matching this label selector --show-labels show labels in the last column ``` ``` --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 backups
Project: Piraeus Datastore (Runtime / Cloud Native Storage)
File: k0s.md

This guide shows you how to configure Piraeus Datastore when using . To complete this guide, you should be familiar with: editing `LinstorCluster` resources. Because k0s store their state in a separate directory (`/var/lib/k0s`) the LINSTOR CSI Driver needs to be updated to use a new path for mounting volumes. To change the LINSTOR CSI Driver, so that it uses the k0s state paths, apply the following `LinstorCluster`: ```yaml apiVersion: piraeus.io/v1 kind: LinstorCluster metadata: name: linstorcluster spec: csiNode: enabled: true podTemplate: spec: containers: name: linstor-csi volumeMounts: mountPath: /var/lib/k0s/kubelet name: publish-dir mountPropagation: Bidirectional name: csi-node-driver-registrar args: --v=5 --csi-address=/csi/csi.sock --kubelet-registration-path=/var/lib/k0s/kubelet/plugins/linstor.csi.linbit.com/csi.sock --health-port=9809 volumes: name: publish-dir hostPath: path: /var/lib/k0s/kubelet name: registration-dir hostPath: path: /var/lib/k0s/kubelet/plugins_registry name: plugin-dir hostPath: path: /var/lib/k0s/kubelet/plugins/linstor.csi.linbit.com ```
Project: Kilo (Runtime / Cloud Native Network)
File: api.md

This document is a reference of the API types introduced by Kilo. Note: this document is generated from code comments. When contributing a change to this document, please do so by changing the code comments. DNSOrIP represents either a DNS name or an IP address. When both are given, the IP address, as it is more specific, override the DNS name. | Field | Description | Scheme | Required | | -- | -- | | -- | | dns | DNS must be a valid RFC 1123 subdomain. | string | false | | ip | IP must be a valid IP address. | string | false | Peer is a WireGuard peer that should have access to the VPN. | Field | Description | Scheme | Required | | -- | -- | | -- | | metadata | Standard objects metadata. More info: https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#metadata | | false | | spec | Specification of the desired behavior of the Kilo Peer. More info: https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md#spec-and-status | | true | PeerEndpoint represents a WireGuard endpoint, which is an IP:port tuple. | Field | Description | Scheme | Required | | -- | -- | | -- | | dnsOrIP | DNSOrIP is a DNS name or an IP address. | | true | | port | Port must be a valid port number. | uint32 | true | PeerList is a list of peers. | Field | Description | Scheme | Required | | -- | -- | | -- | | metadata | Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds | | false | | items | List of peers. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md | | true | PeerSpec is the description and configuration of a peer. | Field | Description | Scheme | Required | | -- | -- | | -- | | allowedIPs | AllowedIPs is the list of IP addresses that are allowed for the given peer's tunnel. | []string | true | | endpoint | Endpoint is the initial endpoint for connections to the peer. | * | false | | persistentKeepalive | PersistentKeepalive is the interval in seconds of the emission of keepalive packets by the peer. This defaults to 0, which disables the feature. | int | false | | presharedKey | PresharedKey is the optional symmetric encryption key for the peer. | string | false | | publicKey | PublicKey is the WireGuard public key for the peer. | string | true |
Project: Alluxio (Runtime / Cloud Native Storage)
File: FUSE-SDK-Overview.md

layout: global title: FUSE SDK Overview The Alluxio POSIX API is a feature that allows mounting training datasets in specific storage services (e.g. S3, HDFS) to the local filesystem and provides caching capabilities to speed up I/O access to frequently used data. There are two kinds of caching capabilities: 1. local caching only 2. local caching + distributed caching. Differences between the two solutions are listed below, choose your desired solution based on training requirements and available resources. <table class="table table-striped"> <tr> <th>Category</th> <th>Local Caching</th> <th>Distributed Caching</th> </tr> <tr> <td>Prerequisite</td> <td>N/A</td> <td>Require a running Alluxio cluster (master + worker)</td> </tr> <tr> <td>Caching Capability</td> <td>Bounded by local storage size</td> <td>Bounded by Alluxio cluster storage size</td> </tr> <tr> <td>Suited Workloads</td> <td>Single node training with large dataset. Distributed training with no data shuffle between nodes</td> <td>Multiple training nodes or training tasks share the same dataset</td> </tr> </table> See to quickly setup your FUSE SDK local cache solution which can connects to your desired storage services. provides different local cache capabilities to speed up your workloads and reduce the pressure of storage services. [Local Kernel Data Cache Configuration]({{ '/en/fuse-sdk/Local-Cache-Tuning.html#local-kernel-data-cache-configuration' | relativize_url }}) [Local Userspace Data Cache Configuration]({{ '/en/fuse-sdk/Local-Cache-Tuning.html#local-userspace-data-cache-configuration' | relativize_url }}) [Local Kernel Metadata Cache Configuration]({{ '/en/fuse-sdk/Local-Cache-Tuning.html#local-kernel-metadata-cache-configuration' | relativize_url }}) [Local Userspace Metadata Cache Configuration]({{ '/en/fuse-sdk/Local-Cache-Tuning.html#local-userspace-metadata-cache-configuration' | relativize_url }}) provides advanced FUSE SDK tuning tips for performance optimization or debugging. FUSE SDK can connect to a shared distributed caching service. For more information, please refer to
Project: Kata Containers (Runtime / Container Runtime)
File: ConsoleConfig.md

Name | Type | Description | Notes | - | - | - File | Pointer to string | | [optional] Socket | Pointer to string | | [optional] Mode | string | | Iommu | Pointer to bool | | [optional] [default to false] `func NewConsoleConfig(mode string, ) *ConsoleConfig` NewConsoleConfig instantiates a new ConsoleConfig 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 NewConsoleConfigWithDefaults() *ConsoleConfig` NewConsoleConfigWithDefaults instantiates a new ConsoleConfig 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 *ConsoleConfig) GetFile() string` GetFile returns the File field if non-nil, zero value otherwise. `func (o ConsoleConfig) GetFileOk() (string, bool)` GetFileOk returns a tuple with the File field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *ConsoleConfig) SetFile(v string)` SetFile sets File field to given value. `func (o *ConsoleConfig) HasFile() bool` HasFile returns a boolean if a field has been set. `func (o *ConsoleConfig) GetSocket() string` GetSocket returns the Socket field if non-nil, zero value otherwise. `func (o ConsoleConfig) GetSocketOk() (string, bool)` GetSocketOk returns a tuple with the Socket field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *ConsoleConfig) SetSocket(v string)` SetSocket sets Socket field to given value. `func (o *ConsoleConfig) HasSocket() bool` HasSocket returns a boolean if a field has been set. `func (o *ConsoleConfig) GetMode() string` GetMode returns the Mode field if non-nil, zero value otherwise. `func (o ConsoleConfig) GetModeOk() (string, bool)` GetModeOk returns a tuple with the Mode field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *ConsoleConfig) SetMode(v string)` SetMode sets Mode field to given value. `func (o *ConsoleConfig) GetIommu() bool` GetIommu returns the Iommu field if non-nil, zero value otherwise. `func (o ConsoleConfig) GetIommuOk() (bool, bool)` GetIommuOk returns a tuple with the Iommu field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *ConsoleConfig) SetIommu(v bool)` SetIommu sets Iommu field to given value. `func (o *ConsoleConfig) HasIommu() bool` HasIommu returns a boolean if a field has been set.