15:01:00 <Swami> #startmeeting distributed_virtual_router
15:01:01 <openstack> Meeting started Wed Jul  9 15:01:00 2014 UTC and is due to finish in 60 minutes.  The chair is Swami. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:04 <openstack> The meeting name has been set to 'distributed_virtual_router'
15:01:05 <Swami> xuhanp: hi
15:01:30 <Swami> #info Back from vacation
15:01:48 <Swami> no more disconnects or power cuts.
15:02:47 <Swami> armax: is busy with an another meeting so may not be able to join the discussion
15:03:07 <armax> armax: I’ll try to chip in if you guys need me
15:03:09 <Swami> #topic L3_Plugin Status
15:03:26 <Swami> armax: thanks, will ping you if I need you.
15:03:52 <Swami> L3_Plugin is up there for review and I hope most of the review comments have been addressed.
15:04:06 <Swami> It had gone through lot of reviews.
15:04:18 <Swami> There was one item that need to be addressed.
15:04:35 <Swami> Router migration or convertion.
15:05:08 <Swami> Today the plugin supports migrating a centralized router to a distributed router, but the underlying scheduler code does not handle it right.
15:05:56 <Swami> So we have been thinking about for time being to raise "NotImplementedError" from the plugin side.
15:06:14 <Swami> Also we have been looking to solve this problem from the scheduler.
15:06:52 <Swami> I had some offline discussions with Murali on the scheduler requirement to perform the migration.
15:07:48 <Swami> The scheduler should be in a position to identify if it is regular router update or a router migration/conversion.
15:08:08 <Swami> Here is my thought on this.
15:08:59 <Swami> Probably it might be helpful to add a flag in the extraattributes table to include the migration identifier.
15:09:32 <Swami> similar to "migration": central-to-distributed or distributed-to-central
15:10:04 <Swami> Any suggestions!!
15:11:08 <Swami> If the migration: attribute is null, it would considered a regular update and there is no need for the scheduler to reschedule the router.
15:11:59 <Swami> But if the migration: attribute has a value, then the scheduler can take action on rescheduling the router and also at the same time safely removing the old namespace from the legacy l3 agent.
15:12:46 <viveknarasimhan> i think for now we should raise a NotImplementedError on detecting a conversion
15:13:14 <Swami> viveknarasimhan: agreed.
15:13:31 <viveknarasimhan> we have to brainstorm further on all use-cases before we attempt to change code
15:13:50 <Swami> But at the same time, if this flag is required for the scheduler to take the necessary action, we just add it to the plugin and still include the "NotImplementedError".
15:14:06 <viveknarasimhan> basically we will allow manual conversion where router is deleted and recreated in its entirety as distributed router by the admin
15:14:25 <viveknarasimhan> all auto-conversions (by router-update) command we return 'NotImplemented'
15:14:27 <Swami> So later we don't need to change the plugin code.
15:14:46 <viveknarasimhan> we will figure out what changes need to go into l3_dvrscheduler and l3_agentscheduler and also any changes to l3-agent
15:14:59 <viveknarasimhan> and then we can know the scope of changes to attack this
15:15:14 <Swami> vivek: I agree with you that there are more use cases that we need to validate and test before we can comfortably claim that we support the migration.
15:15:18 <viveknarasimhan> yeah, basic sheet code can be in plugin
15:15:32 <viveknarasimhan> but breadth of functionality will not be done until it is scoped fully
15:15:44 <xuhanp> Swami and vivek, when you guys saying that raising a NotImplementedError, you mean the conversion from legacy to dvr, right?
15:15:51 <viveknarasimhan> yes legacy to dvr
15:15:58 <xuhanp> does it includes enable SNAT function?
15:16:02 <xuhanp> is that allowed?
15:16:02 <Swami> xuhanp: Yes
15:16:26 <Swami> xuhanp: snat is already supported and allowed.
15:16:49 <xuhanp> I mean from a DVR router not having dvr_SNAT enabled updated to dvr_snat enabled.
15:16:53 <xuhanp> this is allowed, right?
15:17:10 <xuhanp> this requires re-scheduling as well?
15:17:16 <Swami> xuhanp: Yes this is allowed.
15:17:24 <xuhanp> Swami, got it. Thanks
15:17:56 <Swami> xuhanp: but the snat service migration from one service node to another is not supported yet.
15:18:29 <xuhanp> Swami, how can that be done by API?
15:18:59 <xuhanp> or there is no API available too?
15:19:12 <Swami> xuhanp: we were planning to support an API to associate the snat service with an l3-agent that is running in the service node.
15:19:26 <xuhanp> Swami, got it.
15:19:33 <Swami> once we have the support for this feature we will implement the API.
15:20:04 <xuhanp> Swami, I am happy to help it if you need
15:20:28 <Swami> xuhanp: sure, I will ping you.
15:20:34 <xuhanp> Swami, thanks
15:21:05 <Swami> That's all I had on the plugin side.
15:21:15 <Swami> Otherwise the plugin looks good.
15:22:01 <Swami> since vivek is here, I will move on to L2 .
15:22:15 <Swami> #topic DVR L2/Plugin/agent
15:23:06 <Swami> vivek: are you there
15:23:18 <Swami> can you provide any updates on the L2 side.
15:23:58 <viveknarasimhan> on the L2 side
15:24:14 <viveknarasimhan> the upstream patches are under review
15:24:17 <viveknarasimhan> all the 4 of them
15:24:21 <viveknarasimhan> we have addressed review comments
15:24:55 <viveknarasimhan> we are looking forward to merge after acceptance by neutron core team
15:25:15 <viveknarasimhan> thanks to xuhan for testing the patches and reporting issues
15:25:17 <Swami> #link https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/neutron-ovs-dvr,n,z
15:25:26 <viveknarasimhan> that crept in due to rebase issues
15:26:11 <Swami> vivek: anything else
15:26:53 <Swami> murali: hi
15:27:09 <Murali> Hi Swami
15:27:13 <Swami> #topic DVR Scheduler
15:27:24 <Swami> murali: can you provide an update on the DVR scheduler
15:27:45 <Murali> Scheduler almost all review comments are addressed
15:28:27 <Murali> and now armando simplfiying the usuage of the flag to findout the distributed agent and centralised agent
15:28:46 <Murali> The pending task is migration
15:29:23 <Murali> centralised to distributed and distributed to centralised
15:29:30 <Swami> murali: we just briefly touch based on the migration requirements
15:30:15 <Murali> ok
15:30:31 <Murali> any conclusion ?
15:30:50 <Murali> how are dealing it in plugin side?
15:30:55 <Swami> murali: It would be great if you could come up with a list of use cases for the migration and let me know your requirements on the plugin side to support the migration path.
15:31:33 <Swami> from the discussion today, we have not come to any conclusion, but we wanted to get all the use case for the migration.
15:31:43 <Murali> I need the information about the previous router status. which means whether it is distributed or centralised
15:32:02 <Swami> Use case 1: Convert a router without snat to distributed.
15:32:17 <Swami> Use case 2: Convert  a router with snat to distribtued
15:32:43 <Swami> First let us only target the "legacy to distributed" migration.
15:33:04 <Murali> ok
15:33:19 <viveknarasimhan> Swami/Murali: sorry to interrupt, need to leave the meeting.  Will catch up later.  Updated blueprint posted for review here: https://review.openstack.org/#/c/105659
15:33:54 <Swami> As far as my discussion with you, the only additional information that you need is the transition state of the router.
15:34:17 <Swami> But in your use case walk through if you have any other requirements feel free to let me know.
15:34:24 <Swami> vivek: thanks
15:34:44 <Murali> yes Swami. It would be good if you add one more variable in router dict to say that it is in migration state
15:35:17 <Murali> then scheduler can unbind the existing leagcy and try to bind to distributed agents if nay in the given nodes
15:35:47 <Swami> murali: Yes I suggested a "string" attribute that says "legacy-to-distributed" or "distributed-to-legacy". If the string attribute is null, then no migration
15:36:13 <Swami> I will discuss further with Armando and let you know.
15:36:31 <Murali> thats good. then it easy for scheduler to handle the migration both wise
15:36:56 <Murali> But as you said let us target only first leagcy-to-dist
15:37:07 <Swami> The attribute name can be "migration-state" or similar.
15:37:32 <Swami> murali: Yes we are going to target only 'legacy-to-distributed' first.
15:37:54 <Murali> Let try sometime tomorrow
15:38:22 <Murali> please add the attribute in plugin and let me know and i can take-it up tomorrow
15:38:38 <Swami> murali: thanks
15:38:59 <Swami> #topic L3 agent
15:39:34 <Swami> Mike is on vacation this week.
15:40:07 <Swami> L3 agent patch is also under review.
15:40:34 <Swami> carl is currently testing it, he will let us know the status.
15:41:28 <Swami> #topic Services
15:42:03 <Swami> There was a discussion on the FWaaS and the DVR issues recently in the ML and the Neutron team meeting.
15:42:49 <Swami> I am not sure if Yi is here in this meeting, but we will be having an ongoing discussion with the FWaaS team to resolve the problem.
15:43:55 <Swami> But in the short term, the Neutron team have decided to document that FWaaS may have issues with the DVR, if we as a team cannot fix this problem.
15:44:14 <Swami> I will further have a discussion with the FWaaS team today.
15:44:58 <Swami> Again all the legacy Services need to addressed with the DVR including the VPNaaS, FWaaS and LBaaS.
15:45:32 <Swami> But we need to focus on the services once we have the base DVR up running and testable.
15:45:39 <Swami> Hope this helps.
15:45:54 <Swami> #topic DVR_testing
15:46:13 <Swami> Neutron team is working on including a multi node setup to test the DVR.
15:46:51 <Swami> This work might be taken up in the mid-cyle meetup that is held from today to friday.
15:47:23 <Swami> #topic Open Discussion
15:47:39 <Swami> Any items for open discussion please let me know.
15:48:57 <Swami> If there are no other topics, then I will end the meeting.
15:49:24 <Swami> Thanks everyone for joining the meeting.
15:49:30 <Swami> see you all next week.
15:49:39 <Swami> bye
15:49:42 <Murali> ok bye
15:49:51 <Swami> #endmeeting