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

(server-configure)= See {ref}`server` for all configuration options that are available for the Incus server. If the Incus server is part of a cluster, some of the options apply to the cluster, while others apply only to the local server, thus the cluster member. In the {ref}`server` option tables, options that apply to the cluster are marked with a `global` scope, while options that apply to the local server are marked with a `local` scope. You can configure a server option with the following command: incus config set <key> <value> For example, to allow remote access to the Incus server on port 8443, enter the following command: incus config set core.https_address :8443 In a cluster setup, to configure a server option for a cluster member only, add the `--target` flag. For example, to configure where to store image tarballs on a specific cluster member, enter a command similar to the following: incus config set storage.images_volume my-pool/my-volume --target member02 To display the current server configuration, enter the following command: incus config show In a cluster setup, to show the local configuration for a specific cluster member, add the `--target` flag. To edit the full server configuration as a YAML file, enter the following command: incus config edit In a cluster setup, to edit the local configuration for a specific cluster member, add the `--target` flag.
Project: Velero (Runtime / Cloud Native Storage)
File: image-tagging.md

title: "Image tagging policy" layout: docs This document describes Velero's image tagging policy. `velero/velero:<SemVer>` Velero follows the standard for releases. Each tag in the `github.com/vmware-tanzu/velero` repository has a matching image, `velero/velero:v1.0.0`. `velero/velero:latest` The `latest` tag follows the most recently released version of Velero. `velero/velero:main` The `main` tag follows the latest commit to land on the `main` branch.
Project: Flannel (Runtime / Cloud Native Network)
File: reservations.md

When flannel starts up, it ensures that the host has a subnet lease. If there is an existing lease then it's used, otherwise one is assigned. Leases can be viewed by checking the contents of etcd. e.g. ``` $ export ETCDCTL_API=3 $ etcdctl get /coreos.com/network/subnets --prefix --keys-only /coreos.com/network/subnets/10.5.52.0-24 $ etcdctl get /coreos.com/network/subnets/10.5.52.0-24 /coreos.com/network/subnets/10.5.52.0-24 {"PublicIP":"192.168.64.3","PublicIPv6":null,"BackendType":"vxlan","BackendData":{"VNI":1,"VtepMAC":"c6:d2:32:6f:8f:44"}} $ etcdctl lease list found 1 leases 694d854330fc5110 $ etcdctl lease timetolive --keys 694d854330fc5110 lease 694d854330fc5110 granted with TTL(86400s), remaining(74737s), attached keys([/coreos.com/network/subnets/10.5.52.0-24]) ``` This shows that there is a single lease (`10.5.52.0/24`) which will expire in 74737 seconds. flannel will attempt to renew the lease before it expires, but if flannel is not running for an extended period then the lease will be lost. The `"PublicIP"` value is how flannel knows to reuse this lease when restarted. This means that if the public IP changes, then the flannel subnet will change too. In case a host is unable to renew its lease before the lease expires (e.g. a host takes a long time to restart and the timing lines up with when the lease would normally be renewed), flannel will then attempt to renew the last lease that it has saved in its subnet config file (which, unless specified, is located at `/var/run/flannel/subnet.env`) ```bash cat /var/run/flannel/subnet.env FLANNEL_NETWORK=10.5.0.0/16 FLANNEL_SUBNET=10.5.52.1/24 FLANNEL_MTU=1450 FLANNEL_IPMASQ=false ``` In this case, if flannel fails to retrieve an existing lease from etcd, it will attempt to renew lease specified in `FLANNEL_SUBNET` (`10.5.52.1/24`). It will only renew this lease if the subnet specified is valid for the current etcd network configuration otherwise it will allocate a new lease. flannel also supports reservations for the subnet assigned to a host. Reservations allow a fixed subnet to be used for a given host. The only difference between a lease and reservation is the etcd TTL value. Simply removing the TTL from a lease will convert it to a reservation. e.g. ``` $ export ETCDCTL_API=3 $ etcdctl put /coreos.com/network/subnets/10.5.1.0-24 $(etcdctl get /coreos.com/network/subnets/10.5.1.0-24) ```
Project: lxd (Runtime / Container Runtime)
File: server_expose.md

(server-expose)= By default, Incus can be used only by local users through a Unix socket and is not accessible over the network. To expose Incus to the network, you must configure it to listen to addresses other than the local Unix socket. To do so, set the {config:option}`server-core:core.https_address` server configuration option. For example, to allow access to the Incus server on port `8443`, enter the following command: incus config set core.https_address :8443 To allow access through a specific IP address, use `ip addr` to find an available address and then set it. For example: ```{terminal} :input: ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo validlft forever preferredlft forever inet6 ::1/128 scope host validlft forever preferredlft forever 2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:16:3e:e3:f3:3f brd ff:ff:ff:ff:ff:ff inet 10.68.216.12/24 metric 100 brd 10.68.216.255 scope global dynamic enp5s0 validlft 3028sec preferredlft 3028sec inet6 fd42:e819:7a51:5a7b:216:3eff:fee3:f33f/64 scope global mngtmpaddr noprefixroute validlft forever preferredlft forever inet6 fe80::216:3eff:fee3:f33f/64 scope link validlft forever preferredlft forever 3: incusbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 00:16:3e:8d:f3:72 brd ff:ff:ff:ff:ff:ff inet 10.64.82.1/24 scope global incusbr0 validlft forever preferredlft forever inet6 fd42:f4ab:4399:e6eb::1/64 scope global validlft forever preferredlft forever :input: incus config set core.https_address 10.68.216.12 ``` All remote clients can then connect to Incus and access any image that is marked for public use. (server-authenticate)= To be able to access the remote API, clients must authenticate with the Incus server. There are several authentication methods; see {ref}`authentication` for detailed information. The recommended method is to add the client's TLS certificate to the server's trust store through a trust token. To authenticate a client using a trust token, complete the following steps: On the server, enter the following command: incus config trust add <client_name> The command generates and prints a token that can be used to add the client certificate. On the client, add the server with the following command: incus remote add <remote_name> <token> % Include content from ```{include} ../authentication.md :start-after: <!-- Include start NAT authentication --> :end-before: <!-- Include end NAT authentication --> ``` See {ref}`authentication` for detailed information and other authentication methods.
Project: OpenIO (Runtime / Cloud Native Storage)
File: PULL_REQUEST_TEMPLATE.md

<! Describe the change, including rationale and design decisions --> <! If you are fixing an existing issue, please include "Fixes #nnn" in your commit message and your description; but you should still explain what the change does. --> <! Pick one below and delete the rest: --> Feature Pull Request Bugfix Pull Request Docs Pull Request <! Name of the servicetype --> <! Paste verbatim output from "openio --version" between quotes below --> ``` ``` <! Include additional information to help people understand the change here. For bugs that don't have a linked bug report, a step-by-step reproduction of the problem is helpful. --> <! Paste verbatim command output below, e.g. before and after your change --> ``` ```
Project: Antrea (Runtime / Cloud Native Network)
File: antrea-agent-simulator.md

This document describes how to run the Antrea agent simulator. The simulator is useful for Antrea scalability testing, without having to create a very large cluster. ```bash make build-scale-simulator ``` This demo uses 1 simulator, this command will create a yaml file build/yamls/antrea-scale.yml ```bash make manifest-scale ``` The above yaml will create one simulated Node/Pod, to change the number of instances, you can modify `spec.replicas` of the StatefulSet `antrea-agent-simulator` in the yaml, or scale it via `kubectl scale statefulset/antrea-agent-simulator -n kube-system --replicas=<COUNT>` after deploying it. To prevent Pods from being scheduled on the simulated Node(s), you can use the following taint. ```bash kubectl taint -l 'antrea/instance=simulator' node mocknode=true:NoExecute ``` ```bash kubectl create secret generic kubeconfig --type=Opaque --namespace=kube-system --from-file=admin.conf=<path to kubeconfig file> ``` ```bash kubectl apply -f build/yamls/antrea-scale.yml ``` check the simulated Node: ```bash kubectl get nodes -l 'antrea/instance=simulator' ```
Project: Rook (Runtime / Cloud Native Storage)
File: data-model.md

``` The operator manages multiple Rook storage clusters The operator manages all CRDs for the Rook clusters One instance of the operator is active Multiple instances of the operator can be on standby in an HA configuration The cluster CRD defines desired settings for a storage cluster All resources for a Rook cluster are created in the same Kubernetes namespace A cluster has an odd number of mons that form quorum A cluster has an osd per storage device A cluster has zero or more pools A cluster has zero or more block devices A cluster has zero or more object stores A cluster has zero or more shared file services The pool CRD defines desired settings for a pool A pool is created with either replication or erasure coding Replication can be 1 or more Erasure coding requires k >= 2 and m >= 1, where k is data chunks and m is coding chunks Erasure coding specifies a plugin (default=jerasure) Erasure coding specifies an encoding algorithm (default=reedsolvan) A pool can set its failure domain using a CRUSH rule (default=host) The object store CRD defines desired settings for an object store An object store has a set of pools dedicated to its instance Object store metadata pools can specify the same set of pool settings The object store data pool can specify all pool settings An object store has a unique set of authorized users An object store has one or more stateless RGW pods for load balancing An object store can specify an SSL certificate for secure connections An object store can specify a port for RGW services (default=53390) An object store represents a Ceph zone An object store can be configured for replication from an object store in the same cluster or another cluster The file system CRD defines desired settings for a file system A file system has one MDS service if not partitioned A file system has multiple MDS services if partitioned A file system has one metadata pool A file system has one data pool ```
Project: Rook (Runtime / Cloud Native Storage)
File: ROADMAP.md

This document defines a high level roadmap for Rook development and upcoming releases. The features and themes included in each milestone are optimistic in the sense that some do not have clear owners yet. Community and contributor involvement is vital for successfully implementing all desired items for each release. We hope that the items listed below will inspire further engagement from the community to keep Rook progressing and shipping exciting and valuable features. Any dates listed below and the specific issues that will ship in a given milestone are subject to change but should give a general idea of what we are planning. See the for the most up-to-date issues and their status. The following high level features are targeted for Rook v1.14 (April 2024). For more detailed project tracking see the . Support for Ceph Squid (v19) Allow setting the application name on a CephBlockPool Pool sharing for multiple object stores DNS subdomain style access to RGW buckets Replace a single OSD when a metadataDevice is configured with multiple OSDs Create a default service account for all Ceph daemons Enable the rook orchestrator mgr module by default for improved dashboard integration Option to run all components on the host network Multus-enabled clusters to begin "holder" pod deprecation Separate CSI image repository and tag for all images in the helm chart Ceph-CSI Add build support for Go 1.22 Add topology based provisioning for external clusters Features are planned in the 1.14 time frame for the . Collect details to help troubleshoot the csi driver Command to flatten an RBD image
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_policy_validate.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Validate a policy ``` cilium-dbg policy validate <path> [flags] ``` ``` -h, --help help for validate --print Print policy after validation -v, --verbose Enable verbose output (default true) ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage security policies
Project: lxd (Runtime / Container Runtime)
File: devices_tpm.md

(devices-tpm)= ```{note} The `tpm` device type is supported for both containers and VMs. It supports hotplugging only for containers, not for VMs. ``` TPM devices enable access to a {abbr}`TPM (Trusted Platform Module)` emulator. TPM devices can be used to validate the boot process and ensure that no steps in the boot chain have been tampered with, and they can securely generate and store encryption keys. Incus uses a software TPM that supports TPM 2.0. For containers, the main use case is sealing certificates, which means that the keys are stored outside of the container, making it virtually impossible for attackers to retrieve them. For virtual machines, TPM can be used both for sealing certificates and for validating the boot process, which allows using full disk encryption compatible with, for example, Windows BitLocker. `tpm` devices have the following device options: Key | Type | Default | Required | Description :-- | :-- | :-- | :-- | :-- `path` | string | - | for containers | Only for containers: path inside the instance (for example, `/dev/tpm0`) `pathrm` | string | - | for containers | Only for containers: resource manager path inside the instance (for example, `/dev/tpmrm0`)
Project: HwameiStor (Runtime / Cloud Native Storage)
File: admission_controller.md

sidebar_position: 5 sidebar_label: "Admission Controller" `admission-controller` is a webhook that can automatically verify which pod uses the HwameiStor volume and help to modify the schedulerName to hwameistor-scheduler. For the specific principle, refer to . `admission-controller` gets all the PVCs used by a pod, and checks the of each PVC in turn. If the suffix of the provisioner name is `*.hwameistor.io`, it is believed that the pod is using the volume provided by HwameiStor. Only Pod resources will be verified, and the verification process occurs at the time of creation. :::info In order to ensure that the pods of HwameiStor can be started smoothly, the pods in the namespace where HwameiStor is deployed will not be verified. :::
Project: Velero (Runtime / Cloud Native Storage)
File: upgrade-to-1.10.md

title: "Upgrading to Velero 1.10" layout: docs Velero installed. If you're not yet running at least Velero v1.6, see the following: Before upgrading, check the to make sure your version of Kubernetes is supported by the new version of Velero. Caution: From Velero v1.10, except for using restic to do file-system level backup and restore, kopia is also been integrated, so there would be a little bit of difference when upgrading to v1.10 from a version lower than v1.10.0. Install the Velero v1.10 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.10.0 Git commit: <git SHA> ``` Update the Velero custom resource definitions (CRDs) to include schema changes across all CRDs that are at the core of the new features in this release: ```bash velero install --crds-only --dry-run -o yaml | kubectl apply -f - ``` NOTE: Since velero v1.10.0 only v1 CRD will be supported during installation, therefore, the v1.10.0 will only work on kubernetes version >= v1.16 Update the container image and objects fields used by the Velero deployment and, optionally, the restic daemon set: ```bash kubectl get deploy -n velero -ojson \ | sed "s#\"image\"\: \"velero\/velero\:v[0-9].[0-9].[0-9]\"#\"image\"\: \"velero\/velero\:v1.10.0\"#g" \ | sed "s#\"server\",#\"server\",\"--uploader-type=$uploader_type\",#g" \ | sed "s#default-volumes-to-restic#default-volumes-to-fs-backup#g" \ | sed "s#default-restic-prune-frequency#default-repo-maintain-frequency#g" \ | sed "s#restic-timeout#fs-backup-timeout#g" \ | kubectl apply -f - echo $(kubectl get ds -n velero restic -ojson) \ | sed "s#\"image\"\: \"velero\/velero\:v[0-9].[0-9].[0-9]\"#\"image\"\: \"velero\/velero\:v1.10.0\"#g" \ | sed "s#\"name\"\: \"restic\"#\"name\"\: \"node-agent\"#g" \ | sed "s#\[ \"restic\",#\[ \"node-agent\",#g" \ | kubectl apply -f - kubectl delete ds -n velero restic --force --grace-period 0 ``` 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.10.0 Git commit: <git SHA> Server: Version: v1.10.0 ``` If upgraded from v1.9.x, there still remains some resources left over in the cluster and never used in v1.10.x, which could be deleted through kubectl and it is based on your desire: resticrepository CRD and related CRs velero-restic-credentials secret in velero install namespace
Project: gVisor (Runtime / Container Runtime)
File: docker-in-gvisor.md

Docker is a platform designed to help developers build, share, and run container applications. In gVisor, all basic docker commands should function as expected. However, it's important to note that, currently, only the host network driver is supported. This means that both 'docker run' and 'docker build' commands must be executed with the `--network=host` option. First, prepare a container image with pre-installed Docker: ```shell $ cd images/basic/docker/ $ docker build -t docker-in-gvisor . ``` Since Docker requires root privileges and a full set of capabilities, a gVisor sandbox needs to be started in privileged mode: ```shell $ docker run --runtime runsc -d --rm --privileged --name docker-in-gvisor docker-in-gvisor ``` Now, we can build and run Docker containers. Let's enter in the gvisor sandbox and run some docker commands: ```shell docker exec -it docker-in-gvisor bash ``` ```shell $ mkdir whalesay && cd whalesay $ cat > Dockerfile <<EOF FROM ubuntu RUN apt-get update && apt-get install -y cowsay curl RUN mkdir -p /usr/share/cowsay/cows/ RUN curl -o /usr/share/cowsay/cows/docker.cow https://raw.githubusercontent.com/docker/whalesay/master/docker.cow ENTRYPOINT ["/usr/games/cowsay", "-f", "docker.cow"] EOF $ docker build --network=host -t whalesay . .... Successfully tagged whalesay:latest $ docker run --network host -it --rm whalesay "Containers do not contain, but gVisor-s do!" _ / Containers do not contain, but gVisor-s \ \ do! / -- \ ## . \ ## ## ## == /""""""""""""""""\_/ === ~ { ~ ~ / ===- ~~~ \ o / \ \ / \\/ ```
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-health_completion_zsh.md

<!-- This file was autogenerated via cilium-agent --cmdref, do not edit manually--> Generate the autocompletion script for zsh Generate the autocompletion script for the zsh shell. If shell completion is not already enabled in your environment you will need to enable it. You can execute the following once: echo "autoload -U compinit; compinit" >> ~/.zshrc To load completions in your current shell session: source <(cilium-health completion zsh) To load completions for every new session, execute once: cilium-health completion zsh > "${fpath[1]}/_cilium-health" cilium-health completion zsh > $(brew --prefix)/share/zsh/site-functions/_cilium-health You will need to start a new shell for this setup to take effect. ``` cilium-health completion zsh [flags] ``` ``` -h, --help help for zsh --no-descriptions disable completion descriptions ``` ``` -D, --debug Enable debug messages -H, --host string URI to cilium-health server API --log-driver strings Logging endpoints to use for example syslog --log-opt map Log driver options for cilium-health e.g. syslog.level=info,syslog.facility=local5,syslog.tag=cilium-agent ``` - Generate the autocompletion script for the specified shell
Project: Cilium (Runtime / Cloud Native Network)
File: CHANGES.md

Documentation updates. Small linter cleanups. Added example in test. Document the usage of Cleanup when re-reading a file (thanks to @lesovsky) for issue #18. Add example directories with example and tests for issues. Fix of checksum problem because of forced tag. No changes to the code. Incorporated PR 162 by by Mohammed902: "Simplify non-Windows build tag". Incorporated PR 9 by mschneider82: "Added seekinfo to Tail". Incorporated PR 7: "Fix deadlock when stopping on non-empty file/buffer", fixes upstream issue 93. Incorporated changes of unmerged upstream PR 149 by mezzi: "added line num to Line struct". Incorporated changes of unmerged upstream PR 128 by jadekler: "Compile-able code in readme". Incorporated changes of unmerged upstream PR 130 by fgeller: "small change to comment wording". Incorporated changes of unmerged upstream PR 133 by sm3142: "removed spurious newlines from log messages". Incorporated changes of unmerged upstream PR 126 by Code-Hex: "Solved the problem for never return the last line if it's not followed by a newline". Incorporated changes of unmerged upstream PR 131 by StoicPerlman: "Remove deprecated os.SEEK consts". The changes bumped the minimal supported Go release to 1.9. migration to go modules. release of master branch of the dormant upstream, because it contains fixes and improvement no present in the tagged release.