cwielenb/CNCF-Dataset huggingface dataset:
Project: Longhorn (Runtime / Cloud Native Storage)
File: 20230309-recurring-filesystem-trim.md

Longhorn currently supports the feature, which allows users to reclaim volume disk spaces of deleted files. However, this is a manual process, which can be time-consuming and inconvenient. To improve user experience, Longhorn could automate the process by implementing a new RecurringJob `filesystem-trim` type. This enhancement enables regularly freeing up unused volume spaces and reducing the need for manual interventions. https://github.com/longhorn/longhorn/issues/5186 Introduce a new recurring job type called `filesystem-trim` to periodically trim the volume filesystem to reclaim disk spaces. `None` To extend the RecurringJob custom resource definition by adding new `RecurringJobType: filesystem-trim`. To schedule regular volume filesystem trims, user can create a RecurringJob with `spec.task=filesystem-trim` and associating it with volumes. The user sees workload volume size has increased over time. Create RecurringJob with the `filesystem-trim` task type and assign it to the volume. ```yaml apiVersion: longhorn.io/v1beta2 kind: RecurringJob metadata: name: recurring-fs-trim-per-min namespace: longhorn-system spec: concurrency: 1 cron: ' *' groups: [] labels: {} name: recurring-fs-trim-per-min retain: 0 task: filesystem-trim ``` The RecurringJob runs and relaims some volume spaces. `None` Call Volume API `ActionTrimFilesystem` when the RecurringJob type is `filesystem-trim`. Mutate the `Recurringjob.Spec.Retain` to 0 when the task type is `filesystem-trim` as it is not effective for this type of task. Create workload. Create a file with some data in the workload. Volume actual size should increase. Delete the file. Volume actual size should not decrease. Create RecurringJob with type `filesystem-trim` and assign to the workload volume. Wait for RecurringJob to complete. Volume actual size should decrease. `None` `None`
Project: WasmEdge Runtime (Runtime / Container Runtime)
File: ecosystem.md

WasmEdge (formerly SSVM) is a high performance and enterprise-ready WebAssembly (WASM) Virtual Machine for cloud, AI, and Blockchain applications. The `WasmEdge` ecosystem can be separated into the above layers. Core: The . Plug-ins: The extensions of `WASM` host functions with their dependencies. contains the host function extensions which access to . contains the host function extensions about `JPEG` and `PNG` image decodings. contains the host function extensions which access to . contains the host function extensions that are compatible with . Tools: The runtime executables. are the released tools to execute WASM with accessing to `TensorFlow` or `TensorFlow-Lite`. Language supports: The `WasmEdge` triggering in other languages. The is embedded in the core release as a header file and shared library. is the Node.js addon project for `WASM` functions. is the Node.js addon project for `WASM` runtime with `wasmedge-tensorflow`, `wasmedge-image`, and `wasmedge-storage` extensions. is the binding for `WasmEdge` C API. is the Rust binding for `WasmEdge` C API.
Project: Longhorn (Runtime / Cloud Native Storage)
File: 20230418-azure-blob-storage-backup-store-support.md

Longhorn supports Azure Blob Storage as a backup storage. https://github.com/longhorn/longhorn/issues/1309 Support Azure Blob Storage as a backup storage. Introduce Azure Blob Storage client for supporting Azure Blob Storage as a backup storage. Longhorn already supports NFSv4, CIFS and S3 servers as backup storage. However, certain users may still want to be able to utilize Azure blob storage to push/pull backups to/from. Users can configure a Azure Blob Storage as a backup storage Set Backup Target. The path to a Azure Blob Storage is like ```bash azblob://${container}@blob.core.windows.net/${path name} ``` Set Backup Target Credential Secret Create a secret and deploy it ```yaml apiVersion: v1 kind: Secret metadata: name: azblob-secret namespace: longhorn-system type: Opaque data: AZBLOBACCOUNTNAME: ${AZBLOBACCOUNTNAME} AZBLOBACCOUNTKEY: ${AZBLOBACCOUNTKEY} ``` Set the setting Backup Target Credential Secret to `azblob-secret` longhorn-manager Introduce the fields `AZBLOBACCOUNTNAME` and `AZBLOBACCOUNTKEY` in credentials. The two fields are passed to engine and replica processes for volume backup and restore operations. backupstore Implement Azure Blob Storage register/unregister and basic CRUD functions. Set a Azure Blob Storage as backup storage. Create volumes and write some data. Back up volumes to the backup storage and the operation should succeed. Restore backups and operations should succeed. All data is not corrupted.
Project: Velero (Runtime / Cloud Native Storage)
File: rbac.md

title: "Run Velero more securely with restrictive RBAC settings" layout: docs By default Velero runs with an RBAC policy of ClusterRole `cluster-admin`. This is to make sure that Velero can back up or restore anything in your cluster. But `cluster-admin` access is wide open -- it gives Velero components access to everything in your cluster. Depending on your environment and your security needs, you should consider whether to configure additional RBAC policies with more restrictive access. Note: Roles and RoleBindings are associated with a single namespaces, not with an entire cluster. PersistentVolume backups are associated only with an entire cluster. This means that any backups or restores that use a restrictive Role and RoleBinding pair can manage only the resources that belong to the namespace. You do not need a wide open RBAC policy to manage PersistentVolumes, however. You can configure a ClusterRole and ClusterRoleBinding that allow backups and restores only of PersistentVolumes, not of all objects in the cluster. For more information about RBAC and access control generally in Kubernetes, see the Kubernetes documentation about , , and . Here's a sample Role and RoleBinding pair. ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: YOURNAMESPACEHERE name: ROLENAMEHERE labels: component: velero rules: apiGroups: velero.io verbs: "*" resources: "*" ``` ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: ROLEBINDINGNAMEHERE subjects: kind: ServiceAccount name: YOURSERVICEACCOUNTHERE roleRef: kind: Role name: ROLENAMEHERE apiGroup: rbac.authorization.k8s.io ```
Project: runc (Runtime / Container Runtime)
File: runc-kill.8.md

% runc-kill "8" runc-kill - send a specified signal to container runc kill container-id [signal] By default, runc kill sends SIGTERM to the container's initial process only. A different signal can be specified either by its name (with or without the SIG prefix), or its numeric value. Use kill(1) with -l option to list available signals. The following will send a KILL signal to the init process of the ubuntu01 container: runc(1).
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_multicast_group_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List the multicast groups. List the multicast groups configured on the node. ``` cilium-dbg bpf multicast group 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 multicast groups.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_map_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List all open BPF maps ``` cilium-dbg map list [flags] ``` ``` cilium map list ``` ``` -h, --help help for list -o, --output string json| yaml| jsonpath='{}' --verbose Print cache contents of all maps ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Access userspace cached content of BPF maps
Project: Velero (Runtime / Cloud Native Storage)
File: _template.md

Note: The preferred style for design documents is one sentence per line. Do not wrap lines. This aids in review of the document as changes to a line are not obscured by the reflowing those changes caused and has a side effect of avoiding debate about one or two space after a period. Note: The name of the file should follow the name pattern `<short meaningful words joined by '-'>_design.md`, e.g: `listener-design.md`. One to two sentences that describes the goal of this proposal and the problem being solved by the proposed change. The reader should be able to tell by the title, and the opening paragraph, if this document is relevant to them. One to two paragraphs of exposition to set the context for this proposal. A short list of things which will be accomplished by implementing this proposal. Two things is ok. Three is pushing it. More than three goals suggests that the proposal's scope is too large. A short list of items which are: a. out of scope b. follow on items which are deliberately excluded from this proposal. One to two paragraphs that describe the high level changes that will be made to implement this proposal. A detailed design describing how the changes to the product should be made. The names of types, fields, interfaces, and methods should be agreed on here, not debated in code review. The same applies to changes in CRDs, YAML examples, and so on. Ideally the changes should be made in sequence so that the work required to implement this design can be done incrementally, possibly in parallel. If there are alternative high level or detailed designs that were not pursued they should be called out here with a brief explanation of why they were not pursued. If this proposal has an impact to the security of the product, its users, or data stored or transmitted via the product, they must be addressed here. A discussion of any compatibility issues that need to be considered A description of the implementation, timelines, and any resources that have agreed to contribute. A discussion of issues relating to this proposal for which the author does not know the solution. This section may be omitted if there are none.
Project: DatenLord (Runtime / Cloud Native Storage)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: '' assignees: '' Datenlord Version If your test is on master branch, put 'master' here. If your test is on a release, put the release number here. Describe the bug and reproduce steps A clear and concise description of what the bug is and the steps to reproduce it. Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Desktop (please complete the following information): OS: [e.g. Ubuntu 20.04] CPU Arch [e.g. amd64] Kernel Version: [e.g. 5.0] Additional context Add any other context about the problem here.
Project: Soda Foundation (Runtime / Cloud Native Storage)
File: tsc.md

OpenSDS Technical Steering Commitee To provide technical guidance for OpenSDS community development. Anjaneya Chagam (Intel) Rakesh Jain (IBM) Allen Samuels (WD/SanDisk) Steven Tan (Huawei) Jay Bryant (Lenovo) Shinya Hamano (Fujitsu) This meeting is hosted on zoom. Join the TSC mailing list for info on meetings Zoom Meeting: https://zoom.us/j/477192859 Or iPhone one-tap : US: +19294362866,,477192859# or +16699006833,,477192859# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 669 900 6833 Meeting ID: 477 192 859 International numbers available: https://zoom.us/zoomconference?m=h0x5xsxAwYrgrrKRsEx7PLkOfvL3bm Q1 2017 Documents
Project: Spiderpool (Runtime / Cloud Native Network)
File: configmap.md

Instructions for global configuration and environment arguments of Spiderpool. Configmap "spiderpool-conf" is the global configuration of Spiderpool. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: spiderpool-conf namespace: kube-system data: conf.yml: | ipamUnixSocketPath: /var/run/spidernet/spiderpool.sock enableIPv4: true enableIPv6: true enableStatefulSet: true enableKubevirtStaticIP: true enableSpiderSubnet: true clusterSubnetDefaultFlexibleIPNumber: 1 ``` `ipamUnixSocketPath` (string): Spiderpool agent listens to this UNIX socket file and handles IPAM requests from IPAM plugin. `enableIPv4` (bool): `true`: Enable IPv4 IP allocation capability of Spiderpool. `false`: Disable IPv4 IP allocation capability of Spiderpool. `enableIPv6` (bool): `true`: Enable IPv6 IP allocation capability of Spiderpool. `false`: Disable IPv6 IP allocation capability of Spiderpool. `enableStatefulSet` (bool): `true`: Enable StatefulSet static IP capability of Spiderpool. `false`: Disable StatefulSet static IP capability of Spiderpool. `enableKubevirtStaticIP` (bool): `true`: Enable kubevirt VM static IP capability of Spiderpool. `false`: Disable kubevirt VM static IP capability of Spiderpool. `enableSpiderSubnet` (bool): `true`: Enable SpiderSubnet capability of Spiderpool. `false`: Disable SpiderSubnet capability of Spiderpool. `clusterSubnetDefaultFlexibleIPNumber` (int): Global SpiderSubnet default flexible IP number. It takes effect across the cluster.
Project: FabEdge (Runtime / Cloud Native Network)
File: CONTRIBUTING.md

Before you get started Code of Conduct Getting started Contributor Workflow Creating Pull Requests Code Review Testing Please make sure to read and observe our . Fork the repository on GitHub Read the for deployment. We will help you to contribute in different areas like filing issues, developing features, fixing bugs and getting your work reviewed and merged. Please do not ever hesitate to ask a question or send a pull request. This is a rough outline of what a contributor's workflow looks like: Create a topic branch from where to base the contribution. This is usually master. Make commits of logical units. Make sure commit messages are in the proper format (see below). Push changes in a topic branch to a personal fork of the repository. Submit a pull request The PR must receive an approval from maintainers. FabEdge generally follows the standard process. To make it easier for your PR to receive reviews, consider the reviewers will need you to: follow . write . break large changes into a logical series of smaller patches which individually make easily understandable changes, and in aggregate solve a broader issue. We follow a rough convention for commit messages that is designed to answer two questions: what changed and why. The subject line should feature the what and the body of the commit should describe the why. ``` agent: add test codes for manager this add some unit test codes to improve code coverage for agent Fixes #666 ``` The format can be described more formally as follows: ``` <subsystem>: <what changed> <BLANK LINE> <why this change was made> <BLANK LINE> <footer> ``` The first line is the subject and should be no longer than 70 characters, the second line is always blank, and other lines should be wrapped at 80 characters. This allows the message to be easier to read on GitHub as well as in various git tools. Note: if your pull request isn't getting enough attention, you can use the reach out on Slack to get help finding reviewers. There are multiple types of tests. The location of the test code varies with type, as do the specifics of the environment needed to successfully run the test: Unit: These confirm that a particular function behaves as intended. Unit test source code can be found adjacent to the corresponding source code within a given package. These are easily run locally by any developer. Integration: These tests cover interactions of package components or interactions between components and Kubernetes control plane components like API server. End-to-end ("e2e"): These are broad tests of overall system behavior and coherence. Continuous integration will run these tests on PRs.
Project: Longhorn (Runtime / Cloud Native Storage)
File: CHANGELOG-1.4.2.md

Longhorn v1.4.2 is the latest stable version of Longhorn 1.4. It introduces improvements and bug fixes in the areas of stability, performance, space efficiency, resilience, and so on. Please try it out and provide feedback. Thanks for all the contributions! For the definition of stable or latest release, please check . Please ensure your Kubernetes cluster is at least v1.21 before installing v1.4.2. Longhorn supports 3 installation ways including Rancher App Marketplace, Kubectl, and Helm. Follow the installation instructions . Please read the first and ensure your Kubernetes cluster is at least v1.21 before upgrading to Longhorn v1.4.2 from v1.3.x/v1.4.x, which are only supported source versions. Follow the upgrade instructions . N/A Please follow up on about any outstanding issues found after this release. ) - @yangchiu @PhanLe1010 ) - @yangchiu @ChanYiLin ) - @mantissahz @chriscchien ) - @weizhe0422 @roger-ryao ) - @ChanYiLin @chriscchien ) - @PhanLe1010 @khushboo-rancher ) - @yangchiu @PhanLe1010 ) - @mantissahz @smallteeths @roger-ryao ) - @PhanLe1010 @roger-ryao ) - @yangchiu @ChanYiLin ) - @weizhe0422 @roger-ryao ) - @derekbit @roger-ryao ) - @derekbit @chriscchien ) - @derekbit @roger-ryao ) - @ejweber @chriscchien ) - @ChanYiLin @chriscchien ) - @ChanYiLin @roger-ryao ) - @yangchiu @derekbit ) - @ChanYiLin @roger-ryao ) - @mantissahz @roger-ryao ) - @yangchiu @derekbit ) - @derekbit @roger-ryao ) - @yangchiu @c3y1huang ) - @smallteeths @chriscchien ) - @PhanLe1010 @chriscchien ) - @yangchiu @PhanLe1010 ) - @PhanLe1010 @roger-ryao ) - @ejweber @roger-ryao ) - @shuo-wu @chriscchien ) - @c3y1huang @roger-ryao ) - @derekbit @roger-ryao ) - @yangchiu @shuo-wu @ChanYiLin @PhanLe1010 @c3y1huang @chriscchien @derekbit @ejweber @innobead @khushboo-rancher @mantissahz @roger-ryao @shuo-wu @smallteeths @weizhe0422 @yangchiu
Project: containerd (Runtime / Container Runtime)
File: decryption.md

This document describes the method to configure encrypted container image decryption for `containerd` for use with the `cri` plugin. Encrypted container images are OCI images which contain encrypted blobs. These encrypted images can be created through the use of . To decrypt these images, the `containerd` runtime uses information passed from the `cri` such as keys, options and encryption metadata. Encryption ties trust to an entity based on the model in which a key is associated with it. We call this the key model. One such usecase is when we want to tie the trust of a key to the node in a cluster. In this case, we call it the "node" or "host" Key Model. Future work will include more key models to facilitate other trust associations (i.e. for multi-tenancy). In this model encryption is tied to worker nodes. The usecase here revolves around the idea that an image should be decryptable only on trusted host. Using this model, various node based technologies which help bootstrap trust in worker nodes and perform secure key distribution (i.e. TPM, host attestation, secure/measured boot). In this scenario, runtimes are capable of fetching the necessary decryption keys. An example of this is using the . This is the default model since containerd v1.5. For containerd v1.4, you need to add the following configuration to `/etc/containerd/config.toml` and restart the `containerd` service manually. ```toml version = 2 [plugins."io.containerd.grpc.v1.cri".image_decryption] key_model = "node" [stream_processors] [stream_processors."io.containerd.ocicrypt.decoder.v1.tar.gzip"] accepts = ["application/vnd.oci.image.layer.v1.tar+gzip+encrypted"] returns = "application/vnd.oci.image.layer.v1.tar+gzip" path = "ctd-decoder" args = ["--decryption-keys-path", "/etc/containerd/ocicrypt/keys"] env= ["OCICRYPTKEYPROVIDERCONFIG=/etc/containerd/ocicrypt/ocicrypt_keyprovider.conf"] [stream_processors."io.containerd.ocicrypt.decoder.v1.tar"] accepts = ["application/vnd.oci.image.layer.v1.tar+encrypted"] returns = "application/vnd.oci.image.layer.v1.tar" path = "ctd-decoder" args = ["--decryption-keys-path", "/etc/containerd/ocicrypt/keys"] env= ["OCICRYPTKEYPROVIDERCONFIG=/etc/containerd/ocicrypt/ocicrypt_keyprovider.conf"] ``` In this example, container image decryption is set to use the "node" key model. In addition, the decryption are configured as specified in , with the additional field `--decryption-keys-path` configured to specify where decryption keys are located locally in the node. The `$OCICRYPTKEYPROVIDERCONFIG` environment variable is used for .
Project: OpenEBS (Runtime / Cloud Native Storage)
File: community_support_process.md

OpenEBS uses GitHub Projects to track the slack support tasks. A new tracker is created for each month. The monthly community trackers can be found . The trackers are used to ensure that feedback from the community is available in a format that can be consumed by contributors and maintainers. The OpenEBS maintainers, contributors, and users provide community support via or through the Kubernetes Slack workspace. For details on joining the slack, please see the instructions . One or more of the OpenEBS contributors may also take up the additional responsibility of curating the tickets coming through the community support channels and update the Community Tracker. Add new tickets: Read through the created during the duration of the month, E.g. For the project, we'll look at posts created during the month of April, 2021. Add new queries as cards in the `New` section. For queries which already have their own GitHub issue, add the issue card into the `New` section. Add a link to the slack thread in the card to add context to the ticket. Update existing tickets: Issues which have been engaged need to move out of the `New` section. If the slack conversation is active and progressing, move the card to the `In progress` section. If the conversation needs feedback from the user to progress, move the card to the `Waiting on user feedback` section. Reach resolution: Issues which reach resolution should ideally have a line or two describing how it was resolved. Issues may reach resolution in one of 3 ways (4 sections)... Resolved -- Move cards to this section when user's query has been resolved, and no code or documentation change could be recommended. Needs quick update to code / Needs quick update to docs -- Move cards to this section if the resolution demands a change in OpenEBS code/documentation. All cards in these sections have to be linked to a GitHub issue. The cards in this section should reach the `Done` section when their respective GitHub issues close. Pushed into roadmap -- Move cards to this section if changes suggested in the ticket are going to be implemented at a later date, but not immediately. Discussing with the repo maintainers is a good way to find out if a ticket should be a part of the roadmap.