Open Stack

Comments in-line @PCM


PCM (Paul Michali)

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



On Aug 28, 2014, at 11:57 AM, Sridhar Ramaswamy <srics.r at gmail.com> wrote:

> 
> https://bugs.launchpad.net/neutron/+bug/1355360
> 
> I'm working on this vpn vendor bug and am looking for guidance on the approach. I'm also relatively new to neutron development so bear with some newbie gaffs :)
> 
> The problem reported in this bug, in a nutshell, is the policies in the neutron vpn db and virtual-machine implementing vpn goes out of sync when the agent restarts (restart could be either operator driven or due to a software error). 

@PCM To clarify, the bug is an enhancement to VPN to support restart handling (which doesn’t currently exist), right?


> 
> CSR vpn device driver currently doesn't do a sync when it comes up. I'm going to add that as part of this bug fix.

@PCM Does the reference implementation handle restart? Is the handling non-disruptive (no loss to existing VPN connections)? Will this bug fix both reference and vendor VPN implementations?


> Still it will only partially solve the problem as it will take care of new connections created (which goes to PENDING_CREATE state) & updates to existing connections while the agent was down but NOT for deletes. For deletes the connection entry gets deleted right at vpn_db level. 
> 
> My proposal is to introduce PENDING_DELETE state for vpn site-to-site connection.  Implementing pending_delete will involve,

@PCM The PENDING_DELETE state already exists, but is not used currently for reference/vendor solutions, right?


> 
> 1) Moving the delete operation from vpn_db into service driver

@PCM Concerned about my understanding of this, or if it is how I’m interpreting the wording. The delete has two parts - database update and driver update to actually remove the connection. Are the database operations staying in vpn_db.py?


> 2) Changing the reference ipsec service driver to handle PENDING_DELETE state. For now we can just do a simple db delete to preserve the existing behavior.
> 3) CSR device driver will make use of PENDING_DELETE to correctly delete the entries in the CSR device when the agent comes up.

@PCM Would the process be…

1) delete request puts connection in DELETE_PENDING state (dbase write), and notifies service driver
2) service driver sends request to device driver
3) device driver does actions to delete the connection
4) device driver notifies that delete is completed (I think this would be asynchronous, as the device driver doesn’t reply to the request)
5) database would update and remove the connection entry.

Is that correct?

Regards,

PCM


> 
> Sounds reasonable? Any thoughts?
> 
> thanks,
> - Sridhar
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140829/c0bd20f7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140829/c0bd20f7/attachment.pgp>