Add implementation justifications for VirtualMachineReplicaSet
Update the proposal with justifications, why a reimplementation was
chosen over wrapping around the Kubernetes ReplicaSet.
@@ -98,6 +98,47 @@ unknown VirtualMachine states and graceful deletes, it might decide to already
create new replicas in advance, to make sure that the amount of ready replicas
stays close to the expected replica count.
+### Chosen Implementation
+
+The implementation of the VirtualMachineReplicaSet is a reimplementation of the
+ReplicaSet for Pods in Kubernetes. It does not wrap around a Kubernetes
+ReplicaSet.
+
+
+There two *hard* reasons why one was chose over the other:
+
+ 1. Allow possible VirtualMachine related optimizations by implementing a
+ custom deletion order. When scaling down, it can make sense to take
+ migrating VirtualMachines into account. A possible deletion order would be:
+ not ready VMs, migrating VMs, ready VMs. This would be impossible to
+ represent by wrapping around the ReplicaSet.
+ 2. Make Live Migrations an orthogonal feature for every VirtualMachine
+ controller. If a controller does not have to care about the
+ VirtualMachine/Pod relationship, it does not have to care in any special
+ way about migrations. By wrapping around existing controllers, we will
+ always have to hide migration target Pods from the controller, until the
+ VirtualMachine was migrated, and then have to make it somehow visible
+ again. This solution leads to tricky synchronization problems which may not
+ even be completely solvable.
+
+There are several *soft* reasons why one was chosen over the other:
+
+ 1. Provide a clear VirtualMachine abstraction via our VirtualMachine
+ object. This allows domain specific modelling of controllers.
+ 2. Hide the whole relationship between VirtualMachines and Pods behind on
+ controller, so that others don't have to care about it.
+ 3. The actual business-logic of scaling the VirtualMachines is very easy to
+ understand and simple to implement. We get almost all the necessary
+ infrastructure code from k8s libraries. The infrastructure code has a
+ similar similar complexity (entity listeners, creating/deleting resources,
+ ... ) for both implementations. For different types of controllers this
+ argument may not apply (e.g. DaemonSet equivalent for VirtualMachines).
+ 4. Because of the simplicity of the business-logic, the equal complexity
+ regarding to the controller infrastructure and the fact that there exists a
+ ReplicaSet reference implementation from which we can learn/copy, it seems
+ beneficial to really express our domain and avoid design errors, by
+ implementing another complex flow around the existing ReplicaSet.
+
### Milestones
* Basic functionality
