cwielenb/CNCF-Dataset huggingface dataset:
Project: Antrea (Runtime / Cloud Native Network)
File: migrate-to-antrea.md

This document provides guidance on migrating from other CNIs to Antrea starting from version v1.15.0 onwards. NOTE: The following is a reference list of CNIs and versions for which we have verified the migration process. CNIs and versions that are not listed here might also work. Please create an issue if you run into problems during the migration to Antrea. During the migration process, no Kubernetes resources should be created or deleted, otherwise the migration process might fail or some unexpected problems might occur. | CNI | Version | ||| | Calico | v3.26 | | Flannel | v0.22.0 | The migration process is divided into three steps: Clean up the old CNI. Install Antrea in the cluster. Deploy Antrea migrator. The cleanup process varies across CNIs, typically you should remove the DaemonSet, Deployment, and CRDs of the old CNI from the cluster. For example, if you used `kubectl apply -f <CNI_MANIFEST>` to install the old CNI, you could then use `kubectl delete -f <CNI_MANIFEST>` to uninstall it. The second step is to install Antrea in the cluster. You can follow the to install Antrea. The following is an example of installing Antrea v1.14.1: ```bash kubectl apply -f https://github.com/antrea-io/antrea/releases/download/v1.14.1/antrea.yml ``` After Antrea is up and running, you can now deploy Antrea migrator by the following command. The migrator runs as a DaemonSet, `antrea-migrator`, in the cluster, which will restart all non hostNetwork Pods in the cluster in-place and perform necessary network resource cleanup. ```bash kubectl apply -f https://raw.githubusercontent.com/antrea-io/antrea/main/build/yamls/antrea-migrator.yml ``` The reason for restarting all Pods is that Antrea needs to take over the network management and IPAM from the old CNI. In order to avoid the Pods being rescheduled and minimize service downtime, the migrator restarts all non-hostNetwork Pods in-place by restarting their sandbox containers. Therefore, it's expected to see the `RESTARTS` count for these Pods being increased by 1 like below: ```bash $ kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES migrate-example-6d6b97f96b-29qbq 1/1 Running 1 (24s ago) 2m5s 10.10.1.3 test-worker <none> <none> migrate-example-6d6b97f96b-dqx2g 1/1 Running 1 (23s ago) 2m5s 10.10.1.6 test-worker <none> <none> migrate-example-6d6b97f96b-jpflg 1/1 Running 1 (23s ago) 2m5s 10.10.1.5 test-worker <none> <none> ``` When the `antrea-migrator` Pods on all Nodes are in `Running` state, the migration process is completed. You can then remove the `antrea-migrator` DaemonSet safely with the following command: ```bash kubectl delete -f https://raw.githubusercontent.com/antrea-io/antrea/main/build/yamls/antrea-migrator.yml ```
Project: lxd (Runtime / Container Runtime)
File: network_increase_bandwidth.md

(network-increase-bandwidth)= You can increase the network bandwidth of your Incus setup by configuring the transmit queue length (`txqueuelen`). This change makes sense in the following scenarios: You have a NIC with 1 GbE or higher on an Incus host with a lot of local activity (instance-instance connections or host-instance connections). You have an internet connection with 1 GbE or higher on your Incus host. The more instances you use, the more you can benefit from this tweak. ```{note} The following instructions use a `txqueuelen` value of 10000, which is commonly used with 10GbE NICs, and a `net.core.netdevmaxbacklog` value of 182757. Depending on your network, you might need to use different values. In general, you should use small `txqueuelen` values with slow devices with a high latency, and high `txqueuelen` values with devices with a low latency. For the `net.core.netdevmaxbacklog` value, a good guideline is to use the minimum value of the `net.ipv4.tcp_mem` configuration. ``` Complete the following steps to increase the network bandwidth on the Incus host: Increase the transmit queue length (`txqueuelen`) of both the real NIC and the Incus NIC (for example, `incusbr0`). You can do this temporarily for testing with the following command: ifconfig <interface> txqueuelen 10000 To make the change permanent, add the following command to your interface configuration in `/etc/network/interfaces`: up ip link set eth0 txqueuelen 10000 Increase the receive queue length (`net.core.netdevmaxbacklog`). You can do this temporarily for testing with the following command: echo 182757 > /proc/sys/net/core/netdevmaxbacklog To make the change permanent, add the following configuration to `/etc/sysctl.conf`: net.core.netdevmaxbacklog = 182757 You must also change the `txqueuelen` value for all Ethernet interfaces in your instances. To do this, use one of the following methods: Apply the same changes as described above for the Incus host. Set the `queue.tx.length` device option on the instance profile or configuration.
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-operator-aws_completion.md

<!-- This file was autogenerated via cilium-operator --cmdref, do not edit manually--> Generate the autocompletion script for the specified shell Generate the autocompletion script for cilium-operator-aws for the specified shell. See each sub-command's help for details on how to use the generated script. ``` -h, --help help for completion ``` - Run cilium-operator-aws - Generate the autocompletion script for bash - Generate the autocompletion script for fish - Generate the autocompletion script for powershell - Generate the autocompletion script for zsh
Project: rkt (Runtime / Container Runtime)
File: rkt-build-rkt.md

This container contains all build-time dependencies in order to build rkt. It currently can be built in: Debian Sid. All commands assume you are running them in your local git checkout of rkt. Configure the path to your git checkout of `rkt` and the build output directory respectively: ``` export SRC_DIR= export BUILDDIR= mkdir -p $BUILDDIR ``` Start the container which will run the , and compile rkt: ``` ./scripts/build-rir.sh ``` You should see rkt building in your rkt container, and once it's finished, the output should be in `$BUILD_DIR` on your host.
Project: Weave Net (Runtime / Cloud Native Network)
File: plugin-v2.md

title: Integrating Docker via the Network Plugin (V2) menu_order: 20 search_type: Documentation * Docker Engine version 1.12 introduced . This document describes how to use the Network Plugin V2 of Weave Net. Before using the plugin, please keep in mind the plugin works only in Swarm mode and requires Docker version 1.13 or later. To install the plugin run the following command on each host already participating in a Swarm cluster, i.e. on all master and worker nodes: $ docker plugin install weaveworks/net-plugin:latest_release Docker will pull the plugin from Docker Store, and it will ask to grant privileges before installing the plugin. Afterwards, it will start `weaver` process which will try to connect to Swarm masters running Weave Net. There are several configuration parameters which can be set with: $ docker plugin set weaveworks/net-plugin:latest_release PARAM=VALUE The parameters include: `WEAVE_PASSWORD` - if non empty, it will instruct Weave Net to encrypt traffic - see for more details. `WEAVE_MULTICAST` - set to 1 on each host running the plugin to enable multicast traffic on any Weave Net network. `WEAVE_MTU` - Weave Net defaults to 1376 bytes, but you can set a smaller size if your underlying network has a tighter limit, or set a larger size for better performance if your network supports jumbo frames - see for more details. `IPALLOC_RANGE` - the range of IP addresses used by Weave Net and the subnet they are placed in (CIDR format; default 10.32.0.0/12). See for more details. Before setting any parameter, the plugin has to be disabled with: $ docker plugin disable weaveworks/net-plugin:latest_release To re-enable the plugin run the following command: $ docker plugin enable weaveworks/net-plugin:latest_release After you have launched the plugin, you can create a network for Docker Swarm services by running the following command on any Docker Swarm master node: $ docker network create --driver=weaveworks/net-plugin:latest_release mynetwork Or you can create a network for any Docker container with: $ docker network create --driver=weaveworks/net-plugin:latest_release --attachable mynetwork To start a service attached to the network run, for example: $ docker service create --network=mynetwork ... Or to start a container: $ docker run --network=mynetwork ... See Also *
Project: Kata Containers (Runtime / Container Runtime)
File: RngConfig.md

Name | Type | Description | Notes | - | - | - Src | string | | [default to "/dev/urandom"] Iommu | Pointer to bool | | [optional] [default to false] `func NewRngConfig(src string, ) *RngConfig` NewRngConfig instantiates a new RngConfig object This constructor will assign default values to properties that have it defined, and makes sure properties required by API are set, but the set of arguments will change when the set of required properties is changed `func NewRngConfigWithDefaults() *RngConfig` NewRngConfigWithDefaults instantiates a new RngConfig object This constructor will only assign default values to properties that have it defined, but it doesn't guarantee that properties required by API are set `func (o *RngConfig) GetSrc() string` GetSrc returns the Src field if non-nil, zero value otherwise. `func (o RngConfig) GetSrcOk() (string, bool)` GetSrcOk returns a tuple with the Src field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *RngConfig) SetSrc(v string)` SetSrc sets Src field to given value. `func (o *RngConfig) GetIommu() bool` GetIommu returns the Iommu field if non-nil, zero value otherwise. `func (o RngConfig) GetIommuOk() (bool, bool)` GetIommuOk returns a tuple with the Iommu field if it's non-nil, zero value otherwise and a boolean to check if the value has been set. `func (o *RngConfig) SetIommu(v bool)` SetIommu sets Iommu field to given value. `func (o *RngConfig) HasIommu() bool` HasIommu returns a boolean if a field has been set.
Project: CubeFS (Runtime / Cloud Native Storage)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at oss-conduct@uber.com. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at .
Project: Cilium (Runtime / Cloud Native Network)
File: cilium-dbg_bpf.md

<!-- This file was autogenerated via cilium cmdref, do not edit manually--> Direct access to local BPF maps ``` -h, --help help for bpf ``` ``` --config string Config file (default is $HOME/.cilium.yaml) -D, --debug Enable debug messages -H, --host string URI to server-side API ``` - CLI - Manage authenticated connections between identities - BPF datapath bandwidth settings - Manage runtime config - Connection tracking tables - Manage the egress routing rules - Local endpoint map - BPF filesystem mount - Manage the IPCache mappings for IP/CIDR <-> Identity - ip-masq-agent CIDRs - Load-balancing configuration - BPF datapath traffic metrics - Manage multicast BPF programs - NAT mapping tables - Manage the node IDs - Manage policy related BPF maps - PCAP recorder - Manage compiled BPF template objects - Manage the SRv6 routing rules - Tunnel endpoint map - Manage the VTEP mappings for IP/CIDR <-> VTEP MAC/IP
Project: Velero (Runtime / Cloud Native Storage)
File: ark_delete_backup.md

title: "ark delete backup" layout: docs Delete a backup Delete a backup ``` ark delete backup NAME [flags] ``` ``` --confirm Confirm deletion -h, --help help for backup ``` ``` --alsologtostderr log to standard error as well as files --kubeconfig string Path to the kubeconfig file to use to talk to the Kubernetes apiserver. If unset, try the environment variable KUBECONFIG, as well as in-cluster configuration --kubecontext string The context to use to talk to the Kubernetes apiserver. If unset defaults to whatever your current-context is (kubectl config current-context) --logbacktraceat traceLocation when logging hits line file:N, emit a stack trace (default :0) --log_dir string If non-empty, write log files in this directory --logtostderr log to standard error instead of files -n, --namespace string The namespace in which Ark should operate (default "heptio-ark") --stderrthreshold severity logs at or above this threshold go to stderr (default 2) -v, --v Level log level for V logs --vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging ``` - Delete ark resources
Project: Firecracker (Runtime / Container Runtime)
File: logger.md

For the logging capability, Firecracker uses a single Logger object. The Logger can be configured either by sending a `PUT` API Request to the `/logger` path or by command line. You can configure the Logger only once (by using one of these options) and once configured, you can not update it. In order to configure the Logger, first you have to create the resource that will be used for logging: ```bash mkfifo logs.fifo touch logs.file ``` You can configure the Logger by sending the following API command: ```bash curl --unix-socket /tmp/firecracker.socket -i \ -X PUT "http://localhost/logger" \ -H "accept: application/json" \ -H "Content-Type: application/json" \ -d "{ "log_path": "logs.fifo", "level": "Warning", "show_level": false, "showlogorigin": false }" ``` Details about the required and optional fields can be found in the . If you want to configure the Logger on startup and without using the API socket, you can do that by passing the parameter `--log-path` to the Firecracker process: ```bash ./firecracker --api-sock /tmp/firecracker.socket --log-path <pathtotheloggingfifoorfile> ``` The other Logger fields have, in this case, the default values: `Level -> Warning`, `showlevel -> false`, `showlog_origin -> false`. For configuring these too, you can also pass the following optional parameters: `--level <log_level>`, `--show-level`, `--show-log-origin`: ```bash ./firecracker --api-sock /tmp/firecracker.socket --log-path logs.fifo --level Error --show-level --show-log-origin ``` The `logs.fifo` pipe will store the human readable logs, e.g. errors, warnings etc.(depending on the level). If the path provided is a named pipe, you can use the script below to read from it: ```shell logs=logs.fifo while true do if read line <$logs; then echo $line fi done echo "Reader exiting" ``` Otherwise, if the path points to a normal file, you can simply do: ```shell script cat logs.file ```
Project: Kata Containers (Runtime / Container Runtime)
File: vcpu.md

The vCPU manager is to manage all vCPU related actions, we will dive into some of the important structure members in this doc. For now, aarch64 vCPU support is still under development, we'll introduce it when we merge `runtime-rs` to the master branch. (issue: #4445) `VcpuConfig` is used to configure guest overall CPU info. `bootvcpucount` is used to define the initial vCPU number. `maxvcpucount` is used to define the maximum vCPU number and it's used for the upper boundary for CPU hotplug feature `threadpercore`, `coresperdie`, `diespersocket` and `socket` are used to define CPU topology. `vpmu_feature` is used to define `vPMU` feature level. If `vPMU` feature is `Disabled`, it means `vPMU` feature is off (by default). If `vPMU` feature is `LimitedlyEnabled`, it means minimal `vPMU` counters are supported (cycles and instructions). If `vPMU` feature is `FullyEnabled`, it means all `vPMU` counters are supported There are four states for vCPU state machine: `running`, `paused`, `waiting_exit`, `exited`. There is a state machine to maintain the task flow. When the vCPU is created, it'll turn to `paused` state. After vCPU resource is ready at VMM, it'll send a `Resume` event to the vCPU thread, and then vCPU state will change to `running`. During the `running` state, VMM will catch vCPU exit and execute different logic according to the exit reason. If the VMM catch some exit reasons that it cannot handle, the state will change to `waiting_exit` and VMM will stop the virtual machine. When the state switches to `waitingexit`, an exit event will be sent to vCPU `exitevt`, event manager will detect the change in `exitevt` and set VMM `exitevtflag` as 1. A thread serving for VMM event loop will check `exitevt_flag` and if the flag is 1, it'll stop the VMM. When the VMM is stopped / destroyed, the state will change to `exited`. Since `Dragonball Sandbox` doesn't support virtualization of ACPI system, we use to establish a direct communication channel between `Dragonball` and Guest in order to trigger vCPU hotplug. To use `upcall`, kernel patches are needed, you can get the patches from page, and we'll provide a ready-to-use guest kernel binary for you to try. vCPU hot plug / hot unplug range is [1, `maxvcpucount`]. Operations not in this range will be invalid.
Project: Velero (Runtime / Cloud Native Storage)
File: MAINTAINERS.md

title: "Instructions for Maintainers" layout: docs toc: "true" There are some guidelines maintainers need to follow. We list them here for quick reference, especially for new maintainers. These guidelines apply to all projects in the Velero org, including the main project, the Velero Helm chart, and all other . Please be sure to also go through the guidance under the entire section. PRs require 2 approvals before it is mergeable. The second reviewer usually merges the PR (if you notice a PR open for a while and with 2 approvals, go ahead and merge it!) As you review a PR that is not yet ready to merge, please check if the "request review" needs to be refreshed for any reviewer (this is better than @mention at them) Refrain from @mention other maintainers to review the PR unless it is an immediate need. All maintainers already get notified through the automated add to the "request review". If it is an urgent need, please add a helpful message as to why it is so people can properly prioritize work. There is no need to manually request reviewers: after the PR is created, all maintainers will be automatically added to the list (note: feel free to remove people if they are on PTO, etc). Be familiar with the policy for the project. Some tips for doing reviews: There are some we aim for We have When reviewing a design document, ensure it follows . Also, when reviewing a PR that implements a previously accepted design, ensure the associated design doc is moved to the folder. Maintainers are expected to create releases for the project. We have parts of the process automated, and full . We are working towards automating more the Velero testing, but there is still a need for manual testing as part of the release process. The manual test cases for release testing are documented . Maintainers are expected to participate in the community support rotation. We have guidelines for how we handle the . Maintainers for the Velero project are highly involved with the open source community. All the online community meetings for the project are listed in our page. The Velero project welcomes contributors of all kinds. We are also always on the look out for a high level of engagement from contributors and opportunities to bring in new maintainers. If this is of interest, take a look at how is decided.
Project: Network Service Mesh (Runtime / Cloud Native Network)
File: README.md

This folder contains the copyright templates for source files of NSM project. Below is an example of valid copyright header for `.go` files: ``` // Copyright (c) 2020 Doc.ai and/or its affiliates. // // Copyright (c) 2020 Cisco and/or its affiliates. // // SPDX-License-Identifier: Apache-2.0 // // Licensed under the Apache License, Version 2.0 (the "License"); // you may not use this file except in compliance with the License. // You may obtain a copy of the License at: // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, software // distributed under the License is distributed on an "AS IS" BASIS, // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. // See the License for the specific language governing permissions and // limitations under the License. ``` Note you can use your company name instead of `Cisco and/or its affiliates`. Also, source code files can have multi copyright holders, for example: ``` // Copyright (c) 2020 Doc.ai and/or its affiliates. // // Copyright (c) 2020 Cisco and/or its affiliates. // // Copyright (c) 2020 Red Hat Inc. and/or its affiliates. // // Copyright (c) 2020 VMware, Inc. // // SPDX-License-Identifier: Apache-2.0 // // Licensed under the Apache License, Version 2.0 (the "License"); // you may not use this file except in compliance with the License. // You may obtain a copy of the License at: // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, software // distributed under the License is distributed on an "AS IS" BASIS, // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. // See the License for the specific language governing permissions and // limitations under the License. ```