Here are the blueprints (mentioned by Harshad below) to add complete AWS VPC compatibility in Openstack. AWS EC2 compatibility already exists in Openstack.
https://blueprints.launchpad.net/neutron/+spec/ipam-extensions-for-neutron https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron https://blueprints.launchpad.net/nova/+spec/aws-vpc-support Services extension is relevant to NATaas (or Natasha :)), VPNaas, in AWS VPC. Regards, Rudra On Oct 10, 2013, at 6:15 AM, Harshad Nakil <hna...@contrailsystems.com<mailto:hna...@contrailsystems.com>> wrote: Agree, I like what AWS had done. Have a concept of NAT instance. 90 % use cases are solved by just specifying Inside and outside networks for the NAT instance. If one wants fancier NAT config they can always use NATaas API(s) To configure this instance. There is a blueprint for bringing Amazon VPC API compatibility to nova and related extensions to quantum already propose concept of NAT instance. How the NAT instance is implemented is left to the plugin. Regards -Harshad On Oct 10, 2013, at 1:47 AM, Salvatore Orlando <sorla...@nicira.com<mailto:sorla...@nicira.com>> wrote: Can I just ask you to not call it NATaas... if you want to pick a name for it, go for Natasha :) By the way, the idea of a NAT service plugin was first introduced at the Grizzly summit in San Diego. One hurdle, not a big one however, would be that the external gateway and floating IP features of the L3 extension already implicitly implements NAT. It will be important to find a solution to ensure NAT can be configured explicitly as well while allowing for configuring external gateway and floating IPs through the API in the same way that we do today. Apart from this, another interesting aspect would be to be see if we can come up with an approach which will result in an API which abstracts as much as possible networking aspects. In other words, I would like to avoid an API which ends up being "iptables over rest", if possible. Regards, Salvatore On 10 October 2013 09:55, Bob Melander (bmelande) <bmela...@cisco.com<mailto:bmela...@cisco.com>> wrote: Hi Edgar, I'm also interested in a broadening of NAT capability in Neutron using the evolving service framework. Thanks, Bob From: Edgar Magana <emag...@plumgrid.com<mailto:emag...@plumgrid.com>> Reply-To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: onsdag 9 oktober 2013 21:38 To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Neutron] Common requirements for services' discussion Hello all, Is anyone working on NATaaS? I know we have some developer working on Router as a Service and they probably want to include NAT functionality but I have some interest in having NAT as a Service. Please, response is somebody is interested in having some discussions about it. Thanks, Edgar From: Sumit Naiksatam <sumitnaiksa...@gmail.com<mailto:sumitnaiksa...@gmail.com>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Tuesday, October 8, 2013 8:30 PM To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [Neutron] Common requirements for services' discussion Hi All, We had a VPNaaS meeting yesterday and it was felt that we should have a separate meeting to discuss the topics common to all services. So, in preparation for the Icehouse summit, I am proposing an IRC meeting on Oct 14th 22:00 UTC (immediately after the Neutron meeting) to discuss common aspects related to the FWaaS, LBaaS, and VPNaaS. We will begin with service insertion and chaining discussion, and I hope we can collect requirements for other common aspects such as service agents, services instances, etc. as well. Etherpad for service insertion & chaining can be found here: https://etherpad.openstack.org/icehouse-neutron-service-insertion-chaining Hope you all can join. Thanks, ~Sumit. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
