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