nova team mailing list archive
Mailing list archive
Nova's network architecture
Can someone please explain the intended architecture for Nova's networking
Firstly, there is a daemon called nova-network, which I assumed would be
responsible for managing networking in the entirety, but we also have
nova-api handling networking configuration directly (calling
network_manager.allocate_fixed_ip in response to a run_instance request)
and nova-compute also doing some network setup (calling
I don't understand the dividing line of responsibility for these three
(particularly why we need the API layer to allocate IP addresses, and how
it's even possible to do this before the scheduler has had a chance to place
Secondly, looking at the code in network.manager, I see a base class called
NetworkManager, with two subclasses FlatManager and VlanManager, but
NetworkManager also has a driver, of which we seem to only have one example:
I don't understand the division between these two orthogonal customization
routes. What belongs to the manager subclass, and what belongs to the driver?
Thirdly, I don't understand the configuration of the network manager. We've
got a flag called "rs_network_manager" in the Rackspace API layer. How is this
different to flag called "network_manager" elsewhere? What does it mean
if these settings are different? rs_network_manager=FlatManager,
network_manager=VlanManager is the default at the moment, and I don't
understand how that can have a sensible meaning.
The reason I'm looking at all this at the moment is there are definitely
going to be changes required to make this work with XenAPI, both for the
existing bridging mechanism that we use, and for the upcoming Open vSwitch.
I'm trying to figure out how these distinctions should be managed.
Thanks in advance,