Open Stack

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 <pc at 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 <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
>>
>
> __________________________________________________________________________
> 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
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150824/154489e9/attachment.html>