Hi,
The creste neroffer api accepts system=true. The creation should be part of
> the plugin install, though.
Ah, sounds interesting! Does it also accept creating networkofferings for
Traffic types other than Guest? Looking at 4.2, createNetworkOffering does
a check to restrict to Guest traffic only (from ConfigurationManagerImpl):
// Only GUEST traffic type is supported in Acton
if (trafficType != TrafficType.Guest) {
throw new InvalidParameterValueException("Only traffic type " +
TrafficType.Guest
+ " is supported in the current release");
}
One question I had about the external hosted private gateways VPC feature
was whether the change involves allowing plugins to handle VPC itself
(routing between VPC subnets etc) instead of the VpcVirtualRouter? Last
time I looked at having our plugin provide VPC (a few months ago), the
VpcVirtualRouter was hardcoded in several places as the only provider.
Thanks,
Dave.
On Thu, Sep 5, 2013 at 4:08 AM, Daan Hoogland <daan.hoogl...@gmail.com>wrote:
> 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
> > >
> >
>
