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
>> > > >
>> > >
>> >
