<div dir="ltr"><span style="font-size:13px;line-height:19px">Hi,</span><div style="font-size:13px;line-height:19px"><br></div><div style="font-size:13px;line-height:19px">I'm working on the multiple local subnet feature for VPN (RFE <a href="https://bugs.launchpad.net/neutron/+bug/1459423" target="_blank">https://bugs.launchpad.net/neutron/+bug/1459423</a>), with a developer reference document detailing the proposed process (<a href="https://review.openstack.org/#/c/191944/" target="_blank">https://review.openstack.org/#/c/191944/</a>). The plan is to do this in two steps. The first is to add new APIs and database support for "endpoint groups" (see dev ref for details). The second is to modify the IPSec/VPN APIs to make use of the new information (and no longer use some older, but equivalent info that is being extended).</div><div style="font-size:13px;line-height:19px"><br></div><div style="font-size:13px;line-height:19px">I have a few process/procedural questions for the community...</div><div style="font-size:13px;line-height:19px"><br></div><div style="font-size:13px;line-height:19px">Q1) Should I do this all as one huge commit, as two commits (one for endpoint groups and one for modification to support multiple local subnets), or multiple (chained) commits (e.g. commit for each API for the endpoint groups and for each part of the multiple subnet change)?</div><div style="font-size:13px;line-height:19px"><br></div><div style="font-size:13px;line-height:19px">My thought (now) is to do this as two commits, with the endpoint groups as one, and multiple subnet groups as a second. I started with a commit for create API of endpoint (212692), and then did a chained commit for delete/show/list (215717), thinking they could be reviewed in pieces, but they are not that large and could be easily merged.</div><div style="font-size:13px;line-height:19px"><br></div><div style="font-size:13px;line-height:19px">Q2) If the two parts are done separately, should the "endpoint group" portion, which adds a table and API calls, be done as part of the existing version (v2) of VPN, instead of introducing a new version at that step?</div><div style="font-size:13px;line-height:19px"><br></div><div style="font-size:13px;line-height:19px">Q3) For the new API additions, do I create a new subclass for the "interface" that includes all the existing APIs, introduce a new class that is used together with the existing class, or do I add this to the existing API?</div><div style="font-size:13px;line-height:19px"><br></div><div style="font-size:13px;line-height:19px">Q4) With the final multiple local subnet changes, there will be changes to the VPN service API (delete subnet_id arg) and IPSec connection API (delete peer_cidrs arg, and add local_endpoints and peer_endpoints args). Do we modify the URI so that it calls out v3 (versus v2)? Where do we do that?</div><div style="font-size:13px;line-height:19px"><br></div><div style="font-size:13px;line-height:19px">I'm unsure of the mechanism of increasing the version.</div><div style="font-size:13px;line-height:19px"><br></div><div style="font-size:13px;line-height:19px">Thanks in advance for any guidance here on how this should be rolled out...</div><div style="font-size:13px;line-height:19px"><br></div><div style="font-size:13px;line-height:19px">Regards,</div><div style="font-size:13px;line-height:19px"><br></div><div style="font-size:13px;line-height:19px">Paul Michali (pc_m)</div></div>