Update patch set 1
Patch Set 1: Code-Review+1 The thing that needs to be decoupled from Nova is not actually nova-compute. Rather, it is the notion that the nova-compute *service* is equal to the hypervisor that supplies resources for guests to consume. Right now, the design of nova-compute is that the control plane agent that takes commands from the nova-conductor is one and the same with the virt driver that launches resources on the local hardware. [1] This is unfortunate, because there's really no reason that the control plane agent even needs to run on the same local hardware as the hypervisor that dishes out local resources. Basically, we should have a plan to reduce the footprint of the control plane agent and scope its work to only receiving messages from a caller, potentially storing those messages in order to survive long disruptions in control plane communication, and then forwarding those messages on to other microservices that take action. Those microservices could be related to Cinder, to Neutron, to the hypervisor driver, or anything else. Basically, a stripped-down version of kube-minion that doesn't actually take action to create instances (or volumes, or networks, etc) but rather acts as a distributed resource tracker for resources that may or may not be on the hardware upon which the control plane agent is actually running on... This would allow different groups of contributors to focus on the control plane agent and other groups to focus on the services that take some action from the control plane agent. The contributors working on the control plane agent could work on various features that have been asked about for a while, like the ability to tolerate long periods of network disconnection ala the VCPE and VECPE NFV use cases. Meanwhile, contributors working on the "action agents" (for lack of a better term) could focus on testing of those lower-level agents without needing to understand all of the complexity of the control plane agent (and its state management). These contributors could work on features that enable different types of resources to be consumed by a tenant. Anyway, just a few thoughts. I'm +1 on talking about this topic... hell, we've been discussing it for a while now in Nova-land :) -jay [1] This is the design as it currently is, even when the virt driver in the nova-compute is Ironic or vCenter. There are numerous assumptions in the nova-compute manager code that equate the control plane agent with the thing that is launching resources. Patch-set: 1 Reviewer: Gerrit User 7 <7@4a232e18-c5a9-48ee-94c0-e04e7cca6543> Label: Code-Review=+1
This commit is contained in:
Gerrit User 7
Gerrit Code Review
parent
d9dae46d35
commit
90aca72f8d