Hi, A few months back I mailed the list to explain how (and why) the MidoNet plugin handles Public traffic as well as Guest traffic - see [1] for details. Essentially, we plug the System VMs into the virtual network the same way we plug in guest VMs, and the virtual network takes care of all routing between the public IPs and the VMs in the virtual network.
It's kind of cool. :) Since there is no real support for plugins handling Public traffic, our implementation just overrides the existing PublicNetworkGuru in the component XML files. This means it's easy for CloudStack devs to break the integration without realizing. For example, a recent change [2] made it such that Providers are only called if they are in the network service map for a network. This is a smart change, but since the default network offering for Public networks has no Providers defined, the MidoNet provider no longer gets called, and Public traffic doesn't work correctly. I can work around that by manually (in the db) adding MidoNet as a provider for the default System network offering whenever I deploy, but I think that might make it even easier for people to break the integration! Would it make sense to add MidoNet as a provider on the default System network offering upstream? Any other thoughts / comments also welcome. Thanks, Dave. [1] http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201303.mbox/%3ccalytfwbet9ccyzorcfvhe4odog11+wmwc6p_w52vd4zgpai...@mail.gmail.com%3E [2] https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=server/src/com/cloud/network/NetworkManagerImpl.java;h=bcb0e99be1fea28e89ff8ef51a5c15c091f1a116;hp=68b1b4f9497d1dabed0e884d7db2f1810a91b290;hb=c86e8fcae54a6af566ec87cf81b3ae228dfacbf8;hpb=1c31ee22d40d77c10593d87b8237cd0489d192cc
