Thanks Paul for your thoughts. See inline [SridharR] ...
On Fri, Aug 29, 2014 at 4:19 AM, Paul Michali (pcm) <p...@cisco.com> wrote: > Comments in-line @PCM > > > 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 Aug 28, 2014, at 11:57 AM, Sridhar Ramaswamy <sric...@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? > > [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. > > > 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? > [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. > > > 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? > [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. > > > > 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? > [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. > > > 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? > [SridharR] Exactly! thanks, Sridhar *IRC: SridharRamaswamy (irc.freenode.net <http://irc.freenode.net>)* > > Regards, > > PCM > > > > Sounds reasonable? Any thoughts? > > thanks, > - Sridhar > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev