Open Stack

Thanks Kevin, I think I was only seeing messages that had also replied all
to openstack-dev mailing list (I wasn't on openstack-operators, until
today).

Regards,

Paul Michali (pc_m)


On Mon, Aug 24, 2015 at 5:11 PM Kevin Benton <blak111 at 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 <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
> __________________________________________________________________________
> 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/af38d464/attachment.html>