Open Stack

Had a discussion today on Neutron IRC with Salvatore (thanks!) and here is
the thoughts forward going...

1) Will do two commits, one for endpoint groups, which is a new API and
stands independently, and one for multiple local subnets, which will alter
existing APIs. This should prevent any test job breakage, as the API change
is rolled out in the second commit.

2) Will email to operators, indicating that we'll institute a backward
incompatible change, given there is little, possibly none, production use
(from previous e-mail sent out). If that is OK with them, will proceed,
otherwise, we'll look at applying effort to make the change backward
compatible. It's not a trial amount of work, so avoiding it, if not needed.

3) Based on the assumption that we'll not provide backward compatibility,
given the current usage, the endpoint groups API will be added to the
existing extension, as part of v2.0. We can, at a later time, break it out
into a new extension module, if needed.

Jay, there isn't any micro-versioning yet for neutron-vpnaas repo.


Regards,

PCM

On Mon, Aug 24, 2015 at 11:49 AM Jay Pipes <jaypipes at gmail.com> wrote:

> Hi Paul, comments inline...
>
> On 08/24/2015 07:02 AM, Paul Michali wrote:
> > Hi,
> >
> > I'm working on the multiple local subnet feature for VPN (RFE
> > https://bugs.launchpad.net/neutron/+bug/1459423), with a developer
> > reference document detailing the proposed process
> > (https://review.openstack.org/#/c/191944/). 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).
> >
> > I have a few process/procedural questions for the community...
> >
> > 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)?
> >
> > 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.
>
> My advice would be 2 commits, as you have split them out.
>
> > 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?
>
> Is the Neutron VPN API microversioned? If not, then I suppose your only
> option is to modify the existing v2 API. These seem to be additive
> changes, not modifications to existing API calls, in which case they are
> backwards-compatible (just not discoverable via an API microversion).
>
> > 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?
>
> Until microversioning is introduced to the Neutron VPN API, it should
> probably be a change to the existing v2 API.
>
> > 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?
>
> Hmm, with the backwards-incompatible API changes like the above, your
> only option is to increment the major version number. The alternative
> would be to add support for microversioning as a prerequisite to the
> patch that adds backwards-incompatible changes, and then use a
> microversion to introduce those changes.
>
> Best,
> -jay
>
> > I'm unsure of the mechanism of increasing the version.
> >
> > Thanks in advance for any guidance here on how this should be rolled
> out...
> >
> > Regards,
> >
> > Paul Michali (pc_m)
> >
> >
> >
> __________________________________________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150824/f172fda0/attachment.html>