incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: Open vSwitch tunnel Manager (aka Cloudstack SDN) - community feedback required!
Date Tue, 08 May 2012 20:18:51 GMT
> 3) We currently allow users to specify the isolation method for a physical
> network both in the GUI and the API. If the isolation method is GRE, we then
> allow users to specify vnet IDs > 4096. If you think vNets should not be used
> at all, then probably this question is pointless. But otherwise, do you think
> this is a bit confusing, as you might already think that that choice was
> implicitly made when you enabled/disabled the vSwitch controller?
> 

Salvatore,

I think this stamps from me not doing a good enough job of explaining our plugin architecture
and what's in plan for future use cases.  OVS is basically a future use case.

Summary
 NetworkGuru understands how virtual networks are mapped to physical networks.  Each implementation
must deal with three things on that network:
  - Isolation Method
  - Ip Addressing scheme
  - Traffic type carried on the network
NetworkManager is a process engine that simply drives the process of starting up a network
to the NetworkGurus and NetworkElements.

Todos:
OVS already implements a NetworkGuru, which is great.  However, what's not implemented in
CloudStack (deficiency in CloudStack NetworkManager not in the OVS code) is a way for NetworkManager
to select the NetworkGuru based on the underlying technology.  It wasn't necessary to introduce
that before because it was always VLAN and IPv4.  For OVS to get to production, I believe
we need to do the following things:

- OVS has its own way of managing the IDs.  It should avoid the usage of the vnet table. 
 It is not good to share that table to begin with.
- NetworkGuru needs a method for NetworkManager to call to determine the isolation technology,
IP addressing scheme, and traffic type that it supports. 
- Ovs NetworkGuru, of course, implements that.
- NetworkManager needs to add logic to select the correct NetworkGuru based on the above three
things.  When it is GRE, then it should select OvsNetworkGuru.
- OVS Manager should expose its own APIs to configure OVS networking so that we don't shoehorn
what OVS supports into VLAN range.
- OVS should be an entirely separate jar built with dependency on cloud-api.jar only.

Those are things CloudStack supports today and we can make those changes to make OVS production
today.

In the future, when CloudStack supports pluggable UI, then the following things can be done:

- OVS manager exposes a UI fragment such that it can have a separate UI when the network says
the underlying isolation technology is OVS.  

For now, because we don't have pluggable UI.
- OVS manager have to work it out with the UI so that if it is OVS, it no longer exposes VLAN
range as the input to configure the physical network but whatever is appropriate for OVS.

Let me know what you think.

--Alex

Mime
View raw message