Open Stack

Thanks Paul for your thoughts. See inline [SridharR] ...


On Fri, Aug 29, 2014 at 4:19 AM, Paul Michali (pcm) <pcm at cisco.com> wrote:

> 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?
>
>
[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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> 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/bcf79321/attachment.html>