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

`ScaleWorkload` function can be used to scale a workload to specified replicas. It automatically sets the original replica count of the workload as output artifact, which makes using `ScaleWorkload` function in blueprints a lot easier. Below is an example of how this function can be used ``` yaml apiVersion: cr.kanister.io/v1alpha1 kind: Blueprint metadata: name: my-blueprint actions: backup: outputArtifacts: backupOutput: keyValue: origReplicas: "{{ .Phases.shutdownPod.Output.originalReplicaCount }}" phases: func: ScaleWorkload name: shutdownPod args: namespace: "{{ .StatefulSet.Namespace }}" name: "{{ .StatefulSet.Name }}" kind: StatefulSet replicas: 0 # this is the replica count, the STS will scaled to restore: inputArtifactNames: backupOutput phases: func: ScaleWorkload name: bringUpPod args: namespace: "{{ .StatefulSet.Namespace }}" name: "{{ .StatefulSet.Name }}" kind: StatefulSet replicas: "{{ .ArtifactsIn.backupOutput.KeyValue.origReplicas }}" ```
Project: Virtual Kubelet (Runtime / Container Runtime)
File: ADOPTERS.md

Microsoft Azure AWS Alibaba VMWare Netflix Hashi Corp Admiralty Elotl Tencent Games Since end-users are specific per provider within VK we have many end-user customers that we don't have permission to list publically. Please contact ribhatia@microsoft.com for more informtation. Are you currently using Virtual Kubelet in production? Please let us know by adding your company name and a description of your use case to this document!
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_sha.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage compiled BPF template objects ``` -h, --help help for sha ``` ``` --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 - Get datapath SHA header - List BPF template objects.
Project: kube-vip (Runtime / Cloud Native Network)
File: README.md

Prerequisites: Tests must be run on a Linux OS Docker installed with IPv6 enabled You will need to restart your Docker engine after updating the config Target kube-vip Docker image exists locally. Either build the image locally with `make dockerx86Local` or `docker pull` the image from a registry. Run the tests from the repo root: ``` make e2e-tests ``` Note: To preserve the test cluster after a test run, run the following: ``` make E2EPRESERVECLUSTER=true e2e-tests ``` The E2E tests: Start a local kind cluster Load the local docker image into kind Test connectivity to the control plane using the VIP Kills the current leader This causes leader election to occur Attempts to connect to the control plane using the VIP The new leader will need send ndp advertisements before this can succeed within a timeout
Project: Longhorn (Runtime / Cloud Native Storage)
File: release.md

name: Release task about: Create a release task title: "[RELEASE]" labels: release/task assignees: '' What's the task? Please describe. Action items for releasing v<x.y.z> Roles Release captain: <!--responsible for RD efforts of release development and coordinating with QA captain--> QA captain: <!--responsible for coordinating QA efforts of release testing tasks--> Describe the sub-tasks. Pre-Release (QA captain needs to coordinate the following efforts and finish these items) [ ] Regression test plan (manual) - QA captain [ ] Run e2e regression for pre-GA milestones (`install`, `upgrade`) - @yangchiu [ ] Run security testing of container images for pre-GA milestones - @roger-ryao [ ] Verify longhorn chart PR to ensure all artifacts are ready for GA (`install`, `upgrade`) @chriscchien [ ] Run core testing (install, upgrade) for the GA build from the previous patch (1.5.4) and the last patch of the previous feature release (1.4.4). - @yangchiu Release (Release captain needs to finish the following items) [ ] Release longhorn/chart from the release branch to publish to ArtifactHub [ ] Release note [ ] Deprecation note [ ] Upgrade notes including highlighted notes, deprecation, compatible changes, and others impacting the current users Post-Release (Release captain needs to coordinate the following items) [ ] Create a new release branch of manager/ui/tests/engine/longhorn instance-manager/share-manager/backing-image-manager when creating the RC1 (only for new feature release) [ ] Update https://github.com/longhorn/longhorn/blob/master/deploy/upgraderesponderserver/chart-values.yaml @PhanLe1010 [ ] Add another request for the rancher charts for the next patch release (`1.5.6`) @rebeccazzzz Rancher charts: verify the chart can be installed & upgraded - @khushboo-rancher [ ] rancher/image-mirrors update @PhanLe1010 [ ] rancher/charts active branches (2.7 & 2.8) for rancher marketplace @mantissahz @PhanLe1010 cc @longhorn/qa @longhorn/dev
Project: rkt (Runtime / Container Runtime)
File: ROADMAP.md

This document defines a high level roadmap for rkt development. The dates below should not be considered authoritative, but rather indicative of the projected timeline of the project. The represent the most up-to-date state of affairs. rkt's version 1.0 release marks the command line user interface and on-disk data structures as stable and reliable for external development. Adapting rkt to offer first-class implementation of the Kubernetes Container Runtime Interface. Supporting OCI specs natively in rkt. Following OCI evolution and stabilization, it will become the preferred way over appc. However, rkt will continue to support the ACI image format and distribution mechanism. There is currently no plans to remove that support from rkt. Future tasks without a specific timeline are tracked at https://github.com/rkt/rkt/milestone/30.
Project: Stash by AppsCode (Runtime / Cloud Native Storage)
File: VERSIONING.md

We follow the , and use the corresponding tooling. For the purposes of the aforementioned guidelines, controller-runtime counts as a "library project", but otherwise follows the guidelines exactly. For release branches, we generally tend to support backporting one (1) major release (`release-{X-1}` or `release-0.{Y-1}`), but may go back further if the need arises and is very pressing (e.g. security updates). Note the . Particularly: We DO guarantee Kubernetes REST API compatibility -- if a given version of controller-runtime stops working with what should be a supported version of Kubernetes, this is almost certainly a bug. We DO NOT guarantee any particular compatibility matrix between kubernetes library dependencies (client-go, apimachinery, etc); Such compatibility is infeasible due to the way those libraries are versioned.
Project: Spiderpool (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: rkt (Runtime / Container Runtime)
File: selinux.md

rkt supports running containers using SELinux . At start-up, rkt will attempt to read `/etc/selinux/(policy)/contexts/lxc_contexts`. If this file doesn't exist, no SELinux transitions will be performed. If it does, rkt will generate a per-instance context. All mounts for the instance will be created using the file context defined in `lxccontexts`, and the instance processes will be run in a context derived from the process context defined in `lxccontexts`. Processes started in these contexts will be unable to interact with processes or files in any other instance's context, even though they are running as the same user. Individual Linux distributions may impose additional isolation constraints on these contexts. For example, given the following `lxc_contexts`: ``` process = "systemu:systemr:svirtlxcnet_t:s0" content = "systemu:objectr:virtvarlib_t:s0" file = "systemu:objectr:svirtlxcfile_t:s0" ``` You could define a policy where members of `svirtlxcnet_t` context cannot write on TCP sockets. Note that the policy is responsibility of your distribution and might differ from this example. To find out more about policies you can check the . Please refer to your distribution documentation for further details on its policy.
Project: Soda Foundation (Runtime / Cloud Native Storage)
File: opensds-installer.md

For detailed information about this project, please refer to the . This project is designed for locating the code for installing all required components to set up a cluster, including controller and nbp plugins. Currently we support several install tools for diversity. is a radically simple IT automation platform that makes your applications and systems easier to deploy. OpenSDS installer project holds all code related to `opensds-ansible` in ansible folder for installing and configuring OpenSDS cluster through ansible tool. is a popular tool for managing Kubernetes charts. Charts are packages of pre-configured Kubernetes resources. OpenSDS installer project also holds all code related to `opensds-charts` in charts folder for installing and configuring OpenSDS cluster through helm tool. Mailing list: slack: # Ideas/Bugs:
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_cgroups.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Cgroup metadata ``` -h, --help help for cgroups ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI - Display cgroup metadata maintained by Cilium
Project: Stash by AppsCode (Runtime / Cloud Native Storage)
File: SECURITY.md

Join the [kubernetes-security-announce] group for security and vulnerability announcements. You can also subscribe to an RSS feed of the above using . Instructions for reporting a vulnerability can be found on the [Kubernetes Security and Disclosure Information] page. Information about supported Kubernetes versions can be found on the [Kubernetes version and version skew support policy] page on the Kubernetes website.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-alibabacloud_completion_fish.md

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> Generate the autocompletion script for fish Generate the autocompletion script for the fish shell. To load completions in your current shell session: cilium-operator-alibabacloud completion fish | source To load completions for every new session, execute once: cilium-operator-alibabacloud completion fish > ~/.config/fish/completions/cilium-operator-alibabacloud.fish You will need to start a new shell for this setup to take effect. ``` cilium-operator-alibabacloud completion fish [flags] ``` ``` -h, --help help for fish --no-descriptions disable completion descriptions ``` - Generate the autocompletion script for the specified shell
Project: Velero (Runtime / Cloud Native Storage)
File: ark_schedule_delete.md

title: "ark schedule delete" layout: docs Delete a schedule Delete a schedule ``` ark schedule delete NAME [flags] ``` ``` -h, --help help for delete ``` ``` --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 schedules
Project: Velero (Runtime / Cloud Native Storage)
File: upgrade-to-1.4.md

title: "Upgrading to Velero 1.4" layout: docs Velero , or installed. Note: The v1.4.1 tag was created in code, but has no associated docker image due to misconfigured building infrastructure. v1.4.2 fixed this. If you're not yet running at least Velero v1.3, 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.4 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.4.3 Git commit: <git SHA> ``` 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.4.3 \ --namespace velero kubectl set image daemonset/restic \ restic=velero/velero:v1.4.3 \ --namespace velero ``` Update the Velero custom resource definitions (CRDs) to include the new backup progress fields: ```bash velero install --crds-only --dry-run -o yaml | kubectl apply -f - ``` NOTE: If you are upgrading Velero in Kubernetes 1.14.x or earlier, you will need to use `kubectl apply`'s `--validate=false` option when applying the CRD configuration above. See and for more context. 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.4.3 Git commit: <git SHA> Server: Version: v1.4.3 ```
Project: Piraeus Datastore (Runtime / Cloud Native Storage)
File: DEVELOPMENT.md

Before continuing, make sure you've read the This is a (probably incomplete) list of software used to develop the operator: ...the operator is written in it... Provides all the plumbing and project structure Used to ensure all files are formatted, generated code is up to date and more Used for code formatting Lints for go code Some additional software you may find useful: can create virtual machines (for example a virtual kubernetes cluster) Commit hooks ensure that all new and changed code is formatted and tested before committing. To set up commit hooks install `pre-commit` (see above) and run: ``` $ pre-commit install ``` Now, if you try to commit a file that for example is not properly formatted, you will receive a message like: ``` $ git commit -a -m "important fix; no time to check for errors" Trim Trailing Whitespace.................................................Passed Fix End of Files.........................................................Passed Check Yaml...........................................(no files to check)Skipped Check for added large files..............................................Passed gofumpt..................................................................Failed hook id: gofumpt exit code: 1 files were modified by this hook version/version.go golangci-lint............................................................Failed hook id: golangci-lint exit code: 1 ``` Use `make test` to run our test suite. It will download the required control plane binaries to execute the webhook and controller tests. For basic unit testing use the basic go test framework. If something you want to test relies on the Kubernetes API, check out the test suite for the As of right now, there is no recommended way to end-to-end test the operator. It probably involves some virtual machines running a basic kubernetes cluster. On every pull request, we run a set of tests, specified in `.github/workflows`. The checks include `go test` `golandci-lint` `pre-commit run` This repository enforces for every commit. Every commit needs a `Signed-off-by` line. You can add them by passing the `-s` flag to `git commit`: ``` $ git commit -s -m 'This is my commit message' ```
Project: containerd (Runtime / Container Runtime)
File: 2017-03-10.md

This week I (@crosbymichael) have been working on the OCI runtime specifications. Since containerd is to be fully compliant with the OCI specs we need to make sure we reach a 1.0 and have a solid base to build on. We are getting very close on the spec side and have a final rc out for review. If you have time please check it out. I have also been working on the `runc` side of things, fixing terminal handling for `exec` and implementing the changes in our go bindings. I have also worked on adding a global process monitor/reaper to containerd. The issues before with having a `SIGCHLD` reaper is that the Go `exec.Cmd` and especially its `Wait` method did not play well together. This would cause races between the reaper doing a `waitpid` and the `exec.Cmd` doing a `Wait`. I think we solved this problem fully now as long as code is written against the `reaper` api. It is a little more of a burden on developers of containerd but makes it much more robust when dealing with processes being reparented to `containerd` and its `shim`. We merged a PR making the snapshot registration dynamic. This allows users to compile containerd with additional shapshotters than the ones we have builtin to the core. Because of the current state of Go 1.8 plugins the best course of action for adding additional runtimes, snapshotters, and other extensions is to modify the `builtins.go` file for the `containerd` command and recompile. Hopefully the short comings will be fixed in later Go releases. ```go package main // register containerd builtins here import ( _ "github.com/containerd/containerd/linux" _ "github.com/containerd/containerd/services/content" _ "github.com/containerd/containerd/services/execution" _ "github.com/containerd/containerd/snapshot/btrfs" _ "github.com/containerd/containerd/snapshot/overlay" ) ``` We are working towards being feature complete mid April, with a Q2 1.0. The Beta milestone on github should reflect this goal and the dates associated with it. After we hit a feature complete state we hope to finish the Docker, swarm, and kube CRI integrations to make sure that we provide the feature set that is required for each, before locking down the APIs. There is going to be another containerd summit at Dockecon this year. I created a document in the repository so that everyone can add discussion points for the breakout sessions. We should have a much larger crowd than the previous summit, therefore, having a few pre-defined discussion points will help. We will still have ad-hoc discussions but it never hurts to be prepared. We are still moving forward so that we can have the distribution, content, and snapshotters all working together over the API. One of the challenges is to make sure things work well over GRPC. We need to be able to support things like `docker build` and making sure that it performs as good or better than what you expect.
Project: Gluster (Runtime / Cloud Native Storage)
File: README.md

It provides feature of managing blocks used below a given namespace. (Expects the inodes to be linked to the proper namespace). It follows a simple logic for quota implementation: I manage only the local data, but if someone 'trusted' tells me, there is more usage in other places, I will consider it. I don't preserve the information about cluster view, so, everytime I am restarted, someone should give me global data to be proper. This translator is designed to be sitting on brick side (ie, somewhere above `storage/posix` in same graph). More on the reasons for this translator is given in One need to mark a directory as namespace first, and then set Quota on top of it. `setfattr -n trusted.glusterfs.namespace -v true ${mountpoint}/directory` To set 100MiB quota limit: `setfattr -n trusted.gfs.squota.limit -v 100000000 ${mountpoint}/directory` Updating the hard limit is as simple as calling above xattr again. `setfattr -n trusted.gfs.squota.limit -v 500000000 ${mountpoint}/directory` Call removexattr() on the directory, with the flag. `setfattr -x trusted.gfs.squota.limit ${mountpoint}/directory` This quota feature is not complete without a global view helper process, which sees the complete data from all bricks. Idea is to run it at regular frequency on all the directories which has Quota limit set ``` ... qdir=${mountpoint}/directory used_size=$(df --block-size=1 --output=used $qdir | tail -n1); setfattr -n glusterfs.quota.total-usage -v ${used_size} $qdir; ... ``` With this, the total usage would be updated in the translator and the new value would be considered for quota checks.
Project: Velero (Runtime / Cloud Native Storage)
File: 10-container-storage-interface.md

title: Container Storage Interface (CSI) link: https://github.com/vmware-tanzu/velero-plugin-for-csi objectStorage: false volumesnapshotter: true localStorage: true beta: true supportedByVeleroTeam: true This repository contains Velero plugins for snapshotting CSI backed PVCs using the CSI beta snapshot APIs. These plugins are currently in beta as of the Velero 1.4 release and will follow the CSI volumesnapshotting APIs in upstream Kubernetes to GA.
Project: Piraeus Datastore (Runtime / Cloud Native Storage)
File: linstorsatellite.md

This resource controls the state of a LINSTOR satellite. NOTE: This resource is not intended to be changed directly, instead it is created by the Piraeus Operator by merging all matching resources. Holds the desired state the satellite. Holds the default image registry to use for all Piraeus images. Inherited from . If empty (the default), the operator will use `quay.io/piraeusdatastore`. Holds a reference to the that controls this satellite. Holds the storage pools to configure on the node. Inherited from matching resources. Holds the properties which should be set on the node level. Inherited from matching resources. Configures a TLS secret used by the LINSTOR Satellite. Inherited from matching resources. Holds patches to apply to the Kubernetes resources. Inherited from matching resources. Reports the actual state of the satellite. The Operator reports the current state of the LINSTOR Satellite through a set of conditions. Conditions are identified by their `type`. | `type` | Explanation | |--|| | `Applied` | All Kubernetes resources were applied. | | `Available` | The LINSTOR Satellite is connected to the LINSTOR Controller | | `Configured` | Storage Pools and Properties are configured on the Satellite | | `EvacuationCompleted` | Only available when the Satellite is being deleted: Indicates progress of the eviction of resources. |
Project: FabEdge (Runtime / Cloud Native Network)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: '' assignees: '' Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: Go to '...' Click on '....' Scroll down to '....' See error 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. iOS] Browser [e.g. chrome, safari] Version [e.g. 22] Smartphone (please complete the following information): Device: [e.g. iPhone6] OS: [e.g. iOS8.1] Browser [e.g. stock browser, safari] Version [e.g. 22] Additional context Add any other context about the problem here.