cwielenb/CNCF-Dataset huggingface dataset:
Project: Weave Net (Runtime / Cloud Native Network)
File: security-untrusted-networks.md

title: Securing Connections Across Untrusted Networks menu_order: 40 search_type: Documentation To connect containers across untrusted networks, Weave Net peers can be instructed to encrypt traffic by supplying a `--password` option or by using the `WEAVE_PASSWORD` environment variable during `weave launch`. For example: host1$ weave launch --password wfvAwt7sj or host1$ export WEAVE_PASSWORD=wfvAwt7sj host1$ weave launch NOTE: The command line option takes precedence over the environment variable. To avoid leaking your password via the kernel process table or your shell history, we recommend you store it in a file and capture it in a shell variable prior to launching weave: `export WEAVE_PASSWORD=$(cat /path/to/password-file)` To guard against dictionary attacks, the password needs to be reasonably strong, with at least 50 bits of entropy. An easy way to generate a random password that satisfies this requirement is: < /dev/urandom tr -dc A-Za-z0-9 | head -c9 ; echo The same password must be specified for all Weave Net peers, by default both control and data plane traffic will then use authenticated encryption. As an optimization, you can selectively disable data plane encryption if some of your peers are co-located in a trusted network, for example within the boundary of your own data center. List these networks using the `--trusted-subnets` argument with `weave launch`: weave launch --password wfvAwt7sj --trusted-subnets 10.0.2.0/24,192.168.48.0/24 If both peers at the end of a connection consider the other to be in the same trusted subnet, Weave Net attempts to establish non-encrypted connectivity. Otherwise communication is encrypted which imposes overheads. Configured trusted subnets are shown in . Be aware that: Containers will be able to access the router REST API if fast datapath is disabled. You can prevent this by setting: . Containers are able to access the router control and data plane ports, but this can be mitigated by enabling encryption. See Also *
Project: Multus (Runtime / Cloud Native Network)
File: RELEASING.md

A Gomega release is a tagged sha and a GitHub release. To cut a release: Ensure CHANGELOG.md is up to date. Use ```bash LAST_VERSION=$(git tag --sort=version:refname | tail -n1) CHANGES=$(git log --pretty=format:'- %s [%h]' HEAD...$LAST_VERSION) echo -e "## NEXT\n\n$CHANGES\n\n### Features\n\n### Fixes\n\n### Maintenance\n\n$(cat CHANGELOG.md)" > CHANGELOG.md ``` to update the changelog Categorize the changes into Breaking Changes (requires a major version) New Features (minor version) Fixes (fix version) Maintenance (which in general should not be mentioned in `CHANGELOG.md` as they have no user impact) Update GOMEGAVERSION in `gomegadsl.go` Commit, push, and release: ``` git commit -m "vM.m.p" git push gh release create "vM.m.p" git fetch --tags origin master ```
Project: Longhorn (Runtime / Cloud Native Storage)
File: refactor.md

name: Refactor task about: Suggest a refactoring request for an existing implementation title: "[REFACTOR] " labels: kind/refactoring assignees: '' <!--A clear and concise description of what the problem is.--> <!--A clear and concise description of what you want to happen.--> <!--A clear and concise description of any alternative solutions or features you've considered.--> <!--Add any other context or screenshots about the request here.-->
Project: Kilo (Runtime / Cloud Native Network)
File: building_kilo.md

This document describes how you can build and test Kilo. To follow along, you need to install the following utilities: `go` not for building but formatting the code and running unit tests `make` `jq` `git` `curl` `docker` Clone the Repository and `cd` into it. ```shell git clone https://github.com/squat/kilo.git cd kilo ``` For consistency, the Kilo binaries are compiled in a Docker container, so make sure the `docker` package is installed and the daemon is running. To compile the `kg` and `kgctl` binaries run: ```shell make ``` Binaries are always placed in a directory corresponding to the local system's OS and architecture following the pattern `bin/<os>/<architecture>/`, so on an AMD64 machine running Linux, the binaries will be stored in `bin/linux/amd64/`. You can build the binaries for a different architecture by setting the `ARCH` environment variable before invoking `make`, e.g.: ```shell ARCH=<arm|arm64|amd64> make ``` Likewise, to build `kg` for another OS, set the `OS` environment variable before invoking `make`: ```shell OS=<windows|darwin|linux> make ``` To execute the unit tests, run: ```shell make unit ``` To lint the code in the repository, run: ```shell make lint ``` To execute basic end to end tests, run: ```shell make e2e ``` Note: The end to end tests are currently flaky, so try running them again if they fail. To instead run all of the tests with a single command, run: ```shell make test ``` If you want to build containers for a processor architecture that is different from your computer's, then you will first need to configure QEMU as the interpreter for binaries built for non-native architectures: ```shell docker run --rm --privileged multiarch/qemu-user-static --reset -p yes ``` Set the `$IMAGE` environment variable to `<your Docker Hub user name>/kilo`. This way the generated container images and manifests will be named accordingly. By skipping this step, you will be able to tag images but will not be able to push the containers and manifests to your own Docker Hub. ```shell export IMAGE=<docker hub user name>/kilo ``` If you want to use a different container registry, run: ```shell export REGISTRY=<your registry without a trailing slash> ``` To build containers with the `kg` image for `arm`, `arm64` and `amd64`, run: ```shell make all-container ``` Push the container images and build a manifest with: ```shell make manifest ``` To tag and push the manifest with `latest`, run: ```shell make manifest-latest ``` Now you can deploy the custom build of Kilo to your cluster. If you are already running Kilo, change the image from `squat/kilo` to `[registry/]<username>/kilo[:sha]`.
Project: K8up (Runtime / Cloud Native Storage)
File: helm-docs-header.gotmpl.md

{{ template "chart.header" . }} {{ template "chart.deprecationWarning" . }} {{ template "chart.badgesSection" . }} {{ template "chart.description" . }} {{ template "chart.homepageLine" . }} ```bash helm repo add k8up-io https://k8up-io.github.io/k8up helm install {{ template "chart.name" . }} k8up-io/{{ template "chart.name" . }} ```
Project: Gluster (Runtime / Cloud Native Storage)
File: analyzing-regression-cores.md

This document explains how to analyze core-dumps obtained from regression machines, with examples. Download the core-tarball and extract it. `cd` into directory where the tarball is extracted. ``` [sh]# pwd /home/user/Downloads [sh]# ls build build-install-201506250542_39.tar.bz2 lib64 usr ``` Determine the core file you need to examine. There can be more than one core file. You can list them from './build/install/cores' directory. ``` [sh]# ls build/install/cores/ core.9341 liblist.txt liblist.txt.tmp ``` In case you are unsure which binary generated the core-file, executing 'file' command on it will help. ``` [sh]# file ./build/install/cores/core.9341 ./build/install/cores/core.9341: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/build/install/sbin/glusterfsd -s slave26.cloud.gluster.org --volfile-id patchy' ``` As seen, the core file was generated by glusterfsd binary, and path to it is provided (/build/install/sbin/glusterfsd). Now, run the following command on the core: ``` gdb -ex 'set sysroot ./' -ex 'core-file ./build/install/cores/core.xxx' <target, say ./build/install/sbin/glusterd> In this case, gdb -ex 'set sysroot ./' -ex 'core-file ./build/install/cores/core.9341' ./build/install/sbin/glusterfsd ``` You can cross check if all shared libraries are available and loaded by using 'info sharedlibrary' command from inside gdb. Once verified, usual gdb commands based on requirement can be used to debug the core. `bt` or `backtrace` from gdb of core used in examples: ``` Core was generated by `/build/install/sbin/glusterfsd -s slave26.cloud.gluster.org --volfile-id patchy'. Program terminated with signal SIGABRT, Aborted. (gdb) bt at /home/jenkins/root/workspace/rackspace-regression-2GB-triggered/xlators/features/marker/src/marker-quota.c:2921 at /home/jenkins/root/workspace/rackspace-regression-2GB-triggered/xlators/features/marker/src/marker-quota.c:2789 (gdb) ```
Project: lxd (Runtime / Container Runtime)
File: instances_console.md

(instances-console)= Use the command to attach to instance consoles. The console is available at boot time already, so you can use it to see boot messages and, if necessary, debug startup issues of a container or VM. To get an interactive console, enter the following command: incus console <instance_name> To show log output, pass the `--show-log` flag: incus console <instance_name> --show-log You can also immediately attach to the console when you start your instance: incus start <instance_name> --console incus start <instance_name> --console=vga On virtual machines, log on to the console to get graphical output. Using the console you can, for example, install an operating system using a graphical interface or run a desktop environment. An additional advantage is that the console is available even if the `incus-agent` process is not running. This means that you can access the VM through the console before the `incus-agent` starts up, and also if the `incus-agent` is not available at all. To start the VGA console with graphical output for your VM, you must install a SPICE client (for example, `virt-viewer` or `spice-gtk-client`). Then enter the following command: incus console <vm_name> --type vga
Project: Kilo (Runtime / Cloud Native Network)
File: LICENSE.md

Copyright (C) 2018-2019 Matt Layher Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_endpoint_labels.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage label configuration of endpoint ``` cilium-dbg endpoint labels [flags] ``` ``` -a, --add strings Add/enable labels -d, --delete strings Delete/disable labels -h, --help help for labels ``` ``` --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: Cilium (Runtime / Cloud Native Network)
File: cilium-health_ping.md

<!-- This file was autogenerated via cilium-agent --cmdref, do not edit manually--> Check whether the cilium-health API is up ``` cilium-health ping [flags] ``` ``` -h, --help help for ping ``` ``` -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 ``` - Cilium Health Client
Project: lxd (Runtime / Container Runtime)
File: images_remote.md

(images-remote)= The CLI command can support several image servers and comes pre-configured with our own. See {ref}`image-servers` for an overview. <!-- Include start list remotes --> To see all configured remote servers, enter the following command: incus remote list Remote servers that use the are pure image servers. Servers that use the `incus` format are Incus servers, which either serve solely as image servers or might provide some images in addition to serving as regular Incus servers. See {ref}`image-server-types` for more information. <!-- Include end list remotes --> To list all remote images on a server, enter the following command: incus image list <remote>: You can filter the results. See {ref}`images-manage-filter` for instructions. How to add a remote depends on the protocol that the server uses. To add a simple streams server as a remote, enter the following command: incus remote add <remote_name> <URL> --protocol=simplestreams The URL must use HTTPS. <!-- Include start add remotes --> To add an Incus server as a remote, enter the following command: incus remote add <remote_name> <IP|FQDN|URL> [flags] Some authentication methods require specific flags (for example, use for OIDC authentication). See {ref}`server-authenticate` and {ref}`authentication` for more information. For example, enter the following command to add a remote through an IP address: incus remote add my-remote 192.0.2.10 You are prompted to confirm the remote server fingerprint and then asked for the token. <!-- Include end add remotes --> To reference an image, specify its remote and its alias or fingerprint, separated with a colon. For example: images:ubuntu/22.04 images:ubuntu/22.04 local:ed7509d7e83f (images-remote-default)= If you specify an image name without the name of the remote, the default image server is used. To see which server is configured as the default image server, enter the following command: incus remote get-default To select a different remote as the default image server, enter the following command: incus remote switch <remote_name>
Project: Kata Containers (Runtime / Container Runtime)
File: kata-containers-3.0-rust-runtime-installation-guide.md

The following is an overview of the different installation methods available. Kata Containers 3.0 rust runtime requires nested virtualization or bare metal. Check to see if your system is capable of running Kata Containers. Kata Containers 3.0 rust runtime currently runs on 64-bit systems supporting the following architectures: Notes: For other architectures, see https://github.com/kata-containers/kata-containers/issues/4320 | Architecture | Virtualization technology | |-|-| | `x86_64`| VT-x | | `aarch64` ("`arm64`")| Hyp | | Installation method | Description | Automatic updates | Use case | Availability ||-|-|--|-- | | | The preferred way to deploy the Kata Containers distributed binaries on a Kubernetes cluster | No! | Best way to give it a try on kata-containers on an already up and running Kubernetes cluster. | Yes | | | Kata packages provided by Linux distributions official repositories | yes | Recommended for most users. | No | | | Run a single command to install a full system | No! | For those wanting the latest release quickly. | No | | | Follow a guide step-by-step to install a working system | No! | For those who want the latest release with more control. | No | | | Build the software components manually | No! | Power users and developers only. | Yes | Follow the . `ToDo` `ToDo` `ToDo` Download `Rustup` and install `Rust` > Notes: > For Rust version, please set `RUSTVERSION` to the value of `languages.rust.meta.newest-version key` in or, if `yq` is available on your system, run `export RUSTVERSION=$(yq read versions.yaml languages.rust.meta.newest-version)`. Example for `x86_64` ``` $ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh $ source $HOME/.cargo/env $ rustup install ${RUST_VERSION} $ rustup default ${RUSTVERSION}-x8664-unknown-linux-gnu ``` Musl support for fully static binary Example for `x86_64` ``` $ rustup target add x86_64-unknown-linux-musl ``` install Example for musl 1.2.3 ``` $ curl -O https://git.musl-libc.org/cgit/musl/snapshot/musl-1.2.3.tar.gz $ tar vxf musl-1.2.3.tar.gz $ cd musl-1.2.3/ $ ./configure --prefix=/usr/local/ $ make && sudo make install ``` ``` $ git clone https://github.com/kata-containers/kata-containers.git $ cd kata-containers/src/runtime-rs $ make && sudo make install ``` After running the command above, the default config file `configuration.toml` will be installed under `/usr/share/defaults/kata-containers/`, the binary file `containerd-shim-kata-v2` will be installed under `/usr/local/bin/` . Follow the . Follow the . Follow the . Follow the .
Project: JuiceFS (Runtime / Cloud Native Storage)
File: etcd_best_practices.md

sidebar_label: etcd sidebar_position: 3 slug: /etcdbestpractices By default, etcd sets a of 2GB, which can support storing metadata of two million files. Adjusted via the `--quota-backend-bytes` option, do not exceed 8GB. By default, etcd will keep the modification history of all data until the amount of data exceeds the space quota and the service cannot be provided. It is recommended to add the following options to enable : ```` --auto-compaction-mode revision --auto-compaction-retention 1000000 ```` When the amount of data reaches the quota and cannot be written, the capacity can be reduced by manual compaction (`etcdctl compact`) and defragmentation (`etcdctl defrag`). It is strongly recommended to perform these operations on the nodes of the etcd cluster one by one, otherwise the entire etcd cluster may become unavailable. etcd provides strongly consistent read and write access, and all operations involve multi-machine transactions and disk data persistence. It is recommended to use high-performance SSD for deployment, otherwise it will affect the performance of the file system. For more hardware configuration suggestions, please refer to . If the etcd cluster has power-down protection, or other measures that can ensure that all nodes will not go down at the same time, you can also disable data synchronization and disk storage through the `--unsafe-no-fsync` option to reduce access latency and improve files system performance. At this time, if two nodes are down at the same time, there is a risk of data loss. It is recommended to build an independent etcd service in the Kubernetes environment for JuiceFS to use, instead of using the default etcd service in the cluster, to avoid affecting the stability of the Kubernetes cluster when the file system access pressure is high.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_loadinfo.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Show load information ``` cilium-dbg loadinfo [flags] ``` ``` -h, --help help for loadinfo ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_fqdn_cache_list.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> List fqdn cache contents ``` cilium-dbg fqdn cache list [flags] ``` ``` -e, --endpoint string List cache entries for a specific endpoint id -h, --help help for list -p, --matchpattern string List cache entries with FQDN that match matchpattern -o, --output string json| yaml| jsonpath='{}' -s, --source string List cache entries from a specific source (lookup, connection) ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - Manage fqdn proxy cache
Project: CNI-Genie (Runtime / Cloud Native Network)
File: INTRODUCTION.md

CNI Genie is an add-on to open-source project and is designed to provide the following features: Multiple CNI plugins are available to users in runtime. The user can offer any of the available CNI plugins to containers upon creating them User-story: based on performance requirements, application requirements, workload placement requirements, the user could be interested to use different CNI plugins for different application groups Different CNI plugins are different in terms of need for port-mapping, NAT, tunneling, interrupting host ports/interfaces Multiple IP addresses can be injected into a single container making the container reachable across multiple networks User-story: in a serverless platform the Request Dispatcher container that receives requests from customers of all different tenants needs to be able to pass the request to the right tenant. As a result, is should be reachable on the networks of all tenants User-story: many Telecom vendors are adopting container technology. For a router/firewall application to run in a container, it needs to have multiple interfaces Upon creating a pod, the user can manually select the logical network, or multiple logical networks, that the pod should be added to If upon creating a pod no logical network is included in the yaml configuration, CNI Genie will automatically select one of the available CNI plugins CNI Genie maintains a list of KPIs for all available CNI plugins. Examples of such KPIs are occupancy rate, number of subnets, response times CNI Genie stores records of requests made to each CNI plugin for logging and auditing purposes and it can generate reports upon request Network policy Network access control Note: CNI Genie is NOT a routing solution! It gets IP addresses from various CNSs
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_statedb.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Inspect StateDB ``` -h, --help help for statedb ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI - Show contents of table "bandwidth-qdiscs" - Show contents of table "devices" - Dump StateDB contents as JSON - Show contents of table "health" - Show contents of table "ipsets" - Show contents of table "l2-announce" - Show contents of table "node-addresses" - Show contents of table "routes" - Show contents of table "sysctl"