> 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
