Open Stack

Hi,

Yes. The idea is to integrate openwrt with openstack.

Possibly RouteraaS(RTasS) like LBaaS is the best way to go.

Combination of heat/puppet/chef and neutron & openwrt modification is integration content.

Neutron provides L2 functions including create/delete port/interface. All L3/VPN functions are provided by RTaaS.

So tenant can choose L3 functions from neutron or from RTaaS.

After integration, we can fix the gap between openwrt & openstack.


Thanks,
-Ruijing

From: Salvatore Orlando [mailto:sorlando at nicira.com]
Sent: Thursday, April 16, 2015 5:07 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] openwrt VM as service

I think this work falls into the "service VM" category.

openwrt unlike other service VMs used for networking services (like cloudstack's router vm) is very lightweight, and it's fairly easy to provision such VMs on the fly. It should be easy also to integrate with a ML2 control plane or even with other plugins.

It is a decent alternative to the l3 agent. Possibly to the dhcp agent as well. As I see this as an alternative to part of the "reference" control plane, I expect it to provide its own metadata proxy. The only change in neutron would be some sort of configurability in the metadata proxy launcher (assuming you do not provide DHCP as well via openwrt, in which case the problem would not exist, probably).

It's not my call about whether this should live in neutron or not. My vote is not - simply because I believe that neutron is not a control plane, and everything that is control plane or integration with it should live outside of neutron, including our agents.

On the other hand, I don't really see what the 'aaS' part of this. You're not exposing anything "as a service" specific to openwrt, are you?

Salvatore



On 15 April 2015 at 22:06, Sławek Kapłoński <slawek at kaplonski.pl<mailto:slawek at kaplonski.pl>> wrote:
Hello,

I agree. IMHO it should be maybe something like *aaS deployed on VM. I
think that Octavia is something like that for LBaaS now.
Maybe it could be something like "RouteraaS" which will provide all such
functions in VM?

--
Best regards / Pozdrawiam
Sławek Kapłoński
slawek at kaplonski.pl<mailto:slawek at kaplonski.pl>

On Wed, Apr 15, 2015 at 11:55:06AM -0500, Dean Troyer wrote:
> On Wed, Apr 15, 2015 at 2:37 AM, Guo, Ruijing <ruijing.guo at intel.com<mailto:ruijing.guo at intel.com>> wrote:
>
> >   I’d like to propose openwrt VM as service.
> >
> >
> >
> > What’s openWRT VM as service:
> >
> >
> >
> > a)            Tenant can download openWRT VM from
> > http://downloads.openwrt.org/
> >
> > b)            Tenant can create WAN interface from external public network
> >
> > c)            Tenant can create private network and create instance from
> > private network
> >
> > d)            Tenent can configure openWRT for several services including
> > DHCP, route, QoS, ACL and VPNs.
> >
>
>
> So first off, I'll be the first on in line to promote using OpenWRT for the
> basis of appliances for this sort of thing.  I use it to overcome the 'joy'
> of VirtualBox's local networking and love what it can do in 64M RAM.
>
> However, what you are describing are services, yes, but I think to focus on
> the OpenWRT part of it is missing the point.  For example, Neutron has a
> VPNaaS already, but I agree it can also be built using OpenWRT and
> OpenVPN.  I don't think it is a stand-alone service though, using a
> combination of Heat/{ansible|chef|puppet|salt}/any other
> deployment/orchestration can get you there.  I have a shell script
> somewhere for doing exactly that on AWS from way back.
>
> What I've always wanted was an image builder that would customize the
> packages pre-installed.  This would be especially useful for disposable
> ramdisk-only or JFFS images that really can't install additional packages.
> Such a front-end to the SDK/imagebuilder sounds like about half of what you
> are talking about above.
>
> Also, FWIW, a while back I packaged up a micro cloud-init replacement[0] in
> shell that turns out to be really useful.  It's based on something I
> couldn't find again to give proper attribution so if anyone knows who
> originated this I'd be grateful.
>
> dt
>
> [0] https://github.com/dtroyer/openwrt-packages/tree/master/rc.cloud
> --
>
> Dean Troyer
> dtroyer at gmail.com<mailto:dtroyer at gmail.com>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150416/97e67536/attachment.html>