It sounds like you might have missed a couple responses: http://lists.openstack.org/pipermail/openstack-operators/2015-August/007903.html http://lists.openstack.org/pipermail/openstack-operators/2015-August/007910.html
On Mon, Aug 24, 2015 at 1:53 PM, Paul Michali <p...@michali.net> wrote: > Xav, > > In the email, there were no responses of anyone using VPNaaS *in a > production environment*. Summary from responders: > > Erik M - Tried in Juno with no success. Will retry. > Edgar M - said no reports from operators about VPNaaS code > Sam S - Using VPN in VMs and not VPNaaS > Kevin B - Not used. Use VMs instead > Sriram S - Indicating not used. > > If I misread the responses, or if someone has not spoken up, right now is > the time to let us know of your situation and the impact this proposal > would have on your use of VPNaaS IPSec site-to-site connections. > > The request here, is that if operators are not using this in a production > deployment where they need backward compatibility, then we'd like to avoid > having to provide the complexity needed to support backward compatibility. > > In the proposal, there are two APIs that would be changed with this > enhancement. It's detailed in reference [1], and I can elaborate, if needed. > > Please keep in mind, that users/operators using previous versions, can > upgrade to the new version, and any existing VPNaaS configuration will be > automatically migrated to the new table structures, so that existing IPSec > connections would continue to operate with the new release. > > The proposal would not support using the older APIs, once the new APIs are > available. Client apps/scripts would need to be updated to use the new API > (neutron client and the Horizon dashboard will be updated as part of the > overall effort). > > I hope that clarifies the discussion. > > Regards, > > Paul Michali (pc_m) > > > On Mon, Aug 24, 2015 at 3:50 PM Xav Paice <xavpa...@gmail.com> wrote: > >> On 25/08/15 06:32, Paul Michali wrote: >> >> As part of the effort to provide support for multiple local subnets for >> VPNaaS IPSec connections, there are three API changes planned [1]. >> >> One is to add a new "endpoint groups" API that will describe what is >> being connected. This is the place were local and peer subnets will be >> specified. It will allow future VPN flavors to reuse this API for other >> types of VPN endpoints. >> >> The second is to modify the IPSec site connection API to make use of this >> new endpoint groups API and no longer use the peer CIDRs arguments. >> >> The third is to remove the subnet ID from the VPN service API, and again, >> use the new endpoint groups API for this information (and to allow >1). >> >> A previous email send out from Kyle Mestery, asking about the production >> usage of VPNaaS, did not indicate that this service was used in production >> by operators. >> >> >> Not true. There were replies indicating that it is indeed in use, but >> perhaps not from operators of installations deemed significant enough - >> what's the criteria here? >> >> >> As a result, we'd like to propose making this change as a non-backward >> compatible change, which greatly reduces the effort. >> >> The change WILL support migration, so older databases can be migrated to >> the new schema and continue to operate, with future changes using the new >> API. This gives a smooth upgrade path to the new capability. >> >> The change would NOT support the older API in parallel with the new API, >> so users upgrading would need to also update any client scripts/tools to >> use the revised/new VPN API. >> >> >> How will this integrate with Horizon? The majority of our users don't >> use the API directly, but use Horizon for the config, does this mean we'll >> be tied in to using a particular version of Horizon to match Neutron? >> >> >> If this is acceptable to operators, we'd like to go forward with these >> plans. Please respond within 7 days of this email, if you have concerns >> about the proposal. >> >> Regards, >> >> Paul Michali (IRC pc_m) >> VPNaaS Core >> >> Ref: https://review.openstack.org/#/c/191944/ >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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 > > -- Kevin Benton
__________________________________________________________________________ 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
