cwielenb/CNCF-Dataset huggingface dataset:
Project: Kata Containers (Runtime / Container Runtime)
File: how-to-run-rootless-vmm.md

To improve security, Kata Container supports running the VMM process (QEMU and cloud-hypervisor) as a non-`root` user. This document describes how to enable the rootless VMM mode and its limitations. The permission and ownership of the `kvm` device node (`/dev/kvm`) need to be configured to: ``` $ crw-rw- 1 root kvm ``` use the following commands: ``` $ sudo groupadd kvm -r $ sudo chown root:kvm /dev/kvm $ sudo chmod 660 /dev/kvm ``` By default, the VMM process still runs as the root user. There are two ways to enable rootless VMM: Set the `rootless` flag to `true` in the hypervisor section of `configuration.toml`. Set the Kubernetes annotation `io.katacontainers.hypervisor.rootless` to `true`. When `rootless` flag is enabled, upon a request to create a Pod, Kata Containers runtime creates a random user and group (e.g. `kata-123`), and uses them to start the hypervisor process. The `kvm` group is also given to the hypervisor process as a supplemental group to give the hypervisor process access to the `/dev/kvm` device. Another necessary change is to move the hypervisor runtime files (e.g. `vhost-fs.sock`, `qmp.sock`) to a directory (under `/run/user/[uid]/`) where only the non-root hypervisor has access to. Only the VMM process is running as a non-root user. Other processes such as Kata Container shimv2 and `virtiofsd` still run as the root user. Currently, this feature is only supported in QEMU and cloud-hypervisor. For firecracker, you can use jailer to run the VMM process with a non-root user. Certain features will not work when rootless VMM is enabled, including: Passing devices to the guest (`virtio-blk`, `virtio-scsi`) will not work if the non-privileged user does not have permission to access it (leading to a permission denied error). A more permissive permission (e.g. 666) may overcome this issue. However, you need to be aware of the potential security implications of reducing the security on such devices. `vfio` device will also not work because of permission denied error.
Project: Carina (Runtime / Cloud Native Storage)
File: roadmap.md

- - - - - - - - - - - Currently, when node enters NotReady state and kubernetes-shceduler tries to replace it on other nodes, the carina scheduler will bind it the the-notready-node again. This works fine if it's just the pod fails and the newly created pod will reuse the local volume again. But if the node is indeed failed, we should reschedule the pod to give it another change, although the newly borned pod will have an empty volume. This will fix . Use helm chart for ease of installationuninstallationupgrade Currently, carina groups disks with its type. However, some workloads may prefer using spereated disks against others. For now the capacity and allocatable resources will remain the same. This will fix . Provides raw disk or partitions to workload, without LVM management. For example, user may request a raw disk exclusively, or part of disk. Using velero to backup carina PV to S3. Using RAID to manage disks on baremetal. User can configure RAID level due to needs. When disk fails, carina can find the failed disk and try to rebuild the RAID if new disk is plugged in. support NVME disks Carina should get SMART info for HDD and SSD devices. Issue a warning if found bad sectors or SSD is dying. Report raw disk and PV's comprehensive metrics, likes IOPSbandwidthiotop and so on. User can use annottion to enable PVC auto sizeing. So if one PV is 80% full, carina will automatically expanding it without user intervention. Currently carina scheduleing based on node's capacity and allocatable resources. However, node's load maybe very heavy while it's having lots of free disk spaces. Carina should be load-aware. Carina should support cgroup V2 for disk throttling to have better experience for buffered IO. Ensure read out what exactly been written. Some workload may prefer safety with performance. When node's load becomes really heavy, carina can evict some workload with lower priority. The workload priority is same with kubernetes defines.
Project: lxd (Runtime / Container Runtime)
File: devices_none.md

(devices-none)= ```{note} The `none` device type is supported for both containers and VMs. ``` A `none` device doesn't have any properties and doesn't create anything inside the instance. Its only purpose is to stop inheriting devices that come from profiles. To do so, add a device with the same name as the one that you do not want to inherit, but with the device type `none`. You can add this device either in a profile that is applied after the profile that contains the original device, or directly on the instance.
Project: Velero (Runtime / Cloud Native Storage)
File: cloud-common.md

title: "Set up Ark with your cloud provider" layout: docs To run Ark with your cloud provider, you specify provider-specific settings for the Ark server. In version 0.7.0 and later, you can run Ark in any namespace, which requires additional customization. See . The Ark repository includes a set of example YAML files that specify the settings for each cloud provider. For provider-specific instructions, see: After you set up the Ark server, try these examples: Start the sample nginx app: ```bash kubectl apply -f examples/nginx-app/base.yaml ``` Create a backup: ```bash ark backup create nginx-backup --include-namespaces nginx-example ``` Simulate a disaster: ```bash kubectl delete namespaces nginx-example ``` Wait for the namespace to be deleted. Restore your lost resources: ```bash ark restore create --from-backup nginx-backup ``` NOTE: For Azure, your Kubernetes cluster needs to be version 1.7.2+ to support PV snapshotting of its managed disks. Start the sample nginx app: ```bash kubectl apply -f examples/nginx-app/with-pv.yaml ``` Create a backup with PV snapshotting: ```bash ark backup create nginx-backup --include-namespaces nginx-example ``` Simulate a disaster: ```bash kubectl delete namespaces nginx-example ``` Because the default for dynamically-provisioned PVs is "Delete", these commands should trigger your cloud provider to delete the disk backing the PV. The deletion process is asynchronous so this may take some time. Before continuing to the next step, check your cloud provider to confirm that the disk no longer exists. Restore your lost resources: ```bash ark restore create --from-backup nginx-backup ```
Project: FabEdge (Runtime / Cloud Native Network)
File: CHANGELOG-0.7.0.md

[toc] Change the naming strategy of fabedge-agent pods; Add commonName validation for fabedge-agent certificates; Implement node-specific configuration of fabedge-agent arguments; Let fabedge-agent configure sysctl parameters needed; Let fabedge-operator manage calico ippools for CIDRs; Fix wrong service port mapping of fab-proxy;
Project: Submariner (Runtime / Cloud Native Network)
File: failing-test.md

name: Failing Test about: Report continuously failing tests or jobs in Submariner CI labels: failing-test <!-- Please only use this template for submitting reports about continuously failing tests or jobs in Submariner CI --> Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know:
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf_srv6.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Manage the SRv6 routing rules ``` -h, --help help for srv6 ``` ``` --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 - List SRv6 policy entries - List SRv6 SID entries - List SRv6 VRF mappings
Project: CRI-O (Runtime / Container Runtime)
File: go-md2man.1.md

go-md2man 1 "January 2015" go-md2man "User Manual" ================================================== go-md2man - Convert mardown files into manpages go-md2man -in=[/path/to/md/file] -out=[/path/to/output] go-md2man converts standard markdown formatted documents into manpages. It is written purely in Go so as to reduce dependencies on 3rd party libs. By default, the input is stdin and the output is stdout. Convert the markdown file "go-md2man.1.md" into a manpage. go-md2man -in=README.md -out=go-md2man.1.out January 2015, Originally compiled by Brian Goff( cpuguy83@gmail.com )
Project: rkt (Runtime / Container Runtime)
File: overriding-defaults.md

This document holds information about modifying or replacing builtin defaults and is only recommended to advanced users. Please make sure to have read the before treading into these things. If a network has a name "default", it will override the default network added by rkt. It is strongly recommended that such network also has type "ptp" as it protects from the pod spoofing its IP address and defeating identity management provided by the metadata service. The network backend CNI allows the passing of , specifically `CNI_ARGS`, at runtime. These arguments can be used to reconfigure a network without changing the configuration file. rkt supports the `CNI_ARGS` variable through the command line argument `--net`. The syntax for passing arguments to a network looks like `--net="$networkname1:$arg1=$val1;$arg2=val2"`. When executed from a shell, you can use double quotes to avoid `;` being interpreted as a command separator by the shell. To allow the passing of arguments to different networks simply append the arguments to the network name with a colon (`:`), and separate the arguments by semicolon (`;`). All arguments can either be given in a single instance of the `--net`, or can be spread across multiple uses of `--net`. Reminder: the separator for the networks (and their arguments) within one `--net` instance is the comma `,`. A network name must not be passed more than once, not within the same nor throughout multiple instances of `--net`. This example will override the IP in the networks net1 and net2. ```bash rkt run --net="net1:IP=1.2.3.4" --net="net2:IP=1.2.4.5" pod.aci ``` This example will load all configured networks and override the IP addresses for net1 and net2. ```bash rkt run --net="all,net1:IP=1.2.3.4" --net="net2:IP=1.2.4.5" pod.aci ``` This is not documented yet. Please follow CNI issue to track the progress of the documentation.
Project: Stash by AppsCode (Runtime / Cloud Native Storage)
File: legacy_jetstream.md

This is a documentation for the legacy JetStream API. A README for the current API can be found ```go import "github.com/nats-io/nats.go" // Connect to NATS nc, _ := nats.Connect(nats.DefaultURL) // Create JetStream Context js, _ := nc.JetStream(nats.PublishAsyncMaxPending(256)) // Simple Stream Publisher js.Publish("ORDERS.scratch", []byte("hello")) // Simple Async Stream Publisher for i := 0; i < 500; i++ { js.PublishAsync("ORDERS.scratch", []byte("hello")) } select { case <-js.PublishAsyncComplete(): case <-time.After(5 * time.Second): fmt.Println("Did not resolve in time") } // Simple Async Ephemeral Consumer js.Subscribe("ORDERS.", func(m nats.Msg) { fmt.Printf("Received a JetStream message: %s\n", string(m.Data)) }) // Simple Sync Durable Consumer (optional SubOpts at the end) sub, err := js.SubscribeSync("ORDERS.*", nats.Durable("MONITOR"), nats.MaxDeliver(3)) m, err := sub.NextMsg(timeout) // Simple Pull Consumer sub, err := js.PullSubscribe("ORDERS.*", "MONITOR") msgs, err := sub.Fetch(10) // Unsubscribe sub.Unsubscribe() // Drain sub.Drain() ``` ```go import "github.com/nats-io/nats.go" // Connect to NATS nc, _ := nats.Connect(nats.DefaultURL) // Create JetStream Context js, _ := nc.JetStream() // Create a Stream js.AddStream(&nats.StreamConfig{ Name: "ORDERS", Subjects: []string{"ORDERS.*"}, }) // Update a Stream js.UpdateStream(&nats.StreamConfig{ Name: "ORDERS", MaxBytes: 8, }) // Create a Consumer js.AddConsumer("ORDERS", &nats.ConsumerConfig{ Durable: "MONITOR", }) // Delete Consumer js.DeleteConsumer("ORDERS", "MONITOR") // Delete Stream js.DeleteStream("ORDERS") ```
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-alibabacloud_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-alibabacloud completion bash) To load completions for every new session, execute once: cilium-operator-alibabacloud completion bash > /etc/bash_completion.d/cilium-operator-alibabacloud cilium-operator-alibabacloud completion bash > $(brew --prefix)/etc/bash_completion.d/cilium-operator-alibabacloud You will need to start a new shell for this setup to take effect. ``` cilium-operator-alibabacloud completion bash ``` ``` -h, --help help for bash --no-descriptions disable completion descriptions ``` - Generate the autocompletion script for the specified shell
Project: DANM (Runtime / Cloud Native Network)
File: PULL_REQUEST_TEMPLATE.md

<!-- Thanks for sending a pull request! Here are some tips for you: If this is your first time, read our contributor guidelines https://github.com/nokia/danm/blob/master/CONTRIBUTING.md --> What type of PR is this? Uncomment only one, leave it on its own line: bug cleanup design documentation failing-test feature What does this PR give to us: Which issue(s) this PR fixes (in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged): Fixes # Special notes for your reviewer: Does this PR introduce a user-facing change?: <!-- If no, just write "NONE". If yes, a release note is required: Enter your extended release note in the block below. If the PR requires additional action from users switching to the new release, include the string "action required". --> ```release-note ```
Project: Spiderpool (Runtime / Cloud Native Network)
File: LICENSE.md

The MIT License (MIT) Copyright (c) 2013-19 by Carlos Cobo and contributors. 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: Weave Net (Runtime / Cloud Native Network)
File: finding-adding-hosts-dynamically.md

title: Adding and Removing Hosts Dynamically menu_order: 50 search_type: Documentation To add a host to an existing Weave network, launch Weave Net on the host, and supply the address of at least one host. Weave Net automatically discovers any other hosts in the network and establishes connections with them if it can (in order to avoid unnecessary multi-hop routing). In some situations existing Weave Net hosts may be unreachable from the new host due to firewalls, etc. However, it is still possible to add the new host, provided that inverse connections, for example, from existing hosts to the new hosts, are available. To accomplish this, launch Weave Net onto the new host without supplying any additional addresses and then, from one of the existing hosts run: host# weave connect $NEW_HOST Any other existing hosts on the Weave network will attempt to establish connections to the new host as well. To instruct a peer to forget a particular host specified to it via `weave launch` or `weave connect` run: host# weave forget $DECOMMISSIONED_HOST This prevents the peer from reconnecting to that host once connectivity to it is lost, and can be used to administratively remove any decommissioned peers from the network. Hosts can also be bulk-replaced. All existing hosts will be forgotten, and the new hosts added: host# weave connect --replace $NEWHOST1 $NEWHOST2 If Weave Net is restarted by Docker it automatically remembers any previous connect and forget operations, however if you stop it manually and launch it again, it will not remember any prior connects. If you want to launch again and retain the results of those operations use `--resume`: host# weave launch --resume Note: In this case, you cannot specify a list of addresses, since the previous peer list is used exclusively. For complete control over the peer topology, disable automatic discovery using the `--no-discovery` option with `weave launch`. If discovery if disabled, Weave Net only connects to the addresses specified at launch time and with `weave connect`. To return a list of all hosts and their peer connections established with `weave launch` and `weave connect` run: host# weave status targets See Also *
Project: rkt (Runtime / Container Runtime)
File: using-rkt-with-kubernetes.md

is a system for managing containerized applications across a cluster of machines. Kubernetes runs all applications in containers. In the default setup, this is performed using the Docker engine, but Kubernetes also features support for using rkt as its container runtime backend. This allows a Kubernetes cluster to leverage some of rkt's security features and native pod support. The container runtime is configured at the kubelet level. The kubelet is the agent that runs on each machine to manage containers. The kubelet provides several flags to use rkt as the container runtime: `--container-runtime=rkt` Sets the node's container runtime to rkt. `--rkt-api-endpoint=HOST:PORT` Sets the endpoint of the rkt API service. Default to `localhost:15441`. `--rkt-path=PATHTORKT_BINARY` Sets the path of the rkt binary. If empty, it will search for rkt in `$PATH`. `--rkt-stage1-image=STAGE1_NAME` Sets the name of the stage1 image, e.g. `coreos.com/rkt/stage1-coreos`. If not set, the default stage1 image (`coreos.com/rkt/stage1-coreos`) is used. Check the for information about setting up and using a rktnetes cluster. The and repos both support configuring rkt as the Kubernetes runtime out of the box. Check out the coreos-kubernetes repo if you want to spin up a cluster on or . The common configuration option here is setting `CONTAINER_RUNTIME` environment variable to rkt. For baremetal, check out the Kubernetes guides . Minikube is a tool that makes it easy to run Kubernetes locally. It launches a single-node cluster inside a VM aimed at users looking to try out Kubernetes. Follow the instructions in the Minikube section on how to get started with rktnetes. Integration of rkt as a container runtime was officially . Known issues and tips for using rkt with Kubernetes can be found in the .
Project: Velero (Runtime / Cloud Native Storage)
File: build-from-scratch.md

title: "Build from source" layout: docs Access to a Kubernetes cluster, version 1.7 or later. Version 1.7.5 or later is required to run `ark backup delete`. A DNS server on the cluster `kubectl` installed installed (minimum version 1.8) Install with go: ``` go get github.com/heptio/ark ``` The files are installed in `$GOPATH/src/github.com/heptio/ark`. You can build your Ark image locally on the machine where you run your cluster, or you can push it to a private registry. This section covers both workflows. Set the `$REGISTRY` environment variable (used in the `Makefile`) to push the Heptio Ark images to your own registry. This allows any node in your cluster to pull your locally built image. In the Ark root directory, to build your container with the tag `$REGISTRY/ark:$VERSION`, run: ``` make container ``` To push your image to a registry, use `make push`. The following files are automatically generated from the source code: The clientset Listers Shared informers Documentation Protobuf/gRPC types If you make any of the following changes, you must run `make update` to regenerate the files: Add/edit/remove command line flags and/or their help text Add/edit/remove commands or subcommands Add new API types If you make the following change, you must run to regenerate files: Add/edit/remove protobuf message or service definitions. These changes require the . By default, `make` builds an `ark` binary that runs on your host operating system and architecture. To build for another platform, run `make build-<GOOS>-<GOARCH`. For example, to build for the Mac, run `make build-darwin-amd64`. All binaries are placed in `output/bin/<GOOS>/<GOARCH>`-- for example, `output/bin/darwin/amd64/ark`. Ark's `Makefile` has a convenience target, `all-build`, that builds the following platforms: linux-amd64 linux-arm linux-arm64 darwin-amd64 windows-amd64 To run unit tests, use `make test`. You can also run `make verify` to ensure that all generated files (clientset, listers, shared informers, docs) are up to date. When running Heptio Ark, you will need to account for the following (all of which are handled in the manifests): Appropriate RBAC permissions in the cluster Read access for all data from the source cluster and namespaces Write access to the target cluster and namespaces Cloud provider credentials Read/write access to volumes Read/write access to object storage for backup data A definition for the Ark server See for more details. When your Ark deployment is up and running, you must replace the Heptio-provided Ark image with the image that you built. Run: ``` kubectl set image deployment/ark ark=$REGISTRY/ark:$VERSION ``` where `$REGISTRY` and `$VERSION` are the values that you built with. If you need to add or update the vendored dependencies, see .
Project: HwameiStor (Runtime / Cloud Native Storage)
File: 2022-05-19_helper-system-post.md

slug: 2 title: Reliable Helper System for HwameiStor Is Online authors: [JieLi, Michael] tags: [hello, Hwameistor] News today: The HwameiStor Reliable Helper System, an automatic and reliable cloud-native local storage maintenance system dedicated to system operation and maintenance, has been launched. DaoCloud officially opens source of HwameiStor Reliable Helper System, a cloud native, automatic, reliable local storage maintenance system. This system is still in the alpha stage. HwameiStor creates a local storage pool with HDD, SSD, and NVMe disks for a central management. As the underlying data base used by applications, disks often face risks such as natural and unintentional damage. In this case, the Reliable Helper System comes out for disk operation and maintenance. All developers and enthusiasts are welcome to try it out. In the cloud native era, application developers can focus on the business logic itself, while the agility, scalability, and reliability required by the application runtime attribute to the infrastructure platform and O\&M team. The HwameiStor Reliable Helper System is a reliable operation and maintenance system that meets the requirements of the cloud-native era. Currently, it supports the feature of one-click disk replacement. Reliable data migration and backfill Automatically recognize RAID disks and determine if the data migration and backfill is required to guarantee data reliability. One-click disk replacement This feature is implemented by using the disk uuid. Intuitive alert reminder If any exceptions occur in the process of one-click disk replacement, the system will raise an alert to remind you. If the coming future is an era of intelligent Internet, developers will be the pioneers to that milestone, and the open source community will become the "metaverse" of developers. If you have any questions about the HwameiStor cloud-native local storage system, welcome to join the community to explore this metaverse world dedicated for developers and grow together.