Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in object model refactor blueprint

[Bo Lin]

Hi Brandon and Stephen, 
Really thanks for your responses and i got to know it. 

Thanks! 
---Bo 
- Original Message -

From: "Brandon Logan"  
To: "OpenStack Development Mailing List (not for usage questions)" 
 
Sent: Friday, May 30, 2014 1:17:57 PM 
Subject: Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in object 
model refactor blueprint 

Hi Bo, 
Sorry, I forgot to respond but yes what Stephen said lol :) 

From: Stephen Balukoff [sbaluk...@bluebox.net] 
Sent: Thursday, May 29, 2014 10:42 PM 
To: OpenStack Development Mailing List (not for usage questions) 
Subject: Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in object 
model refactor blueprint 


Hi Bo-- 

Haproxy is able to have IPv4 front-ends with IPv6 back-ends (and visa versa) 
because it actually initiates a separate TCP connection between the front end 
client and the back-end server. The front-end thinks haproxy is the server, and 
the back-end thinks haproxy is the client. In practice, therefore, its totally 
possible to have an IPv6 front-end and IPv4 back-end with haproxy (for both 
http and generic TCP service types). 

I think this is similarly true for vendor appliances that are capable of doing 
IPv6, and are also initiating new TCP connections from the appliance to the 
back-end. 

Obviously, the above won't work if your load balancer implementation is doing 
something "transparent" on the network layer like LVM load balancing. 

Stephen 



On Wed, May 28, 2014 at 9:14 PM, Bo Lin < l...@vmware.com > wrote: 



Hi Brandon, 
I have one question. If we support LoadBalancer to Listener relationship M:N, 
then one listener with IPV4 service members backend may be shared by a 
loadbalancer instance with IPV6 forntend. Does it mean we also need to provide 
IPV6 - IPV4 port forwarding functions in LBaaS services products? Does iptables 
or most LBaaS services products such as haproxy or so on provide such function? 
Or I am just wrong in some technique details on these LBaaS products. 

Thanks! 

From: "Vijay B" < os.v...@gmail.com > 

To: "OpenStack Development Mailing List (not for usage questions)" < 
openstack-dev@lists.openstack.org > 
Sent: Thursday, May 29, 2014 6:18:42 AM 

Subject: Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in object 
model refactor blueprint 

Hi Brandon! 

Please see inline.. 




On Wed, May 28, 2014 at 12:01 PM, Brandon Logan < brandon.lo...@rackspace.com > 
wrote: 


Hi Vijay, 

On Tue, 2014-05-27 at 16:27 -0700, Vijay B wrote: 
> Hi Brandon, 
> 
> 
> The current reviews of the schema itself are absolutely valid and 
> necessary, and must go on. However, the place of implementation of 
> this schema needs to be clarified. Rather than make any changes 
> whatsoever to the existing neutron db schema for LBaaS, this new db 
> schema outlined needs to be implemented for a separate LBaaS core 
> service. 
> 
Are you suggesting a separate lbaas database from the neutron database? 
If not, then I could use some clarification. If so, I'd advocate against 
that right now because there's just too many things that would need to 
be changed. Later, when LBaaS becomes its own service then yeah that 
will need to happen. 




v> Ok, so as I understand it, in this scheme, there is no new schema or db, 
there will be a new set of tables resident in neutron_db schema itself, 
alongside legacy lbaas tables. Let's consider a rough view of the 
implementation. 

Layer 1 - We'll have a new lbaas v3.0 api in neutron, with the current lbaas 
service plugin having to support it in addition to the legacy lbaas extensions 
that it already supports. We'll need to put in new code anyway that will 
process the v3.0 lbaas api no matter what our approach is. 
Layer 2 - Management code that will take care of updating the db with entities 
in pending_create, then invoking the right provider driver, choosing/scheduling 
the plugin drivers or the agent drivers, invoking them, getting the results, 
and updating the db. 
Layer 3 - The drivers themselves (either plugin drivers (like the HAProxy 
namespace driver/Netscaler) or plugin drivers + agent drivers). 

While having the new tables sit alongside the legacy tables is one way to 
implement the changes, I don't see how this approach leads to a lesser amount 
of changes overall. Layer 2 above will be the major place where changes can be 
complicated. Also, it will be confusing to have two sets of lbaas tables in the 
same schema. 

I don't want a separate lbaas database under neutron, and neither do I want it 
within neutron. I'm not suggesting that we create a db schema alone, I'm saying 
we must build it with the new LBaaS service (just like neutron itself when it 
got created). If we don't do this now, we'll end up reimplementing the logic 
implemented in neutron for the new lba

Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in object model refactor blueprint

[Bo Lin]

Hi Brandon, 
I have one question. If we support LoadBalancer to Listener relationship M:N, 
then one listener with IPV4 service members backend may be shared by a 
loadbalancer instance with IPV6 forntend. Does it mean we also need to provide 
IPV6 - IPV4 port forwarding functions in LBaaS services products? Does iptables 
or most LBaaS services products such as haproxy or so on provide such function? 
Or I am just wrong in some technique details on these LBaaS products. 

Thanks! 
- Original Message -

From: "Vijay B"  
To: "OpenStack Development Mailing List (not for usage questions)" 
 
Sent: Thursday, May 29, 2014 6:18:42 AM 
Subject: Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in object 
model refactor blueprint 

Hi Brandon! 

Please see inline.. 




On Wed, May 28, 2014 at 12:01 PM, Brandon Logan < brandon.lo...@rackspace.com > 
wrote: 


Hi Vijay, 

On Tue, 2014-05-27 at 16:27 -0700, Vijay B wrote: 
> Hi Brandon, 
> 
> 
> The current reviews of the schema itself are absolutely valid and 
> necessary, and must go on. However, the place of implementation of 
> this schema needs to be clarified. Rather than make any changes 
> whatsoever to the existing neutron db schema for LBaaS, this new db 
> schema outlined needs to be implemented for a separate LBaaS core 
> service. 
> 
Are you suggesting a separate lbaas database from the neutron database? 
If not, then I could use some clarification. If so, I'd advocate against 
that right now because there's just too many things that would need to 
be changed. Later, when LBaaS becomes its own service then yeah that 
will need to happen. 




v> Ok, so as I understand it, in this scheme, there is no new schema or db, 
there will be a new set of tables resident in neutron_db schema itself, 
alongside legacy lbaas tables. Let's consider a rough view of the 
implementation. 

Layer 1 - We'll have a new lbaas v3.0 api in neutron, with the current lbaas 
service plugin having to support it in addition to the legacy lbaas extensions 
that it already supports. We'll need to put in new code anyway that will 
process the v3.0 lbaas api no matter what our approach is. 
Layer 2 - Management code that will take care of updating the db with entities 
in pending_create, then invoking the right provider driver, choosing/scheduling 
the plugin drivers or the agent drivers, invoking them, getting the results, 
and updating the db. 
Layer 3 - The drivers themselves (either plugin drivers (like the HAProxy 
namespace driver/Netscaler) or plugin drivers + agent drivers). 

While having the new tables sit alongside the legacy tables is one way to 
implement the changes, I don't see how this approach leads to a lesser amount 
of changes overall. Layer 2 above will be the major place where changes can be 
complicated. Also, it will be confusing to have two sets of lbaas tables in the 
same schema. 

I don't want a separate lbaas database under neutron, and neither do I want it 
within neutron. I'm not suggesting that we create a db schema alone, I'm saying 
we must build it with the new LBaaS service (just like neutron itself when it 
got created). If we don't do this now, we'll end up reimplementing the logic 
implemented in neutron for the new lbaas v3.0 API all over again for the new 
core LBaaS service. We'd rather do it in the new one in one effort. 

I could be missing some constraints that drive taking the former approach - 
please help me understand those - I don't want to be discounting any one 
approach without thorough consideration. Right now, it looks to me like this 
approach is being taken only to accommodate the HAProxy namespace driver. 
Really that is the only driver which seems to be very intertwined with neutron 
in the way it uses namespaces. 





> 
> What we should be providing in neutron is a switch (a global conf) 
> that can be set to instruct neutron to do one of two things: 
> 
> 
> 1. Use the existing neutron LBaaS API, with the backend being the 
> existing neutron LBaaS db schema. This is the status quo. 
> 2. Use the existing neutron LBaaS API, with the backend being the new 
> LBaaS service. This will invoke calls not to neutron's current LBaaS 
> code at all, rather, it will call into a new set of proxy "backend" 
> code in neutron that will translate the older LBaaS API calls into the 
> newer REST calls serviced by the new LBaaS service, which will write 
> down these details accordingly in its new db schema. As long as the 
> request and response objects to legacy neutron LBaaS calls are 
> preserved as is, there should be no issues. Writing unit tests should 
> also be comparatively more straightforward, and old functional tests 
> can be retained, and newer ones will not clash with legacy code. 
> Legacy code itself will work, having not been touched at all. The 
> blueprint for the db schema that you have referenced 
> ( 
> https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst
>  )

Re: [openstack-dev] How to implement and configure a new Neutron vpnaas driver from scratch?

[Bo Lin]

Hi Julio, 
+1 for Paul's response. Multiple-provider VPNaaS support is delayed. But you 
can take https://review.openstack.org/#/c/74156/ and 
https://review.openstack.org/#/c/74144/ as examples to write your own vpnaas 
driver without multi-provider support. If any questions or problems in your 
codes leading to not work, just upload your codes onto the review board, we can 
find how to solve it :). 

Thanks! 
---Bo 


- Original Message -

From: "Paul Michali (pcm)"  
To: "OpenStack Development Mailing List (not for usage questions)" 
 
Sent: Friday, April 11, 2014 2:15:18 AM 
Subject: Re: [openstack-dev] How to implement and configure a new Neutron 
vpnaas driver from scratch? 

By not “working” do you mean you cannot get the plugin to work in a 
multi-provider environment? Multi-provider solutions have been tabled until 
Juno, where more discussion is occurring on what is the best way to support 
different service providers. 

However, you should be able to get the plugin to work as the “sole” VPN service 
provider, which is what the Cisco solution does currently. You can look at how 
I’ve done that in the cisco_ipsec.py modules in the service_drivers and 
device_drivers directories, under neutron/services/vpn/. 


Regards, 

PCM (Paul Michali) 

MAIL …..…. p...@cisco.com 
IRC ……..… pcm_ ( irc.freenode.com ) 
TW ………... @pmichali 
GPG Key … 4525ECC253E31A83 
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 



On Apr 10, 2014, at 1:51 PM, Julio Carlos Barrera Juez < 
juliocarlos.barr...@i2cat.net > wrote: 




Hi. 

After 8 months of the patch creation and being abandoned weeks ago ( 
https://review.openstack.org/#/c/41827/ ) I still don't how can we develop a 
VPNaaS plugin following Bo Lin instructions. Is there any other patch trying to 
solve the problem? Is there any way to workaround the issue to get a VPNaaS 
plugin working? 

Thank you! 


Julio C. Barrera Juez 
Office phone: +34 93 357 99 27 
Distributed Applications and Networks Area (DANA) 
i2CAT Foundation, Barcelona, Spain 
http://dana.i2cat.net 


On 27 February 2014 10:51, Bo Lin < l...@vmware.com > wrote: 



Hi Julio, 
You can take https://review.openstack.org/#/c/74156/ and 
https://review.openstack.org/#/c/74144/ as examples to write your own vpnaas 
driver. More info about service type framework, you can also refer to 
neutron/services/loadbalancer codes. 


From: "Julio Carlos Barrera Juez" < juliocarlos.barr...@i2cat.net > 
To: "OpenStack Development Mailing List (not for usage questions)" < 
openstack-dev@lists.openstack.org > 
Sent: Thursday, February 27, 2014 5:26:32 PM 
Subject: Re: [openstack-dev] How to implement and configure a new Neutron 
vpnaas driver from scratch? 


I'm following the change you pointed a week ago. It seems that it is working 
now, and will be eventually approved soon. I will be happy when it is approved. 

Anyway, I need more information about how to develop a service driver and a 
device driver for VPN plugin. I realize doing reverse-engineering that I need 
and RPC agent and and RPC between them to communicate and use a kind of 
callbacks to answer. Where I can find documentation about it and some examples? 
Is there any best practise guide of the use of this architecture? 

Thank you again! 


Julio C. Barrera Juez 
Office phone: +34 93 357 99 27 
Distributed Applications and Networks Area (DANA) 
i2CAT Foundation, Barcelona, Spain 
http://dana.i2cat.net 


On 19 February 2014 09:13, Julio Carlos Barrera Juez < 
juliocarlos.barr...@i2cat.net > wrote: 



Thank you very much Bo. I will try all your advices and check if it works! 


Julio C. Barrera Juez 
Office phone: +34 93 357 99 27 
Distributed Applications and Networks Area (DANA) 
i2CAT Foundation, Barcelona, Spain 
http://dana.i2cat.net 


On 18 February 2014 09:18, Bo Lin < l...@vmware.com > wrote: 



I wonder whether your neutron server codes have added the " VPNaaS integration 
with service type framework " change on 
https://review.openstack.org/#/c/41827/21 , if not, the service_provider option 
is useless. You need to include the change before developing your own driver. 

QA (In my opinion and sth may be missing): 
- What is the difference between service drivers and device drivers? 
service drivers are driven by vpn service plugin and are responsible for 
casting rpc request (CRUD of vpnservices) to and do callbacks from vpn agent. 
device drivers are driven by vpn agent and are responsible for implementing 
specific vpn operations and report vpn running status. 

- Could I implement only one of them? 
device driver must be implemented based on your own device. Unless the default 
ipsec service driver is definitely appropriate, suggest you implement both of 
them. After including "VPNaaS integration with service type framework", the 
service driver work is simple. 

- Whe re I need to put my Python 

Re: [openstack-dev] Neutron: Need help with tox failure in VPN code

[Bo Lin]

I don't know whether i got your point. But try to modify 
/neutron/tests/unit/services/vpn/test_vpnaas_driver_plugin.py like the 
following, the error would be fixed: 
--- a/neutron/tests/unit/services/vpn/test_vpnaas_driver_plugin.py 
+++ b/neutron/tests/unit/services/vpn/test_vpnaas_driver_plugin.py 


@@ -17,6 +17,7 @@ 
import contextlib 

import mock 
+from oslo.config import cfg 

from neutron.common import constants 
from neutron import context 
@@ -44,6 +45,11 @@ class TestVPNDriverPlugin(test_db_vpnaas.TestVpnaas, 
self.driver = mock.Mock() 
self.driver.service_type = ipsec_driver.IPSEC 
driver_cls.return_value = self.driver 
+ vpnaas_provider = (p_constants.VPN + 
+ ':vpnaas:neutron.services.vpn.' 
+ 'service_drivers.ipsec.IPsecVPNDriver:default' ) 
+ cfg.CONF.set_override('service_provider', 
+ [vpnaas_provider], 'service_providers') 
super(TestVPNDriverPlugin, self).setUp( 
vpnaas_plugin=VPN_DRIVER_CLASS) 


- Original Message -

From: "Paul Michali"  
To: "OpenStack Development Mailing List (not for usage questions)" 
 
Sent: Tuesday, March 4, 2014 1:28:48 PM 
Subject: [openstack-dev] Neutron: Need help with tox failure in VPN code 

Hi, 

I'm stuck and can use some guidance here…please! 

I have a change set out for review that used the VPN Service Type Framework ( 
https://review.openstack.org/74144 ). Everything worked fine, passed Jenkins, 
etc. 

Found out that the STF won't make it to I-3, so I removed the dependency from 
my change set and tried to modify the plugin.py file to use some STF logic 
(like LBaaS uses) to load the desired service driver that is specified as the 
default. Adjusted the code to no longer use provider info. 

Well, in doing so, tox fails, and unfortunately there little info on the 
failure. This can be seen by running a subset of the tests, where 2 fail: 

tox -e py27 -v -- neutron.tests.unit.services.vpn 

only the name of a failing test case for one, and a mention of return code 10 
on another and no other info on the failure reason. I didn't see this on a full 
tox run in my repo, but Jenkins failed and Akihiro noticed it too, in running 
the above subset of the suite (thanks!). 


I've narrow it down a bit, but have no idea why it fails… 

One, it seems to be some interaction between test_vpnaas_driver_plugin.py and 
the two service driver tests (cisco_ipsec.py and ipsec.py). I can remove either 
one of the service driver tests cases, and it will still fail with the other 
one (so even the reference code fails). 

Two, if I change plugin.py to set self.driver to the reference device driver 
(as is done in the latest patch set) it works fine with all test cases. 

Three, it seems to be a test only issue, because I can run devstack with the 
login I have in plugin.py, currently commented out in __init__(), and 
successfully load either the reference or cisco service driver, by changing 
neutron.conf. 

It seems like I'm doing something wrong in the loading of the service driver, 
or using this implementation, is somehow interacting with the tests. 

If anyone has ideas on what is wrong, or a better way to load the service 
driver, please let me know. I was thinking I could read and parse neutron.conf 
manually and then load the service driver, but there must be a better way! 

Thanks! 

PCM (Paul Michali) 

MAIL p...@cisco.com 
IRC pcm_ ( irc.freenode.net ) 
TW @pmichali 
GPG key 4525ECC253E31A83 
Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83 


___ 
OpenStack-dev mailing list 
OpenStack-dev@lists.openstack.org 
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=J3ghWIVLPZdVsutjofb71dKYtoj4XxhrER%2FD8VzKRX0%3D%0A&s=09cf53ed99065938661b61453a717d77ba3b1ec069c48e356b358d472d3b526a
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] How to implement and configure a new Neutron vpnaas driver from scratch?

[Bo Lin]

Hi Julio, 
You can take https://review.openstack.org/#/c/74156/ and 
https://review.openstack.org/#/c/74144/ as examples to write your own vpnaas 
driver. More info about service type framework, you can also refer to 
neutron/services/loadbalancer codes. 

- Original Message -

From: "Julio Carlos Barrera Juez"  
To: "OpenStack Development Mailing List (not for usage questions)" 
 
Sent: Thursday, February 27, 2014 5:26:32 PM 
Subject: Re: [openstack-dev] How to implement and configure a new Neutron 
vpnaas driver from scratch? 

I'm following the change you pointed a week ago. It seems that it is working 
now, and will be eventually approved soon. I will be happy when it is approved. 

Anyway, I need more information about how to develop a service driver and a 
device driver for VPN plugin. I realize doing reverse-engineering that I need 
and RPC agent and and RPC between them to communicate and use a kind of 
callbacks to answer. Where I can find documentation about it and some examples? 
Is there any best practise guide of the use of this architecture? 

Thank you again! 


Julio C. Barrera Juez 
Office phone: +34 93 357 99 27 
Distributed Applications and Networks Area (DANA) 
i2CAT Foundation, Barcelona, Spain 
http://dana.i2cat.net 


On 19 February 2014 09:13, Julio Carlos Barrera Juez < 
juliocarlos.barr...@i2cat.net > wrote: 



Thank you very much Bo. I will try all your advices and check if it works! 


Julio C. Barrera Juez 
Office phone: +34 93 357 99 27 
Distributed Applications and Networks Area (DANA) 
i2CAT Foundation, Barcelona, Spain 
http://dana.i2cat.net 


On 18 February 2014 09:18, Bo Lin < l...@vmware.com > wrote: 



I wonder whether your neutron server codes have added the " VPNaaS integration 
with service type framework " change on 
https://review.openstack.org/#/c/41827/21 , if not, the service_provider option 
is useless. You need to include the change before developing your own driver. 

QA (In my opinion and sth may be missing): 
- What is the difference between service drivers and device drivers? 
service drivers are driven by vpn service plugin and are responsible for 
casting rpc request (CRUD of vpnservices) to and do callbacks from vpn agent. 
device drivers are driven by vpn agent and are responsible for implementing 
specific vpn operations and report vpn running status. 

- Could I implement only one of them? 
device driver must be implemented based on your own device. Unless the default 
ipsec service driver is definitely appropriate, suggest you implement both of 
them. After including "VPNaaS integration with service type framework", the 
service driver work is simple. 

- Whe re I need to put my Python implementation in my OpenStack instance? 
Do you mean let your instance runs your new codes? The default source codes dir 
is /opt/stack/neutron, you need to put your new changes into the dir and 
restart the neutron server. 

- How could I configure my OpenStack instance to use this implementation? 
1. Add your new codes into source dir 
2. Add appropriate vpnaas service_provider into neutron.conf and add 
appropriate "vpn_device_driver" option into vpn_agent.ini 
3. restart n-svc and q-vpn 

Hope help you. 


From: "Julio Carlos Barrera Juez" < juliocarlos.barr...@i2cat.net > 
To: "OpenStack Development Mailing List" < openstack-dev@lists.openstack.org > 
Sent: Monday, February 17, 2014 7:18:44 PM 
Subject: [openstack-dev] How to implement and configure a new Neutron vpnaas 
driver from scratch? 


Hi. 

I have asked in the Q&A website without success ( 
https://ask.openstack.org/en/question/12072/how-to-implement-and-configure-a-new-vpnaas-driver-from-scratch/
 ). 

I want to develop a vpnaas implementation. It seems that since Havana, there 
are plugins, services and device implementations. I like the plugin and his 
current API, then I don't need to reimplement it. Now I want yo implement a 
vpnaas driver, and I see I have two main parts to take into account: the 
service_drivers and the device_drivers. IPsec/OpenSwan implementation is the 
unique sample I've found. 

I'm using devstack to test my experiments. 

I tried to implement VpnDriver Python class extending the main API methods like 
IPsecVPNDriver does. I placed basic implementation files at the same level of 
IPsec/OpenSwan does and configured Neutron adding this line to 
/etc/neutron/neutron.conf file: 

service_provider = 
VPN:VPNaaS:neutron.services.vpn.service_drivers.our_python_filename.OurClassName:default
 

I restarted Neutron related services in my devstack instance, but it seemed it 
didn't work. 



- What is the difference between service drivers and device drivers? 
- Could I implement only one of them? 
- Whe re I need to put my Python implementation in my OpenStack instance? 
- How could I configure my OpenStac

Re: [openstack-dev] How to implement and configure a new Neutron vpnaas driver from scratch?

[Bo Lin]

I wonder whether your neutron server codes have added the " VPNaaS integration 
with service type framework " change on 
https://review.openstack.org/#/c/41827/21 , if not, the service_provider option 
is useless. You need to include the change before developing your own driver. 

QA (In my opinion and sth may be missing): 
- What is the difference between service drivers and device drivers? 
service drivers are driven by vpn service plugin and are responsible for 
casting rpc request (CRUD of vpnservices) to and do callbacks from vpn agent. 
device drivers are driven by vpn agent and are responsible for implementing 
specific vpn operations and report vpn running status. 

- Could I implement only one of them? 
device driver must be implemented based on your own device. Unless the default 
ipsec service driver is definitely appropriate, suggest you implement both of 
them. After including "VPNaaS integration with service type framework", the 
service driver work is simple. 

- Whe re I need to put my Python implementation in my OpenStack instance? 
Do you mean let your instance runs your new codes? The default source codes dir 
is /opt/stack/neutron, you need to put your new changes into the dir and 
restart the neutron server. 

- How could I configure my OpenStack instance to use this implementation? 
1. Add your new codes into source dir 
2. Add appropriate vpnaas service_provider into neutron.conf and add 
appropriate "vpn_device_driver" option into vpn_agent.ini 
3. restart n-svc and q-vpn 

Hope help you. 

- Original Message -

From: "Julio Carlos Barrera Juez"  
To: "OpenStack Development Mailing List"  
Sent: Monday, February 17, 2014 7:18:44 PM 
Subject: [openstack-dev] How to implement and configure a new Neutron vpnaas 
driver from scratch? 

Hi. 

I have asked in the Q&A website without success ( 
https://ask.openstack.org/en/question/12072/how-to-implement-and-configure-a-new-vpnaas-driver-from-scratch/
 ). 

I want to develop a vpnaas implementation. It seems that since Havana, there 
are plugins, services and device implementations. I like the plugin and his 
current API, then I don't need to reimplement it. Now I want yo implement a 
vpnaas driver, and I see I have two main parts to take into account: the 
service_drivers and the device_drivers. IPsec/OpenSwan implementation is the 
unique sample I've found. 

I'm using devstack to test my experiments. 

I tried to implement VpnDriver Python class extending the main API methods like 
IPsecVPNDriver does. I placed basic implementation files at the same level of 
IPsec/OpenSwan does and configured Neutron adding this line to 
/etc/neutron/neutron.conf file: 

service_provider = 
VPN:VPNaaS:neutron.services.vpn.service_drivers.our_python_filename.OurClassName:default
 

I restarted Neutron related services in my devstack instance, but it seemed it 
didn't work. 



- What is the difference between service drivers and device drivers? 
- Could I implement only one of them? 
- Whe re I need to put my Python implementation in my OpenStack instance? 
- How could I configure my OpenStack instance to use this implementation? 



I didn't find almost any documentation about these topics. 

Thank you very much. 

___ 
OpenStack-dev mailing list 
OpenStack-dev@lists.openstack.org 
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F5etm0B6kVJ9jleIhCvNyA%3D%3D%0A&m=9uhm%2F59JRfiZ3CXzuhBOpqcTqWk8APswRGJFZ8H2Tos%3D%0A&s=46fe06049efb1d29a85b63f7ce101cd69695a368c3da6ea3a91bcd7d2b71ce59
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev