Comments in-line @PCM

PCM (Paul Michali)

MAIL …..….
IRC ……..… pcm_ (
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 <> wrote:

> 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

> 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?



> Sounds reasonable? Any thoughts?
> thanks,
> - Sridhar
> _______________________________________________
> OpenStack-dev mailing list

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

OpenStack-dev mailing list

Reply via email to