Open Stack

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 <xavpaice at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150824/b8f3f6bf/attachment.html>