[openstack-dev] neutron-vpnaas 13.0.0.0rc1 (rocky)

[no-reply]

Hello everyone,

A new release candidate for neutron-vpnaas for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron-vpnaas/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

http://git.openstack.org/cgit/openstack/neutron-vpnaas/log/?h=stable/rocky

Release notes for neutron-vpnaas can be found at:

http://docs.openstack.org/releasenotes/neutron-vpnaas/




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx] Stable/queens build sphinx docs broken

[Gary Kotton]

Maybe we should consider unblocking the stable versions at the moment and then 
enabling us to address in each project. 

On 4/16/18, 5:34 PM, "Jeremy Stanley"  wrote:

On 2018-04-16 10:49:17 + (+), Gary Kotton wrote:
> We have seen that a number of stable projects that the sphinx docs
> is broken. The gate job returns ‘retry limit’. An example of the
> error is
> 
http://logs.openstack.org/22/561522/1/check/build-openstack-sphinx-docs/cd99af8/job-output.txt.gz
> Does anyone have any idea how to address this?

Potential fixes seem to be adjusting the tools/tox_install.sh in
each of these projects to stop erroring when passed only a single
argument, or switch to relying on tox-siblings in those jobs so that
the neutron-horizon-hack role can be dropped from them entirely.
There is some discussion in https://review.openstack.org/561593 but
a centralized temporary workaround is somewhat risky since the
people in charge of reviewing any eventual revert will have a hard
time knowing when it's finally safe to do so.
-- 
Jeremy Stanley


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx] Stable/queens build sphinx docs broken

[Jeremy Stanley]

On 2018-04-16 10:49:17 + (+), Gary Kotton wrote:
> We have seen that a number of stable projects that the sphinx docs
> is broken. The gate job returns ‘retry limit’. An example of the
> error is
> http://logs.openstack.org/22/561522/1/check/build-openstack-sphinx-docs/cd99af8/job-output.txt.gz
> Does anyone have any idea how to address this?

Potential fixes seem to be adjusting the tools/tox_install.sh in
each of these projects to stop erroring when passed only a single
argument, or switch to relying on tox-siblings in those jobs so that
the neutron-horizon-hack role can be dropped from them entirely.
There is some discussion in https://review.openstack.org/561593 but
a centralized temporary workaround is somewhat risky since the
people in charge of reviewing any eventual revert will have a hard
time knowing when it's finally safe to do so.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx][ovn] Stable/queens build sphinx docs broken

[Gary Kotton]

Hi,
Here is an example - https://review.openstack.org/#/c/560893/
Thanks
Gary

From: Gary Kotton <gkot...@vmware.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Monday, April 16, 2018 at 2:28 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx][ovn] 
Stable/queens build sphinx docs broken

Hi,
OVN too. Things were working on the 12th of April and something has changed 
since then.
Thanks
Gary

From: Gary Kotton <gkot...@vmware.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Monday, April 16, 2018 at 1:49 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx] Stable/queens 
build sphinx docs broken

Hi,
We have seen that a number of stable projects that the sphinx docs is broken. 
The gate job returns ‘retry limit’. An example of the error is 
http://logs.openstack.org/22/561522/1/check/build-openstack-sphinx-docs/cd99af8/job-output.txt.gz
Does anyone have any idea how to address this?
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx][ovn] Stable/queens build sphinx docs broken

[Gary Kotton]

Hi,
OVN too. Things were working on the 12th of April and something has changed 
since then.
Thanks
Gary

From: Gary Kotton <gkot...@vmware.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org>
Date: Monday, April 16, 2018 at 1:49 PM
To: OpenStack List <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx] Stable/queens 
build sphinx docs broken

Hi,
We have seen that a number of stable projects that the sphinx docs is broken. 
The gate job returns ‘retry limit’. An example of the error is 
http://logs.openstack.org/22/561522/1/check/build-openstack-sphinx-docs/cd99af8/job-output.txt.gz
Does anyone have any idea how to address this?
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][vpnaas][fwaas][vmware-nsx] Stable/queens build sphinx docs broken

[Gary Kotton]

Hi,
We have seen that a number of stable projects that the sphinx docs is broken. 
The gate job returns ‘retry limit’. An example of the error is 
http://logs.openstack.org/22/561522/1/check/build-openstack-sphinx-docs/cd99af8/job-output.txt.gz
Does anyone have any idea how to address this?
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][vpnaas]

[vidyadhar reddy]

Hello,

Can we setup multiple vpnaas site to site connections on a single router?

can a single router handle two or more site to site connections using
vpnaas?

i have tried this setup using three clouds and interconnecting them via
star topology using vpnaas, the newly created vpn site connections is going
to down state.

https://bugs.launchpad.net/neutron/+bug/1318550

in the above link they mentioned that it is a design constraint with
vpnaas, though the scenario which i tested is not similar to the one
described in the link above, the basic idea is to have multiple site to
site connections on a single router,

kindly let me know if this is fixed already.

thanks in advance

BR
vidyadhar reddy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][vpnaas]

[hoan...@vn.fujitsu.com]

Hi,

Yes. I think It is possible. You need to create new endpoint groups which 
include the current subnet and a new subnet. Then just update the ipsec 
connections with corresponding endpoints.

Best regards,
Hoang

From: vidyadhar reddy [mailto:vidyadharredd...@gmail.com]
Sent: Thursday, March 22, 2018 4:06 PM
To: Cao, Xuan Hoang
Subject: Re: [openstack-dev] [Neutron][vpnaas]

Hello Hoang,
i have tried the subnet grouping seems like its working, but that method is 
fine when we have n subnets before setting up the vpnaas, but i just wanted to 
know if there is any method where we can add subnets to the existing vpnaas 
connection so that the newly entered subnets can communicate using the vpnaas 
connection which is already there.
Best Regards,
vidyadhar reddy

On Wed, Mar 21, 2018 at 3:54 AM, 
hoan...@vn.fujitsu.com<mailto:hoan...@vn.fujitsu.com> 
<hoan...@vn.fujitsu.com<mailto:hoan...@vn.fujitsu.com>> wrote:
Hi,

IIUC, your use case is to connect 4 subnets from different sites (2 subnets for 
each site). If so, did you try with endpoint group?
If not, please refer the following docs for more detail about how to try and 
get more understanding [1][2]

[1] 
https://docs.openstack.org/neutron/latest/admin/vpnaas-scenario.html#using-vpnaas-with-endpoint-group-recommended
[2] 
https://docs.openstack.org/neutron-vpnaas/latest/contributor/multiple-local-subnets.html


BRs,
Cao Xuan Hoang,

From: vidyadhar reddy 
[mailto:vidyadharredd...@gmail.com<mailto:vidyadharredd...@gmail.com>]
Sent: Tuesday, March 20, 2018 4:31 PM
To: openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [Neutron][vpnaas]

Hello,
i have a general question regarding the working of vpnaas,
can we setup multiple vpn connections on a single router? my scenario is lets 
say we have two networks net 1 and net2 in two different sites respectively, 
each network has two subnets, two sites have one router in each, with three 
interfaces one for the public network and remaining two for the two subnets, 
can we setup a two vpnaas connections on the routers in each site to enable 
communication between the two subnets in each site.
i have tried this setup, it didn't work for me. just wanted to know if it is a 
design constraint or not, i am not sure if this issue is under development, is 
there any development going on or is it already been solved?
BR,
Vidyadhar reddy peddireddy

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][vpnaas]

[hoan...@vn.fujitsu.com]

Hi,

IIUC, your use case is to connect 4 subnets from different sites (2 subnets for 
each site). If so, did you try with endpoint group?
If not, please refer the following docs for more detail about how to try and 
get more understanding [1][2]

[1] 
https://docs.openstack.org/neutron/latest/admin/vpnaas-scenario.html#using-vpnaas-with-endpoint-group-recommended
[2] 
https://docs.openstack.org/neutron-vpnaas/latest/contributor/multiple-local-subnets.html


BRs,
Cao Xuan Hoang,

From: vidyadhar reddy [mailto:vidyadharredd...@gmail.com]
Sent: Tuesday, March 20, 2018 4:31 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron][vpnaas]

Hello,
i have a general question regarding the working of vpnaas,
can we setup multiple vpn connections on a single router? my scenario is lets 
say we have two networks net 1 and net2 in two different sites respectively, 
each network has two subnets, two sites have one router in each, with three 
interfaces one for the public network and remaining two for the two subnets, 
can we setup a two vpnaas connections on the routers in each site to enable 
communication between the two subnets in each site.
i have tried this setup, it didn't work for me. just wanted to know if it is a 
design constraint or not, i am not sure if this issue is under development, is 
there any development going on or is it already been solved?

BR,
Vidyadhar reddy peddireddy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][vpnaas]

[vidyadhar reddy]

Hello,

i have a general question regarding the working of vpnaas,

can we setup multiple vpn connections on a single router? my scenario is
lets say we have two networks net 1 and net2 in two different sites
respectively, each network has two subnets, two sites have one router in
each, with three interfaces one for the public network and remaining two
for the two subnets, can we setup a two vpnaas connections on the routers
in each site to enable communication between the two subnets in each site.

i have tried this setup, it didn't work for me. just wanted to know if it
is a design constraint or not, i am not sure if this issue is under
development, is there any development going on or is it already been
solved?


BR,
Vidyadhar reddy peddireddy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][vpnaas]

[vidyadhar reddy]

Hello,

i have a general question regarding the working of vpnaas,

can we setup multiple vpn connections on a single router? my scenario is
lets say we have two networks net 1 and net2 in two different sites
respectiviely, each network has two subnets, in site one and site two we
have two routers, each router with three interfaces one for the public
network and remaining two for the two subnets, can we setup a two vpnaas
connections on the routers in each site to enable communication between the
two subnets in each site.

i have tried this setup, it didn't work for me. just wanted to know if it
is a design constraint or not, i am not sure if this issue is under
development, is there any development going on or is it already been
solved?


BR,
Vidyadhar reddy peddireddy
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] drivers removal

[hoan...@vn.fujitsu.com]

Hi,

Following the announced information by Takashi Yamamoto [1].
I have proposed a patch to remove the following drivers [2]:
- CiscoCsrIPsecDriver
- FedoraStrongSwanDriver
- VyattaIPsecDriver

Those drivers are intended to be removed in Rocky. So, please check it and 
leave comment if you still need those drivers and plan to provide maintaining 
effort to the drivers.

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-July/120264.html 
[2] https://review.openstack.org/#/c/543394/ 

Best regards,
Hoang



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] core reviewer proposal

[Takashi Yamamoto]

Hi,

On Fri, Oct 20, 2017 at 10:10 PM, Takashi Yamamoto
 wrote:
> Hi,
>
> Unless anyone objects, i'll add the following people to neutron-vpnaas
> core reviewers. [1]
>
> - Cao Xuan Hoang 
> - Akihiro Motoki 
> - Miguel Lavalle 
>
> Hoang is the most active contributor for the project these days.
>
> I don't bother to introduce Akihiro and Miguel as i guess everyone here
> knows them. :-)
>
> [1] https://review.openstack.org/#/admin/groups/502,members

As I haven't received any concerns, I updated the list accordingly.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][vpnaas] core reviewer proposal

[Takashi Yamamoto]

Hi,

Unless anyone objects, i'll add the following people to neutron-vpnaas
core reviewers. [1]

- Cao Xuan Hoang 
- Akihiro Motoki 
- Miguel Lavalle 

Hoang is the most active contributor for the project these days.

I don't bother to introduce Akihiro and Miguel as i guess everyone here
knows them. :-)

[1] https://review.openstack.org/#/admin/groups/502,members

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] pike rc

[Takashi Yamamoto]

done

http://git.openstack.org/cgit/openstack/neutron-vpnaas/tag/?h=11.0.0.0rc1
https://review.openstack.org/#/q/status:open+project:openstack/neutron-vpnaas+branch:stable/pike+topic:create-pike

On Tue, Aug 8, 2017 at 10:46 AM, Takashi Yamamoto  wrote:
> hi,
>
> can anyone with an appropriate permission create a stable/pike
> and pike rc1 for neutron-vpnaas?
>
> stable/pike
> 11.0.0.0rc1
> openstack/neutron-vpnaas
> 8278615c1f35f98447a3f9692a78ab45e90ee8c6
>
> thank you.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] neutron-vpnaas 11.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for neutron-vpnaas for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron-vpnaas/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Pike release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/pike release
branch at:

http://git.openstack.org/cgit/openstack/neutron-vpnaas/log/?h=stable/pike

Release notes for neutron-vpnaas can be found at:

http://docs.openstack.org/releasenotes/neutron-vpnaas/




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] pike rc

[Armando M.]

On 8 August 2017 at 14:21, Takashi Yamamoto  wrote:

> On Wed, Aug 9, 2017 at 12:35 AM, Armando M.  wrote:
> >
> >
> > On 8 August 2017 at 02:34, Akihiro Motoki  wrote:
> >>
> >> I proposed a project-config patch to allow us to release neutron-vpnaas.
> >> https://review.openstack.org/#/c/491670/
> >> There is a missing configuration when neutron-vpnaas was pushed out
> >> from the neutron stadium.
> >> Once the patch is merged and -release group are setup, we can release
> >> neutron-vpnaas by ourselves.
> >
> >
> > Is this strictly necessary? I don't see these in other gerrit ACLs
> > (irrespective of whether they are part of neutron or not). My
> understanding
> > is that the release can be fully managed by the openstack release team
> once
> > a patch like [1] is posted to the openstack/releases project.
> >
> > [1] https://review.openstack.org/#/c/491429/
>
> my understanding is it's necessary for hosted projects
> because they are not managed by openstack/releases.
> unlike neutron-vpnaas, networking-hyperv is an official project. [2]
>
> [2] https://github.com/openstack/governance/commit/
> c84d0a702f536a43324212f803e0a43a640c9b56
>
>
Yes, I ended up picking up a bad example, fault of my stale knowledge of
the governance repo.


> >
> >
> >>
> >>
> >> Akihiro
> >>
> >> 2017-08-08 10:46 GMT+09:00 Takashi Yamamoto :
> >> > hi,
> >> >
> >> > can anyone with an appropriate permission create a stable/pike
> >> > and pike rc1 for neutron-vpnaas?
> >> >
> >> > stable/pike
> >> > 11.0.0.0rc1
> >> > openstack/neutron-vpnaas
> >> > 8278615c1f35f98447a3f9692a78ab45e90ee8c6
> >> >
> >> > thank you.
> >> >
> >> >
> >> > 
> __
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> >> > openstack-dev-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] pike rc

[Takashi Yamamoto]

On Wed, Aug 9, 2017 at 12:35 AM, Armando M.  wrote:
>
>
> On 8 August 2017 at 02:34, Akihiro Motoki  wrote:
>>
>> I proposed a project-config patch to allow us to release neutron-vpnaas.
>> https://review.openstack.org/#/c/491670/
>> There is a missing configuration when neutron-vpnaas was pushed out
>> from the neutron stadium.
>> Once the patch is merged and -release group are setup, we can release
>> neutron-vpnaas by ourselves.
>
>
> Is this strictly necessary? I don't see these in other gerrit ACLs
> (irrespective of whether they are part of neutron or not). My understanding
> is that the release can be fully managed by the openstack release team once
> a patch like [1] is posted to the openstack/releases project.
>
> [1] https://review.openstack.org/#/c/491429/

my understanding is it's necessary for hosted projects
because they are not managed by openstack/releases.
unlike neutron-vpnaas, networking-hyperv is an official project. [2]

[2] 
https://github.com/openstack/governance/commit/c84d0a702f536a43324212f803e0a43a640c9b56

>
>
>>
>>
>> Akihiro
>>
>> 2017-08-08 10:46 GMT+09:00 Takashi Yamamoto :
>> > hi,
>> >
>> > can anyone with an appropriate permission create a stable/pike
>> > and pike rc1 for neutron-vpnaas?
>> >
>> > stable/pike
>> > 11.0.0.0rc1
>> > openstack/neutron-vpnaas
>> > 8278615c1f35f98447a3f9692a78ab45e90ee8c6
>> >
>> > thank you.
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] pike rc

[Armando M.]

On 8 August 2017 at 02:34, Akihiro Motoki  wrote:

> I proposed a project-config patch to allow us to release neutron-vpnaas.
> https://review.openstack.org/#/c/491670/
> There is a missing configuration when neutron-vpnaas was pushed out
> from the neutron stadium.
> Once the patch is merged and -release group are setup, we can release
> neutron-vpnaas by ourselves.
>

Is this strictly necessary? I don't see these in other gerrit ACLs
(irrespective of whether they are part of neutron or not). My understanding
is that the release can be fully managed by the openstack release team once
a patch like [1] is posted to the openstack/releases project.

[1] https://review.openstack.org/#/c/491429/



>
> Akihiro
>
> 2017-08-08 10:46 GMT+09:00 Takashi Yamamoto :
> > hi,
> >
> > can anyone with an appropriate permission create a stable/pike
> > and pike rc1 for neutron-vpnaas?
> >
> > stable/pike
> > 11.0.0.0rc1
> > openstack/neutron-vpnaas
> > 8278615c1f35f98447a3f9692a78ab45e90ee8c6
> >
> > thank you.
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] pike rc

[Akihiro Motoki]

I proposed a project-config patch to allow us to release neutron-vpnaas.
https://review.openstack.org/#/c/491670/
There is a missing configuration when neutron-vpnaas was pushed out
from the neutron stadium.
Once the patch is merged and -release group are setup, we can release
neutron-vpnaas by ourselves.

Akihiro

2017-08-08 10:46 GMT+09:00 Takashi Yamamoto :
> hi,
>
> can anyone with an appropriate permission create a stable/pike
> and pike rc1 for neutron-vpnaas?
>
> stable/pike
> 11.0.0.0rc1
> openstack/neutron-vpnaas
> 8278615c1f35f98447a3f9692a78ab45e90ee8c6
>
> thank you.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][vpnaas] pike rc

[Takashi Yamamoto]

hi,

can anyone with an appropriate permission create a stable/pike
and pike rc1 for neutron-vpnaas?

stable/pike
11.0.0.0rc1
openstack/neutron-vpnaas
8278615c1f35f98447a3f9692a78ab45e90ee8c6

thank you.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] driver removal

[Kevin Benton]

+1 to remove during Queens if we don't get maintainers.

On Thu, Jul 27, 2017 at 6:31 PM, Takashi Yamamoto 
wrote:

> hi,
>
> some of drivers in neutron-vpnaas don't have maintainers. [1]
> unless someone steps up, we might end up with removing those drivers.
>
> especially, VyattaIPsecDriver will likely be removed in near future,
> as it requires a special agent [2] which is difficult to maintain for
> those who are not familiar with it.
>
> [1] https://github.com/openstack/neutron-vpnaas/blob/master/
> doc/source/devref/team.rst
> [2] https://github.com/openstack/neutron-vpnaas/blob/
> 797c0466693108dd63415a065750e7a62a5f5ce8/setup.cfg#L36
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][vpnaas] driver removal

[Takashi Yamamoto]

hi,

some of drivers in neutron-vpnaas don't have maintainers. [1]
unless someone steps up, we might end up with removing those drivers.

especially, VyattaIPsecDriver will likely be removed in near future,
as it requires a special agent [2] which is difficult to maintain for
those who are not familiar with it.

[1] 
https://github.com/openstack/neutron-vpnaas/blob/master/doc/source/devref/team.rst
[2] 
https://github.com/openstack/neutron-vpnaas/blob/797c0466693108dd63415a065750e7a62a5f5ce8/setup.cfg#L36

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] [vpnaas] Contribution in order to bring VPNaaS back into the neutron governance

[hoan...@vn.fujitsu.com]

Hi everyone,

As you know that the project neutron-vpnaas is no longer part of the neutron 
governance in Ocata [1][2].
I am planning/working to address the gaps identified in [2] in order to bring 
it back into the neutron governance.
And according to the information from Kevin's email [3] (PTG summary) that 
several contributors interested in keeping it maintained and
alive.

So, I have just created an etherpad for tracking the work [4]. If anyone would 
like to contribute into it, feel free to add yours to the etherpad and lets 
sync each other.

Thanks for your attention.

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-November/107384.html
[2] 
http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.html
 
[3] http://lists.openstack.org/pipermail/openstack-dev/2017-February/113032.html
[4] https://etherpad.openstack.org/p/vpnaas-stadium-compliance 


Best regards,
Hoang



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] vpnaas driver maintainers

[Takashi Yamamoto]

hi,

i want to document who cares which drivers.
https://review.openstack.org/#/c/436081/
please comment on the review if you know an appropriate contact person
for each drivers.

btw, is the following a driver for neutron-vpnaas?  i couldn't find
documentation.
vmware_nsx/plugins/nsx_v/vshield/edge_ipsecvpn_driver.py

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

On Tue, Feb 14, 2017 at 8:15 AM, Doug Hellmann  wrote:
> Excerpts from Takashi Yamamoto's message of 2017-02-14 07:31:34 +0900:
>> hi,
>>
>> On Tue, Feb 14, 2017 at 1:54 AM, Doug Hellmann  wrote:
>> > Excerpts from Takashi Yamamoto's message of 2017-02-06 10:32:10 +0900:
>> >> On Wed, Feb 1, 2017 at 9:46 AM, Takashi Yamamoto  
>> >> wrote:
>> >> > hi,
>> >> >
>> >> > On Fri, Jan 27, 2017 at 7:46 AM, Doug Hellmann  
>> >> > wrote:
>> >> >> Excerpts from Takashi Yamamoto's message of 2017-01-26 11:42:48 +0900:
>> >> >>> hi,
>> >> >>>
>> >> >>> On Sat, Jan 14, 2017 at 2:17 AM, Doug Hellmann 
>> >> >>>  wrote:
>> >> >>> > Excerpts from Dariusz Śmigiel's message of 2017-01-13 09:11:01 
>> >> >>> > -0600:
>> >> >>> >> 2017-01-12 21:43 GMT-06:00 Takashi Yamamoto 
>> >> >>> >> :
>> >> >>> >> > hi,
>> >> >>> >> >
>> >> >>> >> > On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  
>> >> >>> >> > wrote:
>> >> >>> >> >> Hi
>> >> >>> >> >>
>> >> >>> >> >> As of today, the project neutron-vpnaas is no longer part of 
>> >> >>> >> >> the neutron
>> >> >>> >> >> governance. This was a decision reached after the project saw a 
>> >> >>> >> >> dramatic
>> >> >>> >> >> drop in active development over a prolonged period of time.
>> >> >>> >> >>
>> >> >>> >> >> What does this mean in practice?
>> >> >>> >> >>
>> >> >>> >> >> From a visibility point of view, release notes and 
>> >> >>> >> >> documentation will no
>> >> >>> >> >> longer appear on openstack.org as of Ocata going forward.
>> >> >>> >> >> No more releases will be published by the neutron release team.
>> >> >>> >> >> The neutron team will stop proposing fixes for the upstream CI, 
>> >> >>> >> >> if not
>> >> >>> >> >> solely on a voluntary basis (e.g. I still felt like proposing 
>> >> >>> >> >> [2]).
>> >> >>> >> >>
>> >> >>> >> >> How does it affect you, the user or the deployer?
>> >> >>> >> >>
>> >> >>> >> >> You can continue to use vpnaas and its CLI via the 
>> >> >>> >> >> python-neutronclient and
>> >> >>> >> >> expect it to work with neutron up until the newton
>> >> >>> >> >> release/python-neutronclient 6.0.0. After this point, if you 
>> >> >>> >> >> want a release
>> >> >>> >> >> that works for Ocata or newer, you need to proactively request 
>> >> >>> >> >> a release
>> >> >>> >> >> [5], and reach out to a member of the neutron release team [3] 
>> >> >>> >> >> for approval.
>> >> >>> >> >
>> >> >>> >> > i want to make an ocata release. (and more importantly the 
>> >> >>> >> > stable branch,
>> >> >>> >> > for the benefit of consuming subprojects)
>> >> >>> >> > for the purpose, the next step would be ocata-3, right?
>> >> >>> >>
>> >> >>> >> Hey Takashi,
>> >> >>> >> If you want to release new version of neutron-vpnaas, please look 
>> >> >>> >> at [1].
>> >> >>> >> This is the place, which you need to update and based on provided
>> >> >>> >> details, tags and branches will be cut.
>> >> >>> >>
>> >> >>> >> [1] 
>> >> >>> >> https://github.com/openstack/releases/blob/master/deliverables/ocata/neutron-vpnaas.yaml
>> >> >>> >
>> >> >>> > Unfortunately, since vpnaas is no longer part of an official 
>> >> >>> > project,
>> >> >>> > we won't be using the releases repository to manage and publish
>> >> >>> > information about the releases. It'll need to be done by hand.
>> >> >>>
>> >> >>> who can/should do it by hand?
>> >> >>
>> >> >> I can do it. Let me know the version number, and for each repository 
>> >> >> the
>> >> >> SHA of the commit on the master branch to be tagged.
>> >>
>> >> please make it with the following.  thank you!
>> >>
>> >> stable/ocata
>> >> 10.0.0
>> >> openstack/neutron-vpnaas
>> >> d6db1238a4950df03dfb28acabcf4df14ebfa3ac
>> >
>> > Sorry, I missed this email earlier.
>>
>> no problem!
>>
>> >
>> > Do you want 10.0.0 or 10.0.0.0rc1?
>>
>> 10.0.0.
>
> OK, the tag is in place and the branch is created.

thank you!

>
> Doug
>
>>
>> >
>> > Doug
>> >
>> >>
>> >> >
>> >> > thank you. i'll ask you when necessary.
>> >> >
>> >> > i think it's fine to just make a branch from master when stable branch 
>> >> > is cut
>> >> > for neutron.  how others think?
>> >> >
>> >> >>
>> >> >> Doug
>> >> >>
>> >> >>>
>> >> >>> >
>> >> >>> > Doug
>> >> >>> >
>> >> >>> >>
>> >> >>> >> BR, Dariusz
>> >> >>> >>
>> >> >>> >
>> >> >>> > __
>> >> >>> > OpenStack Development Mailing List (not for usage questions)
>> >> >>> > Unsubscribe: 
>> >> >>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> >> >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >>>
>> >> >>
>> >> >> __
>> >> >> OpenStack Development Mailing List (not for usage questions)
>> >> >> Unsubscribe: 
>> >> >> 

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Doug Hellmann]

Excerpts from Takashi Yamamoto's message of 2017-02-14 07:31:34 +0900:
> hi,
> 
> On Tue, Feb 14, 2017 at 1:54 AM, Doug Hellmann  wrote:
> > Excerpts from Takashi Yamamoto's message of 2017-02-06 10:32:10 +0900:
> >> On Wed, Feb 1, 2017 at 9:46 AM, Takashi Yamamoto  
> >> wrote:
> >> > hi,
> >> >
> >> > On Fri, Jan 27, 2017 at 7:46 AM, Doug Hellmann  
> >> > wrote:
> >> >> Excerpts from Takashi Yamamoto's message of 2017-01-26 11:42:48 +0900:
> >> >>> hi,
> >> >>>
> >> >>> On Sat, Jan 14, 2017 at 2:17 AM, Doug Hellmann  
> >> >>> wrote:
> >> >>> > Excerpts from Dariusz Śmigiel's message of 2017-01-13 09:11:01 -0600:
> >> >>> >> 2017-01-12 21:43 GMT-06:00 Takashi Yamamoto :
> >> >>> >> > hi,
> >> >>> >> >
> >> >>> >> > On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  
> >> >>> >> > wrote:
> >> >>> >> >> Hi
> >> >>> >> >>
> >> >>> >> >> As of today, the project neutron-vpnaas is no longer part of the 
> >> >>> >> >> neutron
> >> >>> >> >> governance. This was a decision reached after the project saw a 
> >> >>> >> >> dramatic
> >> >>> >> >> drop in active development over a prolonged period of time.
> >> >>> >> >>
> >> >>> >> >> What does this mean in practice?
> >> >>> >> >>
> >> >>> >> >> From a visibility point of view, release notes and documentation 
> >> >>> >> >> will no
> >> >>> >> >> longer appear on openstack.org as of Ocata going forward.
> >> >>> >> >> No more releases will be published by the neutron release team.
> >> >>> >> >> The neutron team will stop proposing fixes for the upstream CI, 
> >> >>> >> >> if not
> >> >>> >> >> solely on a voluntary basis (e.g. I still felt like proposing 
> >> >>> >> >> [2]).
> >> >>> >> >>
> >> >>> >> >> How does it affect you, the user or the deployer?
> >> >>> >> >>
> >> >>> >> >> You can continue to use vpnaas and its CLI via the 
> >> >>> >> >> python-neutronclient and
> >> >>> >> >> expect it to work with neutron up until the newton
> >> >>> >> >> release/python-neutronclient 6.0.0. After this point, if you 
> >> >>> >> >> want a release
> >> >>> >> >> that works for Ocata or newer, you need to proactively request a 
> >> >>> >> >> release
> >> >>> >> >> [5], and reach out to a member of the neutron release team [3] 
> >> >>> >> >> for approval.
> >> >>> >> >
> >> >>> >> > i want to make an ocata release. (and more importantly the stable 
> >> >>> >> > branch,
> >> >>> >> > for the benefit of consuming subprojects)
> >> >>> >> > for the purpose, the next step would be ocata-3, right?
> >> >>> >>
> >> >>> >> Hey Takashi,
> >> >>> >> If you want to release new version of neutron-vpnaas, please look 
> >> >>> >> at [1].
> >> >>> >> This is the place, which you need to update and based on provided
> >> >>> >> details, tags and branches will be cut.
> >> >>> >>
> >> >>> >> [1] 
> >> >>> >> https://github.com/openstack/releases/blob/master/deliverables/ocata/neutron-vpnaas.yaml
> >> >>> >
> >> >>> > Unfortunately, since vpnaas is no longer part of an official project,
> >> >>> > we won't be using the releases repository to manage and publish
> >> >>> > information about the releases. It'll need to be done by hand.
> >> >>>
> >> >>> who can/should do it by hand?
> >> >>
> >> >> I can do it. Let me know the version number, and for each repository the
> >> >> SHA of the commit on the master branch to be tagged.
> >>
> >> please make it with the following.  thank you!
> >>
> >> stable/ocata
> >> 10.0.0
> >> openstack/neutron-vpnaas
> >> d6db1238a4950df03dfb28acabcf4df14ebfa3ac
> >
> > Sorry, I missed this email earlier.
> 
> no problem!
> 
> >
> > Do you want 10.0.0 or 10.0.0.0rc1?
> 
> 10.0.0.

OK, the tag is in place and the branch is created.

Doug

> 
> >
> > Doug
> >
> >>
> >> >
> >> > thank you. i'll ask you when necessary.
> >> >
> >> > i think it's fine to just make a branch from master when stable branch 
> >> > is cut
> >> > for neutron.  how others think?
> >> >
> >> >>
> >> >> Doug
> >> >>
> >> >>>
> >> >>> >
> >> >>> > Doug
> >> >>> >
> >> >>> >>
> >> >>> >> BR, Dariusz
> >> >>> >>
> >> >>> >
> >> >>> > __
> >> >>> > OpenStack Development Mailing List (not for usage questions)
> >> >>> > Unsubscribe: 
> >> >>> > openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

hi,

On Tue, Feb 14, 2017 at 1:54 AM, Doug Hellmann  wrote:
> Excerpts from Takashi Yamamoto's message of 2017-02-06 10:32:10 +0900:
>> On Wed, Feb 1, 2017 at 9:46 AM, Takashi Yamamoto  
>> wrote:
>> > hi,
>> >
>> > On Fri, Jan 27, 2017 at 7:46 AM, Doug Hellmann  
>> > wrote:
>> >> Excerpts from Takashi Yamamoto's message of 2017-01-26 11:42:48 +0900:
>> >>> hi,
>> >>>
>> >>> On Sat, Jan 14, 2017 at 2:17 AM, Doug Hellmann  
>> >>> wrote:
>> >>> > Excerpts from Dariusz Śmigiel's message of 2017-01-13 09:11:01 -0600:
>> >>> >> 2017-01-12 21:43 GMT-06:00 Takashi Yamamoto :
>> >>> >> > hi,
>> >>> >> >
>> >>> >> > On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  
>> >>> >> > wrote:
>> >>> >> >> Hi
>> >>> >> >>
>> >>> >> >> As of today, the project neutron-vpnaas is no longer part of the 
>> >>> >> >> neutron
>> >>> >> >> governance. This was a decision reached after the project saw a 
>> >>> >> >> dramatic
>> >>> >> >> drop in active development over a prolonged period of time.
>> >>> >> >>
>> >>> >> >> What does this mean in practice?
>> >>> >> >>
>> >>> >> >> From a visibility point of view, release notes and documentation 
>> >>> >> >> will no
>> >>> >> >> longer appear on openstack.org as of Ocata going forward.
>> >>> >> >> No more releases will be published by the neutron release team.
>> >>> >> >> The neutron team will stop proposing fixes for the upstream CI, if 
>> >>> >> >> not
>> >>> >> >> solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >>> >> >>
>> >>> >> >> How does it affect you, the user or the deployer?
>> >>> >> >>
>> >>> >> >> You can continue to use vpnaas and its CLI via the 
>> >>> >> >> python-neutronclient and
>> >>> >> >> expect it to work with neutron up until the newton
>> >>> >> >> release/python-neutronclient 6.0.0. After this point, if you want 
>> >>> >> >> a release
>> >>> >> >> that works for Ocata or newer, you need to proactively request a 
>> >>> >> >> release
>> >>> >> >> [5], and reach out to a member of the neutron release team [3] for 
>> >>> >> >> approval.
>> >>> >> >
>> >>> >> > i want to make an ocata release. (and more importantly the stable 
>> >>> >> > branch,
>> >>> >> > for the benefit of consuming subprojects)
>> >>> >> > for the purpose, the next step would be ocata-3, right?
>> >>> >>
>> >>> >> Hey Takashi,
>> >>> >> If you want to release new version of neutron-vpnaas, please look at 
>> >>> >> [1].
>> >>> >> This is the place, which you need to update and based on provided
>> >>> >> details, tags and branches will be cut.
>> >>> >>
>> >>> >> [1] 
>> >>> >> https://github.com/openstack/releases/blob/master/deliverables/ocata/neutron-vpnaas.yaml
>> >>> >
>> >>> > Unfortunately, since vpnaas is no longer part of an official project,
>> >>> > we won't be using the releases repository to manage and publish
>> >>> > information about the releases. It'll need to be done by hand.
>> >>>
>> >>> who can/should do it by hand?
>> >>
>> >> I can do it. Let me know the version number, and for each repository the
>> >> SHA of the commit on the master branch to be tagged.
>>
>> please make it with the following.  thank you!
>>
>> stable/ocata
>> 10.0.0
>> openstack/neutron-vpnaas
>> d6db1238a4950df03dfb28acabcf4df14ebfa3ac
>
> Sorry, I missed this email earlier.

no problem!

>
> Do you want 10.0.0 or 10.0.0.0rc1?

10.0.0.

>
> Doug
>
>>
>> >
>> > thank you. i'll ask you when necessary.
>> >
>> > i think it's fine to just make a branch from master when stable branch is 
>> > cut
>> > for neutron.  how others think?
>> >
>> >>
>> >> Doug
>> >>
>> >>>
>> >>> >
>> >>> > Doug
>> >>> >
>> >>> >>
>> >>> >> BR, Dariusz
>> >>> >>
>> >>> >
>> >>> > __
>> >>> > OpenStack Development Mailing List (not for usage questions)
>> >>> > Unsubscribe: 
>> >>> > openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Doug Hellmann]

Excerpts from Takashi Yamamoto's message of 2017-02-06 10:32:10 +0900:
> On Wed, Feb 1, 2017 at 9:46 AM, Takashi Yamamoto  
> wrote:
> > hi,
> >
> > On Fri, Jan 27, 2017 at 7:46 AM, Doug Hellmann  
> > wrote:
> >> Excerpts from Takashi Yamamoto's message of 2017-01-26 11:42:48 +0900:
> >>> hi,
> >>>
> >>> On Sat, Jan 14, 2017 at 2:17 AM, Doug Hellmann  
> >>> wrote:
> >>> > Excerpts from Dariusz Śmigiel's message of 2017-01-13 09:11:01 -0600:
> >>> >> 2017-01-12 21:43 GMT-06:00 Takashi Yamamoto :
> >>> >> > hi,
> >>> >> >
> >>> >> > On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  
> >>> >> > wrote:
> >>> >> >> Hi
> >>> >> >>
> >>> >> >> As of today, the project neutron-vpnaas is no longer part of the 
> >>> >> >> neutron
> >>> >> >> governance. This was a decision reached after the project saw a 
> >>> >> >> dramatic
> >>> >> >> drop in active development over a prolonged period of time.
> >>> >> >>
> >>> >> >> What does this mean in practice?
> >>> >> >>
> >>> >> >> From a visibility point of view, release notes and documentation 
> >>> >> >> will no
> >>> >> >> longer appear on openstack.org as of Ocata going forward.
> >>> >> >> No more releases will be published by the neutron release team.
> >>> >> >> The neutron team will stop proposing fixes for the upstream CI, if 
> >>> >> >> not
> >>> >> >> solely on a voluntary basis (e.g. I still felt like proposing [2]).
> >>> >> >>
> >>> >> >> How does it affect you, the user or the deployer?
> >>> >> >>
> >>> >> >> You can continue to use vpnaas and its CLI via the 
> >>> >> >> python-neutronclient and
> >>> >> >> expect it to work with neutron up until the newton
> >>> >> >> release/python-neutronclient 6.0.0. After this point, if you want a 
> >>> >> >> release
> >>> >> >> that works for Ocata or newer, you need to proactively request a 
> >>> >> >> release
> >>> >> >> [5], and reach out to a member of the neutron release team [3] for 
> >>> >> >> approval.
> >>> >> >
> >>> >> > i want to make an ocata release. (and more importantly the stable 
> >>> >> > branch,
> >>> >> > for the benefit of consuming subprojects)
> >>> >> > for the purpose, the next step would be ocata-3, right?
> >>> >>
> >>> >> Hey Takashi,
> >>> >> If you want to release new version of neutron-vpnaas, please look at 
> >>> >> [1].
> >>> >> This is the place, which you need to update and based on provided
> >>> >> details, tags and branches will be cut.
> >>> >>
> >>> >> [1] 
> >>> >> https://github.com/openstack/releases/blob/master/deliverables/ocata/neutron-vpnaas.yaml
> >>> >
> >>> > Unfortunately, since vpnaas is no longer part of an official project,
> >>> > we won't be using the releases repository to manage and publish
> >>> > information about the releases. It'll need to be done by hand.
> >>>
> >>> who can/should do it by hand?
> >>
> >> I can do it. Let me know the version number, and for each repository the
> >> SHA of the commit on the master branch to be tagged.
> 
> please make it with the following.  thank you!
> 
> stable/ocata
> 10.0.0
> openstack/neutron-vpnaas
> d6db1238a4950df03dfb28acabcf4df14ebfa3ac

Sorry, I missed this email earlier.

Do you want 10.0.0 or 10.0.0.0rc1?

Doug

> 
> >
> > thank you. i'll ask you when necessary.
> >
> > i think it's fine to just make a branch from master when stable branch is 
> > cut
> > for neutron.  how others think?
> >
> >>
> >> Doug
> >>
> >>>
> >>> >
> >>> > Doug
> >>> >
> >>> >>
> >>> >> BR, Dariusz
> >>> >>
> >>> >
> >>> > __
> >>> > OpenStack Development Mailing List (not for usage questions)
> >>> > Unsubscribe: 
> >>> > openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

On Wed, Feb 1, 2017 at 9:51 AM, Takashi Yamamoto  wrote:
> hi,
>
>>> That's great to hear Yamamoto. Since you are already a neutron-core I assume
>>> you are already intimate with the work required to strengthen the VPNaaS
>>> project. I have added you to [4] and you can lean on me for any changes that
>>> needs reviewing.
>
> i wrote a scenario test.
> https://review.openstack.org/#/c/424459/
> while it's working well with midonet, it seems failing with strongswan driver.
> is there any possibly related known issues with strongswan?

https://bugs.launchpad.net/neutron/+bug/1660899

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

On Wed, Feb 1, 2017 at 9:46 AM, Takashi Yamamoto  wrote:
> hi,
>
> On Fri, Jan 27, 2017 at 7:46 AM, Doug Hellmann  wrote:
>> Excerpts from Takashi Yamamoto's message of 2017-01-26 11:42:48 +0900:
>>> hi,
>>>
>>> On Sat, Jan 14, 2017 at 2:17 AM, Doug Hellmann  
>>> wrote:
>>> > Excerpts from Dariusz Śmigiel's message of 2017-01-13 09:11:01 -0600:
>>> >> 2017-01-12 21:43 GMT-06:00 Takashi Yamamoto :
>>> >> > hi,
>>> >> >
>>> >> > On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
>>> >> >> Hi
>>> >> >>
>>> >> >> As of today, the project neutron-vpnaas is no longer part of the 
>>> >> >> neutron
>>> >> >> governance. This was a decision reached after the project saw a 
>>> >> >> dramatic
>>> >> >> drop in active development over a prolonged period of time.
>>> >> >>
>>> >> >> What does this mean in practice?
>>> >> >>
>>> >> >> From a visibility point of view, release notes and documentation will 
>>> >> >> no
>>> >> >> longer appear on openstack.org as of Ocata going forward.
>>> >> >> No more releases will be published by the neutron release team.
>>> >> >> The neutron team will stop proposing fixes for the upstream CI, if not
>>> >> >> solely on a voluntary basis (e.g. I still felt like proposing [2]).
>>> >> >>
>>> >> >> How does it affect you, the user or the deployer?
>>> >> >>
>>> >> >> You can continue to use vpnaas and its CLI via the 
>>> >> >> python-neutronclient and
>>> >> >> expect it to work with neutron up until the newton
>>> >> >> release/python-neutronclient 6.0.0. After this point, if you want a 
>>> >> >> release
>>> >> >> that works for Ocata or newer, you need to proactively request a 
>>> >> >> release
>>> >> >> [5], and reach out to a member of the neutron release team [3] for 
>>> >> >> approval.
>>> >> >
>>> >> > i want to make an ocata release. (and more importantly the stable 
>>> >> > branch,
>>> >> > for the benefit of consuming subprojects)
>>> >> > for the purpose, the next step would be ocata-3, right?
>>> >>
>>> >> Hey Takashi,
>>> >> If you want to release new version of neutron-vpnaas, please look at [1].
>>> >> This is the place, which you need to update and based on provided
>>> >> details, tags and branches will be cut.
>>> >>
>>> >> [1] 
>>> >> https://github.com/openstack/releases/blob/master/deliverables/ocata/neutron-vpnaas.yaml
>>> >
>>> > Unfortunately, since vpnaas is no longer part of an official project,
>>> > we won't be using the releases repository to manage and publish
>>> > information about the releases. It'll need to be done by hand.
>>>
>>> who can/should do it by hand?
>>
>> I can do it. Let me know the version number, and for each repository the
>> SHA of the commit on the master branch to be tagged.

please make it with the following.  thank you!

stable/ocata
10.0.0
openstack/neutron-vpnaas
d6db1238a4950df03dfb28acabcf4df14ebfa3ac

>
> thank you. i'll ask you when necessary.
>
> i think it's fine to just make a branch from master when stable branch is cut
> for neutron.  how others think?
>
>>
>> Doug
>>
>>>
>>> >
>>> > Doug
>>> >
>>> >>
>>> >> BR, Dariusz
>>> >>
>>> >
>>> > __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

hi,

>> That's great to hear Yamamoto. Since you are already a neutron-core I assume
>> you are already intimate with the work required to strengthen the VPNaaS
>> project. I have added you to [4] and you can lean on me for any changes that
>> needs reviewing.

i wrote a scenario test.
https://review.openstack.org/#/c/424459/
while it's working well with midonet, it seems failing with strongswan driver.
is there any possibly related known issues with strongswan?

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

hi,

On Fri, Jan 27, 2017 at 7:46 AM, Doug Hellmann  wrote:
> Excerpts from Takashi Yamamoto's message of 2017-01-26 11:42:48 +0900:
>> hi,
>>
>> On Sat, Jan 14, 2017 at 2:17 AM, Doug Hellmann  wrote:
>> > Excerpts from Dariusz Śmigiel's message of 2017-01-13 09:11:01 -0600:
>> >> 2017-01-12 21:43 GMT-06:00 Takashi Yamamoto :
>> >> > hi,
>> >> >
>> >> > On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
>> >> >> Hi
>> >> >>
>> >> >> As of today, the project neutron-vpnaas is no longer part of the 
>> >> >> neutron
>> >> >> governance. This was a decision reached after the project saw a 
>> >> >> dramatic
>> >> >> drop in active development over a prolonged period of time.
>> >> >>
>> >> >> What does this mean in practice?
>> >> >>
>> >> >> From a visibility point of view, release notes and documentation will 
>> >> >> no
>> >> >> longer appear on openstack.org as of Ocata going forward.
>> >> >> No more releases will be published by the neutron release team.
>> >> >> The neutron team will stop proposing fixes for the upstream CI, if not
>> >> >> solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >> >>
>> >> >> How does it affect you, the user or the deployer?
>> >> >>
>> >> >> You can continue to use vpnaas and its CLI via the 
>> >> >> python-neutronclient and
>> >> >> expect it to work with neutron up until the newton
>> >> >> release/python-neutronclient 6.0.0. After this point, if you want a 
>> >> >> release
>> >> >> that works for Ocata or newer, you need to proactively request a 
>> >> >> release
>> >> >> [5], and reach out to a member of the neutron release team [3] for 
>> >> >> approval.
>> >> >
>> >> > i want to make an ocata release. (and more importantly the stable 
>> >> > branch,
>> >> > for the benefit of consuming subprojects)
>> >> > for the purpose, the next step would be ocata-3, right?
>> >>
>> >> Hey Takashi,
>> >> If you want to release new version of neutron-vpnaas, please look at [1].
>> >> This is the place, which you need to update and based on provided
>> >> details, tags and branches will be cut.
>> >>
>> >> [1] 
>> >> https://github.com/openstack/releases/blob/master/deliverables/ocata/neutron-vpnaas.yaml
>> >
>> > Unfortunately, since vpnaas is no longer part of an official project,
>> > we won't be using the releases repository to manage and publish
>> > information about the releases. It'll need to be done by hand.
>>
>> who can/should do it by hand?
>
> I can do it. Let me know the version number, and for each repository the
> SHA of the commit on the master branch to be tagged.

thank you. i'll ask you when necessary.

i think it's fine to just make a branch from master when stable branch is cut
for neutron.  how others think?

>
> Doug
>
>>
>> >
>> > Doug
>> >
>> >>
>> >> BR, Dariusz
>> >>
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Doug Hellmann]

Excerpts from Takashi Yamamoto's message of 2017-01-26 11:42:48 +0900:
> hi,
> 
> On Sat, Jan 14, 2017 at 2:17 AM, Doug Hellmann  wrote:
> > Excerpts from Dariusz Śmigiel's message of 2017-01-13 09:11:01 -0600:
> >> 2017-01-12 21:43 GMT-06:00 Takashi Yamamoto :
> >> > hi,
> >> >
> >> > On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
> >> >> Hi
> >> >>
> >> >> As of today, the project neutron-vpnaas is no longer part of the neutron
> >> >> governance. This was a decision reached after the project saw a dramatic
> >> >> drop in active development over a prolonged period of time.
> >> >>
> >> >> What does this mean in practice?
> >> >>
> >> >> From a visibility point of view, release notes and documentation will no
> >> >> longer appear on openstack.org as of Ocata going forward.
> >> >> No more releases will be published by the neutron release team.
> >> >> The neutron team will stop proposing fixes for the upstream CI, if not
> >> >> solely on a voluntary basis (e.g. I still felt like proposing [2]).
> >> >>
> >> >> How does it affect you, the user or the deployer?
> >> >>
> >> >> You can continue to use vpnaas and its CLI via the python-neutronclient 
> >> >> and
> >> >> expect it to work with neutron up until the newton
> >> >> release/python-neutronclient 6.0.0. After this point, if you want a 
> >> >> release
> >> >> that works for Ocata or newer, you need to proactively request a release
> >> >> [5], and reach out to a member of the neutron release team [3] for 
> >> >> approval.
> >> >
> >> > i want to make an ocata release. (and more importantly the stable branch,
> >> > for the benefit of consuming subprojects)
> >> > for the purpose, the next step would be ocata-3, right?
> >>
> >> Hey Takashi,
> >> If you want to release new version of neutron-vpnaas, please look at [1].
> >> This is the place, which you need to update and based on provided
> >> details, tags and branches will be cut.
> >>
> >> [1] 
> >> https://github.com/openstack/releases/blob/master/deliverables/ocata/neutron-vpnaas.yaml
> >
> > Unfortunately, since vpnaas is no longer part of an official project,
> > we won't be using the releases repository to manage and publish
> > information about the releases. It'll need to be done by hand.
> 
> who can/should do it by hand?

I can do it. Let me know the version number, and for each repository the
SHA of the commit on the master branch to be tagged.

Doug

> 
> >
> > Doug
> >
> >>
> >> BR, Dariusz
> >>
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

hi,

On Sat, Jan 14, 2017 at 2:17 AM, Doug Hellmann  wrote:
> Excerpts from Dariusz Śmigiel's message of 2017-01-13 09:11:01 -0600:
>> 2017-01-12 21:43 GMT-06:00 Takashi Yamamoto :
>> > hi,
>> >
>> > On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
>> >> Hi
>> >>
>> >> As of today, the project neutron-vpnaas is no longer part of the neutron
>> >> governance. This was a decision reached after the project saw a dramatic
>> >> drop in active development over a prolonged period of time.
>> >>
>> >> What does this mean in practice?
>> >>
>> >> From a visibility point of view, release notes and documentation will no
>> >> longer appear on openstack.org as of Ocata going forward.
>> >> No more releases will be published by the neutron release team.
>> >> The neutron team will stop proposing fixes for the upstream CI, if not
>> >> solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >>
>> >> How does it affect you, the user or the deployer?
>> >>
>> >> You can continue to use vpnaas and its CLI via the python-neutronclient 
>> >> and
>> >> expect it to work with neutron up until the newton
>> >> release/python-neutronclient 6.0.0. After this point, if you want a 
>> >> release
>> >> that works for Ocata or newer, you need to proactively request a release
>> >> [5], and reach out to a member of the neutron release team [3] for 
>> >> approval.
>> >
>> > i want to make an ocata release. (and more importantly the stable branch,
>> > for the benefit of consuming subprojects)
>> > for the purpose, the next step would be ocata-3, right?
>>
>> Hey Takashi,
>> If you want to release new version of neutron-vpnaas, please look at [1].
>> This is the place, which you need to update and based on provided
>> details, tags and branches will be cut.
>>
>> [1] 
>> https://github.com/openstack/releases/blob/master/deliverables/ocata/neutron-vpnaas.yaml
>
> Unfortunately, since vpnaas is no longer part of an official project,
> we won't be using the releases repository to manage and publish
> information about the releases. It'll need to be done by hand.

who can/should do it by hand?

>
> Doug
>
>>
>> BR, Dariusz
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Dariusz Śmigiel]

2017-01-13 11:17 GMT-06:00 Doug Hellmann :
> Excerpts from Dariusz Śmigiel's message of 2017-01-13 09:11:01 -0600:
>> 2017-01-12 21:43 GMT-06:00 Takashi Yamamoto :
>> > hi,
>> >
>> > On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
>> >> Hi
>> >>
>> >> As of today, the project neutron-vpnaas is no longer part of the neutron
>> >> governance. This was a decision reached after the project saw a dramatic
>> >> drop in active development over a prolonged period of time.
>> >>
>> >> What does this mean in practice?
>> >>
>> >> From a visibility point of view, release notes and documentation will no
>> >> longer appear on openstack.org as of Ocata going forward.
>> >> No more releases will be published by the neutron release team.
>> >> The neutron team will stop proposing fixes for the upstream CI, if not
>> >> solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >>
>> >> How does it affect you, the user or the deployer?
>> >>
>> >> You can continue to use vpnaas and its CLI via the python-neutronclient 
>> >> and
>> >> expect it to work with neutron up until the newton
>> >> release/python-neutronclient 6.0.0. After this point, if you want a 
>> >> release
>> >> that works for Ocata or newer, you need to proactively request a release
>> >> [5], and reach out to a member of the neutron release team [3] for 
>> >> approval.
>> >
>> > i want to make an ocata release. (and more importantly the stable branch,
>> > for the benefit of consuming subprojects)
>> > for the purpose, the next step would be ocata-3, right?
>>
>> Hey Takashi,
>> If you want to release new version of neutron-vpnaas, please look at [1].
>> This is the place, which you need to update and based on provided
>> details, tags and branches will be cut.
>>
>> [1] 
>> https://github.com/openstack/releases/blob/master/deliverables/ocata/neutron-vpnaas.yaml
>
> Unfortunately, since vpnaas is no longer part of an official project,
> we won't be using the releases repository to manage and publish
> information about the releases. It'll need to be done by hand.
>
> Doug
>
Thanks Doug for clarification,

Dariusz

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Doug Hellmann]

Excerpts from Dariusz Śmigiel's message of 2017-01-13 09:11:01 -0600:
> 2017-01-12 21:43 GMT-06:00 Takashi Yamamoto :
> > hi,
> >
> > On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
> >> Hi
> >>
> >> As of today, the project neutron-vpnaas is no longer part of the neutron
> >> governance. This was a decision reached after the project saw a dramatic
> >> drop in active development over a prolonged period of time.
> >>
> >> What does this mean in practice?
> >>
> >> From a visibility point of view, release notes and documentation will no
> >> longer appear on openstack.org as of Ocata going forward.
> >> No more releases will be published by the neutron release team.
> >> The neutron team will stop proposing fixes for the upstream CI, if not
> >> solely on a voluntary basis (e.g. I still felt like proposing [2]).
> >>
> >> How does it affect you, the user or the deployer?
> >>
> >> You can continue to use vpnaas and its CLI via the python-neutronclient and
> >> expect it to work with neutron up until the newton
> >> release/python-neutronclient 6.0.0. After this point, if you want a release
> >> that works for Ocata or newer, you need to proactively request a release
> >> [5], and reach out to a member of the neutron release team [3] for 
> >> approval.
> >
> > i want to make an ocata release. (and more importantly the stable branch,
> > for the benefit of consuming subprojects)
> > for the purpose, the next step would be ocata-3, right?
> 
> Hey Takashi,
> If you want to release new version of neutron-vpnaas, please look at [1].
> This is the place, which you need to update and based on provided
> details, tags and branches will be cut.
> 
> [1] 
> https://github.com/openstack/releases/blob/master/deliverables/ocata/neutron-vpnaas.yaml

Unfortunately, since vpnaas is no longer part of an official project,
we won't be using the releases repository to manage and publish
information about the releases. It'll need to be done by hand.

Doug

> 
> BR, Dariusz
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Dariusz Śmigiel]

2017-01-12 21:43 GMT-06:00 Takashi Yamamoto :
> hi,
>
> On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
>> Hi
>>
>> As of today, the project neutron-vpnaas is no longer part of the neutron
>> governance. This was a decision reached after the project saw a dramatic
>> drop in active development over a prolonged period of time.
>>
>> What does this mean in practice?
>>
>> From a visibility point of view, release notes and documentation will no
>> longer appear on openstack.org as of Ocata going forward.
>> No more releases will be published by the neutron release team.
>> The neutron team will stop proposing fixes for the upstream CI, if not
>> solely on a voluntary basis (e.g. I still felt like proposing [2]).
>>
>> How does it affect you, the user or the deployer?
>>
>> You can continue to use vpnaas and its CLI via the python-neutronclient and
>> expect it to work with neutron up until the newton
>> release/python-neutronclient 6.0.0. After this point, if you want a release
>> that works for Ocata or newer, you need to proactively request a release
>> [5], and reach out to a member of the neutron release team [3] for approval.
>
> i want to make an ocata release. (and more importantly the stable branch,
> for the benefit of consuming subprojects)
> for the purpose, the next step would be ocata-3, right?

Hey Takashi,
If you want to release new version of neutron-vpnaas, please look at [1].
This is the place, which you need to update and based on provided
details, tags and branches will be cut.

[1] 
https://github.com/openstack/releases/blob/master/deliverables/ocata/neutron-vpnaas.yaml

BR, Dariusz

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

hi,

On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
> Hi
>
> As of today, the project neutron-vpnaas is no longer part of the neutron
> governance. This was a decision reached after the project saw a dramatic
> drop in active development over a prolonged period of time.
>
> What does this mean in practice?
>
> From a visibility point of view, release notes and documentation will no
> longer appear on openstack.org as of Ocata going forward.
> No more releases will be published by the neutron release team.
> The neutron team will stop proposing fixes for the upstream CI, if not
> solely on a voluntary basis (e.g. I still felt like proposing [2]).
>
> How does it affect you, the user or the deployer?
>
> You can continue to use vpnaas and its CLI via the python-neutronclient and
> expect it to work with neutron up until the newton
> release/python-neutronclient 6.0.0. After this point, if you want a release
> that works for Ocata or newer, you need to proactively request a release
> [5], and reach out to a member of the neutron release team [3] for approval.

i want to make an ocata release. (and more importantly the stable branch,
for the benefit of consuming subprojects)
for the purpose, the next step would be ocata-3, right?

> Assuming that the vpnaas CI is green, you can expect to have a working
> vpnaas system upon release of its package in the foreseeable future.
> Outstanding bugs and new bug reports will be rejected on the basis of lack
> of engineering resources interested in helping out in the typical OpenStack
> review workflow.
> Since we are freezing the development of the neutron CLI in favor of the
> openstack unified client (OSC), the lack of a plan to make the VPN commands
> available in the OSC CLI means that at some point in the future the neutron
> client CLI support for vpnaas may be dropped (though I don't expect this to
> happen any time soon).
>
> Can this be reversed?
>
> If you are interested in reversing this decision, now it is time to step up.
> That said, we won't be reversing the decision for Ocata. There is quite a
> curve to ramp up to make neutron-vpnaas worthy of being classified as a
> neutron stadium project, and that means addressing all the gaps identified
> in [6]. If you are interested, please reach out, and I will work with you to
> add your account to [4], so that you can drive the neutron-vpnaas agenda
> going forward.
>
> Please do not hesitate to reach out to ask questions and/or clarifications.
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/392010/
> [2] https://review.openstack.org/#/c/397924/
> [3] https://review.openstack.org/#/admin/groups/150,members
> [4] https://review.openstack.org/#/admin/groups/502,members
> [5] https://github.com/openstack/releases
> [6]
> http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

On Thu, Dec 1, 2016 at 1:02 AM, Armando M.  wrote:
>
>
> On 27 November 2016 at 20:50, Takashi Yamamoto 
> wrote:
>>
>> On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
>> > Hi
>> >
>> > As of today, the project neutron-vpnaas is no longer part of the neutron
>> > governance. This was a decision reached after the project saw a dramatic
>> > drop in active development over a prolonged period of time.
>> >
>> > What does this mean in practice?
>> >
>> > From a visibility point of view, release notes and documentation will no
>> > longer appear on openstack.org as of Ocata going forward.
>> > No more releases will be published by the neutron release team.
>> > The neutron team will stop proposing fixes for the upstream CI, if not
>> > solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >
>> > How does it affect you, the user or the deployer?
>> >
>> > You can continue to use vpnaas and its CLI via the python-neutronclient
>> > and
>> > expect it to work with neutron up until the newton
>> > release/python-neutronclient 6.0.0. After this point, if you want a
>> > release
>> > that works for Ocata or newer, you need to proactively request a release
>> > [5], and reach out to a member of the neutron release team [3] for
>> > approval.
>> > Assuming that the vpnaas CI is green, you can expect to have a working
>> > vpnaas system upon release of its package in the foreseeable future.
>> > Outstanding bugs and new bug reports will be rejected on the basis of
>> > lack
>> > of engineering resources interested in helping out in the typical
>> > OpenStack
>> > review workflow.
>> > Since we are freezing the development of the neutron CLI in favor of the
>> > openstack unified client (OSC), the lack of a plan to make the VPN
>> > commands
>> > available in the OSC CLI means that at some point in the future the
>> > neutron
>> > client CLI support for vpnaas may be dropped (though I don't expect this
>> > to
>> > happen any time soon).
>> >
>> > Can this be reversed?
>> >
>> > If you are interested in reversing this decision, now it is time to step
>> > up.
>> > That said, we won't be reversing the decision for Ocata. There is quite
>> > a
>> > curve to ramp up to make neutron-vpnaas worthy of being classified as a
>> > neutron stadium project, and that means addressing all the gaps
>> > identified
>> > in [6]. If you are interested, please reach out, and I will work with
>> > you to
>> > add your account to [4], so that you can drive the neutron-vpnaas agenda
>> > going forward.
>> >
>> > Please do not hesitate to reach out to ask questions and/or
>> > clarifications.
>>
>> hi,
>>
>> i'm interested in working on the project.
>> well, at least on the parts which is used by networking-midonet.
>
>
> That's great to hear Yamamoto. Since you are already a neutron-core I assume
> you are already intimate with the work required to strengthen the VPNaaS
> project. I have added you to [4] and you can lean on me for any changes that
> needs reviewing.

these fixes for gate jobs need review:
https://review.openstack.org/#/c/410511/
https://review.openstack.org/#/c/410530/
https://review.openstack.org/#/c/419396/

>
>>
>>
>> >
>> > Cheers,
>> > Armando
>> >
>> > [1] https://review.openstack.org/#/c/392010/
>> > [2] https://review.openstack.org/#/c/397924/
>> > [3] https://review.openstack.org/#/admin/groups/150,members
>> > [4] https://review.openstack.org/#/admin/groups/502,members
>> > [5] https://github.com/openstack/releases
>> > [6]
>> >
>> > http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.html
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Lingxian Kong]

On Wed, Dec 14, 2016 at 4:34 PM, Takashi Yamamoto 
wrote:

> hi,
>
> which driver are you using?
>

neutron.services.vpn.device_drivers.ipsec.OpenSwanDriver
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

hi,

On Sat, Dec 3, 2016 at 4:07 PM, Lingxian Kong  wrote:
> Hi, Takashi,
>
> Thanks for working on this project, we (Catalyst Cloud) also provide VPNaaS
> in our OpenStack based public cloud, so maybe we can also provide help from
> our side.

which driver are you using?

>
>
> Cheers,
> Lingxian Kong (Larry)
>
> On Mon, Nov 28, 2016 at 5:50 PM, Takashi Yamamoto 
> wrote:
>>
>> On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
>> > Hi
>> >
>> > As of today, the project neutron-vpnaas is no longer part of the neutron
>> > governance. This was a decision reached after the project saw a dramatic
>> > drop in active development over a prolonged period of time.
>> >
>> > What does this mean in practice?
>> >
>> > From a visibility point of view, release notes and documentation will no
>> > longer appear on openstack.org as of Ocata going forward.
>> > No more releases will be published by the neutron release team.
>> > The neutron team will stop proposing fixes for the upstream CI, if not
>> > solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >
>> > How does it affect you, the user or the deployer?
>> >
>> > You can continue to use vpnaas and its CLI via the python-neutronclient
>> > and
>> > expect it to work with neutron up until the newton
>> > release/python-neutronclient 6.0.0. After this point, if you want a
>> > release
>> > that works for Ocata or newer, you need to proactively request a release
>> > [5], and reach out to a member of the neutron release team [3] for
>> > approval.
>> > Assuming that the vpnaas CI is green, you can expect to have a working
>> > vpnaas system upon release of its package in the foreseeable future.
>> > Outstanding bugs and new bug reports will be rejected on the basis of
>> > lack
>> > of engineering resources interested in helping out in the typical
>> > OpenStack
>> > review workflow.
>> > Since we are freezing the development of the neutron CLI in favor of the
>> > openstack unified client (OSC), the lack of a plan to make the VPN
>> > commands
>> > available in the OSC CLI means that at some point in the future the
>> > neutron
>> > client CLI support for vpnaas may be dropped (though I don't expect this
>> > to
>> > happen any time soon).
>> >
>> > Can this be reversed?
>> >
>> > If you are interested in reversing this decision, now it is time to step
>> > up.
>> > That said, we won't be reversing the decision for Ocata. There is quite
>> > a
>> > curve to ramp up to make neutron-vpnaas worthy of being classified as a
>> > neutron stadium project, and that means addressing all the gaps
>> > identified
>> > in [6]. If you are interested, please reach out, and I will work with
>> > you to
>> > add your account to [4], so that you can drive the neutron-vpnaas agenda
>> > going forward.
>> >
>> > Please do not hesitate to reach out to ask questions and/or
>> > clarifications.
>>
>> hi,
>>
>> i'm interested in working on the project.
>> well, at least on the parts which is used by networking-midonet.
>>
>> >
>> > Cheers,
>> > Armando
>> >
>> > [1] https://review.openstack.org/#/c/392010/
>> > [2] https://review.openstack.org/#/c/397924/
>> > [3] https://review.openstack.org/#/admin/groups/150,members
>> > [4] https://review.openstack.org/#/admin/groups/502,members
>> > [5] https://github.com/openstack/releases
>> > [6]
>> >
>> > http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.html
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

hi,

On Sat, Dec 3, 2016 at 4:07 PM, Lingxian Kong  wrote:
> Hi, Takashi,
>
> Thanks for working on this project, we (Catalyst Cloud) also provide VPNaaS
> in our OpenStack based public cloud, so maybe we can also provide help from
> our side.

thank you!
it's great to hear the project has more demands.

>
>
> Cheers,
> Lingxian Kong (Larry)
>
> On Mon, Nov 28, 2016 at 5:50 PM, Takashi Yamamoto 
> wrote:
>>
>> On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
>> > Hi
>> >
>> > As of today, the project neutron-vpnaas is no longer part of the neutron
>> > governance. This was a decision reached after the project saw a dramatic
>> > drop in active development over a prolonged period of time.
>> >
>> > What does this mean in practice?
>> >
>> > From a visibility point of view, release notes and documentation will no
>> > longer appear on openstack.org as of Ocata going forward.
>> > No more releases will be published by the neutron release team.
>> > The neutron team will stop proposing fixes for the upstream CI, if not
>> > solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >
>> > How does it affect you, the user or the deployer?
>> >
>> > You can continue to use vpnaas and its CLI via the python-neutronclient
>> > and
>> > expect it to work with neutron up until the newton
>> > release/python-neutronclient 6.0.0. After this point, if you want a
>> > release
>> > that works for Ocata or newer, you need to proactively request a release
>> > [5], and reach out to a member of the neutron release team [3] for
>> > approval.
>> > Assuming that the vpnaas CI is green, you can expect to have a working
>> > vpnaas system upon release of its package in the foreseeable future.
>> > Outstanding bugs and new bug reports will be rejected on the basis of
>> > lack
>> > of engineering resources interested in helping out in the typical
>> > OpenStack
>> > review workflow.
>> > Since we are freezing the development of the neutron CLI in favor of the
>> > openstack unified client (OSC), the lack of a plan to make the VPN
>> > commands
>> > available in the OSC CLI means that at some point in the future the
>> > neutron
>> > client CLI support for vpnaas may be dropped (though I don't expect this
>> > to
>> > happen any time soon).
>> >
>> > Can this be reversed?
>> >
>> > If you are interested in reversing this decision, now it is time to step
>> > up.
>> > That said, we won't be reversing the decision for Ocata. There is quite
>> > a
>> > curve to ramp up to make neutron-vpnaas worthy of being classified as a
>> > neutron stadium project, and that means addressing all the gaps
>> > identified
>> > in [6]. If you are interested, please reach out, and I will work with
>> > you to
>> > add your account to [4], so that you can drive the neutron-vpnaas agenda
>> > going forward.
>> >
>> > Please do not hesitate to reach out to ask questions and/or
>> > clarifications.
>>
>> hi,
>>
>> i'm interested in working on the project.
>> well, at least on the parts which is used by networking-midonet.
>>
>> >
>> > Cheers,
>> > Armando
>> >
>> > [1] https://review.openstack.org/#/c/392010/
>> > [2] https://review.openstack.org/#/c/397924/
>> > [3] https://review.openstack.org/#/admin/groups/150,members
>> > [4] https://review.openstack.org/#/admin/groups/502,members
>> > [5] https://github.com/openstack/releases
>> > [6]
>> >
>> > http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.html
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Lingxian Kong]

Hi, Takashi,

Thanks for working on this project, we (Catalyst Cloud) also provide VPNaaS
in our OpenStack based public cloud, so maybe we can also provide help from
our side.


Cheers,
Lingxian Kong (Larry)

On Mon, Nov 28, 2016 at 5:50 PM, Takashi Yamamoto 
wrote:

> On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
> > Hi
> >
> > As of today, the project neutron-vpnaas is no longer part of the neutron
> > governance. This was a decision reached after the project saw a dramatic
> > drop in active development over a prolonged period of time.
> >
> > What does this mean in practice?
> >
> > From a visibility point of view, release notes and documentation will no
> > longer appear on openstack.org as of Ocata going forward.
> > No more releases will be published by the neutron release team.
> > The neutron team will stop proposing fixes for the upstream CI, if not
> > solely on a voluntary basis (e.g. I still felt like proposing [2]).
> >
> > How does it affect you, the user or the deployer?
> >
> > You can continue to use vpnaas and its CLI via the python-neutronclient
> and
> > expect it to work with neutron up until the newton
> > release/python-neutronclient 6.0.0. After this point, if you want a
> release
> > that works for Ocata or newer, you need to proactively request a release
> > [5], and reach out to a member of the neutron release team [3] for
> approval.
> > Assuming that the vpnaas CI is green, you can expect to have a working
> > vpnaas system upon release of its package in the foreseeable future.
> > Outstanding bugs and new bug reports will be rejected on the basis of
> lack
> > of engineering resources interested in helping out in the typical
> OpenStack
> > review workflow.
> > Since we are freezing the development of the neutron CLI in favor of the
> > openstack unified client (OSC), the lack of a plan to make the VPN
> commands
> > available in the OSC CLI means that at some point in the future the
> neutron
> > client CLI support for vpnaas may be dropped (though I don't expect this
> to
> > happen any time soon).
> >
> > Can this be reversed?
> >
> > If you are interested in reversing this decision, now it is time to step
> up.
> > That said, we won't be reversing the decision for Ocata. There is quite a
> > curve to ramp up to make neutron-vpnaas worthy of being classified as a
> > neutron stadium project, and that means addressing all the gaps
> identified
> > in [6]. If you are interested, please reach out, and I will work with
> you to
> > add your account to [4], so that you can drive the neutron-vpnaas agenda
> > going forward.
> >
> > Please do not hesitate to reach out to ask questions and/or
> clarifications.
>
> hi,
>
> i'm interested in working on the project.
> well, at least on the parts which is used by networking-midonet.
>
> >
> > Cheers,
> > Armando
> >
> > [1] https://review.openstack.org/#/c/392010/
> > [2] https://review.openstack.org/#/c/397924/
> > [3] https://review.openstack.org/#/admin/groups/150,members
> > [4] https://review.openstack.org/#/admin/groups/502,members
> > [5] https://github.com/openstack/releases
> > [6]
> > http://specs.openstack.org/openstack/neutron-specs/specs/
> stadium/ocata/neutron-vpnaas.html
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

On Thu, Dec 1, 2016 at 1:02 AM, Armando M.  wrote:
>
>
> On 27 November 2016 at 20:50, Takashi Yamamoto 
> wrote:
>>
>> On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
>> > Hi
>> >
>> > As of today, the project neutron-vpnaas is no longer part of the neutron
>> > governance. This was a decision reached after the project saw a dramatic
>> > drop in active development over a prolonged period of time.
>> >
>> > What does this mean in practice?
>> >
>> > From a visibility point of view, release notes and documentation will no
>> > longer appear on openstack.org as of Ocata going forward.
>> > No more releases will be published by the neutron release team.
>> > The neutron team will stop proposing fixes for the upstream CI, if not
>> > solely on a voluntary basis (e.g. I still felt like proposing [2]).
>> >
>> > How does it affect you, the user or the deployer?
>> >
>> > You can continue to use vpnaas and its CLI via the python-neutronclient
>> > and
>> > expect it to work with neutron up until the newton
>> > release/python-neutronclient 6.0.0. After this point, if you want a
>> > release
>> > that works for Ocata or newer, you need to proactively request a release
>> > [5], and reach out to a member of the neutron release team [3] for
>> > approval.
>> > Assuming that the vpnaas CI is green, you can expect to have a working
>> > vpnaas system upon release of its package in the foreseeable future.
>> > Outstanding bugs and new bug reports will be rejected on the basis of
>> > lack
>> > of engineering resources interested in helping out in the typical
>> > OpenStack
>> > review workflow.
>> > Since we are freezing the development of the neutron CLI in favor of the
>> > openstack unified client (OSC), the lack of a plan to make the VPN
>> > commands
>> > available in the OSC CLI means that at some point in the future the
>> > neutron
>> > client CLI support for vpnaas may be dropped (though I don't expect this
>> > to
>> > happen any time soon).
>> >
>> > Can this be reversed?
>> >
>> > If you are interested in reversing this decision, now it is time to step
>> > up.
>> > That said, we won't be reversing the decision for Ocata. There is quite
>> > a
>> > curve to ramp up to make neutron-vpnaas worthy of being classified as a
>> > neutron stadium project, and that means addressing all the gaps
>> > identified
>> > in [6]. If you are interested, please reach out, and I will work with
>> > you to
>> > add your account to [4], so that you can drive the neutron-vpnaas agenda
>> > going forward.
>> >
>> > Please do not hesitate to reach out to ask questions and/or
>> > clarifications.
>>
>> hi,
>>
>> i'm interested in working on the project.
>> well, at least on the parts which is used by networking-midonet.
>
>
> That's great to hear Yamamoto. Since you are already a neutron-core I assume
> you are already intimate with the work required to strengthen the VPNaaS
> project. I have added you to [4] and you can lean on me for any changes that
> needs reviewing.

thank you.

>
>>
>>
>> >
>> > Cheers,
>> > Armando
>> >
>> > [1] https://review.openstack.org/#/c/392010/
>> > [2] https://review.openstack.org/#/c/397924/
>> > [3] https://review.openstack.org/#/admin/groups/150,members
>> > [4] https://review.openstack.org/#/admin/groups/502,members
>> > [5] https://github.com/openstack/releases
>> > [6]
>> >
>> > http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.html
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Armando M.]

On 27 November 2016 at 20:50, Takashi Yamamoto 
wrote:

> On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
> > Hi
> >
> > As of today, the project neutron-vpnaas is no longer part of the neutron
> > governance. This was a decision reached after the project saw a dramatic
> > drop in active development over a prolonged period of time.
> >
> > What does this mean in practice?
> >
> > From a visibility point of view, release notes and documentation will no
> > longer appear on openstack.org as of Ocata going forward.
> > No more releases will be published by the neutron release team.
> > The neutron team will stop proposing fixes for the upstream CI, if not
> > solely on a voluntary basis (e.g. I still felt like proposing [2]).
> >
> > How does it affect you, the user or the deployer?
> >
> > You can continue to use vpnaas and its CLI via the python-neutronclient
> and
> > expect it to work with neutron up until the newton
> > release/python-neutronclient 6.0.0. After this point, if you want a
> release
> > that works for Ocata or newer, you need to proactively request a release
> > [5], and reach out to a member of the neutron release team [3] for
> approval.
> > Assuming that the vpnaas CI is green, you can expect to have a working
> > vpnaas system upon release of its package in the foreseeable future.
> > Outstanding bugs and new bug reports will be rejected on the basis of
> lack
> > of engineering resources interested in helping out in the typical
> OpenStack
> > review workflow.
> > Since we are freezing the development of the neutron CLI in favor of the
> > openstack unified client (OSC), the lack of a plan to make the VPN
> commands
> > available in the OSC CLI means that at some point in the future the
> neutron
> > client CLI support for vpnaas may be dropped (though I don't expect this
> to
> > happen any time soon).
> >
> > Can this be reversed?
> >
> > If you are interested in reversing this decision, now it is time to step
> up.
> > That said, we won't be reversing the decision for Ocata. There is quite a
> > curve to ramp up to make neutron-vpnaas worthy of being classified as a
> > neutron stadium project, and that means addressing all the gaps
> identified
> > in [6]. If you are interested, please reach out, and I will work with
> you to
> > add your account to [4], so that you can drive the neutron-vpnaas agenda
> > going forward.
> >
> > Please do not hesitate to reach out to ask questions and/or
> clarifications.
>
> hi,
>
> i'm interested in working on the project.
> well, at least on the parts which is used by networking-midonet.
>

That's great to hear Yamamoto. Since you are already a neutron-core I
assume you are already intimate with the work required to strengthen the
VPNaaS project. I have added you to [4] and you can lean on me for any
changes that needs reviewing.


>
> >
> > Cheers,
> > Armando
> >
> > [1] https://review.openstack.org/#/c/392010/
> > [2] https://review.openstack.org/#/c/397924/
> > [3] https://review.openstack.org/#/admin/groups/150,members
> > [4] https://review.openstack.org/#/admin/groups/502,members
> > [5] https://github.com/openstack/releases
> > [6]
> > http://specs.openstack.org/openstack/neutron-specs/specs/
> stadium/ocata/neutron-vpnaas.html
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Takashi Yamamoto]

On Wed, Nov 16, 2016 at 11:02 AM, Armando M.  wrote:
> Hi
>
> As of today, the project neutron-vpnaas is no longer part of the neutron
> governance. This was a decision reached after the project saw a dramatic
> drop in active development over a prolonged period of time.
>
> What does this mean in practice?
>
> From a visibility point of view, release notes and documentation will no
> longer appear on openstack.org as of Ocata going forward.
> No more releases will be published by the neutron release team.
> The neutron team will stop proposing fixes for the upstream CI, if not
> solely on a voluntary basis (e.g. I still felt like proposing [2]).
>
> How does it affect you, the user or the deployer?
>
> You can continue to use vpnaas and its CLI via the python-neutronclient and
> expect it to work with neutron up until the newton
> release/python-neutronclient 6.0.0. After this point, if you want a release
> that works for Ocata or newer, you need to proactively request a release
> [5], and reach out to a member of the neutron release team [3] for approval.
> Assuming that the vpnaas CI is green, you can expect to have a working
> vpnaas system upon release of its package in the foreseeable future.
> Outstanding bugs and new bug reports will be rejected on the basis of lack
> of engineering resources interested in helping out in the typical OpenStack
> review workflow.
> Since we are freezing the development of the neutron CLI in favor of the
> openstack unified client (OSC), the lack of a plan to make the VPN commands
> available in the OSC CLI means that at some point in the future the neutron
> client CLI support for vpnaas may be dropped (though I don't expect this to
> happen any time soon).
>
> Can this be reversed?
>
> If you are interested in reversing this decision, now it is time to step up.
> That said, we won't be reversing the decision for Ocata. There is quite a
> curve to ramp up to make neutron-vpnaas worthy of being classified as a
> neutron stadium project, and that means addressing all the gaps identified
> in [6]. If you are interested, please reach out, and I will work with you to
> add your account to [4], so that you can drive the neutron-vpnaas agenda
> going forward.
>
> Please do not hesitate to reach out to ask questions and/or clarifications.

hi,

i'm interested in working on the project.
well, at least on the parts which is used by networking-midonet.

>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/392010/
> [2] https://review.openstack.org/#/c/397924/
> [3] https://review.openstack.org/#/admin/groups/150,members
> [4] https://review.openstack.org/#/admin/groups/502,members
> [5] https://github.com/openstack/releases
> [6]
> http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

[Armando M.]

Hi

As of today, the project neutron-vpnaas is no longer part of the neutron
governance. This was a decision reached after the project saw a dramatic
drop in active development over a prolonged period of time.

What does this mean in practice?

   - From a visibility point of view, release notes and documentation will
   no longer appear on openstack.org as of Ocata going forward.
   - No more releases will be published by the neutron release team.
   - The neutron team will stop proposing fixes for the upstream CI, if not
   solely on a voluntary basis (e.g. I still felt like proposing [2]).

How does it affect you, the user or the deployer?

   - You can continue to use vpnaas and its CLI via the
   python-neutronclient and expect it to work with neutron up until the newton
   release/python-neutronclient 6.0.0. After this point, if you want a release
   that works for Ocata or newer, you need to proactively request a release
   [5], and reach out to a member of the neutron release team [3] for
   approval. Assuming that the vpnaas CI is green, you can expect to have a
   working vpnaas system upon release of its package in the foreseeable future.
   - Outstanding bugs and new bug reports will be rejected on the basis of
   lack of engineering resources interested in helping out in the typical
   OpenStack review workflow.
   - Since we are freezing the development of the neutron CLI in favor of
   the openstack unified client (OSC), the lack of a plan to make the VPN
   commands available in the OSC CLI means that at some point in the future
   the neutron client CLI support for vpnaas may be dropped (though I don't
   expect this to happen any time soon).

Can this be reversed?

   - If you are interested in reversing this decision, now it is time to
   step up. That said, we won't be reversing the decision for Ocata. There is
   quite a curve to ramp up to make neutron-vpnaas worthy of being classified
   as a neutron stadium project, and that means addressing all the gaps
   identified in [6]. If you are interested, please reach out, and I will work
   with you to add your account to [4], so that you can drive the
   neutron-vpnaas agenda going forward.

Please do not hesitate to reach out to ask questions and/or clarifications.

Cheers,
Armando

[1] https://review.openstack.org/#/c/392010/
[2] https://review.openstack.org/#/c/397924/
[3] https://review.openstack.org/#/admin/groups/150,members
[4] https://review.openstack.org/#/admin/groups/502,members
[5] https://github.com/openstack/releases
[6]
http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][VPNaaS]IPSec Pluto is not running

[dongcan ye]

Hi, all

I want to install vpnaas in mitaka, but failed to create ipsec-connection.

OS version: Centos 7
Libreswan version: 3.10.0-327.18.2.el7.x86_64


In /etc/neutron/vpn_agent.ini, vpn_device_driver is
neutron_vpnaas.services.vpn.device_drivers.libreswan_ipsec.LibreSwanDriver.

Before running neutron-vpn-agent, I had checked ipsec status, it seems
normal:
# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path [OK]
Linux Libreswan 3.15 (netkey) on 3.10.0-327.18.2.el7.x86_64
Checking for IPsec support in kernel [OK]
 SAref kernel support   [N/A]
 NETKEY:  Testing XFRM related proc values   [OK]
[OK]
[OK]
Hardware RNG detected, testing if used properly [OK]
Checking that pluto is running   [OK]
 Pluto listening for IKE on udp 500 [OK]
 Pluto listening for NAT-T on udp 4500   [OK]
Two or more interfaces found, checking IP forwarding [FAILED]
Checking NAT and MASQUERADEing   [OK]
Checking for 'ip' command   [OK]
Checking /bin/sh is not /bin/dash   [OK]
Checking for 'iptables' command [OK]
Opportunistic Encryption Support [DISABLED]


After create ikepolicy, ipsecpolicy and vpn service, create a
ipsec-site-connection failed,
status code in vpn-agent.log returns 1 :
# ip netns exec qrouter-5758220e-5c35-429a-975f-39375db70efe ipsec whack
--ctlbase
/var/lib/neutron/ipsec/5758220e-5c35-429a-975f-39375db70efe/var/run/pluto
--status
whack: Pluto is not running (no
"/var/lib/neutron/ipsec/5758220e-5c35-429a-975f-39375db70efe/var/run/pluto.ctl")

By the way, ipsec checknss had already run, but I had not seen any db files
in the /etc/pki/nssdb directory:
root 14087  0.0  0.0 113252   912 ?S23:21   0:00 /bin/sh
/sbin/ipsec checknss
/var/lib/neutron/ipsec/5758220e-5c35-429a-975f-39375db70efe/etc
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][vpnaas]Question about MPLS VPN

[Anita Kuno]

On 05/26/2016 02:50 AM, zhangyali (D) wrote:
> Hi all,
> 
> I am interested in the VPNaaS project in Neutron. Now I notice that only 
> IPsec tunnel has completed, but other types of VPN, such as, MPLS/BGP, have 
> not completed. I'd like to know how's going about MPLS/BGP vpn? What's the 
> mechanism or extra work need to be done? 
> 
> Thanks.
> 
> Best,
> Yali
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

Please start your own thread for a new topic. Replying to post from an
existing thread just confuses the existing thread, as this post for a
new topic is nested within a different thread.
http://lists.openstack.org/pipermail/openstack-dev/2016-May/thread.html#94076

Also you might find suggestions for how to form good email subjects
helpful: http://www.catb.org/esr/faqs/smart-questions.html#bespecific

Thank you,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][vpnaas]Question about MPLS VPN

[Mathieu Rohon]

Hi,

sorry for the late reply, but if you want to attach a neutron network or a
neutron router to an existing MPLS based BGP L3 VPN, you can use the BGPVPN
project [1], with its API and one of it's backend, bagpipe [2] being its
opensource and reference implementation.

Those projects have dedicated devstack plugins, so it's quite easy to
experiment.

[1]http://git.openstack.org/cgit/openstack/networking-bgpvpn
[2]http://git.openstack.org/cgit/openstack/networking-bagpipe

Mathieu

On Thu, May 26, 2016 at 5:29 PM, Kosnik, Lubosz 
wrote:

> I had a discussion with few operators and after what I heard about VPNaaS
> I can tell that we not suppose to help with that implementation.
> Maybe we should work on service VM’s and prepare implementation of VPNaaS
> using them and using some prebuild images like VyOS or other.
>
> Lubosz Kosnik
> Cloud Software Engineer OSIC
> lubosz.kos...@intel.com
>
> > On May 26, 2016, at 9:39 AM, Ihar Hrachyshka 
> wrote:
> >
> >
> >> On 26 May 2016, at 16:23, Kosnik, Lubosz 
> wrote:
> >>
> >> You should read e-mails on ML. VPNaaS will be removed in next 6 months
> from repo. You need to look into something else like starting VyOS image,
> pfSense or other.
> >
> > Strictly speaking, vpnaas is on probation right now, and if interested
> parties actually revive the project, it may stay past those 6 months. That
> said, I haven’t heard about anyone stepping in since the summit.
> >
> > Ihar
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][vpnaas]Question about MPLS VPN

[Paul Carver]

On 5/26/2016 02:50, zhangyali (D) wrote:

I am interested in the VPNaaS project in Neutron. Now I notice that only IPsec 
tunnel has completed, but other types of VPN, such as, MPLS/BGP, have not 
completed. I'd like to know how's going about MPLS/BGP vpn? What's the 
mechanism or extra work need to be done?


For MPLS/BGP VPNs refer to the networking-bgpvpn project rather than VPNaaS.

http://docs.openstack.org/developer/networking-bgpvpn



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][vpnaas]Question about MPLS VPN

[Kosnik, Lubosz]

I had a discussion with few operators and after what I heard about VPNaaS I can 
tell that we not suppose to help with that implementation.
Maybe we should work on service VM’s and prepare implementation of VPNaaS using 
them and using some prebuild images like VyOS or other.

Lubosz Kosnik
Cloud Software Engineer OSIC
lubosz.kos...@intel.com

> On May 26, 2016, at 9:39 AM, Ihar Hrachyshka  wrote:
> 
> 
>> On 26 May 2016, at 16:23, Kosnik, Lubosz  wrote:
>> 
>> You should read e-mails on ML. VPNaaS will be removed in next 6 months from 
>> repo. You need to look into something else like starting VyOS image, pfSense 
>> or other.
> 
> Strictly speaking, vpnaas is on probation right now, and if interested 
> parties actually revive the project, it may stay past those 6 months. That 
> said, I haven’t heard about anyone stepping in since the summit.
> 
> Ihar
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][vpnaas]Question about MPLS VPN

[Ihar Hrachyshka]

> On 26 May 2016, at 16:23, Kosnik, Lubosz  wrote:
> 
> You should read e-mails on ML. VPNaaS will be removed in next 6 months from 
> repo. You need to look into something else like starting VyOS image, pfSense 
> or other.

Strictly speaking, vpnaas is on probation right now, and if interested parties 
actually revive the project, it may stay past those 6 months. That said, I 
haven’t heard about anyone stepping in since the summit.

Ihar
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][vpnaas]Question about MPLS VPN

[Kosnik, Lubosz]

You should read e-mails on ML. VPNaaS will be removed in next 6 months from 
repo. You need to look into something else like starting VyOS image, pfSense or 
other.

Lubosz Kosnik
Cloud Software Engineer OSIC
lubosz.kos...@intel.com

> On May 26, 2016, at 1:50 AM, zhangyali (D)  wrote:
> 
> Hi all,
> 
> I am interested in the VPNaaS project in Neutron. Now I notice that only 
> IPsec tunnel has completed, but other types of VPN, such as, MPLS/BGP, have 
> not completed. I'd like to know how's going about MPLS/BGP vpn? What's the 
> mechanism or extra work need to be done? 
> 
> Thanks.
> 
> Best,
> Yali
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][vpnaas]Question about MPLS VPN

[zhangyali (D)]

Hi all,

I am interested in the VPNaaS project in Neutron. Now I notice that only IPsec 
tunnel has completed, but other types of VPN, such as, MPLS/BGP, have not 
completed. I'd like to know how's going about MPLS/BGP vpn? What's the 
mechanism or extra work need to be done? 

Thanks.

Best,
Yali

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] VPNaaS tox api failure

[Bharath Kumar Gubbala]

Thanks madhu, I will try it out below patchset.

From: Madhusudhan Kandadai [madhusudhan.openst...@gmail.com]
Sent: 27 April 2016 03:28
To: Bharath Kumar Gubbala
Cc: OpenStack Development Mailing List (not for usage questions); Alex 
Geevarghese; Paul Michali; hen...@gessau.net
Subject: Re: [openstack-dev] [neutron][vpnaas] VPNaaS tox api failure

Hi Bharath,

Yes. Did you have this patch 
https://review.openstack.org/#/c/281493/<https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_281493_=CwMFaQ=IL_XqQWOjubgfqINi2jTzg=87NL1fmn9sX2yN6wRmckSjVQpenT6rqPI7fvK0O5yfk=UO3NuGlhJBlMDomX-pSY_zgMUQCdJSvrA29drPEtjEw=Q20HS2UPxa_kJQyUIyZmdwx33Vrxps8caCFSD1dKU9w=>
 before you run "tox -e api" ? There was a change in neutron that removed vpn 
and fw tests and its in their tree. However, to make it work for vpn api tests, 
we need to figure out a way to implement the changes in vpn tree. However for 
time being, patch 281493 needs to be cherry picked until we get a timeline to 
implement in vpnaas tree.

If you have cycles, feel free to take on 
https://review.openstack.org/#/c/281493<https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_281493=CwMFaQ=IL_XqQWOjubgfqINi2jTzg=87NL1fmn9sX2yN6wRmckSjVQpenT6rqPI7fvK0O5yfk=UO3NuGlhJBlMDomX-pSY_zgMUQCdJSvrA29drPEtjEw=VHQWmcFfAKpwxmGiLTBPSlo-GxqZPbtX6hk4XKl-8vE=>
 and once that merges, 
https://review.openstack.org/#/c/279787/<https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_279787_=CwMFaQ=IL_XqQWOjubgfqINi2jTzg=87NL1fmn9sX2yN6wRmckSjVQpenT6rqPI7fvK0O5yfk=UO3NuGlhJBlMDomX-pSY_zgMUQCdJSvrA29drPEtjEw=5DUiNO7Dxl6nqfdz5m3WeMyVBZqbzp6nXLJbtk_y9kI=>
 is the traditional way of running tempest tests using tempest plugin. Hope 
this helps.

Regards,
Madhu

On Mon, Apr 25, 2016 at 11:14 AM, Bharath Kumar Gubbala 
<bhar...@brocade.com<mailto:bhar...@brocade.com>> wrote:

Hi Henry,


Do you have any info on below query in the thread.(is 'tox -e api' working in 
neutron-vpnaas ?)



Thanks,

bharath



From: bharath <bhar...@brocade.com<mailto:bhar...@brocade.com>>
Sent: 08 April 2016 01:53
To: OpenStack Development Mailing List (not for usage questions); Alex 
Geevarghese; 
madhusudhan.openst...@gmail.com<mailto:madhusudhan.openst...@gmail.com>; 
p...@michali.net<mailto:p...@michali.net>
Subject: Re: [openstack-dev] [neutron][vpnaas] VPNaaS tox api failure

Thanks Paul for info.

Yes i had run the tests locally under VPN-repo.

My analysis:

  *   VPN test cases were using the neutron client for VPN services 
(which no longer supported by neutron).

 Thats why its throwing "tempest.lib.exceptions.NotFound: 
Object not found"

  *   In the case of FW , there were using router client directly 
instead of neutron client.


I will check with madhusudhan for additional info.



Madhu,
Let me know if you have info on "tox api" support.
If it is an known issue, i can take it up and complete fix

Thanks,
bharath




On Friday 08 April 2016 01:00 AM, Paul Michali wrote:
Are you running the test locally?

IIRC, the tempest based API tests for VPN have been (are being) moved to the 
VPN repo, but I don't know if a job was ever created for this so that the tests 
actually run. You may want to check with the author who moved the tests 
(madhusudan-kandadai) under commit 3cae934a, to see if the CI job was ever 
created. It is possible that it was never completed.

Likewise, I don't know if support was added to tox.ini for the api test. I've 
never run the test, granted I've been away from VPN for a while and only 
involved intermittently since Liberty, so I may be a bit out of touch.

Regards,

PCM


On Thu, Apr 7, 2016 at 2:23 PM bharath 
<bhar...@brocade.com<mailto:bhar...@brocade.com>> wrote:

Hi,

While running "tox -e api" i hitting " tempest.lib.NotFound" Error.

Is it a known issue ? failures expected?

https://review.openstack.org/#/c/291949/1<https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_291949_1=CwMFaQ=IL_XqQWOjubgfqINi2jTzg=87NL1fmn9sX2yN6wRmckSjVQpenT6rqPI7fvK0O5yfk=9pS9SGHSr62ETR_Qt_kSEpw9f-DjUThD6EYZ90W4cyU=ZDw4wmaoyLK168h__uf18GUBHbyWR45DLbdEGW5G-jY=>
  ==> In this commit messages it says it kindof expected failure.

Can someone provide some clarification on this

Thanks,
bharath
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<https://urldefense.proofpoint.com/v2/url?u=http-3A__OpenStack-2Ddev-2Drequest-40lists.openstack.org-3Fsubject-3Aunsubscribe=CwMFaQ=IL_XqQWOjubgfqINi2jTzg=87NL1fmn9sX2yN6wRmckSjVQpenT6rqPI7fvK0O5yfk=9pS9SGHSr62ETR_Qt_kSEpw9f-DjUThD6

Re: [openstack-dev] [neutron][vpnaas] VPNaaS tox api failure

[Madhusudhan Kandadai]

Hi Bharath,

Yes. Did you have this patch https://review.openstack.org/#/c/281493/
before you run "tox -e api" ? There was a change in neutron that removed
vpn and fw tests and its in their tree. However, to make it work for vpn
api tests, we need to figure out a way to implement the changes in vpn
tree. However for time being, patch 281493 needs to be cherry picked until
we get a timeline to implement in vpnaas tree.

If you have cycles, feel free to take on
https://review.openstack.org/#/c/281493 and once that merges,
https://review.openstack.org/#/c/279787/ is the traditional way of running
tempest tests using tempest plugin. Hope this helps.

Regards,
Madhu

On Mon, Apr 25, 2016 at 11:14 AM, Bharath Kumar Gubbala <bhar...@brocade.com
> wrote:

> Hi Henry,
>
>
> Do you have any info on below query in the thread.(is 'tox -e api' working
> in neutron-vpnaas ?)
>
>
>
> Thanks,
>
> bharath
>
>
> --
> *From:* bharath <bhar...@brocade.com>
> *Sent:* 08 April 2016 01:53
> *To:* OpenStack Development Mailing List (not for usage questions); Alex
> Geevarghese; madhusudhan.openst...@gmail.com; p...@michali.net
> *Subject:* Re: [openstack-dev] [neutron][vpnaas] VPNaaS tox api failure
>
> Thanks Paul for info.
>
> Yes i had run the tests locally under VPN-repo.
>
> My analysis:
>
>- VPN test cases were using the neutron client for VPN
>services (which no longer supported by neutron).
>
>  Thats why its throwing "tempest.lib.exceptions.NotFound:
> Object not found"
>
>- In the case of FW , there were using router client directly
>instead of neutron client.
>
>
>
> I will check with madhusudhan for additional info.
>
>
>
> Madhu,
> Let me know if you have info on "tox api" support.
> If it is an known issue, i can take it up and complete fix
>
> Thanks,
> bharath
>
>
>
>
> On Friday 08 April 2016 01:00 AM, Paul Michali wrote:
>
> Are you running the test locally?
>
> IIRC, the tempest based API tests for VPN have been (are being) moved to
> the VPN repo, but I don't know if a job was ever created for this so that
> the tests actually run. You may want to check with the author who moved the
> tests (madhusudan-kandadai) under commit 3cae934a, to see if the CI job was
> ever created. It is possible that it was never completed.
>
> Likewise, I don't know if support was added to tox.ini for the api test.
> I've never run the test, granted I've been away from VPN for a while and
> only involved intermittently since Liberty, so I may be a bit out of touch.
>
> Regards,
>
> PCM
>
>
> On Thu, Apr 7, 2016 at 2:23 PM bharath <bhar...@brocade.com> wrote:
>
>>
>> Hi,
>>
>> While running "tox -e api" i hitting " tempest.lib.NotFound" Error.
>>
>> Is it a known issue ? failures expected?
>>
>> https://review.openstack.org/#/c/291949/1
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_291949_1=CwMFaQ=IL_XqQWOjubgfqINi2jTzg=87NL1fmn9sX2yN6wRmckSjVQpenT6rqPI7fvK0O5yfk=9pS9SGHSr62ETR_Qt_kSEpw9f-DjUThD6EYZ90W4cyU=ZDw4wmaoyLK168h__uf18GUBHbyWR45DLbdEGW5G-jY=>
>> ==> In this commit messages it says it kindof expected failure.
>>
>> Can someone provide some clarification on this
>>
>> Thanks,
>> bharath
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__OpenStack-2Ddev-2Drequest-40lists.openstack.org-3Fsubject-3Aunsubscribe=CwMFaQ=IL_XqQWOjubgfqINi2jTzg=87NL1fmn9sX2yN6wRmckSjVQpenT6rqPI7fvK0O5yfk=9pS9SGHSr62ETR_Qt_kSEpw9f-DjUThD6EYZ90W4cyU=t2nU4BBA6qpk-pfDWdMrl63vsszVHXW9Sh8ateqFmcE=>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=CwMFaQ=IL_XqQWOjubgfqINi2jTzg=87NL1fmn9sX2yN6wRmckSjVQpenT6rqPI7fvK0O5yfk=9pS9SGHSr62ETR_Qt_kSEpw9f-DjUThD6EYZ90W4cyU=ajURyED5NOlDi3x19ZS_layCPNAtjp7vjElGBLVMOtQ=>
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttps://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=CwICAg=IL_XqQWOjubgfqINi2jTzg=87NL1fmn9sX2yN6wRmckSjVQpenT6rqPI7fvK0O5yfk=9pS9SGHSr62ETR_Qt_kSEpw9f-DjUThD6EYZ90W4cyU=ajURyED5NOlDi3x19ZS_layCPNAtjp7vjElGBLVMOtQ=
>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] VPNaaS tox api failure

[Bharath Kumar Gubbala]

Hi Henry,


Do you have any info on below query in the thread.(is 'tox -e api' working in 
neutron-vpnaas ?)



Thanks,

bharath



From: bharath <bhar...@brocade.com>
Sent: 08 April 2016 01:53
To: OpenStack Development Mailing List (not for usage questions); Alex 
Geevarghese; madhusudhan.openst...@gmail.com; p...@michali.net
Subject: Re: [openstack-dev] [neutron][vpnaas] VPNaaS tox api failure

Thanks Paul for info.

Yes i had run the tests locally under VPN-repo.

My analysis:

  *   VPN test cases were using the neutron client for VPN services 
(which no longer supported by neutron).

 Thats why its throwing "tempest.lib.exceptions.NotFound: 
Object not found"

  *   In the case of FW , there were using router client directly 
instead of neutron client.


I will check with madhusudhan for additional info.



Madhu,
Let me know if you have info on "tox api" support.
If it is an known issue, i can take it up and complete fix

Thanks,
bharath




On Friday 08 April 2016 01:00 AM, Paul Michali wrote:
Are you running the test locally?

IIRC, the tempest based API tests for VPN have been (are being) moved to the 
VPN repo, but I don't know if a job was ever created for this so that the tests 
actually run. You may want to check with the author who moved the tests 
(madhusudan-kandadai) under commit 3cae934a, to see if the CI job was ever 
created. It is possible that it was never completed.

Likewise, I don't know if support was added to tox.ini for the api test. I've 
never run the test, granted I've been away from VPN for a while and only 
involved intermittently since Liberty, so I may be a bit out of touch.

Regards,

PCM


On Thu, Apr 7, 2016 at 2:23 PM bharath 
<bhar...@brocade.com<mailto:bhar...@brocade.com>> wrote:

Hi,

While running "tox -e api" i hitting " tempest.lib.NotFound" Error.

Is it a known issue ? failures expected?

https://review.openstack.org/#/c/291949/1<https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_291949_1=CwMFaQ=IL_XqQWOjubgfqINi2jTzg=87NL1fmn9sX2yN6wRmckSjVQpenT6rqPI7fvK0O5yfk=9pS9SGHSr62ETR_Qt_kSEpw9f-DjUThD6EYZ90W4cyU=ZDw4wmaoyLK168h__uf18GUBHbyWR45DLbdEGW5G-jY=>
  ==> In this commit messages it says it kindof expected failure.

Can someone provide some clarification on this

Thanks,
bharath
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<https://urldefense.proofpoint.com/v2/url?u=http-3A__OpenStack-2Ddev-2Drequest-40lists.openstack.org-3Fsubject-3Aunsubscribe=CwMFaQ=IL_XqQWOjubgfqINi2jTzg=87NL1fmn9sX2yN6wRmckSjVQpenT6rqPI7fvK0O5yfk=9pS9SGHSr62ETR_Qt_kSEpw9f-DjUThD6EYZ90W4cyU=t2nU4BBA6qpk-pfDWdMrl63vsszVHXW9Sh8ateqFmcE=>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=CwMFaQ=IL_XqQWOjubgfqINi2jTzg=87NL1fmn9sX2yN6wRmckSjVQpenT6rqPI7fvK0O5yfk=9pS9SGHSr62ETR_Qt_kSEpw9f-DjUThD6EYZ90W4cyU=ajURyED5NOlDi3x19ZS_layCPNAtjp7vjElGBLVMOtQ=>



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=CwICAg=IL_XqQWOjubgfqINi2jTzg=87NL1fmn9sX2yN6wRmckSjVQpenT6rqPI7fvK0O5yfk=9pS9SGHSr62ETR_Qt_kSEpw9f-DjUThD6EYZ90W4cyU=ajURyED5NOlDi3x19ZS_layCPNAtjp7vjElGBLVMOtQ=


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] VPNaaS tox api failure

[bharath]

Thanks Paul for info.

Yes i had run the tests locally under VPN-repo.

My analysis:

 *  VPN test cases were using the neutron client for VPN
   services (which no longer supported by neutron).

 Thats why its throwing 
"tempest.lib.exceptions.NotFound: Object not found"


 *  In the case of FW , there were using router client directly
   instead of neutron client.



I will check with madhusudhan for additional info.



Madhu,
Let me know if you have info on "tox api" support.
If it is an known issue, i can take it up and complete fix

Thanks,
bharath




On Friday 08 April 2016 01:00 AM, Paul Michali wrote:

Are you running the test locally?

IIRC, the tempest based API tests for VPN have been (are being) moved 
to the VPN repo, but I don't know if a job was ever created for this 
so that the tests actually run. You may want to check with the author 
who moved the tests (madhusudan-kandadai) under commit 3cae934a, to 
see if the CI job was ever created. It is possible that it was never 
completed.


Likewise, I don't know if support was added to tox.ini for the api 
test. I've never run the test, granted I've been away from VPN for a 
while and only involved intermittently since Liberty, so I may be a 
bit out of touch.


Regards,

PCM


On Thu, Apr 7, 2016 at 2:23 PM bharath > wrote:



Hi,

While running "tox -e api" i hitting " tempest.lib.NotFound" Error.

Is it a known issue ? failures expected?

https://review.openstack.org/#/c/291949/1


==> In this commit messages it says it kindof expected failure.

Can someone provide some clarification on this

Thanks,
bharath
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=CwICAg=IL_XqQWOjubgfqINi2jTzg=87NL1fmn9sX2yN6wRmckSjVQpenT6rqPI7fvK0O5yfk=9pS9SGHSr62ETR_Qt_kSEpw9f-DjUThD6EYZ90W4cyU=ajURyED5NOlDi3x19ZS_layCPNAtjp7vjElGBLVMOtQ=


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] VPNaaS tox api failure

[Paul Michali]

Are you running the test locally?

IIRC, the tempest based API tests for VPN have been (are being) moved to
the VPN repo, but I don't know if a job was ever created for this so that
the tests actually run. You may want to check with the author who moved the
tests (madhusudan-kandadai) under commit 3cae934a, to see if the CI job was
ever created. It is possible that it was never completed.

Likewise, I don't know if support was added to tox.ini for the api test.
I've never run the test, granted I've been away from VPN for a while and
only involved intermittently since Liberty, so I may be a bit out of touch.

Regards,

PCM


On Thu, Apr 7, 2016 at 2:23 PM bharath  wrote:

>
> Hi,
>
> While running "tox -e api" i hitting " tempest.lib.NotFound" Error.
>
> Is it a known issue ? failures expected?
>
> https://review.openstack.org/#/c/291949/1  ==> In this commit messages it
> says it kindof expected failure.
>
> Can someone provide some clarification on this
>
> Thanks,
> bharath
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][vpnaas] VPNaaS tox api failure

[bharath]

Hi,

While running "tox -e api" i hitting " tempest.lib.NotFound" Error.

Is it a known issue ? failures expected?

https://review.openstack.org/#/c/291949/1  ==> In this commit messages 
it says it kindof expected failure.


Can someone provide some clarification on this

Thanks,
bharath
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][VPNaaS] Question regarding creating an IPSec Connection Site with multiple subnets attached to a router on each site in stable/kilo

[Chirag Shahani]

Hi All,

I am using https://wiki.openstack.org/wiki/Neutron/VPNaaS/HowToInstall to
install VPNaaS with single devstack and two routers.


stack@whiskey:/opt/stack$ neutron router-list
+--+--+---+-+---+
| id   | name | external_gateway_info

  | distributed | ha|
+--+--+---+-+---+
| 6e730589-113e-4105-af61-3945bc5c9413 | r1   | {"network_id":
"dfcb5c47-712c-4c6e-b98e-53ea9688d7d5", "enable_snat": true,
"external_fixed_ips": [{"subnet_id": "fcb87cfa-734b-  | False   |
False |
|  |  | 47d0-83b2-523ecbd2fa5c",
"ip_address": "5.5.5.3"}]}
  | |   |
| eaeae30a-e281-42a7-9c38-1f678ec1ccbf | r2   | {"network_id":
"dfcb5c47-712c-4c6e-b98e-53ea9688d7d5", "enable_snat": true,
"external_fixed_ips": [{"subnet_id": "fcb87cfa-734b-  | False   |
False |
|  |  | 47d0-83b2-523ecbd2fa5c",
"ip_address": "5.5.5.4"}]}
  | |   |
+--+--+---+-+---+

stack@whiskey:/opt/stack$ neutron vpn-service-list
+--++--++
| id   | name   | router_id
   | status |
+--++--++
| 59adbee1-7cc7-415e-8273-d4c2491ab878 | myvpn  |
6e730589-113e-4105-af61-3945bc5c9413 | ACTIVE |
| c453caf5-839a-4687-b44a-148014671fce | myvpn2 |
eaeae30a-e281-42a7-9c38-1f678ec1ccbf | ACTIVE |
+--++--++



(neutron) stack@whiskey:/opt/stack$ neutron ipsec-site-connection-list
+--++--+---++
| id   | name   | peer_address |
auth_mode | status |
+--++--+---++
| 0f5db508-5248-48e4-a76e-f4ef17d8f975 | vpnconnection1 | 5.5.5.4  |
psk   | ACTIVE |
| 5db83673-4e3c-41ef-8697-dd6a33e57576 | vpnconnection2 | 5.5.5.3  |
psk   | ACTIVE |
+--++--+---++
stack@whiskey:/opt/stack$

stack@whiskey:/opt/stack$ nova list
+--+--+++-++
| ID   | Name | Status | Task State | Power
State | Networks   |
+--+--+++-++
| c390da65-9a5c-40d3-aa55-6627f66afabb | vm1  | ACTIVE | -  |
Running | n1=1.1.1.3 |
| 2186a7dd-b5c9-464e-bc10-bd8a92890509 | vm2  | ACTIVE | -  |
Running | n2=2.2.2.3 |
+--+--+++-++


>From the above three commands, I could get the topology mentioned in the
install guide to work perfectly and could ping the vm's on the two routers
from each other.


Now, I added 2 more subnets to each router on either side and spun 2 vms's
(vm3 and vm4) on subnets s3 and s4 attached to routers r1 and r2
respectively.


Now create a vpn service myvpn3 with r1 and s3 & myvpn4  with r2 and s4.

stack@whiskey:/opt/stack$ neutron vpn-service-list
+--++--++
| id   | name   | router_id
   | status |
+--++--++
| 05bdaa03-374d-4df6-af67-96ad209b8126 | myvpn4 |
eaeae30a-e281-42a7-9c38-1f678ec1ccbf | PENDING_CREATE |
| 4fd6fc1f-9f5e-4980-a28c-520a1c3a8e8a | myvpn3 |
6e730589-113e-4105-af61-3945bc5c9413 | PENDING_CREATE |
| 59adbee1-7cc7-415e-8273-d4c2491ab878 | myvpn  |
6e730589-113e-4105-af61-3945bc5c9413 | ACTIVE |
| c453caf5-839a-4687-b44a-148014671fce | myvpn2 |
eaeae30a-e281-42a7-9c38-1f678ec1ccbf | ACTIVE |
+--++--++


Now create a ipsec-site-conneciton.

stack@whiskey:/opt/stack$ neutron ipsec-site-connection-create --name
vpnconnection3 --vpnservice-id myvpn3 

[openstack-dev] [Neutron][VPNaaS]How to enable VPNaas in devstack ?

[lichen.hangzhou]

hello,

I have a question, can I enable vpnaas under devstack?

https://wiki.openstack.org/wiki/Neutron/VPNaaS/HowToInstall#VPNaaS_with_Single_DevStack_and_Two_Routers

==> There is a section said :
Checkout Test branches

Neutron : https://review.openstack.org/#/c/33148/

Neutron client : https://review.openstack.org/#/c/29811/





Do I must checkout neutron to change https://review.openstack.org/#/c/33148/ ?
Can vpnaas work with master branch directly ?

Thanks.
-chen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][VPNaaS]How to enable VPNaas in devstack ?

[Elena Ezhova]

Hi!

Just enabling the neutron-vpnaas plugin is enough, master branch will be
automatically fetched if you set RECLONE=True in your local.conf.
The "Checkout Test branches" section is outdated and should be removed from
the doc.

On Wed, Dec 2, 2015 at 12:31 PM, lichen.hangzhou 
wrote:

> hello,
>
> I have a question, can I enable vpnaas under devstack?
>
>
> https://wiki.openstack.org/wiki/Neutron/VPNaaS/HowToInstall#VPNaaS_with_Single_DevStack_and_Two_Routers
>
> ==> There is a section said :
>
>- Checkout Test branches
>
> Neutron : https://review.openstack.org/#/c/33148/
>
> Neutron client : https://review.openstack.org/#/c/29811/
>
>
> Do I must checkout neutron to change
> https://review.openstack.org/#/c/33148/ ?
> Can vpnaas work with master branch directly ?
>
> Thanks.
> -chen
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][vpnaas] "SKIPPED: Neutron support is required" while running tox

[Ihar Hrachyshka]

bharath  wrote:


Hi,

when running tox "sudo -u stack -H tox -e api  
neutron.tests.api.test_vpnaas_extensions"
test cases are failing with Error " setUpClass  
(neutron.tests.api.test_vpnaas_extensions.VPNaaSTestJSON) ... SKIPPED:  
Neutron support is required"


I even tried setting tempest_config_dir as below, still i am hitting the  
issue.


[testenv:api]
basepython = python2.7
passenv = {[testenv]passenv} TEMPEST_CONFIG_DIR
setenv = {[testenv]setenv}
 OS_TEST_PATH=./neutron/tests/api
 TEMPEST_CONFIG_DIR={env:TEMPEST_CONFIG_DIR:/opt/stack/tempest/etc}
 OS_TEST_API_WITH_REST=1


Can someone help me out



Does your /opt/stack/tempest/etc have tempest configured to run tests for  
neutron?


Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][vpnaas] "SKIPPED: Neutron support is required" while running tox

[Paul Michali]

There is an effort to move the VPN API tests from neutron to neutron-vpnaas
repo under https://review.openstack.org/#/c/211381.  You may want to help
the submitter getting those tests running as an alternative to trying to
get this working (unless there is some need to run this specific test -
older release or something).

Regards,

Paul Michali (pc_m)


On Mon, Nov 30, 2015 at 4:33 AM Ihar Hrachyshka  wrote:

> bharath  wrote:
>
> > Hi,
> >
> > when running tox "sudo -u stack -H tox -e api
> > neutron.tests.api.test_vpnaas_extensions"
> > test cases are failing with Error " setUpClass
> > (neutron.tests.api.test_vpnaas_extensions.VPNaaSTestJSON) ... SKIPPED:
> > Neutron support is required"
> >
> > I even tried setting tempest_config_dir as below, still i am hitting the
> > issue.
> >
> > [testenv:api]
> > basepython = python2.7
> > passenv = {[testenv]passenv} TEMPEST_CONFIG_DIR
> > setenv = {[testenv]setenv}
> >  OS_TEST_PATH=./neutron/tests/api
> >
> TEMPEST_CONFIG_DIR={env:TEMPEST_CONFIG_DIR:/opt/stack/tempest/etc}
> >  OS_TEST_API_WITH_REST=1
> >
> >
> > Can someone help me out
> >
>
> Does your /opt/stack/tempest/etc have tempest configured to run tests for
> neutron?
>
> Ihar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][vpnaas] "SKIPPED: Neutron support is required" while running tox

[bharath]

Hi,

when running tox *"sudo -u stack -H tox -e api 
neutron.tests.api.test_vpnaas_extensions"*
test cases are failing with Error " setUpClass 
(neutron.tests.api.test_vpnaas_extensions.VPNaaSTestJSON) ... SKIPPED: 
Neutron support is required"


I even tried setting tempest_config_dir as below, still i am hitting the 
issue.


   [testenv:api]
   basepython = python2.7
   passenv = {[testenv]passenv} TEMPEST_CONFIG_DIR
   setenv = {[testenv]setenv}
 OS_TEST_PATH=./neutron/tests/api
   *TEMPEST_CONFIG_DIR={env:TEMPEST_CONFIG_DIR:/opt/stack/tempest/etc}*
 OS_TEST_API_WITH_REST=1



Can someone help me out


Thanks,
bharath


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status

[Elena Ezhova]

Thanks for everything you've done for VPNaaS, Paul! Your help and guidance
was (and is) always very helpful.

On Thu, Nov 12, 2015 at 5:56 PM, Paul Michali  wrote:

> Neutron community,
>
> During the past several releases, while leading the VPNaaS project, I've
> seen many great enhancements and features added to the VPNaaS project by
> the community, including support for StrongSwan, Libreswan, completion of
> the project split out, functional and rally tests, endpoint groups,
> multiple local subnets, vendor drivers, etc.
>
> There is still work needed (certificate support the most important,
> followed by documentation and scale testing), but there is a solid (in my
> bias and subjective opinion :) foundation in place for people to play with
> this capability.
>
> As I mentioned to Armando at the summit, it's time for me to move on to
> other areas of Neutron, and as such, I'm stepping down as VPNaaS chair and
> wrapping up work on the project over the next few weeks. I'll still try to
> review VPNaaS commits as much as possible, and be available to advise in
> this area.
>
> Towards that end, I've updated the VPNaaS wiki page (
> https://wiki.openstack.org/wiki/Meetings/VPNaaS) to list what I think are
> outstanding work that can be done in this area, from important to wish
> items.  Meetings have transitioned to on-demand, and future meetings can
> either be done as an on-demand topic in the Neutron IRC meeting, or as an
> on-demand special meeting.
>
> I'll go through the VPNaaS bugs in Launchpad and comment on them, as to my
> opinion of importance, priority, relevance, etc.
>
> Regards,
>
> PCM (pc_m)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status

[Al Miller]

Paul, I echo the prior comments.  Your hard work and persistence in getting the 
recent new features written, as well as your review suggestions are very much 
appreciated!

Thanks,

Al


From: Paul Michali [mailto:p...@michali.net]
Sent: Thursday, November 12, 2015 8:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][vpnaas] VPNaaS project status

Neutron community,

During the past several releases, while leading the VPNaaS project, I've seen 
many great enhancements and features added to the VPNaaS project by the 
community, including support for StrongSwan, Libreswan, completion of the 
project split out, functional and rally tests, endpoint groups, multiple local 
subnets, vendor drivers, etc.

There is still work needed (certificate support the most important, followed by 
documentation and scale testing), but there is a solid (in my bias and 
subjective opinion :) foundation in place for people to play with this 
capability.

As I mentioned to Armando at the summit, it's time for me to move on to other 
areas of Neutron, and as such, I'm stepping down as VPNaaS chair and wrapping 
up work on the project over the next few weeks. I'll still try to review VPNaaS 
commits as much as possible, and be available to advise in this area.

Towards that end, I've updated the VPNaaS wiki page 
(https://wiki.openstack.org/wiki/Meetings/VPNaaS) to list what I think are 
outstanding work that can be done in this area, from important to wish items.  
Meetings have transitioned to on-demand, and future meetings can either be done 
as an on-demand topic in the Neutron IRC meeting, or as an on-demand special 
meeting.

I'll go through the VPNaaS bugs in Launchpad and comment on them, as to my 
opinion of importance, priority, relevance, etc.

Regards,

PCM (pc_m)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status

[Paul Michali]

Thanks folks.

I have gone through all of the "open" VPN bugs and commented/updated them.
The Wiki was updated with references to some of the LP bugs of particular
interest.

Regards,

PCM (pc_m)

On Fri, Nov 13, 2015 at 3:42 AM Elena Ezhova  wrote:

> Thanks for everything you've done for VPNaaS, Paul! Your help and guidance
> was (and is) always very helpful.
>
> On Thu, Nov 12, 2015 at 5:56 PM, Paul Michali  wrote:
>
>> Neutron community,
>>
>> During the past several releases, while leading the VPNaaS project, I've
>> seen many great enhancements and features added to the VPNaaS project by
>> the community, including support for StrongSwan, Libreswan, completion of
>> the project split out, functional and rally tests, endpoint groups,
>> multiple local subnets, vendor drivers, etc.
>>
>> There is still work needed (certificate support the most important,
>> followed by documentation and scale testing), but there is a solid (in my
>> bias and subjective opinion :) foundation in place for people to play with
>> this capability.
>>
>> As I mentioned to Armando at the summit, it's time for me to move on to
>> other areas of Neutron, and as such, I'm stepping down as VPNaaS chair and
>> wrapping up work on the project over the next few weeks. I'll still try to
>> review VPNaaS commits as much as possible, and be available to advise in
>> this area.
>>
>> Towards that end, I've updated the VPNaaS wiki page (
>> https://wiki.openstack.org/wiki/Meetings/VPNaaS) to list what I think
>> are outstanding work that can be done in this area, from important to wish
>> items.  Meetings have transitioned to on-demand, and future meetings can
>> either be done as an on-demand topic in the Neutron IRC meeting, or as an
>> on-demand special meeting.
>>
>> I'll go through the VPNaaS bugs in Launchpad and comment on them, as to
>> my opinion of importance, priority, relevance, etc.
>>
>> Regards,
>>
>> PCM (pc_m)
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status

[Sridar Kandaswamy (skandasw)]

Could not agree more. Thanks very much Paul.  And thanks also for always being 
a sounding board for common things across FWaaS and VPNaaS.

Thanks

Sridar

From: Madhusudhan Kandadai 
<madhusudhan.openst...@gmail.com<mailto:madhusudhan.openst...@gmail.com>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, November 12, 2015 at 7:28 AM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status

Thanks Paul for leading over the previous releases. Looking forward to have 
your guidance in neutron.

On Thu, Nov 12, 2015 at 8:48 PM, Kyle Mestery 
<mest...@mestery.com<mailto:mest...@mestery.com>> wrote:
On Thu, Nov 12, 2015 at 9:56 AM, Paul Michali 
<p...@michali.net<mailto:p...@michali.net>> wrote:
Neutron community,

During the past several releases, while leading the VPNaaS project, I've seen 
many great enhancements and features added to the VPNaaS project by the 
community, including support for StrongSwan, Libreswan, completion of the 
project split out, functional and rally tests, endpoint groups, multiple local 
subnets, vendor drivers, etc.

There is still work needed (certificate support the most important, followed by 
documentation and scale testing), but there is a solid (in my bias and 
subjective opinion :) foundation in place for people to play with this 
capability.

As I mentioned to Armando at the summit, it's time for me to move on to other 
areas of Neutron, and as such, I'm stepping down as VPNaaS chair and wrapping 
up work on the project over the next few weeks. I'll still try to review VPNaaS 
commits as much as possible, and be available to advise in this area.

Towards that end, I've updated the VPNaaS wiki page 
(https://wiki.openstack.org/wiki/Meetings/VPNaaS) to list what I think are 
outstanding work that can be done in this area, from important to wish items.  
Meetings have transitioned to on-demand, and future meetings can either be done 
as an on-demand topic in the Neutron IRC meeting, or as an on-demand special 
meeting.

I'll go through the VPNaaS bugs in Launchpad and comment on them, as to my 
opinion of importance, priority, relevance, etc.

Regards,


Thanks for all your hard work over the previous releases Paul! Looking forward 
to what you'll be doing next in Neutron.

Thanks,
Kyle

PCM (pc_m)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][vpnaas] VPNaaS project status

[Paul Michali]

Neutron community,

During the past several releases, while leading the VPNaaS project, I've
seen many great enhancements and features added to the VPNaaS project by
the community, including support for StrongSwan, Libreswan, completion of
the project split out, functional and rally tests, endpoint groups,
multiple local subnets, vendor drivers, etc.

There is still work needed (certificate support the most important,
followed by documentation and scale testing), but there is a solid (in my
bias and subjective opinion :) foundation in place for people to play with
this capability.

As I mentioned to Armando at the summit, it's time for me to move on to
other areas of Neutron, and as such, I'm stepping down as VPNaaS chair and
wrapping up work on the project over the next few weeks. I'll still try to
review VPNaaS commits as much as possible, and be available to advise in
this area.

Towards that end, I've updated the VPNaaS wiki page (
https://wiki.openstack.org/wiki/Meetings/VPNaaS) to list what I think are
outstanding work that can be done in this area, from important to wish
items.  Meetings have transitioned to on-demand, and future meetings can
either be done as an on-demand topic in the Neutron IRC meeting, or as an
on-demand special meeting.

I'll go through the VPNaaS bugs in Launchpad and comment on them, as to my
opinion of importance, priority, relevance, etc.

Regards,

PCM (pc_m)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status

[Kyle Mestery]

On Thu, Nov 12, 2015 at 9:56 AM, Paul Michali  wrote:

> Neutron community,
>
> During the past several releases, while leading the VPNaaS project, I've
> seen many great enhancements and features added to the VPNaaS project by
> the community, including support for StrongSwan, Libreswan, completion of
> the project split out, functional and rally tests, endpoint groups,
> multiple local subnets, vendor drivers, etc.
>
> There is still work needed (certificate support the most important,
> followed by documentation and scale testing), but there is a solid (in my
> bias and subjective opinion :) foundation in place for people to play with
> this capability.
>
> As I mentioned to Armando at the summit, it's time for me to move on to
> other areas of Neutron, and as such, I'm stepping down as VPNaaS chair and
> wrapping up work on the project over the next few weeks. I'll still try to
> review VPNaaS commits as much as possible, and be available to advise in
> this area.
>
> Towards that end, I've updated the VPNaaS wiki page (
> https://wiki.openstack.org/wiki/Meetings/VPNaaS) to list what I think are
> outstanding work that can be done in this area, from important to wish
> items.  Meetings have transitioned to on-demand, and future meetings can
> either be done as an on-demand topic in the Neutron IRC meeting, or as an
> on-demand special meeting.
>
> I'll go through the VPNaaS bugs in Launchpad and comment on them, as to my
> opinion of importance, priority, relevance, etc.
>
> Regards,
>
>
Thanks for all your hard work over the previous releases Paul! Looking
forward to what you'll be doing next in Neutron.

Thanks,
Kyle


> PCM (pc_m)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status

[Madhusudhan Kandadai]

Thanks Paul for leading over the previous releases. Looking forward to have
your guidance in neutron.

On Thu, Nov 12, 2015 at 8:48 PM, Kyle Mestery  wrote:

> On Thu, Nov 12, 2015 at 9:56 AM, Paul Michali  wrote:
>
>> Neutron community,
>>
>> During the past several releases, while leading the VPNaaS project, I've
>> seen many great enhancements and features added to the VPNaaS project by
>> the community, including support for StrongSwan, Libreswan, completion of
>> the project split out, functional and rally tests, endpoint groups,
>> multiple local subnets, vendor drivers, etc.
>>
>> There is still work needed (certificate support the most important,
>> followed by documentation and scale testing), but there is a solid (in my
>> bias and subjective opinion :) foundation in place for people to play with
>> this capability.
>>
>> As I mentioned to Armando at the summit, it's time for me to move on to
>> other areas of Neutron, and as such, I'm stepping down as VPNaaS chair and
>> wrapping up work on the project over the next few weeks. I'll still try to
>> review VPNaaS commits as much as possible, and be available to advise in
>> this area.
>>
>> Towards that end, I've updated the VPNaaS wiki page (
>> https://wiki.openstack.org/wiki/Meetings/VPNaaS) to list what I think
>> are outstanding work that can be done in this area, from important to wish
>> items.  Meetings have transitioned to on-demand, and future meetings can
>> either be done as an on-demand topic in the Neutron IRC meeting, or as an
>> on-demand special meeting.
>>
>> I'll go through the VPNaaS bugs in Launchpad and comment on them, as to
>> my opinion of importance, priority, relevance, etc.
>>
>> Regards,
>>
>>
> Thanks for all your hard work over the previous releases Paul! Looking
> forward to what you'll be doing next in Neutron.
>
> Thanks,
> Kyle
>
>
>> PCM (pc_m)
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status

[Edgar Magana]

Great Work Done Paul!

Thanks a lot!

Edgar




On 11/12/15, 9:35 AM, "Eichberger, German" <german.eichber...@hpe.com> wrote:

>Thanks for your hard work. Really appreciated!!
>
>Looking forward what you tackle next :-)
>
>All the best.
>German
>
>From: "Sridar Kandaswamy (skandasw)"
>Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>Date: Thursday, November 12, 2015 at 7:55 AM
>To: "OpenStack Development Mailing List (not for usage questions)"
>Subject: Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status
>
>Could not agree more. Thanks very much Paul.  And thanks also for always being 
>a sounding board for common things across FWaaS and VPNaaS.
>
>Thanks
>
>Sridar
>
>From: Madhusudhan Kandadai 
><madhusudhan.openst...@gmail.com<mailto:madhusudhan.openst...@gmail.com>>
>Reply-To: OpenStack List 
><openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
>Date: Thursday, November 12, 2015 at 7:28 AM
>To: OpenStack List 
><openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
>Subject: Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status
>
>Thanks Paul for leading over the previous releases. Looking forward to have 
>your guidance in neutron.
>
>On Thu, Nov 12, 2015 at 8:48 PM, Kyle Mestery 
><mest...@mestery.com<mailto:mest...@mestery.com>> wrote:
>On Thu, Nov 12, 2015 at 9:56 AM, Paul Michali 
><p...@michali.net<mailto:p...@michali.net>> wrote:
>Neutron community,
>
>During the past several releases, while leading the VPNaaS project, I've seen 
>many great enhancements and features added to the VPNaaS project by the 
>community, including support for StrongSwan, Libreswan, completion of the 
>project split out, functional and rally tests, endpoint groups, multiple local 
>subnets, vendor drivers, etc.
>
>There is still work needed (certificate support the most important, followed 
>by documentation and scale testing), but there is a solid (in my bias and 
>subjective opinion :) foundation in place for people to play with this 
>capability.
>
>As I mentioned to Armando at the summit, it's time for me to move on to other 
>areas of Neutron, and as such, I'm stepping down as VPNaaS chair and wrapping 
>up work on the project over the next few weeks. I'll still try to review 
>VPNaaS commits as much as possible, and be available to advise in this area.
>
>Towards that end, I've updated the VPNaaS wiki page 
>(https://wiki.openstack.org/wiki/Meetings/VPNaaS) to list what I think are 
>outstanding work that can be done in this area, from important to wish items.  
>Meetings have transitioned to on-demand, and future meetings can either be 
>done as an on-demand topic in the Neutron IRC meeting, or as an on-demand 
>special meeting.
>
>I'll go through the VPNaaS bugs in Launchpad and comment on them, as to my 
>opinion of importance, priority, relevance, etc.
>
>Regards,
>
>
>Thanks for all your hard work over the previous releases Paul! Looking forward 
>to what you'll be doing next in Neutron.
>
>Thanks,
>Kyle
>
>PCM (pc_m)
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: 
>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status

[Eichberger, German]

Thanks for your hard work. Really appreciated!!

Looking forward what you tackle next :-)

All the best.
German

From: "Sridar Kandaswamy (skandasw)"
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Thursday, November 12, 2015 at 7:55 AM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status

Could not agree more. Thanks very much Paul.  And thanks also for always being 
a sounding board for common things across FWaaS and VPNaaS.

Thanks

Sridar

From: Madhusudhan Kandadai 
<madhusudhan.openst...@gmail.com<mailto:madhusudhan.openst...@gmail.com>>
Reply-To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, November 12, 2015 at 7:28 AM
To: OpenStack List 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron][vpnaas] VPNaaS project status

Thanks Paul for leading over the previous releases. Looking forward to have 
your guidance in neutron.

On Thu, Nov 12, 2015 at 8:48 PM, Kyle Mestery 
<mest...@mestery.com<mailto:mest...@mestery.com>> wrote:
On Thu, Nov 12, 2015 at 9:56 AM, Paul Michali 
<p...@michali.net<mailto:p...@michali.net>> wrote:
Neutron community,

During the past several releases, while leading the VPNaaS project, I've seen 
many great enhancements and features added to the VPNaaS project by the 
community, including support for StrongSwan, Libreswan, completion of the 
project split out, functional and rally tests, endpoint groups, multiple local 
subnets, vendor drivers, etc.

There is still work needed (certificate support the most important, followed by 
documentation and scale testing), but there is a solid (in my bias and 
subjective opinion :) foundation in place for people to play with this 
capability.

As I mentioned to Armando at the summit, it's time for me to move on to other 
areas of Neutron, and as such, I'm stepping down as VPNaaS chair and wrapping 
up work on the project over the next few weeks. I'll still try to review VPNaaS 
commits as much as possible, and be available to advise in this area.

Towards that end, I've updated the VPNaaS wiki page 
(https://wiki.openstack.org/wiki/Meetings/VPNaaS) to list what I think are 
outstanding work that can be done in this area, from important to wish items.  
Meetings have transitioned to on-demand, and future meetings can either be done 
as an on-demand topic in the Neutron IRC meeting, or as an on-demand special 
meeting.

I'll go through the VPNaaS bugs in Launchpad and comment on them, as to my 
opinion of importance, priority, relevance, etc.

Regards,


Thanks for all your hard work over the previous releases Paul! Looking forward 
to what you'll be doing next in Neutron.

Thanks,
Kyle

PCM (pc_m)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] Need community guidance please...

[Germy Lure]

Hi,

Maybe I missed some key points. But why we introduced vpn-endpoint groups
here?

ipsec-site-connection for IPSec VPN only, gre-connection for GRE VPN
only, and mpls-connection for MPLS VPN only. You see, different
connections for different vpn types. Indeed, We can't reuse connection API.

Piece of the ref document(https://review.openstack.org/#/c/191944/) like
this:
allowing subnets (local) and CIDRs (peer) to be used for IPSec, but
routers, networks, and VLANs to be used for other VPN types (BGP, L2,
direct connection)

You see, different epg types for different vpn types. We can't reuse epg.

So, how we meet The third goal, is to do this in a manner that the code
can be reused for other flavors of VPN.?

Thanks.


On Tue, Aug 25, 2015 at 1:54 AM, Madhusudhan Kandadai 
madhusudhan.openst...@gmail.com wrote:

 My two cents..

 On Mon, Aug 24, 2015 at 8:48 AM, Jay Pipes jaypi...@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.


 I would prefer to have two commits with end-point groups as one and
 modification to support multiple local subnets as another. This will be
 easy to troubleshoot when in need.


 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).

 I suggest to be done as part of the existing version v2 API . As the api
 tests are in transition from neutron to neutron-vpnaas repo, we can modify
 the tests and submit as a one patch


 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.

 +1


 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.

 Right now, we are beefing up scenario tests for VPN, adding
 microversioning feature seems better option for me, but open to have
 reviews from community.


 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
 

Re: [openstack-dev] [neutron][vpnaas] Need community guidance please...

[Paul Michali]

See @PCM inline...


On Wed, Aug 26, 2015 at 4:44 AM Germy Lure germy.l...@gmail.com wrote:

 Hi,

 Maybe I missed some key points. But why we introduced vpn-endpoint groups
 here?


@PCM For the multiple local subnet capabilities for IPSec, the existing API
would need to be changed, so that we can specify 1+ local subnets, as part
of the VPN connection. This would have been the simplest approach for
updating IPSec connections, however, it makes it a point solution.

Other VPN flavors would also have similar endpoint specifications in
their connection APIs.

The approach that I'm advocating, is to extract out some of the commonality
between VPN flavors such that we can have some reuse.

Essentially, the idea is to break VPN into two parts. One is what is
connected and the other is how the connection is made.

For the former, the idea of an endpoint group is introduced. It provides a
collection of endpoints that can be identified by a type (e.g. subnet,
CIDR, network, vlan, ...) and an ID.

The latter would be VPN flavor specific, having all of the details needed
for that type of VPN connection and would reference the needed endpoint
group(s) by ID.

This separates the what from the how.



 ipsec-site-connection for IPSec VPN only, gre-connection for GRE VPN
 only, and mpls-connection for MPLS VPN only. You see, different
 connections for different vpn types. Indeed, We can't reuse connection API.


@PCM Correct. The how is VPN type specific. But we can have a common API
for the what.




 Piece of the ref document(https://review.openstack.org/#/c/191944/) like
 this:
 allowing subnets (local) and CIDRs (peer) to be used for IPSec, but
 routers, networks, and VLANs to be used for other VPN types (BGP, L2,
 direct connection)

 You see, different epg types for different vpn types. We can't reuse epg.


@PCM We're not reusing the endpoint group itself for different types of
VPN, we're reusing the API for different types of VPN. A common API that
holds a collection of endpoints of a specific type.

You can look at the code out for review, for a feel for the implementation
being worked on:  https://review.openstack.org/#/c/212692/3



 So, how we meet The third goal, is to do this in a manner that the code
 can be reused for other flavors of VPN.?


@PCM The code for the endpoint group API could be used for other VPN types.
Instead of them creating table fields (and the corresponding db logic) for
the endpoints of their connection, they can refer to the ID(s) from the
endpoint groups table, and can add additional validation based on the VPN
type.

FYI, I pushed up version 7 of the dev ref document yesterday.

Regards,

PCM


 Thanks.


 On Tue, Aug 25, 2015 at 1:54 AM, Madhusudhan Kandadai 
 madhusudhan.openst...@gmail.com wrote:

 My two cents..

 On Mon, Aug 24, 2015 at 8:48 AM, Jay Pipes jaypi...@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.


 I would prefer to have two commits with end-point groups as one and
 modification to support multiple local subnets as another. This will be
 easy to troubleshoot when in need.


 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).

 I suggest to be done as part of the existing version v2 API . As the api
 tests are in 

[openstack-dev] [neutron][vpnaas] Need community guidance please...

[Paul Michali]

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.

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?

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?

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?

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] Need community guidance please...

[Jay Pipes]

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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] Need community guidance please...

[Paul Michali]

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 jaypi...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [neutron][vpnaas] Need community guidance please...

[Madhusudhan Kandadai]

My two cents..

On Mon, Aug 24, 2015 at 8:48 AM, Jay Pipes jaypi...@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.


I would prefer to have two commits with end-point groups as one and
modification to support multiple local subnets as another. This will be
easy to troubleshoot when in need.


 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).

I suggest to be done as part of the existing version v2 API . As the api
tests are in transition from neutron to neutron-vpnaas repo, we can modify
the tests and submit as a one patch


 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.

+1


 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.

Right now, we are beefing up scenario tests for VPN, adding microversioning
feature seems better option for me, but open to have reviews from
community.


 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] VPNaaS and DVR compatibility

[Sergey Kolekonov]

Thanks for the link, Sean.

No, it doesn't seem to resolve the issue with FWaaS.
BTW, I have the following cluster:
- OpenStack Kilo (including *aaS) from the latest stable/kilo branches
- 2 networks nodes
- 1 compute node
Ubuntu 14.04, ML2+OVS, vxlan segmentation.
All nodes are KVM VMs.

So with the patch you provided I observe firewall rules both in
SNAT/qrouter namespaces on network nodes, but still no rules on the compute
node when instances have floating IPs assigned.
So traffic just goes without any restrictions.

On Mon, Aug 17, 2015 at 9:15 PM, Sean M. Collins s...@coreitpro.com wrote:

 On Mon, Aug 17, 2015 at 10:42:18AM EDT, Sergey Kolekonov wrote:
  BTW, the similar situation is with FWaaS [1]
 
  [1] https://bugs.launchpad.net/neutron/+bug/1485509

 Can you take a look at the following patch?

 https://review.openstack.org/203493

 If it resolves the issue I may need to re-think my -1, and we may need
 to restore it.

 --
 Sean M. Collins

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Regards,
Sergey Kolekonov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] VPNaaS and DVR compatibility

[Sergey Kolekonov]

BTW, the similar situation is with FWaaS [1]

[1] https://bugs.launchpad.net/neutron/+bug/1485509

On Fri, Aug 7, 2015 at 4:07 AM, shihanzhang ayshihanzh...@126.com wrote:

 I have same question, I have filed a bug on launchpad:
 https://bugs.launchpad.net/neutron/+bug/1476469,
 who can help to clarify it?
 Thanks,
 Hanzhang, shi





 At 2015-08-05 00:33:05, Sergey Kolekonov skoleko...@mirantis.com
 wrote:

 Hi,

 I'd like to clarify a situation around VPNaaS and DVR compatibility in
 Neutron.
 In non-DVR case VMs use a network node to access each other and external
 network.
 So with VPNaaS enabled we just have additional setup steps performed on
 network nodes to establish VPN connection between VMs.
 With DVR enabled two VMs from different networks (or even clouds) should
 still reach each other through network nodes, but if floating IPs are
 assigned, this doesn't work.
 So my question is: is it expected and if yes are there any plans to add
 full support for VPNaaS on DVR-enabled clusters?

 Thank you.
 --
 Regards,
 Sergey Kolekonov




 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Regards,
Sergey Kolekonov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] VPNaaS and DVR compatibility

[Sean M. Collins]

On Mon, Aug 17, 2015 at 10:42:18AM EDT, Sergey Kolekonov wrote:
 BTW, the similar situation is with FWaaS [1]
 
 [1] https://bugs.launchpad.net/neutron/+bug/1485509

Can you take a look at the following patch?

https://review.openstack.org/203493

If it resolves the issue I may need to re-think my -1, and we may need
to restore it.

-- 
Sean M. Collins

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] VPNaaS and DVR compatibility

[shihanzhang]

I have same question, I have filed a bug on launchpad: 
https://bugs.launchpad.net/neutron/+bug/1476469, 
who can help to clarify it?
Thanks,
Hanzhang, shi 






At 2015-08-05 00:33:05, Sergey Kolekonov skoleko...@mirantis.com wrote:

Hi,


I'd like to clarify a situation around VPNaaS and DVR compatibility in Neutron.
In non-DVR case VMs use a network node to access each other and external 
network.
So with VPNaaS enabled we just have additional setup steps performed on network 
nodes to establish VPN connection between VMs.
With DVR enabled two VMs from different networks (or even clouds) should still 
reach each other through network nodes, but if floating IPs are assigned, this 
doesn't work.
So my question is: is it expected and if yes are there any plans to add full 
support for VPNaaS on DVR-enabled clusters?


Thank you.
--

Regards,
Sergey Kolekonov__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] VPNaaS and DVR compatibility

[Sergey Kolekonov]

Hi,

I'd like to clarify a situation around VPNaaS and DVR compatibility in
Neutron.
In non-DVR case VMs use a network node to access each other and external
network.
So with VPNaaS enabled we just have additional setup steps performed on
network nodes to establish VPN connection between VMs.
With DVR enabled two VMs from different networks (or even clouds) should
still reach each other through network nodes, but if floating IPs are
assigned, this doesn't work.
So my question is: is it expected and if yes are there any plans to add
full support for VPNaaS on DVR-enabled clusters?

Thank you.
-- 
Regards,
Sergey Kolekonov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][vpnaas] Next IRC meeting - Tuesday, August 4th.

[Paul Michali]

Will hold another meeting tomorrow. If you have items for the agenda,
please update the Wiki.

Regards,

Paul Michali (pc_m)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][vpnaas] No VPNaaS IRC meeting Tuesday, July 27th.

[Paul Michali]

I'm on vacation tomorrow (yeah!), and there wasn't much new to discuss, so
I was planning on canceling the meeting this week. If you have something
pressing and want to host the meeting, let everyone know, by updating the
agenda and responding to this message. Otherwise you can use neutron IRC
channel or ML to discuss items.

Regards,

Paul Michali (pc_m)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][vpnaas] No VPNaaS weekly IRC meeting next week (June 23rd)

[Sridhar Ramaswamy]

As some of us are attending Neutron mid-cycle we are skipping the VPNaaS
weekly IRC meeting for next week Tuesday June 23rd. The meeting will resume
the week after.

As usual please update agenda on the wiki page:
https://wiki.openstack.org/wiki/Meetings/VPNaaS before the meeting.

See you all on Tuesday June 30th!
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron[[vpnaas] Next meeting June 16th at 1600 UTC

[Paul Michali]

Planning on weekly meetings for a while, since this are several things to
discuss. See the agenda on the wiki page:
https://wiki.openstack.org/wiki/Meetings/VPNaaS

There are a bunch of questions to discuss.

See you Tuesday!
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][vpnaas][barbican] What types of authentication to support?

[Paul Michali]

Hi,

There is a Request for Feature Enhancement [1] to support authentication
certifications for VPNaaS IPSec site to site connections, by using
Barbican, in a manner similar to what was done for LBaaS listeners.

Currently, VPNaaS only supports pre-shared keys for authentication, but the
reference StrongSwan implementation of VPN supports several types of
authentication. [2]

Looking at IPsec site-to-site connections, there are examples [3] for PSK
and X.509 certificates.

Should we just do X.509 certificates for now?
Are there other methods that we should support?
Can Barbican support such methods?

The plan is to support other VPN types in the future (e.g. DM VPN), so we
want to make sure this will be extendable.

Suggestions/Comments/Concerns?

Thanks!

Paul Michali (pc_m)


[1] https://bugs.launchpad.net/neutron/+bug/1459427
[2] https://wiki.strongswan.org/projects/strongswan/wiki/IpsecSecrets
[3] https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2Examples (see
site-2-site)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][vpnaas] Team meeting Tuesday, June 9th @ 1600 UTC

[Paul Michali]

Will hold weekly meetings to discuss VPNaaS topics.  Please check out the
meeting page for proposed agenda, time, and IRC channel (
https://wiki.openstack.org/wiki/Meetings/VPNaaS).

Also, there is an Etherpad for VPN info, where we hope to collect use-cases
and workflow information to (hopefully) create a shared understanding of
the various VPN proposals. Please contribute to the page (
https://etherpad.openstack.org/p/vpn-flavors).

Regards,

PCM
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][vpnaas] Etherpad for Friday Neutron Contributors' session

[Paul Michali]

I created an etherpad to help focus the discussion. We'll try to form a
collective in the morning and start talking through these items.

https://etherpad.openstack.org/p/YVR-neutron-vpnaas

Regards,

Paul Michali (pc_m)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][vpnaas] Supporting multiple local subnets for VPN connections

[Mathieu Rohon]

However after thinking about it more deeply, option A might be suitable if
the vpn-service becomes more generic, and usable by other vpn objects
(ipsec-site-connection, bgpvpn-connection).
I would become an object that the tenant can update to attach CIDR it wants
to export in its VPN.
To transform the vpn-service object in a generic vpn description, we need
to remove the mandatory ROUTER attribute, so that we can use it for l2vpn
either.

Hope we can discuss that on friday morning

On Wed, May 20, 2015 at 5:12 PM, Paul Michali p...@michali.net wrote:

 Hi Mathieu,

 In Kilo, VPNaaS APIs were no longer marked as experimental. We need to
 understand the implication of changing the API. I'm not sure how much
 VPNaaS is being used by OpenStack users at this time, either.  I'm hoping
 to seek out answers to this at the summit.

 If anyone has suggestions, comments, information on this, please chime in. 
 I'll
 likely make a BP for multiple subnets, when I get back from the summit.

 Lastly, I'm planning on trying to get people interested in VPN to meet on
 Friday morning at the summit to discuss all the VPN topics that have been
 coming up.

 Regards,

 Paul Michali (pc_m)

 On Wed, May 20, 2015 at 7:54 AM Mathieu Rohon mathieu.ro...@gmail.com
 wrote:

 Hi paul,

 this is also something that we would like to introduce for BGP/MPLS VPNs
 [2].

 We choose to allow tenants to attach existing networks ( it might evolve
 to subnets) to bgpvpn-connection objects, by updating the bgpvpn-connection
 object, which is the equivalent of the ipsec-site-connection object.

 So I think that Option B is suitable here.

 Concerning backward compatibility, I think VPNaas is still considered as
 experimental, am I wrong? Do you have to provide backward compatbility in
 this case?

 Mathieu

 [2] https://review.openstack.org/#/c/177740/

 On Wed, May 13, 2015 at 8:59 PM, Paul Michali p...@michali.net wrote:

 Hi,

 There has been, over the years, some mention about having VPN IPSec
 connections supporting multiple CIDRs for local (left side) private
 networks, in addition to the current support for multiple peer CIDRs (right
 side).

 I'm raising the question again with these goals:

 1) Determine if the reference IPSec implementations support this
 capability
 2) Determine if there is a community desire to enhance VPN to support
 this capability (for all VPN types)
 3) See what would be the best way to handle this (changes to API and
 model)
 4) Identify any consequences of making this change.

 Note: My assumption here is something that could be used for any type of
 VPN connection - current IPSec, future BGP/MPLS VPN, DM VPN, etc.

 Here is some information that was gathered from people on the VPN team
 so far. Please correct any inaccuracies and comment on the items...

 (1) It looks like OpenSwan and Libreswan will support this capability.
 StrongSwan will support this with IKEv2. For IKEv1, a Cisco Unity plugin
 extensions is needed. I'm not sure what that implies [1].

 (2) Do we, as a community, want to enhance VPNaaS to provide this
 capability of N:M subnets for VPN implementations? Putting on my vendor
 hat, I can see cases where customers want to be able to only create one
 connection and reference multiple subnets on each end. Is there a desire to
 do this and bake it into the reference implementation (thus making it
 available for other implementations)?

 (3) Currently, the vpn service API includes the router and subnet ID.
 The IPSec connection command includes the peer CIDR(s). For reference, here
 are two of the APIs:

 usage: neutron vpn-service-create [-h] [-f
 {html,json,shell,table,value,yaml}]
   [-c COLUMN] [--max-width integer]
   [--prefix PREFIX]
   [--request-format {json,xml}]
   [--tenant-id TENANT_ID]
 [--admin-state-down]
   [--name NAME] [--description
 DESCRIPTION]
   ROUTER SUBNET

 usage: neutron ipsec-site-connection-create [-h]
 [-f
 {html,json,shell,table,value,yaml}]
 [-c COLUMN]
 [--max-width integer]
 [--prefix PREFIX]
 [--request-format {json,xml}]
 [--tenant-id TENANT_ID]
 [--admin-state-down] [--name
 NAME]
 [--description DESCRIPTION]
 [--mtu MTU]
 [--initiator
 {bi-directional,response-only}]
 [--dpd
 action=ACTION,interval=INTERVAL,timeout=TIMEOUT]
 --vpnservice-id 

Re: [openstack-dev] [neutron][vpnaas] Supporting multiple local subnets for VPN connections

[loy wolfe]

Extra subnets is suitable for attribute of IKE connections, but not
the whole VPN service. Because customer usually want fine-grained
control of which local subnet could communicate to remote subnets.

On Wed, May 20, 2015 at 11:21 PM, Mathieu Rohon mathieu.ro...@gmail.com wrote:
 However after thinking about it more deeply, option A might be suitable if
 the vpn-service becomes more generic, and usable by other vpn objects
 (ipsec-site-connection, bgpvpn-connection).
 I would become an object that the tenant can update to attach CIDR it wants
 to export in its VPN.
 To transform the vpn-service object in a generic vpn description, we need to
 remove the mandatory ROUTER attribute, so that we can use it for l2vpn
 either.

 Hope we can discuss that on friday morning

 On Wed, May 20, 2015 at 5:12 PM, Paul Michali p...@michali.net wrote:

 Hi Mathieu,

 In Kilo, VPNaaS APIs were no longer marked as experimental. We need to
 understand the implication of changing the API. I'm not sure how much VPNaaS
 is being used by OpenStack users at this time, either.  I'm hoping to seek
 out answers to this at the summit.

 If anyone has suggestions, comments, information on this, please chime in.
 I'll likely make a BP for multiple subnets, when I get back from the summit.

 Lastly, I'm planning on trying to get people interested in VPN to meet on
 Friday morning at the summit to discuss all the VPN topics that have been
 coming up.

 Regards,

 Paul Michali (pc_m)

 On Wed, May 20, 2015 at 7:54 AM Mathieu Rohon mathieu.ro...@gmail.com
 wrote:

 Hi paul,

 this is also something that we would like to introduce for BGP/MPLS VPNs
 [2].

 We choose to allow tenants to attach existing networks ( it might evolve
 to subnets) to bgpvpn-connection objects, by updating the bgpvpn-connection
 object, which is the equivalent of the ipsec-site-connection object.

 So I think that Option B is suitable here.

 Concerning backward compatibility, I think VPNaas is still considered as
 experimental, am I wrong? Do you have to provide backward compatbility in
 this case?

 Mathieu

 [2] https://review.openstack.org/#/c/177740/

 On Wed, May 13, 2015 at 8:59 PM, Paul Michali p...@michali.net wrote:

 Hi,

 There has been, over the years, some mention about having VPN IPSec
 connections supporting multiple CIDRs for local (left side) private
 networks, in addition to the current support for multiple peer CIDRs (right
 side).

 I'm raising the question again with these goals:

 1) Determine if the reference IPSec implementations support this
 capability
 2) Determine if there is a community desire to enhance VPN to support
 this capability (for all VPN types)
 3) See what would be the best way to handle this (changes to API and
 model)
 4) Identify any consequences of making this change.

 Note: My assumption here is something that could be used for any type of
 VPN connection - current IPSec, future BGP/MPLS VPN, DM VPN, etc.

 Here is some information that was gathered from people on the VPN team
 so far. Please correct any inaccuracies and comment on the items...

 (1) It looks like OpenSwan and Libreswan will support this capability.
 StrongSwan will support this with IKEv2. For IKEv1, a Cisco Unity plugin
 extensions is needed. I'm not sure what that implies [1].

 (2) Do we, as a community, want to enhance VPNaaS to provide this
 capability of N:M subnets for VPN implementations? Putting on my vendor 
 hat,
 I can see cases where customers want to be able to only create one
 connection and reference multiple subnets on each end. Is there a desire to
 do this and bake it into the reference implementation (thus making it
 available for other implementations)?

 (3) Currently, the vpn service API includes the router and subnet ID.
 The IPSec connection command includes the peer CIDR(s). For reference, here
 are two of the APIs:

 usage: neutron vpn-service-create [-h] [-f
 {html,json,shell,table,value,yaml}]
   [-c COLUMN] [--max-width integer]
   [--prefix PREFIX]
   [--request-format {json,xml}]
   [--tenant-id TENANT_ID]
 [--admin-state-down]
   [--name NAME] [--description
 DESCRIPTION]
   ROUTER SUBNET

 usage: neutron ipsec-site-connection-create [-h]
 [-f
 {html,json,shell,table,value,yaml}]
 [-c COLUMN]
 [--max-width integer]
 [--prefix PREFIX]
 [--request-format
 {json,xml}]
 [--tenant-id TENANT_ID]
 [--admin-state-down] [--name
 NAME]
 [--description DESCRIPTION]
 

Re: [openstack-dev] [neutron][vpnaas] Supporting multiple local subnets for VPN connections

[Paul Michali]

Loy, yeah, that is why I was thinking option B, as user has flexibility to
specify what subnet(s) are used for a connection.  Ideally, we want to
consider different VPN connection types.

Regards,
Paul Michali (pc_m)


On Wed, May 20, 2015 at 5:34 PM loy wolfe loywo...@gmail.com wrote:

 Extra subnets is suitable for attribute of IKE connections, but not
 the whole VPN service. Because customer usually want fine-grained
 control of which local subnet could communicate to remote subnets.

 On Wed, May 20, 2015 at 11:21 PM, Mathieu Rohon mathieu.ro...@gmail.com
 wrote:
  However after thinking about it more deeply, option A might be suitable
 if
  the vpn-service becomes more generic, and usable by other vpn objects
  (ipsec-site-connection, bgpvpn-connection).
  I would become an object that the tenant can update to attach CIDR it
 wants
  to export in its VPN.
  To transform the vpn-service object in a generic vpn description, we
 need to
  remove the mandatory ROUTER attribute, so that we can use it for l2vpn
  either.
 
  Hope we can discuss that on friday morning
 
  On Wed, May 20, 2015 at 5:12 PM, Paul Michali p...@michali.net wrote:
 
  Hi Mathieu,
 
  In Kilo, VPNaaS APIs were no longer marked as experimental. We need to
  understand the implication of changing the API. I'm not sure how much
 VPNaaS
  is being used by OpenStack users at this time, either.  I'm hoping to
 seek
  out answers to this at the summit.
 
  If anyone has suggestions, comments, information on this, please chime
 in.
  I'll likely make a BP for multiple subnets, when I get back from the
 summit.
 
  Lastly, I'm planning on trying to get people interested in VPN to meet
 on
  Friday morning at the summit to discuss all the VPN topics that have
 been
  coming up.
 
  Regards,
 
  Paul Michali (pc_m)
 
  On Wed, May 20, 2015 at 7:54 AM Mathieu Rohon mathieu.ro...@gmail.com
  wrote:
 
  Hi paul,
 
  this is also something that we would like to introduce for BGP/MPLS
 VPNs
  [2].
 
  We choose to allow tenants to attach existing networks ( it might
 evolve
  to subnets) to bgpvpn-connection objects, by updating the
 bgpvpn-connection
  object, which is the equivalent of the ipsec-site-connection object.
 
  So I think that Option B is suitable here.
 
  Concerning backward compatibility, I think VPNaas is still considered
 as
  experimental, am I wrong? Do you have to provide backward compatbility
 in
  this case?
 
  Mathieu
 
  [2] https://review.openstack.org/#/c/177740/
 
  On Wed, May 13, 2015 at 8:59 PM, Paul Michali p...@michali.net wrote:
 
  Hi,
 
  There has been, over the years, some mention about having VPN IPSec
  connections supporting multiple CIDRs for local (left side) private
  networks, in addition to the current support for multiple peer CIDRs
 (right
  side).
 
  I'm raising the question again with these goals:
 
  1) Determine if the reference IPSec implementations support this
  capability
  2) Determine if there is a community desire to enhance VPN to support
  this capability (for all VPN types)
  3) See what would be the best way to handle this (changes to API and
  model)
  4) Identify any consequences of making this change.
 
  Note: My assumption here is something that could be used for any type
 of
  VPN connection - current IPSec, future BGP/MPLS VPN, DM VPN, etc.
 
  Here is some information that was gathered from people on the VPN team
  so far. Please correct any inaccuracies and comment on the items...
 
  (1) It looks like OpenSwan and Libreswan will support this capability.
  StrongSwan will support this with IKEv2. For IKEv1, a Cisco Unity
 plugin
  extensions is needed. I'm not sure what that implies [1].
 
  (2) Do we, as a community, want to enhance VPNaaS to provide this
  capability of N:M subnets for VPN implementations? Putting on my
 vendor hat,
  I can see cases where customers want to be able to only create one
  connection and reference multiple subnets on each end. Is there a
 desire to
  do this and bake it into the reference implementation (thus making it
  available for other implementations)?
 
  (3) Currently, the vpn service API includes the router and subnet ID.
  The IPSec connection command includes the peer CIDR(s). For
 reference, here
  are two of the APIs:
 
  usage: neutron vpn-service-create [-h] [-f
  {html,json,shell,table,value,yaml}]
[-c COLUMN] [--max-width integer]
[--prefix PREFIX]
[--request-format {json,xml}]
[--tenant-id TENANT_ID]
  [--admin-state-down]
[--name NAME] [--description
  DESCRIPTION]
ROUTER SUBNET
 
  usage: neutron ipsec-site-connection-create [-h]
  [-f
  {html,json,shell,table,value,yaml}]
  [-c COLUMN]
   

Re: [openstack-dev] [neutron][vpnaas] Supporting multiple local subnets for VPN connections

[Paul Michali]

Hi Mathieu,

In Kilo, VPNaaS APIs were no longer marked as experimental. We need to
understand the implication of changing the API. I'm not sure how much
VPNaaS is being used by OpenStack users at this time, either.  I'm hoping
to seek out answers to this at the summit.

If anyone has suggestions, comments, information on this, please chime in. I'll
likely make a BP for multiple subnets, when I get back from the summit.

Lastly, I'm planning on trying to get people interested in VPN to meet on
Friday morning at the summit to discuss all the VPN topics that have been
coming up.

Regards,

Paul Michali (pc_m)

On Wed, May 20, 2015 at 7:54 AM Mathieu Rohon mathieu.ro...@gmail.com
wrote:

 Hi paul,

 this is also something that we would like to introduce for BGP/MPLS VPNs
 [2].

 We choose to allow tenants to attach existing networks ( it might evolve
 to subnets) to bgpvpn-connection objects, by updating the bgpvpn-connection
 object, which is the equivalent of the ipsec-site-connection object.

 So I think that Option B is suitable here.

 Concerning backward compatibility, I think VPNaas is still considered as
 experimental, am I wrong? Do you have to provide backward compatbility in
 this case?

 Mathieu

 [2] https://review.openstack.org/#/c/177740/

 On Wed, May 13, 2015 at 8:59 PM, Paul Michali p...@michali.net wrote:

 Hi,

 There has been, over the years, some mention about having VPN IPSec
 connections supporting multiple CIDRs for local (left side) private
 networks, in addition to the current support for multiple peer CIDRs (right
 side).

 I'm raising the question again with these goals:

 1) Determine if the reference IPSec implementations support this
 capability
 2) Determine if there is a community desire to enhance VPN to support
 this capability (for all VPN types)
 3) See what would be the best way to handle this (changes to API and
 model)
 4) Identify any consequences of making this change.

 Note: My assumption here is something that could be used for any type of
 VPN connection - current IPSec, future BGP/MPLS VPN, DM VPN, etc.

 Here is some information that was gathered from people on the VPN team so
 far. Please correct any inaccuracies and comment on the items...

 (1) It looks like OpenSwan and Libreswan will support this capability.
 StrongSwan will support this with IKEv2. For IKEv1, a Cisco Unity plugin
 extensions is needed. I'm not sure what that implies [1].

 (2) Do we, as a community, want to enhance VPNaaS to provide this
 capability of N:M subnets for VPN implementations? Putting on my vendor
 hat, I can see cases where customers want to be able to only create one
 connection and reference multiple subnets on each end. Is there a desire to
 do this and bake it into the reference implementation (thus making it
 available for other implementations)?

 (3) Currently, the vpn service API includes the router and subnet ID. The
 IPSec connection command includes the peer CIDR(s). For reference, here are
 two of the APIs:

 usage: neutron vpn-service-create [-h] [-f
 {html,json,shell,table,value,yaml}]
   [-c COLUMN] [--max-width integer]
   [--prefix PREFIX]
   [--request-format {json,xml}]
   [--tenant-id TENANT_ID]
 [--admin-state-down]
   [--name NAME] [--description
 DESCRIPTION]
   ROUTER SUBNET

 usage: neutron ipsec-site-connection-create [-h]
 [-f
 {html,json,shell,table,value,yaml}]
 [-c COLUMN]
 [--max-width integer]
 [--prefix PREFIX]
 [--request-format {json,xml}]
 [--tenant-id TENANT_ID]
 [--admin-state-down] [--name
 NAME]
 [--description DESCRIPTION]
 [--mtu MTU]
 [--initiator
 {bi-directional,response-only}]
 [--dpd
 action=ACTION,interval=INTERVAL,timeout=TIMEOUT]
 --vpnservice-id VPNSERVICE
 --ikepolicy-id IKEPOLICY
 --ipsecpolicy-id IPSECPOLICY
 --peer-address PEER_ADDRESS
 --peer-id PEER_ID --peer-cidr
 PEER_CIDRS --psk PSK

 I could envision several ways to handle this (feel free to add more).
 Here are some thoughts on this...

 A) Allow multiple subnets for the vpn service API. The implication here
 is that all types of VPN 

Re: [openstack-dev] [neutron][vpnaas] Supporting multiple local subnets for VPN connections

[Mathieu Rohon]

Hi paul,

this is also something that we would like to introduce for BGP/MPLS VPNs
[2].

We choose to allow tenants to attach existing networks ( it might evolve to
subnets) to bgpvpn-connection objects, by updating the bgpvpn-connection
object, which is the equivalent of the ipsec-site-connection object.

So I think that Option B is suitable here.

Concerning backward compatibility, I think VPNaas is still considered as
experimental, am I wrong? Do you have to provide backward compatbility in
this case?

Mathieu

[2] https://review.openstack.org/#/c/177740/

On Wed, May 13, 2015 at 8:59 PM, Paul Michali p...@michali.net wrote:

 Hi,

 There has been, over the years, some mention about having VPN IPSec
 connections supporting multiple CIDRs for local (left side) private
 networks, in addition to the current support for multiple peer CIDRs (right
 side).

 I'm raising the question again with these goals:

 1) Determine if the reference IPSec implementations support this capability
 2) Determine if there is a community desire to enhance VPN to support this
 capability (for all VPN types)
 3) See what would be the best way to handle this (changes to API and model)
 4) Identify any consequences of making this change.

 Note: My assumption here is something that could be used for any type of
 VPN connection - current IPSec, future BGP/MPLS VPN, DM VPN, etc.

 Here is some information that was gathered from people on the VPN team so
 far. Please correct any inaccuracies and comment on the items...

 (1) It looks like OpenSwan and Libreswan will support this capability.
 StrongSwan will support this with IKEv2. For IKEv1, a Cisco Unity plugin
 extensions is needed. I'm not sure what that implies [1].

 (2) Do we, as a community, want to enhance VPNaaS to provide this
 capability of N:M subnets for VPN implementations? Putting on my vendor
 hat, I can see cases where customers want to be able to only create one
 connection and reference multiple subnets on each end. Is there a desire to
 do this and bake it into the reference implementation (thus making it
 available for other implementations)?

 (3) Currently, the vpn service API includes the router and subnet ID. The
 IPSec connection command includes the peer CIDR(s). For reference, here are
 two of the APIs:

 usage: neutron vpn-service-create [-h] [-f
 {html,json,shell,table,value,yaml}]
   [-c COLUMN] [--max-width integer]
   [--prefix PREFIX]
   [--request-format {json,xml}]
   [--tenant-id TENANT_ID]
 [--admin-state-down]
   [--name NAME] [--description DESCRIPTION]
   ROUTER SUBNET

 usage: neutron ipsec-site-connection-create [-h]
 [-f
 {html,json,shell,table,value,yaml}]
 [-c COLUMN]
 [--max-width integer]
 [--prefix PREFIX]
 [--request-format {json,xml}]
 [--tenant-id TENANT_ID]
 [--admin-state-down] [--name
 NAME]
 [--description DESCRIPTION]
 [--mtu MTU]
 [--initiator
 {bi-directional,response-only}]
 [--dpd
 action=ACTION,interval=INTERVAL,timeout=TIMEOUT]
 --vpnservice-id VPNSERVICE
 --ikepolicy-id IKEPOLICY
 --ipsecpolicy-id IPSECPOLICY
 --peer-address PEER_ADDRESS
 --peer-id PEER_ID --peer-cidr
 PEER_CIDRS --psk PSK

 I could envision several ways to handle this (feel free to add more). Here
 are some thoughts on this...

 A) Allow multiple subnets for the vpn service API. The implication here is
 that all types of VPN connections would be able to support multiple subnets.

 vpn-service-create ... ROUTER LOCAL_CIDRS

 Issue here is that, if a change is desired on a subnet for a specific
 connection, the service must be updated.

 Today, I think one has to delete the connections from the service, and
 then can update the service. Would need to have ability to update a
 service, but still there is concern about the effect on other connections.
 It just doesn't seem like the right thing to me.


 B) Remove the subnet from the vpn service API and add it to the IPSec
 connection API, like is done with peer CIDR selection, allowing multiples.
 Different VPN types could do the same thing for their connection API.