<div dir="ltr">Thanks Paul for your thoughts. See inline [SridharR] ...<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 29, 2014 at 4:19 AM, Paul Michali (pcm) <span dir="ltr"><<a href="mailto:pcm@cisco.com" target="_blank">pcm@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Comments in-line @PCM<div><br></div><div><br><div>
<div><div>PCM (Paul Michali)</div><div><br></div><div>MAIL …..…. <a href="mailto:pcm@cisco.com" target="_blank">pcm@cisco.com</a></div><div>IRC ……..… pcm_ (<a href="http://irc.freenode.com" target="_blank">irc.freenode.com</a>)</div>
<div>TW ………... @pmichali</div><div>GPG Key … 4525ECC253E31A83</div><div>Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83</div></div><div><br></div><br>
</div>
<br><div><div class=""><div>On Aug 28, 2014, at 11:57 AM, Sridhar Ramaswamy <<a href="mailto:srics.r@gmail.com" target="_blank">srics.r@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><div><br>
</div><div><a href="https://bugs.launchpad.net/neutron/+bug/1355360" target="_blank">https://bugs.launchpad.net/neutron/+bug/1355360</a><br></div><div><br></div><div>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 :)</div>
<div><br></div><div>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). </div>
</div></blockquote><div><br></div></div>@PCM To clarify, the bug is an enhancement to VPN to support restart handling (which doesn’t currently exist), right?</div><div><br></div></div></div></blockquote><div><br></div><div>
[SridharR] Yeah, you can say that. I reported (and trying to fix) the issue with vpn functionality in mind where it fails removing the vpn-tunnel in some valid operational scenarios. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div></div><div><div class=""><br><blockquote type="cite"><div dir="ltr">
<div><br></div><div>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.</div></div></blockquote><div><br></div></div>@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?</div>
</div></div></blockquote><div><br></div><div>[SridharR] Looking at the reference implementation I don't think it explicitly handles a restart. However looks if it finds an active openswan process the agents does a stop / start - so yes it will disrupt existing VPN connections.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div><div class=""><br><blockquote type="cite"><div dir="ltr">
<div> 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. </div>
<div><br></div><div>My proposal is to introduce PENDING_DELETE state for vpn site-to-site connection. Implementing pending_delete will involve,</div></div></blockquote><div><br></div></div>@PCM The PENDING_DELETE state already exists, but is not used currently for reference/vendor solutions, right?</div>
</div></div></blockquote><div><br></div><div>[SridharR] Yes. I propose we introduce it in the plug-in side first. And incrementally enhance the agents to support it. This way we can ensure the code changes are relatively smaller & easier to review.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div><div class=""><br><blockquote type="cite"><div dir="ltr">
<div><br></div><div>1) Moving the delete operation from vpn_db into service driver</div></div></blockquote><div><br></div></div>@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?</div>
</div></div></blockquote><div><br></div><div>[SridharR] My proposal is to have the database delete code in vpn_db as a utility method. It will get called once driver 'acks' the delete the operation.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div><div class=""><br><blockquote type="cite"><div dir="ltr">
<div>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.</div><div>3) CSR device driver will make use of PENDING_DELETE to correctly delete the entries in the CSR device when the agent comes up.</div>
</div></blockquote><div><br></div></div>@PCM Would the process be…</div><div><br></div><div>1) delete request puts connection in DELETE_PENDING state (dbase write), and notifies service driver</div><div>2) service driver sends request to device driver</div>
<div>3) device driver does actions to delete the connection</div><div>4) device driver notifies that delete is completed (I think this would be asynchronous, as the device driver doesn’t reply to the request)</div><div>5) database would update and remove the connection entry.</div>
<div><br></div><div>Is that correct?</div></div></div></blockquote><div><br></div><div>[SridharR] Exactly!</div><div><br></div><div><br></div><div>thanks,<br>Sridhar</div><div><br></div><div><i>IRC: SridharRamaswamy (<a href="http://irc.freenode.net">irc.freenode.net</a>)</i></div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>Regards,</div><div><br></div><div>
PCM</div><div><br></div><div><br><blockquote type="cite"><div class=""><div dir="ltr">
<div><br></div><div>Sounds reasonable? Any thoughts?<br></div><div><br></div><div>thanks,</div><div>- Sridhar</div><div><br></div></div></div>
_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>