You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Dave Cahill <dc...@midokura.com> on 2013/09/03 12:02:17 UTC
Handling Public network traffic in a plugin
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_w52VD4Zgpaiw3g@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
Re: Handling Public network traffic in a plugin
Posted by Daan Hoogland <da...@gmail.com>.
Yes Dave,
And maybe more generic: plugin installation procedures would be yet
another level of api permission. They would be allowed to do even more
then admins.
Like add our system network offerings.
regards,
Daan
On Mon, Sep 16, 2013 at 3:19 PM, Dave Cahill <dc...@midokura.com> wrote:
> That looks perfectly fine.
>
> I was just saying it would be nice if it were also possible to create
> network offerings for traffic types other than Guest - it would, for
> example, provide a mechanism for network plugins to handle other traffic
> types.
>
> Thanks,
> Dave.
>
>
> On Mon, Sep 16, 2013 at 6:07 PM, Daan Hoogland <da...@gmail.com>
> wrote:
>>
>> Dave,
>>
>> As I suspected I used guest type for this offering:
>>
>> def createPrivateGatewayNetworkOffering(self, conn):
>> offers = self.listNetworkOfferings(conn,
>> name="NiciraNvpPrivateGatewayNetwork")
>> if offers != None:
>> return offers[0].id
>> # else create it
>> cno = createNetworkOffering.createNetworkOfferingCmd()
>> cno.name = "NiciraNvpPrivateGatewayNetwork"
>> cno.displaytext = "VPC private gateway network offering with Nicira
>> NVP"
>> cno.traffictype = "GUEST"
>> cno.specifyvlan = True
>> cno.specifyipranges = True
>> cno.availability = "Optional"
>> cno.conservemode = True
>> cno.guestiptype = "Isolated"
>> cno.usevpc = True
>> cno.systemonly = True
>> cno.supportedservices = [ "Connectivity" ]
>> cno.serviceproviderlist = [ { "service": "Connectivity",
>> "provider": "NiciraNVP"} ]
>> #cno.servicecapabilitylist
>> cno.tags = [ "nicira-based" ]
>> #cno.networkrate
>> #cno.serviceofferingid
>>
>> try:
>> resp = conn.marvin_request(cno)
>> except:
>> print "nicira based offering already exists"
>> #todo query and return
>>
>> Do you know if this is going to be a problem? It works for me and I
>> don't see any objections to it.
>>
>> regards,
>> Daan
>>
>> On Fri, Sep 6, 2013 at 12:30 PM, Daan Hoogland <da...@gmail.com>
>> wrote:
>> > 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" <dc...@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
>> >> <da...@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" <dc...@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.hoogland@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
>> >> > > > <dc...@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_w52VD4Zgpaiw3g@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
>> >> > > >
>> >> > >
>> >> >
>
>
Re: Handling Public network traffic in a plugin
Posted by Dave Cahill <dc...@midokura.com>.
That looks perfectly fine.
I was just saying it would be nice if it were also possible to create
network offerings for traffic types other than Guest - it would, for
example, provide a mechanism for network plugins to handle other traffic
types.
Thanks,
Dave.
On Mon, Sep 16, 2013 at 6:07 PM, Daan Hoogland <da...@gmail.com>wrote:
> Dave,
>
> As I suspected I used guest type for this offering:
>
> def createPrivateGatewayNetworkOffering(self, conn):
> offers = self.listNetworkOfferings(conn,
> name="NiciraNvpPrivateGatewayNetwork")
> if offers != None:
> return offers[0].id
> # else create it
> cno = createNetworkOffering.createNetworkOfferingCmd()
> cno.name = "NiciraNvpPrivateGatewayNetwork"
> cno.displaytext = "VPC private gateway network offering with Nicira
> NVP"
> cno.traffictype = "GUEST"
> cno.specifyvlan = True
> cno.specifyipranges = True
> cno.availability = "Optional"
> cno.conservemode = True
> cno.guestiptype = "Isolated"
> cno.usevpc = True
> cno.systemonly = True
> cno.supportedservices = [ "Connectivity" ]
> cno.serviceproviderlist = [ { "service": "Connectivity",
> "provider": "NiciraNVP"} ]
> #cno.servicecapabilitylist
> cno.tags = [ "nicira-based" ]
> #cno.networkrate
> #cno.serviceofferingid
>
> try:
> resp = conn.marvin_request(cno)
> except:
> print "nicira based offering already exists"
> #todo query and return
>
> Do you know if this is going to be a problem? It works for me and I
> don't see any objections to it.
>
> regards,
> Daan
>
> On Fri, Sep 6, 2013 at 12:30 PM, Daan Hoogland <da...@gmail.com>
> wrote:
> > 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" <dc...@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
> >> <da...@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" <dc...@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.hoogland@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 <
> dcahill@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_w52VD4Zgpaiw3g@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
> >> > > >
> >> > >
> >> >
>
Re: Handling Public network traffic in a plugin
Posted by Daan Hoogland <da...@gmail.com>.
Dave,
As I suspected I used guest type for this offering:
def createPrivateGatewayNetworkOffering(self, conn):
offers = self.listNetworkOfferings(conn,
name="NiciraNvpPrivateGatewayNetwork")
if offers != None:
return offers[0].id
# else create it
cno = createNetworkOffering.createNetworkOfferingCmd()
cno.name = "NiciraNvpPrivateGatewayNetwork"
cno.displaytext = "VPC private gateway network offering with Nicira NVP"
cno.traffictype = "GUEST"
cno.specifyvlan = True
cno.specifyipranges = True
cno.availability = "Optional"
cno.conservemode = True
cno.guestiptype = "Isolated"
cno.usevpc = True
cno.systemonly = True
cno.supportedservices = [ "Connectivity" ]
cno.serviceproviderlist = [ { "service": "Connectivity",
"provider": "NiciraNVP"} ]
#cno.servicecapabilitylist
cno.tags = [ "nicira-based" ]
#cno.networkrate
#cno.serviceofferingid
try:
resp = conn.marvin_request(cno)
except:
print "nicira based offering already exists"
#todo query and return
Do you know if this is going to be a problem? It works for me and I
don't see any objections to it.
regards,
Daan
On Fri, Sep 6, 2013 at 12:30 PM, Daan Hoogland <da...@gmail.com> wrote:
> 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" <dc...@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
>> <da...@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" <dc...@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.hoogland@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 <dc...@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_w52VD4Zgpaiw3g@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
>> > > >
>> > >
>> >
Re: Handling Public network traffic in a plugin
Posted by Daan Hoogland <da...@gmail.com>.
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" <dc...@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.hoogland@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" <dc...@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.hoogland@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 <dc...@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_w52VD4Zgpaiw3g@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
> > > >
> > >
> >
>
Re: Handling Public network traffic in a plugin
Posted by Dave Cahill <dc...@midokura.com>.
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 <da...@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" <dc...@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.hoogland@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 <dc...@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_w52VD4Zgpaiw3g@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
> > >
> >
>
Re: Handling Public network traffic in a plugin
Posted by Daan Hoogland <da...@gmail.com>.
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" <dc...@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.hoogland@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 <dc...@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_w52VD4Zgpaiw3g@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
> >
>
Re: Handling Public network traffic in a plugin
Posted by Dave Cahill <dc...@midokura.com>.
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 <da...@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 <dc...@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_w52VD4Zgpaiw3g@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
>
Re: Handling Public network traffic in a plugin
Posted by Daan Hoogland <da...@gmail.com>.
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 <dc...@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_w52VD4Zgpaiw3g@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