cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: Handling Public network traffic in a plugin
Date Mon, 16 Sep 2013 13:25:12 GMT
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 <dcahill@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 <daan.hoogland@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.hoogland@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" <dcahill@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" <dcahill@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
>> >> > > >
>> >> > >
>> >> >
>
>

Mime
View raw message