cwielenb/CNCF-Dataset huggingface dataset:
Project: Firecracker (Runtime / Container Runtime)
File: seccomp.md

Seccomp filters are used by default to limit the host system calls Firecracker can use. The default filters only allow the bare minimum set of system calls and parameters that Firecracker needs in order to function correctly. The filters are loaded in the Firecracker process, on a per-thread basis, as follows: VMM (main) - right before executing guest code on the VCPU threads; API - right before launching the HTTP server; VCPUs - right before executing guest code. Note: On experimental GNU targets, there are no default seccomp filters installed, since they are not intended for production use. Firecracker uses JSON files for expressing the filter rules and relies on the tool for all the seccomp functionality. At build time, the default target-specific JSON file is compiled into the serialized binary file, using seccompiler-bin, and gets embedded in the Firecracker binary. This process is performed automatically, when building the executable. To minimise the overhead of succesive builds, the compiled filter file is cached in the build folder and is only recompiled if modified. You can find the default seccomp filters under `resources/seccomp`. For a certain release, the default JSON filters used to build Firecracker are also included in the respective release archive, viewable on the . Note 1: This feature overrides the default filters and can be dangerous. Filter misconfiguration can result in abruptly terminating the process or disabling the seccomp security boundary altogether. We recommend using the default filters instead. Note 2: The user is fully responsible for managing the filter files. We recommend using integrity checks whenever transferring/downloading files, for example checksums, as well as for the Firecracker binary or other artifacts, in order to mitigate potential man-in-the-middle attacks. Firecracker exposes a way for advanced users to override the default filters with fully customisable alternatives, leveraging the same JSON/seccompiler tooling, at startup time. Via Firecracker's optional `--seccomp-filter` parameter, one can supply the path to a custom filter file compiled with seccompiler-bin. Potential use cases: Users of experimentally-supported targets (like GNU libc builds) may be able to use this feature to implement seccomp filters without needing to have a custom build of Firecracker. Faced with a theoretical production issue, due to a syscall that was issued by the Firecracker process, but not allowed by the seccomp policy, one may use a custom filter in order to quickly mitigate the issue. This can speed up the resolution time, by not needing to build and deploy a new Firecracker binary. However, as the note above states, this needs to be thoroughly tested and should not be a long-term solution. Firecracker also has support for a `--no-seccomp` parameter, which disables all seccomp filtering. It can be helpful when quickly prototyping changes in Firecracker that use new system calls. Do not use in production.
Project: Velero (Runtime / Cloud Native Storage)
File: upgrade-to-1.1.md

title: "Upgrading to Velero 1.1" layout: docs installed. Velero v1.1 only requires user intervention if Velero is running in a namespace other than `velero`. Previous versions of Velero's server detected the namespace in which it was running by inspecting the container's filesystem. With v1.1, this is no longer the case, and the server must be made aware of the namespace it is running in with the `VELERO_NAMESPACE` environment variable. `velero install` automatically writes this for new deployments, but existing installations will need to add the environment variable before upgrading. You can use the following command to patch the deployment: ```bash kubectl patch deployment/velero -n <YOUR_NAMESPACE> \ --type='json' \ -p='[{"op":"add","path":"/spec/template/spec/containers/0/env/0","value":{"name":"VELERO_NAMESPACE", "valueFrom":{"fieldRef":{"fieldPath":"metadata.namespace"}}}}]' ```
Project: lxd (Runtime / Container Runtime)
File: instances.md

(instances)= ```{toctree} :titlesonly: explanation/instances.md Create instances <howto/instances_create.md> Manage instances <howto/instances_manage.md> Configure instances <howto/instances_configure.md> Back up instances <howto/instances_backup.md> Use profiles <profiles.md> Use cloud-init <cloud-init> Run commands <instance-exec.md> Access the console <howto/instances_console.md> Access files <howto/instancesaccessfiles.md> Add a routed NIC to a VM </howto/instancesroutednic_vm.md> Troubleshoot errors <howto/instances_troubleshoot.md> explanation/instance_config.md Container environment <container-environment> migration ```
Project: Container Storage Interface (CSI) (Runtime / Cloud Native Storage)
File: CONTRIBUTING.md

This document outlines some of the requirements and conventions for contributing to the Container Storage Interface, including development workflow, commit message formatting, contact points, and other resources to make it easier to get your contribution accepted. CSI is under and accepts contributions via GitHub pull requests. Before contributing to the Container Storage Interface, contributors MUST sign the CLA available . The CLA MAY be signed on behalf of a company, possibly covering multiple contributors, or as an individual (put "Individual" for "Corporation name"). The completed CLA MUST be mailed to the CSI Approvers mailing list: container-storage-interface-approvers@googlegroups.com. To keep consistency throughout the Markdown files in the CSI spec, all files should be formatted one sentence per line. This fixes two things: it makes diffing easier with git and it resolves fights about line wrapping length. For example, this paragraph will span three lines in the Markdown source. This also applies to the code snippets in the markdown files. Please wrap the code at 72 characters. This also applies to the code snippets in the markdown files. End each sentence within a comment with a punctuation mark (please note that we generally prefer periods); this applies to incomplete sentences as well. For trailing comments, leave one space between the end of the code and the beginning of the comment. The "system of record" for the specification is the `spec.md` file and all hand-edits of the specification should happen there. DO NOT manually edit the generated protobufs or generated language bindings. Once changes to `spec.md` are complete, please run `make` to update generated files. IMPORTANT: Prior to committing code please run `make` to ensure that your specification changes have landed in all generated files. Each commit should represent a single logical (atomic) change: this makes your changes easier to review. Try to avoid unrelated cleanups (e.g., typo fixes or style nits) in the same commit that makes functional changes. While typo fixes are great, including them in the same commit as functional changes makes the commit history harder to read. Developers often make incremental commits to save their progress when working on a change, and then rewrite history (e.g., using `git rebase -i`) to create a clean set of commits once the change is ready to be reviewed. Simple house-keeping for clean git history. Read more on or the Discussion section of . Separate the subject from body with a blank line. Limit the subject line to 50 characters. Capitalize the subject line. Do not end the subject line with a period. Use the imperative mood in the subject line. Wrap the body at 72 characters. Use the body to explain what and why vs. how. If there was important/useful/essential conversation or information, copy or include a reference. When possible, one keyword to scope the change in the subject (i.e. "README: ...", "tool: ...").
Project: Curve (Runtime / Cloud Native Storage)
File: k8s_csi_interface_en.md

Currently, Curve can be connected to Kubernetes through the CSI plugin. This article gives instructions on the development of CSI plugin. For the source code of the Curve CSI plugin, please see . Curve provides a command line management tool curve, which is used to create and delete volumes and other management operations. The specific interface is as follows: create volume: `curve create [-h] --filename FILENAME --length LENGTH --user USER` delete volume: `curve delete [-h] --user USER --filename FILENAME` recover volume: `curve recover [-h] --user USER --filename FILENAME [--id ID]` extend volume: `curve extend [-h] --user USER --filename FILENAME --length LENGTH` get volume info: `curve stat [-h] --user USER --filename FILENAME` rename volume: `curve rename [-h] --user USER --filename FILENAME --newname NEWNAME` create directory: `curve mkdir [-h] --user USER --dirname DIRNAME` delete directory: `curve rmdir [-h] --user USER --dirname DIRNAME` list files in the directory`curve list [-h] --user USER --dirname DIRNAME` Provide curve-nbd tool to map, unmap, list on node: ```bash Usage: curve-nbd [options] map <image> (Map an image to nbd device) unmap <device|image> (Unmap nbd device) list-mapped (List mapped nbd devices) Map options: --device <device path> Specify nbd device path (/dev/nbd{num}) --read-only Map read-only --nbdsmax <limit> Override for module param nbdsmax --maxpart <limit> Override for module param maxpart --timeout <seconds> Set nbd request timeout --try-netlink Use the nbd netlink interface ``` CSI spec: ``` CreateVolume ++ DeleteVolume +->| CREATED +--+ | ++-^+ | | Controller | | Controller v +++ Publish | | Unpublish +++ |X| Volume | | Volume | | +-+ +v-++ +-+ | NODE_READY | ++-^+ Node | | Node Stage | | Unstage Volume | | Volume +v-++ | VOL_READY | ++-^+ Node | | Node Publish | | Unpublish Volume | | Volume +v-++ | PUBLISHED | ++ ``` In CSI plugin: CreateVolume: curve mkdir: DIRNAME defined in `k8s storageClass` curve create: FILENAME is `k8s persistentVolume name` curve stat: wait volume ready Controller Publish Volume: Nothing to do Node Stage Volume: curve-nbd list-mapped: check if it has been mounted curve-nbd map: mount Node Publish Volume: mount the stagePath to the publishPath Node Unpublish Volume: umount publishPath Node Unstage Volume: curve-nbd list-mapped: check if it has been umounted curve-nbd unmap: umount Controller Unpublish Volume: Nothing to do DeleteVolume: curve delete Other optional support: Extend ControllerExpandVolume: curve extend NodeExpandVolume: resize2fs/xfs_growfs Snapshot: not yet supported
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_endpoint_log.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> View endpoint status log ``` cilium-dbg endpoint log <endpoint id> [flags] ``` ``` cilium endpoint log 5421 ``` ``` -h, --help help for log -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 endpoints
Project: containerd (Runtime / Container Runtime)
File: testing.md

CRI Plugin Testing Guide ======================== This document assumes you have already setup the development environment (go, git, `github.com/containerd/containerd` repo etc.). Before sending pull requests you should at least make sure your changes have passed code verification, unit, integration and CRI validation tests. Follow the instructions. Run all CRI integration tests: ```bash make cri-integration ``` Run specific CRI integration tests: use the `FOCUS` parameter to specify the test case. ```bash FOCUS=<TEST_NAME> make cri-integration ``` Example: ```bash FOCUS=TestContainerListStats make cri-integration ``` is a test framework for validating that a Container Runtime Interface (CRI) implementation such as containerd with the `cri` plugin meets all the requirements necessary to manage pod sandboxes, containers, images etc. CRI validation test makes it possible to verify CRI conformance of `containerd` without setting up Kubernetes components or running Kubernetes end-to-end tests. . Run the containerd you built above with the `cri` plugin built in: ```bash containerd -l debug ``` Run CRI test. about CRI validation test. is a test framework testing Kubernetes node level functionalities such as managing pods, mounting volumes etc. It starts a local cluster with Kubelet and a few other minimum dependencies, and runs node functionality tests against the local cluster. Currently e2e-node tests are supported from via Pull Request comments on github. Enter "/test all" as a comment on a pull request for a list of testing options that have been integrated through prow bot with kubernetes testing services hosted on GCE. Typing `/test pull-containerd-node-e2e` will start a node e2e test run on your pull request commits. about Kubernetes node e2e test.
Project: lxd (Runtime / Container Runtime)
File: general.md

See the following sections for information on how to get started with Incus: ```{toctree} :maxdepth: 1 Containers and VMs </explanation/containersandvms> Install Incus </installing> Initialize Incus </howto/initialize> Get support </support> Frequently asked </faq> Contribute to Incus </contributing> ``` You can find a series of demos and tutorials on YouTube: <iframe width="560" height="315" src="https://www.youtube.com/embed/videoseries?list=PLVhiK8li7a-5aRPwUHHfpfMuwWCava4" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
Project: Firecracker (Runtime / Container Runtime)
File: CHARTER.md

Our mission is to enable secure, multi-tenant, minimal-overhead execution of container and function workloads. These tenets guide Firecracker's development: Built-In Security: We provide compute security barriers that enable multi-tenant workloads, and cannot be mistakenly disabled by customers. Customer workloads are simultaneously considered sacred (shall not be touched) and malicious (shall be defended against). We continuously invest in defense in depth and maintain mechanisms that ensure security best practices. Light-Weight Virtualization: We prioritize measuring Firecracker's hardware overhead in the dimensions that are important for our customers, and we strive to make this overhead negligible. Minimalist in Features: If it's not clearly required for our mission, we won't build it. We maintain a single implementation per capability, and deprecate obsolete implementations; resolving exceptions is a high priority issue. Compute Oversubscription: All of the hardware compute resources exposed by Firecracker to guests can be securely oversubscribed. All contributions must align with this charter and follow Firecracker's . Firecracker merge contributions into the main branch and create Firecracker releases. Maintainers are also subject to the mission and tenets outlined above. Anyone may submit and review contributions.
Project: Alluxio (Runtime / Cloud Native Storage)
File: Environment-List.md

layout: global title: List of Environment Variables Alluxio supports defining a few frequently used configuration settings through environment variables. <table class="table table-striped"> <tr><th>Environment Variable</th><th>Description</th></tr> {% for envvar in site.data.table.en.envvars %} <tr> <td markdown="span">`{{env_var.name}}`</td> <td markdown="span">{{env_var.description}}</td> </tr> {% endfor %} </table> The following example will set up: an Alluxio master at `localhost` the root mount point as an HDFS cluster with a namenode also running at `localhost` defines the maximum heap space of the VM to be 30g enable Java remote debugging at port 7001 ```shell $ export ALLUXIOMASTERHOSTNAME="localhost" $ export ALLUXIOMASTERMOUNTTABLEROOT_UFS="hdfs://localhost:9000" $ export ALLUXIOMASTERJAVA_OPTS="-Xmx30g" $ export ALLUXIOMASTERATTACHOPTS="-agentlib:jdwp=transport=dtsocket,server=y,suspend=n,address=7001" ``` Users can either set these variables through the shell or in `conf/alluxio-env.sh`. If this file does not exist yet, it can be copied from the template file under `${ALLUXIO_HOME}/conf`: ```shell $ cp conf/alluxio-env.sh.template conf/alluxio-env.sh ```
Project: Triton Object Storage (Runtime / Cloud Native Storage)
File: CONTRIBUTING.md

<!-- This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/. --> <!-- Copyright 2019 Joyent, Inc. Copyright 2024 MNX Cloud, Inc. --> Thanks for using Manta and for considering contributing to it! All changes to Manta project repositories go through code review via a GitHub pull request. If you're making a substantial change, you probably want to contact developers first. If you have any trouble with the contribution process, please feel free to contact developers [on the mailing list or IRC](README.md#community). See the for useful information about building and testing the software. Manta repositories use the same [Joyent Engineering Guidelines](https://github.com/TritonDataCenter/eng/blob/master/docs/index.md) as the Triton project. Notably: The #master branch should be first-customer-ship (FCS) quality at all times. Don't push anything until it's tested. All repositories should be "make check" clean at all times. All repositories should have tests that run cleanly at all times. Typically each repository has `make check` to lint and check code style. Specific code style can vary by repository. There are two separate issue trackers that are relevant for Manta code: An internal JIRA instance. A JIRA ticket has an ID like `MANTA-380`, where "MANTA" is the JIRA project name. A read-only view of many JIRA tickets is made available at <https://smartos.org/bugview/> (e.g. <https://smartos.org/bugview/MANTA-380>). GitHub issues for the relevant repository. Before Manta was open sourced, Joyent engineering used a private JIRA instance. While Joyent continues to use JIRA internally, we also use GitHub issues for tracking -- primarily to allow interaction with those without access to JIRA. All persons and/or organizations contributing to, or intercting with our repositories or communities are required to abide by the .
Project: Weave Net (Runtime / Cloud Native Network)
File: weavedns.md

title: Discovering Containers with WeaveDNS menu_order: 5 search_type: Documentation WeaveDNS is a DNS server that answers name queries on a Weave network and provides a simple way for containers to find each other. Just give the containers hostnames and then tell other containers to connect to those names. Unlike Docker 'links', this requires no code changes and it works across hosts. WeaveDNS is deployed as an embedded service within the Weave router. The service is automatically started when the router is launched: ``` host1$ weave launch host1$ eval $(weave env) ``` WeaveDNS related configuration arguments can be passed to `launch`. Application containers use weaveDNS automatically if it is running when they are started. They use it for name resolution, and will register themselves if they either have a hostname in the weaveDNS domain (`weave.local` by default) or are given an explicit container name: ``` host1$ docker run -dti --name=pingme weaveworks/ubuntu host1$ docker run -ti --hostname=ubuntu.weave.local weaveworks/ubuntu root@ubuntu:/# ping pingme ... ``` Moreover, weaveDNS always register all network aliases (--network-alias option to docker run). ``` host1$ docker run --network weave --network-alias pingme --network-alias pingme2 -dti weaveworks/ubuntu host1$ docker run --network weave --hostname=ubuntu.weave.local -ti weaveworks/ubuntu root@ubuntu:/# ping pingme ... root@ubuntu:/# ping pingme2 ... ``` Note If both hostname and container name are specified at the same time, the hostname takes precedence. In this circumstance, if the hostname is not in the weaveDNS domain, the container is not registered, but it will still use weaveDNS for resolution. By default, weaveDNS will listen on port 53 on the address of the Docker bridge. To make it listen on a different address or port use `weave launch --dns-listen-address <address>:<port>` To disable an application container's use of weaveDNS, add the `--without-dns` option to `weave launch`. To disable weaveDNS itself, launch weave with the `--no-dns` option. Note WeaveDNS is not part of the Weave Net Kubernetes add-on. Kubernetes has its own DNS service, integrated with Kubernetes Services, and WeaveDNS does not duplicate that functionality. See Also *
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_fs_show.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Show bpf filesystem mount details ``` cilium-dbg bpf fs show [flags] ``` ``` cilium bpf fs show ``` ``` -h, --help help for show -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 ``` - BPF filesystem mount
Project: Project Calico (Runtime / Cloud Native Network)
File: SECURITY.md

The Tigera team generally support the most recent two minor versions of Project Calico on a rolling basis. Support for older versions is on a case-by-case basis. For example, at the time of writing, Calico v3.26.x and v3.25.x are supported. When v3.27.0 is released, automatic support for v3.25.x is dropped. Please follow responsible disclosure best practices and when submitting security vulnerabilities. Do not create a GitHub issue or pull request because those are immediately public. Instead: Email . Report a private through the GitHub interface. Please include as much information as possible, including the affected version(s) and steps to reproduce.
Project: runc (Runtime / Container Runtime)
File: checkpoint-restore.md

For a basic description about checkpointing and restoring containers with `runc` please see and . In addition to specifying options on the command-line like it is described in the man-pages (see above), it is also possible to influence CRIU's behaviour using CRIU configuration files. For details about CRIU's configuration file support please see . In addition to CRIU's default configuration files `runc` tells CRIU to also evaluate the file `/etc/criu/runc.conf`. Using the annotation `org.criu.config` it is, however, possible to change this additional CRIU configuration file. If the annotation `org.criu.config` is set to an empty string `runc` will not pass any additional configuration file to CRIU. With an empty string it is therefore possible to disable the additional CRIU configuration file. This can be used to make sure that no additional configuration file changes CRIU's behaviour accidentally. If the annotation `org.criu.config` is set to a non-empty string `runc` will pass that string to CRIU to be evaluated as an additional configuration file. If CRIU cannot open this additional configuration file, it will ignore this file and continue. ``` { "ociVersion": "1.0.0", "annotations": { "org.criu.config": "" }, "process": { ``` ``` { "ociVersion": "1.0.0", "annotations": { "org.criu.config": "/etc/special-runc-criu-options" }, "process": { ```
Project: Spiderpool (Runtime / Cloud Native Network)
File: third-party-controller.md

| Case ID | Title | Priority | Smoke | Status | Other | | - | -- | -- | -- | | -- | | T00001 | SpiderIPPool feature supports third party controllers. | p3 | | done | | | T00002 | SpiderSubnet feature supports third party controllers. | p3 | | done | | | T00003 | The statefulset of the third-party control is removed, the endpoint will be released. | p3 | | done | | | T00004 | Third-party applications with the same name and type can use the reserved IPPool. | p2 | | done | | | T00005 | Third-party applications with the same name and different types cannot use the reserved IPPool. | p2 | | done | |