H Dave, Sorry about the white space.
The creste neroffer api accepts system=true. The creation should be part of the plugin install, though. I will have to write more doc and any specific questions would help. mobile biligual spell checker used Op 4 sep. 2013 11:45 schreef "Dave Cahill" <dcah...@midokura.com> het volgende: > 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 > > >
