<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 25/08/15 06:32, Paul Michali wrote:<br>
</div>
<blockquote
cite="mid:CA+ikoRM=xTJ_84bKVfKsa3pc7Cu3GTjRuga1NpuRzZXA6uJgaA@mail.gmail.com"
type="cite">
<div dir="ltr">As part of the effort to provide support for
multiple local subnets for VPNaaS IPSec connections, there are
three API changes planned [1].
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
</blockquote>
<br>
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?<br>
<br>
<blockquote
cite="mid:CA+ikoRM=xTJ_84bKVfKsa3pc7Cu3GTjRuga1NpuRzZXA6uJgaA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>As a result, we'd like to propose making this change as a
non-backward compatible change, which greatly reduces the
effort.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
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?<br>
<br>
<blockquote
cite="mid:CA+ikoRM=xTJ_84bKVfKsa3pc7Cu3GTjRuga1NpuRzZXA6uJgaA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div>Paul Michali (IRC pc_m)</div>
<div>VPNaaS Core</div>
<div><br>
</div>
<div>Ref: <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/191944/">https://review.openstack.org/#/c/191944/</a></div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>