H Dave,
I actually didn't give 'guest' to much thought. I had to change the
vpcvirtualrouter. It calls the right guru based on the netoffer.
I feel I am not answering your question.
Are you in Amsterdam the 22th of november? A hackathon on this seems
appropriate.
mobile biligual spell checker used
Op 5 sep. 2013 03:08 schreef "Dave Cahill" <dcah...@midokura.com> het
volgende:
> 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
> > > >
> > >
> >
>
