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

title: "ark schedule" layout: docs Work with schedules Work with schedules ``` -h, --help help for schedule ``` ``` --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 ``` - Back up and restore Kubernetes cluster resources. - Create a schedule - Delete a schedule - Describe schedules - Get schedules
Project: Weave Net (Runtime / Cloud Native Network)
File: tasks.md

title: Weave Net Tasks menu_order: 50 search_type: Documentation The section describes the configuration options available in Weave Net. It is divided into: Managing Containerized Applications, Administering IP Addresses, Managing WeaveDNS, and finally attaching Docker Containers via the Weave API Proxy. * * * * * * * *
Project: Weave Net (Runtime / Cloud Native Network)
File: dynamically-attach-containers.md

title: Dynamically Attaching and Detaching Applications menu_order: 10 search_type: Documentation When containers may not know the network to which they will be attached, Weave Net enables you to dynamically attach and detach containers to and from a given network, even when a container is already running. To illustrate... host1$ C=$(docker run -e WEAVE_CIDR=none -dti weaveworks/ubuntu) host1$ weave attach $C 10.2.1.3 where, `C=$(docker run -e WEAVE_CIDR=none -dti weaveworks/ubuntu)` starts a container and assigns its ID to a variable `weave attach` the Weave Net command to attach to the specified container `10.2.1.3` - the allocated IP address output by `weave attach`, in this case in the default subnet Note If you are using the Weave Docker API proxy, it will have modified `DOCKERHOST` to point to the proxy and therefore you will have to pass `-e WEAVECIDR=none` to start a container that doesn't get automatically attached to the weave network for the purposes of this example. If `weave attach` sees the container has a hostname with a domain-name, it will add those into WeaveDNS (unless you turn this off with the `--without-dns` argument). host1$ docker run -dti --name=c1 --hostname=c1.weave.local weaveworks/ubuntu host1$ weave attach c1 10.32.0.1 host1$ weave dns-lookup c1 10.32.0.1 If you would like `/etc/hosts` to contain the Weave Net address (the same way ), specify `--rewrite-hosts` when running `weave attach`: host1$ weave attach --rewrite-hosts c1 A container can be detached from a subnet, by using the `weave detach` command: host1$ weave detach $C 10.2.1.3 You can also detach a container from one network and then attach it to a different one: host1$ weave detach net:default $C 10.2.1.3 host1$ weave attach net:10.2.2.0/24 $C 10.2.2.3 or, attach a container to multiple application networks, effectively sharing the same container between applications: host1$ weave attach net:default 10.2.1.3 host1$ weave attach net:10.2.2.0/24 10.2.2.3 Finally, multiple addresses can be attached or detached using a single command: host1$ weave attach net:default net:10.2.2.0/24 net:10.2.3.0/24 $C 10.2.1.3 10.2.2.3 10.2.3.1 host1$ weave detach net:default net:10.2.2.0/24 net:10.2.3.0/24 $C 10.2.1.3 10.2.2.3 10.2.3.1 Important! Any addresses that were dynamically attached will not be re-attached if the container restarts. See Also
Project: lxd (Runtime / Container Runtime)
File: database.md

(database)= Incus uses a distributed database to store the server configuration and state, which allows for quicker queries than if the configuration was stored inside each instance's directory (as it is done by LXC, for example). To understand the advantages, consider a query against the configuration of all instances, like "what instances are using `br0`?". To answer that question without a database, you would have to iterate through every single instance, load and parse its configuration, and then check which network devices are defined in there. With a database, you can run a simple query on the database to retrieve this information. In an Incus cluster, all members of the cluster must share the same database state. Therefore, Incus uses , a distributed version of SQLite. Cowsql provides replication, fault-tolerance, and automatic failover without the need of external database processes. When using Incus as a single machine and not as a cluster, the Cowsql database effectively behaves like a regular SQLite database. The database files are stored in the `database` sub-directory of your Incus data directory (`/var/lib/incus/database/`). Upgrading Incus to a newer version might require updating the database schema. In this case, Incus automatically stores a backup of the database and then runs the update. See {ref}`installing-upgrade` for more information. See {ref}`backup-database` for instructions on how to back up the contents of the Incus database.
Project: CubeFS (Runtime / Cloud Native Storage)
File: tiny.md

The results of the small file performance test by are as follows: ``` bash set -e TARGET_PATH="/home/service/chubaofs/adls/mnt-perform-test" # mount point of CubeFS volume for FILE_SIZE in 1024 2048 4096 8192 16384 32768 65536 131072 # file size do CMD="/usr/lib64/openmpi/bin/mpirun --allow-run-as-root -mca plmrshargs '-p 18822' -np 512 --hostfile hfile64 mdtest -n 1000 -w $FILESIZE -e $FILESIZE -y -u -i 3 -N 1 -F -R -d $TARGET_PATH" echo echo $CMD eval $CMD | tee -a ${LOGPREFIX}.txt echo "start to sleep 5s" sleep 5 done ``` | File Size (KB) | 1 | 2 | 4 | 8 | 16 | 32 | 64 | 128 | |-|--|--|--|--|--|--|--|--| | Creation (TPS) | 49808 | 37726 | 42296 | 44826 | 41481 | 35699 | 31609 | 35622 | | Read (TPS) | 76743 | 81085 | 84831 | 75397 | 73165 | 69665 | 62135 | 53658 | | Deletion (TPS) | 72522 | 67749 | 70919 | 68689 | 69819 | 71671 | 71568 | 71647 | | Stat (TPS) | 188609 | 185945 | 188542 | 180602 | 188274 | 174771 | 171100 | 183334 |
Project: Inclavare Containers (Runtime / Container Runtime)
File: spec_v1.md

Initialize enclave runtime with specific attributes. ```c struct palattrt { const char *args; const char *log_level; }; int palinit(const struct palattr_t *attr); ``` ``` @args: the enclave runtime specific argument string. @log_level: the output log level of enclave runtime. ``` ``` 0: Success -ENOENT: Invalid instance path of enclave runtime Others: Enclave runtime specific error codes ``` Pass the path of the application to be executed, and synchronously wait for the end of the application to run and return the result. ```c struct palstdiofds { int stdin, stdout, stderr; }; int palexec(char *path, char *argv[], struct palstdiofds *stdio, int *exitcode); ``` ``` @path: The path of the application to be run. @argv: The array of argument strings passed to the application, terminated by a NULL pointer. @stdio: The stdio fds consumed by the application. @exit_code: Return the exit code of an application. ``` ``` 0: success -ENOENT: The path does not exist -EACCES: Permission denied -ENOEXEC: The path is not an executable file -ENOMEM: No Memory -EINVAL: Invalid argument ``` Destroy the enclave runtime instance ```c int pal_destroy(); ``` ``` N/A ``` ``` 0: Success -ENOSYS: The function is not supported ```
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_kvstore_delete.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Delete a key ``` cilium-dbg kvstore delete [options] <key> [flags] ``` ``` cilium kvstore delete --recursive foo ``` ``` -h, --help help for delete --recursive Recursive lookup ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API --kvstore string Key-Value Store type --kvstore-opt map Key-Value Store options ``` - Direct access to the kvstore
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_encrypt_status.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Display the current encryption state ``` cilium-dbg encrypt status [flags] ``` ``` -h, --help help for status -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 transparent encryption
Project: CubeFS (Runtime / Cloud Native Storage)
File: zsh_completions.md

Cobra supports native Zsh completion generated from the root `cobra.Command`. The generated completion script should be put somewhere in your `$fpath` named `_<YOUR COMMAND>`. Completion for all non-hidden subcommands using their `.Short` description. Completion for all non-hidden flags using the following rules: Filename completion works by marking the flag with `cmd.MarkFlagFilename...` family of commands. The requirement for argument to the flag is decided by the `.NoOptDefVal` flag value - if it's empty then completion will expect an argument. Flags of one of the various `Array` and `*Slice` types supports multiple specifications (with or without argument depending on the specific type). Completion of positional arguments using the following rules: Argument position for all options below starts at `1`. If argument position `0` is requested it will raise an error. Use `command.MarkZshCompPositionalArgumentFile` to complete filenames. Glob patterns (e.g. `"*.log"`) are optional - if not specified it will offer to complete all file types. Use `command.MarkZshCompPositionalArgumentWords` to offer specific words for completion. At least one word is required. It's possible to specify completion for some arguments and leave some unspecified (e.g. offer words for second argument but nothing for first argument). This will cause no completion for first argument but words completion for second argument. If no argument completion was specified for 1st argument (but optionally was specified for 2nd) and the command has `ValidArgs` it will be used as completion options for 1st argument. Argument completions only offered for commands with no subcommands. Custom completion scripts are not supported yet (We should probably create zsh specific one, doesn't make sense to re-use the bash one as the functions will be different). Whatever other feature you're looking for and doesn't exist :)
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-azure_completion_powershell.md

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

Container deployments utilize explicit or implicit file sharing between host filesystem and containers. From a trust perspective, avoiding a shared file-system between the trusted host and untrusted container is recommended. This is not always feasible. In Kata Containers, block-based volumes are preferred as they allow usage of either device pass through or `virtio-blk` for access within the virtual machine. As of the 2.0 release of Kata Containers, is the default filesystem sharing mechanism. virtio-fs support works out of the box for `cloud-hypervisor` and `qemu`, when Kata Containers is deployed using `kata-deploy`. Learn more about `kata-deploy` and how to use `kata-deploy` in Kubernetes .
Project: Spiderpool (Runtime / Cloud Native Network)
File: annotation.md

| Case ID | Title | Priority | Smoke | Status | Other | ||--|-|-|--|-| | A00001 | It fails to run a pod with different VLANs for IPv4 and IPv6 IPPools | p3 | | done | | | A00002 | Added fields such as `"dist":"1.0.0.0/16"`, `"gw":"1.0.0.1"`, and `nics` and the pod was running successfully | p2 | | done | | | A00003 | Failed to run a pod with invalid annotations | p3 | | done | | | A00004 | Take a test with the Priority: pod annotation > namespace annotation > specified in a CNI profile | p1 | | done | | | A00005 | The "IPPools" annotation has the higher Priority over the "IPPool" annotation | p1 | | done | | | A00006 | The namespace annotation has precedence over global default IPPool | p1 | true | done | | | A00007 | Use wildcard for namespace annotation to specify IPPools | p1 | true | done | | | A00008 | Successfully run an annotated multi-container pod | p2 | | done | | | A00009 | Modify the annotated IPPool for a specified Deployment pod<br />Modify the annotated IPPool for a specified StatefulSet pod | p2 | | done | | | A00010 | Modify the annotated IPPool for a pod running on multiple NICs | p3 | | done | | | A00011 | Use the ippool route with `cleanGateway=false` in the pod annotation as a default route | p3 | | done | | | A00012 | Specify the default route NIC through Pod annotation: `ipam.spidernet.io/default-route-nic` | p2 | | done | | | A00013 | It's invalid to specify one NIC corresponding IPPool in IPPools annotation with multiple NICs | p2 | | done | | | A00014 | It's invalid to specify same NIC name for IPPools annotation with multiple NICs | p2 | | done | | | A00015 | Use wildcard for 'ipam.spidernet.io/ippools' annotation to specify IPPools | p2 | | done | |
Project: Inclavare Containers (Runtime / Container Runtime)
File: LICENSE.md

ISC License Copyright 2015, John Chadwick <johnwchadwick@gmail.com> Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_cgroups_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Display cgroup metadata maintained by Cilium ``` cilium-dbg cgroups list [flags] ``` ``` -h, --help help for list --no-headers Do not print headers -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 ``` - Cgroup metadata
Project: lxd (Runtime / Container Runtime)
File: ISSUE_TEMPLATE.md

<!-- Github issues are used for bug reports. For support questions, please use . Please fill the template below as it will greatly help us track down your issue and reproduce it on our side. Feel free to remove anything which doesn't apply to you and add more information where it makes sense. --> Distribution: Distribution version: The output of "incus info" or if that fails: Kernel version: LXC version: Incus version: Storage backend in use: A brief description of the problem. Should include what you were attempting to do, what you did, what happened and what you expected to see happen. Step one Step two Step three [ ] Any relevant kernel output (`dmesg`) [ ] Container log (`incus info NAME --show-log`) [ ] Container configuration (`incus config show NAME --expanded`) [ ] Main daemon log (at /var/log/incus/incusd.log) [ ] Output of the client with --debug [ ] Output of the daemon with --debug (alternatively output of `incus monitor --pretty` while reproducing the issue)
Project: Spiderpool (Runtime / Cloud Native Network)
File: reclaim.md

| Case ID | Title | Priority | Smoke | Status | Other | ||--|-|-|--|-| | G00001 | Related IP resource recorded in IPPool will be reclaimed after the namespace is deleted | p1 | true | done | | | G00002 | The IP of a running pod should not be reclaimed after a same-name pod within a different namespace is deleted | p1 | | done | | | G00003 | The IP can be reclaimed after its deployment, statefulset, daemonset, replica, or job is deleted, even when CNI binary is gone on the host | p1 | | done | | | G00004 | The IP should be reclaimed when deleting the pod with 0 second of grace period | p2 | | done | | | G00005 | A dirty IP record (pod name is wrong) in the IPPool should be auto clean by Spiderpool | p2 | | done | | | G00006 | The IP should be reclaimed for the job pod finished with success or failure Status | p2 | | done | | | G00007 | A dirty IP record (pod name is right but container ID is wrong) in the IPPool should be auto clean by Spiderpool | p3 | | done | | | G00008 | The Spiderpool component recovery from repeated reboot, and could correctly reclaim IP | p3 | | done | | | G00009 | stateless workload IP could be released with node not ready | p3 | | done | |
Project: Stash by AppsCode (Runtime / Cloud Native Storage)
File: MAINTAINERS.md

This page lists all active maintainers of this repository. If you were a maintainer and would like to add your name to the Emeritus list, please send us a PR. See for governance guidelines and how to become a maintainer. See for general contribution guidelines. , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC , Google LLC
Project: Velero (Runtime / Cloud Native Storage)
File: repository-maintenance.md

title: "Repository Maintenance" layout: docs From v1.14 on, Velero decouples repository maintenance from the Velero server by launching a k8s job to do maintenance when needed, to mitigate the impact on the Velero server during backups. Before v1.14.0, Velero performs periodic maintenance on the repository within Velero server pod, this operation may consume significant CPU and memory resources in some cases, leading to Velero server being killed by OOM. Now Velero will launch independent k8s jobs to do the maintenance in Velero installation namespace. For repository maintenance jobs, there's no limit on resources by default. You could configure the job resource limitation based on target data to be backed up. You can customize the maintenance job resource requests and limit when using the CLI command. Maintenance job inherits the log level and log format settings from the Velero server, so if the Velero server enabled the debug log, the maintenance job will also open the debug level log. Velero will keep one specific number of the latest maintenance jobs for each repository. By default, we only keep 3 latest maintenance jobs for each repository, and Velero support configures this setting by the below command when Velero installs: ```bash velero install --keep-latest-maintenance-jobs <NUM> ``` The frequency of running maintenance jobs could be set by the below command when Velero is installed: ```bash velero install --default-repo-maintain-frequency <DURATION> ``` For Kopia the default maintenance frequency is 1 hour, and Restic is 7 * 24 hours. Maintenance jobs will inherit the labels, annotations, tolerations, affinity, nodeSelector, service account, image, environment variables, cloud-credentials etc. from Velero deployment.
Project: JuiceFS (Runtime / Cloud Native Storage)
File: postgresql_best_practices.md

sidebar_label: PostgreSQL sidebar_position: 2 slug: /postgresqlbestpractices For distributed file systems where data and metadata are stored separately, the read and write performance and security of metadata directly affects the efficiency and data security of the whole system, respectively. In the production environment, it is recommended to select hosted cloud databases provided by cloud computing platforms first, and comebine it with appropriate high availability architecture to use. Please always pay attention to the integrity and security of metadata when using JuiceFS no matter whether databases is build on your own or in the cloud. By default, JuiceFS clients will use SSL encryption to connect to PostgreSQL. If SSL encryption is not enabled on the database, you need to append the `sslmode=disable` parameter to the metadata URL. It is recommended to configure and keep SSL encryption enabled on the database server side all the time. Database password can be set directly through the metadata URL. Although it is easy and convenient, the password may leak during logging and process outputing processes. For the sake of security, it's better to pass the database password through an environment variable. `META_PASSWORD` is a predefined environment variable for the database password: ```shell export META_PASSWORD=mypassword juicefs mount -d "postgres://user@192.168.1.6:5432/juicefs" /mnt/jfs ``` PostgreSQL supports the md5 authentication method. The following section can be adapted in the pg_hba.conf of your PostgreSQL instance. ``` host juicefs juicefsuser 192.168.1.0/24 md5 ``` Please refer to the official manual to learn how to back up and restore databases. It is recommended to make a plan for regularly backing up your database, and at the same time, do some tests to restore the data in an experimental environment to confirm that the backup is valid. Connection pooler is a middleware that works between client and database and reuses the earlier connection from the pool, which improve connection efficiency and reduce the loss of short connections. Commonly used connection poolers are and . The official PostgreSQL document compares several common databases in terms of high availability solutions. Please choose the appropriate ones according to your needs. :::note JuiceFS uses to ensure atomicity of metadata operations. Since PostgreSQL does not yet support Multi-Shard (Distributed) transactions, do not use a multi-server distributed architecture for the JuiceFS metadata. :::
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_multicast.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage multicast BPF programs ``` -h, --help help for multicast ``` ``` --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 - Manage the multicast groups. - Manage the multicast subscribers.