Reviewed: https://review.openstack.org/457527
Committed:
https://git.openstack.org/cgit/openstack/neutron-vpnaas/commit/?id=058469e1b99b647537a5228c6a384d93df5484df
Submitter: Jenkins
Branch: master
commit 058469e1b99b647537a5228c6a384d93df5484df
Author: Hunt Xu <mhun...@gmail.com>
Date: Wed Apr 12 19:20:43 2017 +0800
VPNaaS integration with services flavor framework
* adds new attribute 'flavor_id' for vpnservice
* adds support for multiple drivers for VPNaaS
This solution uses a flavor of service type VPN associated with a flavor
profile containing a driver. During vpnservice creation, if a flavor_id
is passed, it is used to find the provider for the driver which would
handle the newly created vpnservice. The flavor_id and the
provider-vpnservice association are pesisted in the DB.
ApiImpact and DocImpact tags are added as the new optional flavor_id
parameter should be described, as well as the support of multiple VPNaaS
drivers.
The original work and discussion about integrating VPNaaS and service
type framework can be found in the following change:
I9e195dfaee21b1cf204cb9b9fc773bc9e5af5936
ApiImpact
DocImpact
Closes-Bug: #1672920
Signed-off-by: Hunt Xu <mhun...@gmail.com>
Change-Id: I0095e160481f1d4572e38ad1d3bbc8e183039b84
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1672920
Title:
[RFE] Flavor support for VPNaaS
Status in neutron:
Fix Released
Bug description:
Neutron already supports flavor framework, and currently, only l3
service is using it. In VPNaaS, we also would like to support flavor,
in order to support multiple vpn service drivers in one deployment.
One real use case from us:
We (a public cloud provider) are using openswan driver for vpnaas in
our public cloud, and recently, some customers are asking SHA2 for
more secure connection, it's time for us to do upgrade for vpnaas now
(we are still running liberty). Since openswan is not maintained
properly, we are also considering switching to stongswan smoothly
without bring much overhead to customers.
The upgrade will be a non-trivial job without flavor support. With
flavor, we could easily add strongswan as the default driver, but
still use openswan for old vpn connections. Of course, other things
need to be done to make sure operations for old resources are handled
properly by the right driver. With thad said, after upgrade, customers
could still use their old ipsec site connections which are served by
openswan, but new request will use strongswan to create vpn service.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1672920/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
