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

title: "Velero Backup Storage Locations" layout: docs Velero can store backups in a number of locations. These are represented in the cluster via the `BackupStorageLocation` CRD. Velero must have at least one `BackupStorageLocation`. By default, this is expected to be named `default`, however the name can be changed by specifying `--default-backup-storage-location` on `velero server`. Backups that do not explicitly specify a storage location will be saved to this `BackupStorageLocation`. A sample YAML `BackupStorageLocation` looks like the following: ```yaml apiVersion: velero.io/v1 kind: BackupStorageLocation metadata: name: default namespace: velero spec: backupSyncPeriod: 2m0s provider: aws objectStorage: bucket: myBucket credential: name: secret-name key: key-in-secret config: region: us-west-2 profile: "default" ``` The configurable parameters are as follows: {{< table caption="Main config parameters" >}} | Key | Type | Default | Meaning | | | | | | | `provider` | String | Required Field | The name for whichever object storage provider will be used to store the backups. See for the appropriate value to use. | | `objectStorage` | ObjectStorageLocation | Required Field | Specification of the object storage for the given provider. | | `objectStorage/bucket` | String | Required Field | The storage bucket where backups are to be uploaded. | | `objectStorage/prefix` | String | Optional Field | The directory inside a storage bucket where backups are to be uploaded. | | `objectStorage/caCert` | String | Optional Field | A base64 encoded CA bundle to be used when verifying TLS connections | | `config` | map for details. | | `accessMode` | String | `ReadWrite` | How Velero can access the backup storage location. Valid values are `ReadWrite`, `ReadOnly`. | | `backupSyncPeriod` | metav1.Duration | Optional Field | How frequently Velero should synchronize backups in object storage. Default is Velero's server backup sync period. Set this to `0s` to disable sync. | | `validationFrequency` | metav1.Duration | Optional Field | How frequently Velero should validate the object storage . Default is Velero's server validation frequency. Set this to `0s` to disable validation. Default 1 minute. | | `credential` | | Optional Field | The credential information to be used with this location. | | `credential/name` | String | Optional Field | The name of the secret within the Velero namespace which contains the credential information. | | `credential/key` | String | Optional Field | The key to use within the secret. | {{< /table >}}
Project: Inclavare Containers (Runtime / Container Runtime)
File: RELEASE.md

The `klog` is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
Project: FD.io (Runtime / Cloud Native Network)
File: index_header.md

{# The VPP network stack comes with several configuration options that can be provided either on the command line or in a configuration file. Specific applications built on the stack have been known to require a dozen arguments, depending on requirements. This section describes commonly-used options and parameters. You can find command-line argument parsers in the source code by searching for instances of the `VLIBCONFIGFUNCTION` macro. The invocation `VLIBCONFIGFUNCTION(foo_config, "foo")` will cause the function `foo_config` to receive all the options and values supplied in a parameter block named "`foo`", for example: `foo { arg1 arg2 arg3 ... }`. @todo Tell the nice people where this document lives so that the might help improve it! Parameters are grouped by a section name. When providing more than one parameter to a section all parameters for that section must be wrapped in curly braces. ``` /usr/bin/vpp unix { interactive cli-listen 127.0.0.1:5002 } ``` Which will produce output similar to this: <startup diagnostic messages> _ _ _ _ _ / / \ () | | / / \/ \ / // // / / / \ | |/ / / _/ // /_(_)_/\/ |// // vpp# <start-typing> When providing only one such parameter the braces are optional. For example, the following command argument, `unix interactive` does not have braces: ``` /usr/bin/vpp unix interactive ``` The command line can be presented as a single string or as several; anything given on the command line is concatenated with spaces into a single string before parsing. VPP applications must be able to locate their own executable images. The simplest way to ensure this will work is to invoke a VPP application by giving its absolute path; for example: `/usr/bin/vpp <options>`. At startup, VPP applications parse through their own ELF-sections (primarily) to make lists of init, configuration, and exit handlers. When developing with VPP, in gdb it's often sufficient to start an application like this at the `(gdb)` prompt: ``` run unix interactive ``` It is also possible to supply parameters in a startup configuration file the path of which is provided to the VPP application on its command line. The format of the configuration file is a simple text file with the same content as the command line but with the benefit of being able to use newlines to make the content easier to read. For example: ``` unix { nodaemon log /var/log/vpp/vpp.log full-coredump cli-listen localhost:5002 } api-trace { on } dpdk { dev 0000:03:00.0 } ``` VPP is then instructed to load this file with the `-c` option: ``` /usr/bin/vpp -c /etc/vpp/startup.conf ``` [TOC]
Project: HwameiStor (Runtime / Cloud Native Storage)
File: evictor.md

sidebar_position: 6 sidebar_label: "Evictor" The Evictor is used to automatically migrate HwameiStor volumes in case of node or pod eviction. When a node or pod is evicted as either Planned or Unplanned, the associated HwameiStor volumes, which have a replica on the node, will be detected and migrated out of this node automatically. A scheduler will work for both LVM and Disk volumes. The Evictor should be deployed with the HA mode in the cluster, which is a best practice for production.
Project: Gluster (Runtime / Cloud Native Storage)
File: rpc-for-glusterfs.new-versions.md

RPC layer of glusterfs is implemented with possible changes over the protocol layers in mind. If there are any changes in the FOPs from what is assumed to be client side, and whats in serverside, they are to be added as a separate program table. A given RPC program has a specific Task, and Version along with actors belonging to the program. In any of the programs, if a new actor is added, it is very important to define one more program with different version, and then keep both, if both are supported. Or else, it is important to handle the 'handshake' properly. More info on RPC program is at `rpc/rpc-lib/src/rpcsvc.h` and check for structure `rpcsvcactort` and `struct rpcsvc_program`. For usage, check `xlators/protocol/server/src/server-rpc-fops.c` For details on client structures check `rpc/rpc-lib/src/rpc-clnt.h` for `rpcclntproceduret` and `rpcclntprogramt`. For usage, check `xlators/protocol/client/src/client-rpc-fops.c` A protocol is what is agreed between two parties. In glusterfs, a RPC protocol is defined as .x file, which then gets converted to .c/.h file using `rpcgen`. There are different protocols defined for communication between `xlators/mgmt/glusterd <==> glusterfsd`, `gluster CLI <==> glusterd`, and `client-protocol <==> server-protocol` Once a protocol is defined and a release is made with that protocol, make sure no one changes it. Any edits to a given structure there should be a new version of the structure, and also it should get used in new actor, and thus new program version. When a client succeeds to establish a connect (it can be any transport, socket, ib-verbs or unix), client sends a dump (GFDUMPDUMP) request to server, which will respond back with all the supported versions of the server RPC (the supported programs which are registered with `rpcsvcprogramregister()`). A client which expects certain programs to be present in server, it should be taking care of looking for it in the handshake methods, and take appropriate action depending on what to do next. In general a compatibility issue should be handled at handshake level itself, thus we can clearly let user/admin know of any 'in-compatibilities'. As a developer of GlusterFS protocol layer, one just has to make sure never to make changes to existing program structures, but they have to add new programs if required. New programs can have the same actors as present in existing, and also little more. Or it can even have same actor behave differently, take different parameter. If this is followed properly, there would be smooth upgrade / downgrade of versions. If not, technically, it is 100% guarantee of getting compatibility related issues.
Project: JuiceFS (Runtime / Cloud Native Storage)
File: posix_acl.md

title: POSIX ACLs description: Learn about POSIX ACL support in JuiceFS and how to enable and use ACL permissions. sidebar_position: 1 POSIX ACLs (Portable Operating System Interface for Unix - Access Control Lists) are an access control mechanism in Unix-like operating systems that allows for finer-grained control over file and directory access permissions. This document introduces how to enable and use POSIX ACL permissions in JuiceFS. Since version 1.2, JuiceFS has supported POSIX ACLs. All client versions can mount volumes without ACLs enabled, regardless of their creation by new or old client versions. Once ACLs are enabled, they cannot be disabled. Therefore, the `--enable-acl` option is tied to the volume. :::caution If you plan to use ACL functionality, it is recommended to upgrade all clients to the latest version to avoid potential issues with older versions affecting the accuracy of ACLs. ::: As mentioned earlier, you can enable ACLs when creating a new volume or on an existing volume using a new version of the client. Execute the following command to create a new volume and enable ACLs: ```shell juicefs format --enable-acl sqlite3://myjfs.db myjfs ``` Use the `config` command to enable ACL functionality on an existing volume: ``` juicefs config --enable-acl sqlite3://myjfs.db ``` To set ACL permissions for a file or directory, you can use the `setfacl` command, for example: ``` setfacl -m u:alice:rw- /mnt/jfs/file ``` For detailed rules, guidelines, and implementation of POSIX ACLs, see: ACL permission checks require or later. Enabling ACLs may impact performance. However, due to memory cache optimization, most usage scenarios experience minimal performance degradation.
Project: rkt (Runtime / Container Runtime)
File: security.md

This document tries to give an overview of the security recommendations to follow when running rkt containers and discuss non-obvious communication channels between the host and the pod. Don't run applications as root.* Use the in your images or the `--user` and `--group` when running containers. Don't disable security features unless you really need it.* You should not use the `--insecure-options=` flag unless strictly necessary. Restrict capabilities given to your images as much as possible.* Only those actually needed by your app . Tweak seccomp syscall filtering instead of disabling it.* The default seccomp profile might be too restrictive for your app. If that's the case, instead of disabling it. If you're not affected by its , use user namespaces.* Don't use host networking* since that will give the app in the container access to the host network interfaces and allow it to connect to any other application listening on the host, including on abstract Unix sockets. When using volumes, special care should be taken to avoid dangerous interactions with the host. Here are some security best practices: Use read-only volumes unless writing to them is necessary.* If you use Linux v4.2 or older, avoid sharing directories when tools on the host can move files outside the directory* (such as Nautilus moving directories to the trash bin when a user deletes it). This could expose the entire host filesystem to the container. See . To avoid the previous point: share a full filesystem instead of just a directory in a filesystem if possible*. For example, a mounted partition or some file mounted with `mount -o loop`. Sharing devices from the host to the container is generally not recommended*. If you need to do it, you can find examples in the . Mounts can be added to a pod at runtime by using or when adding apps to a rkt pod with the . This could be used in a malicious way although it requires privileges on the host. In certain situations, some file descriptors belonging to the host namespaces are sent to the pod. rkt supports and . This means some file descriptors will be passed from the host to the container when using those features. In particular, all file descriptors defined in the socket unit file accompanying the service file where rkt is started are passed to the container. rkt supports the mechanism to notify systemd on the host that the pod is ready. This means systemd in the pod will receive a file descriptor which can be used to send information about whether the apps are initialized or not to the host.
Project: MinIO (Runtime / Cloud Native Storage)
File: COMPLIANCE.md

We have designed MinIO as an Open Source software for the Open Source software community. This requires applications to consider whether their usage of MinIO is in compliance with the GNU AGPLv3 . MinIO cannot make the determination as to whether your application's usage of MinIO is in compliance with the AGPLv3 license requirements. You should instead rely on your own legal counsel or licensing specialists to audit and ensure your application is in compliance with the licenses of MinIO and all other open-source projects with which your application integrates or interacts. We understand that AGPLv3 licensing is complex and nuanced. It is for that reason we strongly encourage using experts in licensing to make any such determinations around compliance instead of relying on apocryphal or anecdotal advice. is the best option for applications that trigger AGPLv3 obligations (e.g. open sourcing your application). Applications using MinIO - or any other OSS-licensed code - without validating their usage do so at their own risk.
Project: Weave Net (Runtime / Cloud Native Network)
File: securing-proxy.md

title: Securing the Docker Communications With TLS menu_order: 20 search_type: Documentation If you are [connecting to the docker daemon with TLS](https://docs.docker.com/articles/https/), you most likely want to do the same when connecting to the proxy. The proxy automatically detects the Docker daemon's TLS configuration, and attempts to duplicate it. In the standard auto-detection case you can launch a TLS-enabled proxy as follows: host1$ weave launch To disable auto-detection of TLS configuration, you can either pass the `--no-detect-tls` flag, or you can manually configure the proxy's TLS using the same TLS-related command-line flags supplied to the Docker daemon. For example, if you generated your certificates and keys into the Docker host's `/tls` directory, launch the proxy using: host1$ weave launch --tlsverify --tlscacert=/tls/ca.pem \ --tlscert=/tls/server-cert.pem --tlskey=/tls/server-key.pem The paths to your certificates and key must be provided as absolute paths as they exist on the Docker host. Because the proxy connects to the Docker daemon at `unix:///var/run/docker.sock`, you must ensure that the daemon is actually listening there. To do ensure this, pass the `-H unix:///var/run/docker.sock` option when starting the Docker daemon, in addition to the `-H` options for configuring the TCP listener. See for an example. With the proxy running over TLS, you can configure the Docker client to use TLS on a per-invocation basis by running: $ docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem \ --tlskey=key.pem -H=tcp://host1:12375 version or, , using: $ mkdir -pv ~/.docker $ cp -v {ca,cert,key}.pem ~/.docker $ eval $(weave env) $ export DOCKERTLSVERIFY=1 $ docker version This is exactly the same configuration used when connecting to the Docker daemon directly, except that the specified port is the Weave proxy port. See Also
Project: Rook (Runtime / Cloud Native Storage)
File: key-encryption-key-rotation.md

title: key-encryption-key-rotation target-version: release-1.11.1 Target version: 1.11.1 Currently, Rook encrypts the PVCs backing OSDs with using . The Key Encryption Key (KEK) can be stored in various Key Management Systems (KMS) that Rook supports such as Kubernetes Secrets, HashiCorp Vault, IBM Key Protect and Key Management Interoperability Protocol (KMIP). Rook needs to be able to periodically rotate the KEK, update it simultaeously in both the encrypted device backing OSD and the KMS, to enhance security. This proposal describes how Rook will implement this feature. Rook will be able to periodically rotate the KEK, update the encrypted devices backing OSDs and update the KMS, without any downtime. On demand KEK rotation. The changes required and the workflows are described in the following sections: One per encrypted PVC backed OSD will be created when key rotation is enabled with the given schedule, written in . The CronJob will use OSD pod affinity `requiredDuringScheduling` using the OSD's labels as selector to run on the same node as the OSD. The CronJob will share the host bridge directory with the OSD which contains the enrcypted devices mapped to be able to rotate the KEK. Support for `KMS.UpdateSecret()` needs to be added for each KMS type. This will be used to update the KEK in the KMS. K1 - current KEK in KMS; K2 - new KEK to be added to KMS. | Step | Operation | Luks Slot 0 | Luks Slot 1 | Key in KMS | |:- |:- |:-- |:-- |:- | | 1 | Obtain K1 | K1 | | K1 | | 2 | Add K1 to slot 1 | K1 | K1 | K1 | | 3 | Create K2 & add to slot 0 | K2 | K1 | K1 | | 4 | Update K2 in KMS | K2 | K1 | K2 | | 5 | Remove K1 from slot 1 | K2 | | K2 | Note: The above steps will ensure the KEK in kms will be able to open the encrypted device even if the operation is disrupted at any step and all the edge cases occurring from disrupted processes are handled. `luksAddKey, luksChangeKey, luksKillSlot` commands will be used to achieve this. Refer: Following new section `security.keyRotation` will be added to cephcluster spec to enable and configure the key rotation. ```yaml security: keyRotation: enabled: "true" schedule: "@weekly" ```
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator_completion_bash.md

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> Generate the autocompletion script for bash Generate the autocompletion script for the bash shell. This script depends on the 'bash-completion' package. If it is not installed already, you can install it via your OS's package manager. To load completions in your current shell session: source <(cilium-operator completion bash) To load completions for every new session, execute once: cilium-operator completion bash > /etc/bash_completion.d/cilium-operator cilium-operator completion bash > $(brew --prefix)/etc/bash_completion.d/cilium-operator You will need to start a new shell for this setup to take effect. ``` cilium-operator completion bash ``` ``` -h, --help help for bash --no-descriptions disable completion descriptions ``` - Generate the autocompletion script for the specified shell
Project: Gluster (Runtime / Cloud Native Storage)
File: daemon-management-framework.md

How to introduce new daemons using daemon management framework ============================================================== Glusterd manages GlusterFS daemons providing services like NFS, Proactive self-heal, Quota, User servicable snapshots etc. Following are some of the aspects that come under daemon management. Data members & functions of different management objects Connection Management unix domain sockets based channel for internal communication rpc connection for the communication frame timeout value for UDS Methods - notify init, connect, termination, disconnect APIs can be invoked using the connection management object Process Management Name of the process pidfile to detect if the daemon is running loggging directory, log file, volfile, volfileserver & volfileid init, stop APIs can be invoked using the process management object Service Management connection object process object online status Methods - manager, start, stop which can be abstracted as a common methods or specific to service requirements init API can be invoked using the service management object The above structures defines the skeleton of the daemon management framework. Introduction of new daemons in GlusterFS needs to inherit these properties. Any requirement specific to a daemon needs to be implemented in its own service (for eg : snapd defines its own type glusterdsnapdsvct using glusterdsvct and snapd specific data). New daemons will need to have its own service specific code written in glusterd-<feature>-svc.h{c} and need to reuse the existing framework.
Project: Project Calico (Runtime / Cloud Native Network)
File: CONTRIBUTING.md

networking-calico is part of Project Calico. It provides integration between Calico and OpenStack. If you'd like to contribute in some way, thank you! This file explains how best to do that. Please file new bugs at https://github.com/projectcalico/networking-calico/issues. There are also legacy bugs at https://bugs.launchpad.net/networking-calico, so there could be useful history there, if you'd like to explore whether others have already experienced the issue you are seeing. To discuss anything related to the networking-calico code, please use the 'openstack' channel on https://calicousers.slack.com/, for which you can get an invite at https://slack.projectcalico.org/. Please propose fixes or enhancements as GitHub pull requests against this repo. OpenStack-related documentation is presented as part of the overall Calico doc site at https://docs.projectcalico.org/. The source for that is at https://github.com/projectcalico/calico, so please propose any documentation improvements as pull requests to that repo. For guidance on contributing to the wider Calico project, please see https://docs.projectcalico.org/reference/involved.
Project: MooseFS (Runtime / Cloud Native Storage)
File: PULL_REQUEST_TEMPLATE.md

<! Please fill out the following template, which will help other contributors review your Pull Request. --> <! Provide a general summary of your changes in the Title above --> <! Why is this change required? What problem does it solve? --> <! If it fixes an open issue, please link to the issue here. --> <! Describe your changes in detail --> <! Please describe in detail how you tested your changes. --> <! Include details of your testing environment, and the tests you ran to --> <! see how your change affects other areas of the code, etc. --> <! If your change is a performance enhancement, please provide benchmarks here. --> <! What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> [ ] Bug fix (non-breaking change which fixes an issue) [ ] New feature (non-breaking change which adds functionality) [ ] Performance enhancement (non-breaking change which improves efficiency) [ ] Code cleanup (non-breaking change which makes code smaller or more readable) [ ] Breaking change (fix or feature that would cause existing functionality to change) [ ] Documentation (a change to man pages or other documentation) <! Go over all the following points, and put an `x` in all the boxes that apply. --> <! If you're unsure about any of these, don't hesitate to ask. We're here to help! --> <! - . --> [ ] I have updated the documentation accordingly. <! - . --> to cover my changes. [ ] All new and existing tests passed. <! - . --> <! This PULLREQUESTTEMPLATE.md was shamelessly stolen from from https://github.com/zfsonlinux/zfs As MooseFS evolves it should adopt contribution guidelines and work with the community on an extensive set of tests. -->