Also: http://lists.openstack.org/pipermail/openstack-operators/2015-August/007928.html http://lists.openstack.org/pipermail/openstack-operators/2015-August/007891.html
On 25 August 2015 at 09:09, Kevin Benton <blak...@gmail.com> wrote: > 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 > >
__________________________________________________________________________ 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
