Hi Daan, My take on things is to add a network offering for vpc private gateways. I > extend the api > call with the optional netoffer.
I read the wiki page on that feature [1] and the most recent code review, but I don't fully understand it yet - is there any other documentation / code around? replacing the guru does not seem like the way to go to me. I'd > say that the offer is what drives what guru/element to use. That would be nicer. When we implemented Public traffic via MidoNet back in February / March, it wasn't possible to create System offerings / private offerings - if that changed, it would be great. Thanks, Dave. [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/external+hosted+private+gateways On Tue, Sep 3, 2013 at 9:25 PM, Daan Hoogland <daan.hoogl...@gmail.com>wrote: > H Dave, > > It seems we are working on similar things, David. My take on things is > to add a network offering for vpc private gateways. I extend the api > call with the optional netoffer. It sounds like you are doing > something slightly different but we are bound to break each others > code as well, even when i am working with private networks and you > with public ones. > > In general the extensibility of net-implementations does need some > work. replacing the guru does not seem like the way to go to me. I'd > say that the offer is what drives what guru/element to use. > > regards, > Daan > > On Tue, Sep 3, 2013 at 12:02 PM, Dave Cahill <dcah...@midokura.com> wrote: > > 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 >
