15:01:42 <Swami> #startmeeting distributed-virtual-router
15:01:43 <openstack> Meeting started Wed Apr  9 15:01:42 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:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:46 <openstack> The meeting name has been set to 'distributed_virtual_router'
15:01:55 <Swami> mrsmith:hi
15:02:14 <Swami> #topic Agenda
15:02:34 <Swami> 1. DVR Plugin extension update
15:02:38 <Swami> 2. L2 Agent Update
15:02:43 <Swami> 3. L3 Agent Update
15:03:03 <Swami> 4. Open Discussion
15:03:20 <Swami> #topic DVR Plugin extension update
15:03:39 <Swami> As you all may know the WIP code for the DVR extension is up for review.
15:03:56 <Swami> Thanks for the early review comments and I have address most of the comments.
15:04:07 <Swami> The latest patch set if patch 5
15:04:36 <Swami> xunahp: I had an issue addressing one of your comments
15:04:58 <vivekn> hi
15:05:07 <Swami> vivekn: hi
15:05:13 <xuhanp> Swami, let me know how I can help :-)
15:05:45 <Swami> There was the "sqlalchemy Or_" that you mentioned in the review for the L3_db.
15:05:58 <Swami> For some reason it gives me an error.
15:06:13 <Swami> I am not sure if there was any syntax errors.
15:06:43 <xuhanp> Swami, yes. I saw your reply about it. maybe I need to download your code and experiment a little bit.
15:06:49 <Swami> when I include the key "device_owner =yyyy". It says that device_owner is unrecognized.
15:07:20 <xuhanp> ok. Let me try that this week and let you know?
15:07:53 <Swami> xuhanp: I will try to do some more investigation on that. In the meanwhile if you can give me a handle on that, it would be great.
15:08:06 <xuhanp> Swami, sure thing.
15:08:31 <Swami> There was on other topic related to the plugin that I wanted to discuss with the sub-team.
15:09:01 <Swami> Is there a cleaner way of accessing the ml2 plugin based port binding information from the l3 Plugin.
15:10:11 <Swami> If anyone have any ideas on this, just ping me.
15:10:18 <vivekn> swami,
15:10:29 <Swami> vivekn: yes
15:10:30 <vivekn> you need port binding host_id information?
15:10:38 <vivekn> for DVR interfaces?
15:10:51 <Swami> vivekn:yes
15:11:11 <vivekn> host_id for dvr interfaces are now stored in an extension table different than port-binding
15:11:21 <vivekn> that table is called ml2_dvr_port_binding
15:11:41 <Swami> Is it still part of the ml2 db.
15:12:01 <vivekn> it is still part of ml2 db only. Let me try to give a cleaner interface through python abstract classes so that you can access that table as well
15:12:19 <Swami> vivekn: I can chat with you offline on this.
15:12:23 <xuhanp> Swami and vivekn, will that limit the DVR to only support ML2 plugin?
15:12:23 <vivekn> the original port-binding table will continue to hold only non-dvr interfaces (liek nova ports, centralized nn ports etc)
15:12:28 <Swami> vivekn: thanks
15:12:40 <vivekn> for now we have coded it that way
15:12:56 <carl_baldwin> An interface would be good.  Is it something that other plugins could implement down the road?
15:13:00 <vivekn> when we post WIP code of L2 for review, we will go through this in more detail
15:13:20 <Swami> vivekn: thanks
15:13:28 <xuhanp> thanks
15:13:31 <vivekn> in the current shape no
15:13:49 <Swami> xuhanp: We are not trying to tie the DVR with the ML2, but there is a dependency on the OVS for the DVR.
15:13:49 <vivekn> is same as the port-binding schema
15:14:20 <vivekn> with status as an extra collumn
15:14:20 <vivekn> correct swami
15:14:20 <vivekn> ovs today works with ml2 plugin only
15:14:34 <Swami> But any port addition and port deletion and the corresponding action to those ports are basically handled in the ML2.
15:14:58 <Swami> These are basically to address the OVS rules in the Compute node bridges.
15:15:13 <xuhanp> Swami, thanks for the information.
15:15:34 <Swami> #topic L2 Agent
15:15:57 <Swami> vivekn: Can you give us an update on the L2 Agent where you are right now.
15:16:55 <Swami> vivekn_: I think your connection is not so good.
15:17:07 <vivekn_> yes kinda logged out automatically
15:17:15 <vivekn_> figured out and rejoined :(
15:17:23 <Swami> vivekn_: can you give an update on the L2 agent before you log off.
15:17:31 <vivekn_> currently
15:17:42 <vivekn_> pursuing addressing l2-pop to use
15:17:47 <vivekn_> extended ml2_dvr_port_bindings table
15:18:07 <vivekn_> to decide whether vm is first on a network in an agent and also a vm is last on the network in a given l2 agent
15:18:51 <vivekn_> also started working on gerrit work flow to post WIP code of L2 Agent/Plugin for review on 'master'
15:19:06 <Swami> vivekn_: thanks for the info.
15:19:25 <Swami> We are looking forward to see the L2 Agent code, so that we might get early feedback.
15:19:42 <Swami> vivekn_: can it be pushed in the next couple of days.
15:19:57 <vivekn_> yes ,
15:20:08 <vivekn_> but since travelling
15:20:09 <Swami> vivekn_: Thanks, that's great.
15:20:15 <vivekn_> may take 4-5 days
15:20:42 <Swami> vivekn_: ok, by next week then we should have it posted.
15:20:55 <Swami> vivekn_: hope this helps.
15:21:13 <vivekn_> yes
15:21:26 <Swami> vivekn_: Thanks for your time.
15:21:33 <Swami> #topic L3 Agent
15:21:34 <vivekn_> welcome
15:21:41 <Swami> mrsmith: hi
15:21:55 <mrsmith> hi all
15:22:01 <Swami> mrsmith: Any updates on the L3 Agent
15:22:19 <mrsmith> FIP code changes are almost done
15:22:36 <mrsmith> but since upstream/icehouse has alot of FIP changes
15:22:41 <mrsmith> the merge has been delayed
15:22:52 <mrsmith> and therefore posting for review is delayed
15:23:02 <mrsmith> trying to resolve the merge ASAP
15:23:34 <Swami> mrsmith: got it.
15:23:50 <mrsmith> yesterday I got the unit tests passing with DVR changes for l3_agent
15:23:55 <mrsmith> on icehouse
15:23:58 <mrsmith> good progress
15:24:08 <Swami> mrsmith: Great!!!
15:25:01 <Swami> mrsmith: Thanks, please make sure that you push you code as quick as possible to upstream to get the early feedback.
15:25:10 <mrsmith> understood
15:25:23 <Swami> mrsmith: Thanks for the update
15:25:26 <mrsmith> np
15:25:45 <Swami> #Open Discussions
15:26:03 <Swami> Any open discussions
15:26:07 <vivekn_> yes
15:26:20 <vivekn_> i had a chance to read mails from Robert Kukura of l3-team
15:26:25 <Swami> #topic Open Discussions
15:26:27 <vivekn_> for the external network multiple subnets blueprint
15:26:44 <Swami> vivekn_: Kukura is part of the ml2 team
15:26:44 <vivekn_> recent changes have been made for multiple external networks in icehouse
15:26:53 <vivekn_> which might have impact on DVR
15:27:07 <carl_baldwin> What is that blueprint called?
15:27:10 <vivekn_> all internet traffic now goes through br-int
15:27:19 <vivekn_> earlier it went throuh br-ex directly, but not anymore
15:27:40 <mrsmith> that would impact DVR
15:27:46 <vivekn_> and br-ex has flows to strip_vlan (for egress) and insert_vlan(for ingress) packets to internet
15:27:48 <Swami> vivekn_: was that the blueprint implemented by Sylvain
15:28:00 <vivekn_> this is the direction of N-S movement from icehouse
15:28:14 <vivekn_> they want to eliminate br-ex being tied to ineternal routers
15:28:16 <xuhanp> vivekn_, do you have the link of the blueprint or the link of the email?
15:28:21 <vivekn_> yes
15:28:26 <vivekn_> swami
15:28:41 <vivekn_> Sylvain fix for multiple external networks changed the paradigm
15:28:43 <Swami> vivekn_: can you post the blueprint link
15:28:52 <vivekn_> of how N-S traffic is handled in incehouse
15:29:04 <vivekn_> i think i have the bug id , i will find blueprint and post it over email
15:29:49 <xuhanp> vivekn_, thanks
15:30:14 <Swami> vivekn_: I thought the blueprint that Sylvain posted was related to allowing the L3 agent to handle more than one external networks.
15:30:15 <vivekn_> here it is
15:30:22 <Swami> I was not sure that it touched the bridges.
15:30:54 <vivekn_> one sec
15:31:33 <vivekn_> couldn't find the right blueprint
15:31:48 <Swami> carl: are you aware about this in Icehouse were br-ex is bypassed.
15:32:17 <vivekn_> https://bugs.launchpad.net/neutron/+bug/1303682
15:32:31 <vivekn_> please look at this bug for conversation by robert kukura on the paradigm change
15:33:13 <vivekn_> Sylvain enhancement
15:33:13 <vivekn_> https://review.openstack.org/#/c/59359/
15:33:24 <vivekn_> br-ex is not bypassed
15:33:31 <vivekn_> br-ex will talk to br-int
15:33:32 <vivekn_> not to IRs anymore
15:33:45 <vivekn_> if you need a single external network then old method will continue to work
15:33:56 <vivekn_> but that will be for backward compatibility fro existing customers
15:33:58 <carl_baldwin> Swami: I'm not aware.
15:34:10 <vivekn_> going forward support for external networks is via provider external networks
15:34:22 <vivekn_> please see Sylvain enhancement posted above for details
15:34:25 <Swami> vivekn_: We might have to discuss this with Sylvain, he has already commented on the bug that vinod had proposed.
15:34:36 <carl_baldwin> I've just opened the bug and review linked and will take a look.
15:34:52 <vivekn_> with a single l3_agent, you can host multiple external networks going forward
15:35:10 <vivekn_> earlier this was big limitation where you need one instance for l3_agent for every new external network
15:35:17 <carl_baldwin> I did review the patch early on so my memory of it is beginning to come back.
15:35:39 <Swami> vivekn_: Can you join the l3-subteam meeting tomorrow, sametime #openstack-meeting-3, and then we can discuss with Sylvain about this provider network scenario with multple external networks
15:35:57 <vivekn_> sure, i will try to join
15:36:07 <Swami> vivekn_: thanks.
15:36:26 <Swami> vivekn_: thanks for bringing up this point.
15:36:49 <Swami> vivekn_: Can you also send a detailed mail to sylvain and copy me.
15:37:09 <vivekn_> i will forward the mail that was being discussed between vinod and
15:37:09 <vivekn_> robert
15:37:22 <vivekn_> to you , carl, mike and we can take it up from there
15:37:37 <Swami> vivekn_: thanks vivek.
15:37:44 <vivekn_> robert's responses are not captured in teh review comments, but he mailed the intent
15:38:11 <vivekn_> i think attending ml2 meetings would help both l2 and l3 people in DVR
15:39:17 <Swami> vivekn_: ml2 meeting is just after our meeting today in the same channel. If you are available can you join the meeting and have this discussion with the kukura and mystery.
15:39:28 <vivekn_> sure
15:39:46 <Swami> I will also try to join the ml2 meeting, but may join a bit late.
15:40:10 <Swami> vivekn_: Thanks
15:40:24 <xuhanp> Swami, I have another question to bring up if you don't have other topics :-)
15:40:41 <Swami> xuhanp: go ahead, I was about to ask you.
15:40:50 <xuhanp> in current design, what happen after one distributed L3 agent on compute node fails?  will the VM on that node still be able to talk to other node or external network?
15:41:30 <xuhanp> I mean the compute node is working fine but just the L3 agent fails for some reason.
15:42:20 <mrsmith> it should get restarted - via /etc/init
15:42:39 <mrsmith> but that is part of the interest in DVR - the impact of failure should be smaller
15:42:44 <mrsmith> limited to a CN
15:42:46 <Swami> mrsmith: but the vms that are already provisioned should still be able to communicate.
15:43:11 <mrsmith> yes - but if the l3_agent fails and does not recover there may be a problem
15:43:19 <mrsmith> but it should be better than the NN case
15:43:24 <xuhanp> Swami, my question is exactly about how to do that?
15:44:36 <Swami> xuhanp: When an L3 agent fails, the current behaviour should be similar to the current centralized l3 agent behavior.
15:45:12 <xuhanp> Swami, but we won't provide HA solution for the distributed L3 agent, right?
15:45:17 <Swami> mrsmith: Is there any other option where when a L3 agent fails, the VMs can continue to pass traffic.
15:45:56 <mrsmith> are we assuming the auto re-start fails as well?
15:46:22 <Swami> xuhanp: The HA solution that is currently being proposed for L3 agent should still work, but there may be some difficulties which we have not thought about.
15:46:32 <mrsmith> sure
15:46:51 <xuhanp> mrsmith, you mean the auto restart with the help of monitor tool, right?
15:47:09 <Swami> We may have to do some testing. Since we are using the same L3 agent for all the DVR work, L3 vrrp can be used.
15:47:11 <mrsmith> the upstart linux functionality
15:47:16 <mrsmith> for services
15:47:25 <mrsmith> will monitor when a process dies - and auto restart
15:47:26 <xuhanp> mrsmith, I see.
15:47:57 <mrsmith> but if there is a bad bug - the l3_agent may continuously restart
15:48:10 <mrsmith> the cloud admin may need to take manual steps
15:48:16 <Swami> Any other questions.
15:48:42 <xuhanp> also if there are many compute node, say 100, will there be too many l3 agents?
15:49:03 <Swami> xuhanp: Each compute node will host a l3 agent.
15:49:23 <Swami> xuhanp: This is minimum requirement.
15:49:50 <Swami> xuhanp: Hope it is clear now.
15:49:55 <mrsmith> yes - each compute node will host a l3_agent
15:50:05 <mrsmith> how many is "too many" ?
15:50:41 <Swami> Ok, folks we are at the end of the hour.
15:50:47 <Swami> See you all next week.
15:51:00 <Swami> Thanks everyone for joining the meeting.
15:51:05 <xuhanp> Swami, ok. Thanks for the explanation. talk to you later
15:51:06 <Swami> #endmeeting