← Back to team overview

nova team mailing list archive

Re: Nova's network architecture

 

I agree with Vish this is where we should look at going.

We¹ll have to version the RS side of the api for this but I think it is
definitely worth the trade off.


On 10/2/10 1:21 PM, "Vishvananda Ishaya" <vishvananda@xxxxxxxxx> wrote:

> I will make a detailed description of this and where it is going.  I have a
> couple of branches cleaning up some of this, and some ideas for how it should
> be.  Briefly, the allocate and setup were split out so we could give a quick
> response from the api including the ip without having to wait for the setup,
> but it should really be returning 'pending' and doing all of the network setup
> at once with a call to nova-network from the compute host or the scheduler.
> More after Nebula 1.0 (Monday)
> 
> Vish
> On Oct 2, 2010, at 6:56 AM, Ewan Mellor wrote:
> 
>> > Can someone please explain the intended architecture for Nova's networking
>> > code?
>> >
>> > 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
>> > network_manager.setup_compute_network).
>> >
>> > 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
>> > the VM).
>> >
>> > 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:
>> > linux_net.
>> >
>> > 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,
>> >
>> > Ewan.
>> >
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~nova
>> > Post to     : nova@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~nova
>> > More help   : https://help.launchpad.net/ListHelp
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~nova
> Post to     : nova@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~nova
> More help   : https://help.launchpad.net/ListHelp
> 



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.

Attachment: smime.p7s
Description: S/MIME cryptographic signature


References