Service VM is a good way to go. Possibly we need to change metadata proxy in neutron for VM based L3:
https://blueprints.launchpad.net/neutron/+spec/metadata-overlapping-networks Thanks, -Ruijing From: Sridhar Ramaswamy [mailto:sric...@gmail.com] Sent: Friday, April 17, 2015 1:59 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] openwrt VM as service As mentioned earlier in this thread there are few VM based L3 implementations already in neutron - from Cisco (CSR) and Brocade (Vyatta vRouter). Both extends off neutron L3 service-plugin framework. And they both have been decomposed in the current Kilo cycle into stackforge. So all you need is another L3 service-plugin for openwrt hosted in stackforge. I don't see any framework level enhancements required to support this. However I do see some value in extracting common elements off these "service-VM" implementations - particularly related to launching the VM, plumbing the ports, etc into an utility library (oslo? tacker?). - Sridhar On Thu, Apr 16, 2015 at 2:06 PM, Sławek Kapłoński <sla...@kaplonski.pl<mailto:sla...@kaplonski.pl>> wrote: Hello, -- Pozdrawiam Sławek Kapłoński sla...@kaplonski.pl<mailto:sla...@kaplonski.pl> On Wed, Apr 15, 2015 at 11:06:49PM +0200, Salvatore Orlando wrote: > 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? I told here only my (maybe not good) idea that instead of openwrt as a service which will provide router functionalities in vm maybe better would be to provide some mechanism to make possibility to connect different vms which provide such router functionalities (something like service here). > > Salvatore > > > > On 15 April 2015 at 22:06, Sławek Kapłoński > <sla...@kaplonski.pl<mailto:sla...@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 > > sla...@kaplonski.pl<mailto:sla...@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....@intel.com<mailto:ruijing....@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 > > > dtro...@gmail.com<mailto:dtro...@gmail.com> > > > > > > > __________________________________________________________________________ > > > OpenStack Development Mailing List (not for usage questions) > > > Unsubscribe: > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
