From e0b43e5c4c9ca7a86bfe6dfa3923803e5a8b9349 Mon Sep 17 00:00:00 2001
From: Orel Misan <omisan@redhat.com>
Date: Sun, 23 Jun 2024 13:44:09 +0300
Subject: [PATCH] Network binding plugin: Address compute container resource
 overhead

Signed-off-by: Orel Misan <omisan@redhat.com>
---
 .../network-binding-plugin.md                 | 63 +++++++++++++++++++
 1 file changed, 63 insertions(+)

diff --git a/design-proposals/network-binding-plugin/network-binding-plugin.md b/design-proposals/network-binding-plugin/network-binding-plugin.md
index b6b367c3..27ea54b5 100644
--- a/design-proposals/network-binding-plugin/network-binding-plugin.md
+++ b/design-proposals/network-binding-plugin/network-binding-plugin.md
@@ -270,6 +270,22 @@ The requirement to maintain certificates for the webhook could be mitigated usin
 
 For the alternative solutions please see [Appendix G](#appendix-g-alternatives-to-plugin-sidecar-container-resource-specification)
 
+##### Compute Container Resource Overhead
+
+For some plugins, an additional resource consumption can be expected from the virt-launcher pod compute container.
+For example, there could be need to execute an additional binary in the compute container.
+Since this binary has its own CPU and memory limits, they should be somehow accounted for.
+Another example could be increased resource consumption of the virt-stack resulting from using the plugin.
+
+Suggested solution:
+
+Shipping a mutating webhook as part of the plugin's deliverables.
+The webhook will add the required resource overhead for the compute container.
+
+This solution was selected since it is able to address both compute container and plugin's sidecar requirements.
+
+For the alternative solutions please see [Appendix H](#appendix-h-alternatives-to-compute-container-resource-overhead-specification)
+
 #### Configure Pod netns
 
 The CNI plugin has privileged access to the pod network namespace and
@@ -1258,3 +1274,50 @@ Pros:
 Cons:
 - Requires an API change.
 - When upgrading KubeVirt / network binding plugin versions, the sidecar container's resource specification might require adjustments.
+
+# Appendix H:  Alternatives to compute container resource overhead specification
+
+1. Manually setting the VM's resources:
+
+The user can override KubeVirt's algorithms and set resource requirements.
+
+Pros:
+- Already implemented.
+
+Cons:
+- Error prune
+- The user does not take into account the overhead considerations KubeVirt takes when templating a virt-launcher pod.
+
+2. Additional API for compute container resource overhead:
+
+The network binding plugin API in the KubeVirt CR could receive an additional input field to specify the resource requirements overhead for the compute container:
+
+```yaml
+apiVersion: kubevirt.io/v1
+kind: KubeVirt
+metadata:
+  name: kubevirt
+  namespace: kubevirt
+spec:
+  configuration:
+    network:
+      binding:
+        mynetbindingplugin:
+          sidecarImage: quay.io/kubevirt/mynetbindingplugin
+          computeContainerResourceOverhead:
+            requests:
+              cpu: 200m
+              memory: 20Mi
+```
+
+If specified, KubeVirt will add the resource overhead provided in `computeContainerResourceOverhead` to the compute container.
+The resource overhead specification will only be added once, and not per NIC using the binding.
+
+Pros:
+- Cluster-wide definition of compute resource overhead per plugin.
+- Additional resources could be requested other than CPU and Memory.
+- The resource overhead specification is visible to cluster admins.
+
+Cons:
+- Requires an API change.
+- When upgrading KubeVirt / network binding plugin versions, the compute resource overhea specification might require adjustments.