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 <daan.hoogl...@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 <daan.hoogl...@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" <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
> >> > > >
> >> > >
> >> >
>
