15:01:24 #startmeeting distributed-virtual-router 15:01:26 Meeting started Wed Mar 19 15:01:24 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:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:30 The meeting name has been set to 'distributed_virtual_router' 15:01:37 hi 15:01:45 xuhanp: hi 15:01:59 #topic agenda 15:02:15 Agent design doc status 15:02:30 L3 Namespace 15:02:39 L2 Pop FDB timeout 15:02:50 admin_state_up 15:02:56 DVR+HA 15:03:03 Distributed DHCP 15:03:22 Is there any other topic that you would like to discuss today as part of the DVR 15:03:39 the arbitrary port for router 15:03:45 if that's not communicated already 15:04:19 vivek: thanks for bringing it up 15:05:08 We would be also discussing about the support of attaching an arbitrary port to an existing router with a subnet with the DVR context. 15:05:25 #topic Agent Design doc status 15:06:07 #link https://docs.google.com/document/d/1depasJSnGZPOnRLxEC_PYsVLcGVFXZLqP52RFTe21BE/edit 15:06:11 L2 agent design doc 15:06:18 ajo: hi 15:06:56 hi Swami :) 15:07:55 Hi folks the l2 agent design doc is out there for the community review, if you have any questions or concerns please feel free to let us know. 15:08:14 If your comments or not addressed please let me know and I will make sure that those are addressed. 15:08:26 #link https://docs.google.com/document/d/1jCmraZGirmXq5V1MtRqhjdZCbUfiwBhRkUjDXGt5QUQ/edit 15:08:30 L3 agent design doc 15:08:50 This week we posted the L3 agent design doc for review. 15:09:13 Both these docs were created based on the community feedback from the face to face meeting. 15:09:48 Please review those documents and provide me your feedback. 15:10:04 Is sylvain in here 15:10:33 I don't see sylvain today in the IRC. 15:10:39 #topic L2 Pop 15:11:04 We found out that L2 Pop entries times out. 15:11:13 Swami a clarification 15:11:21 we just found out that they don't timeout today 15:11:28 vivek: sure 15:11:35 there is a mix of timing out and non-timing out entries though 15:11:52 jumbled by tunnel-bridge learning and L2-POP both working on Table 20 - UCAST_TO_TUN 15:12:04 vivek: can you explain the mix of timeout and not-timeout 15:12:23 basically, tunnel bridge learning entries also show up in Table 20 even though L2-Pop is enabled 15:12:40 so there are two entries for the same destination mac in table 20, one learnt by tunnel-bridge and other pushed by L2-POP 15:13:13 those entries pushed in by tunnel-bridge learning logic has hard_timeout of 300 secs of expiry (ie., in 5 minutes they expire) 15:13:21 those entries (same dest mac) pushed by L2-POP donot expire 15:13:30 are you proposing to disable one of the learning or trying to understand if there is a way to disable one of the learning 15:13:50 i thought that having both learning and l2-pop is redundant as they 15:13:57 occupy tunnel-bridge finite flow space 15:13:57 carl: do you have any insight on this 15:14:37 Swami: Not yet. 15:14:55 vivek: May be sylvain would be able to answer your question. Unfortunately he is not here. 15:15:14 It sounds like redundant to me, 15:15:29 there's something not to be populated via L2-POP that could be discovered by learning? 15:15:34 I have sent an email to sylvain, if not he will be attending the L3-subteam meeting tomorrow and I will try to bring this topic. 15:15:48 yes 15:16:24 ajo: Is we need to identify it this is the expected behavior or a bug. If it is a bug we need to log a bug on the launchpad or discuss with Sylvain. 15:16:25 (or) atelast shut off tunnel bridge learning and have L2-POP totally deal with entries in Table 20 15:16:43 aha 15:16:43 having double entries for same MAC seems to be redundant 15:16:49 But here different VLAN with same Mac address in the ovs-rules 15:16:58 Vivek-Narasimhan, the double mac entries, are for vrouters, right? 15:16:58 No murali 15:17:05 the different VLAN thing we wil investigate further 15:17:06 which it's what's populated via L2-POP 15:17:10 or do we populate something else? 15:18:03 Vivek: Good point, thanks for bringing this up. I will log it and discuss it with sylvain. 15:18:39 #topic admin_state_up 15:19:21 In the current openstack neutron implementation the "admin_state_up" flag does not do anything usefull to get the state of the object. 15:20:08 or control the state 15:20:29 For example if the "router" admin_state_up is down, the router is still active and serviced by the scheduler. 15:20:37 Swami, the problem is that it works for some objects, but it doesn't for other? 15:20:39 That is a defect 15:20:49 ajo: May be right. 15:20:54 ye,s the vrouter should not be created in such case. 15:21:04 afaik 15:21:15 Yes that is how it was in Grizzly 15:21:37 I think the setting name is confusing itself 15:21:41 In the "neutron-team-meeting" this monday there was a question about getting rid of "admin_state_up" and use the "status". 15:21:50 "admin_state_up", talks about "status", not a setting... 15:21:51 just back 15:22:09 "admin_disabled" would be something more appropriate IMHO 15:22:26 so how to set the status without admin_state_up anymore? 15:22:41 I think those should be two different things 15:22:56 status = current status, is it having any problem . Read only from the admin perspective 15:23:13 If this is a bug then we need to file a bug on this. If there is already a bug on this, we need to see if we can take the bug and fix it. 15:23:16 admin_disabled (current admin_state_up ... bad name) = read/write , to let the admin disable a resource. 15:23:55 ajo, ok. that makes sense. as long as there is a way to do that. 15:24:21 The reason I brought up this topic is because if this is not fixed, then there is not good way of re-scheduling the routers to a different agent, unless you manually associate a router to a specific agent. 15:24:29 a name change affects the API specification: https://wiki.openstack.org/wiki/Neutron/APIv2-specification 15:24:35 open bug: https://bugs.launchpad.net/neutron/+bug/1215387 15:24:50 from bug: We can not stop router forwarding packets by admin_state_up false. Master branch has this problem (stable/grizzly branch don't have the problem). I know the cause. When run router-update --admin_state_up false, transitions as follows: 15:25:02 Swami, I don't see the connection between admin_state_up and rescheduling 15:25:07 could you elaborate the problem? 15:25:12 mrsmith: thanks for the link 15:25:49 swami: np 15:26:32 at agent side if the admin_state_up is false we dont allow port updates for that router 15:26:46 ajo: Yes from our DVR design we were planning to use the "admin_state_up" to disable or disassociate a router from the current agent and then re-associate to a new agent, when an update occurs ( this is for migration when people wanted to migrate from centralized router to distributed router) 15:27:31 Swami, I believe that if admin_state_up is set to False by admin, we may obey that setting, and not schedule the router anywhere 15:28:02 the flag (AFAIK, I could be wrong, I had to read the description several times) means that the router want's this router disabled (for some administrative or security reason) 15:28:14 we can false existing router also 15:28:19 As a team we need to identify if "admin_state_up" can be fixed an used in the way it is designed or else we need to come up with "admin_state_enabled" or "admin_state_distabled" true/false. 15:29:13 Swami, I think you may use some other flag for that 15:29:35 Swami: Do you have to set the router as 'down' in order to migrate it? 15:29:35 but admin_state_enabled or admin_state_disabled doesn't look very descriptive, 15:30:15 Swami, a normal l3-agent-router-remove 15:30:17 amuller: We need to hand over the control of the router to a different agent, when we migrate. 15:30:18 swami for migration admin_state_up may not the right option 15:30:18 would'nt do? 15:30:33 I mean, you remove it from the agent, and then it knows it needs to reschedule somewhere else? 15:30:49 hmm, but I suppose, you need to mark the agent to avoid it for being rescheduled to the same agent again 15:30:53 , is that your problem? 15:31:40 ajo: Yes l3-agent-router-remove will remove the router, but when a router is an operational state, can we move to a different agent. 15:32:07 That is the reason that we wanted to disable the state of the router to inactive and then move the router. 15:32:13 Swami, wouldn't be enough to start the scheduling logic once you remove it from an agent? 15:32:17 Swami: We've been able to migrate a router with admin_state_up=True if that is what you mean. 15:33:27 carl: Thanks that helps. But will there be a network glitch when it happens. 15:33:35 Yes. 15:34:18 ok, thanks for the inputs. 15:34:25 #topic namespace 15:34:49 The next topic is about the router namespace and when to delete the namespace. 15:35:38 In the DVR, we will be starting the IR ( internal router) namespace on all the compute nodes. 15:35:55 But what would be the right approach to clean up the namespaces. 15:36:38 Swami: "all compute nodes" means all compute nodes with a VM on the same network, right? 15:37:26 carl: yes all compute node means with a VM on the compute node and VM being part of a network that is connected to an active router. 15:38:17 Swami, I suppose namespaces need to be cleaned up, when there are no resources in the compute node making use of such namespace 15:38:37 clean up the iptable rules inside the namespace, kill the processes, remove the ports, kill the namespace 15:38:39 Today we are able to create a namespace only if there is a VM in the network, otherwise that compute will not have an active namespace. 15:38:54 that makes sense 15:39:01 Swami: I have to say, this would be a lot more productive if you guys published your code as WIP 15:39:12 Swami: The rest of us would know what problems you guys are facing and try to help 15:39:30 amuller: Thanks for reminding us, we will be publishing the WIP code soon. 15:39:46 We're discussing details right now but we don't have the code, it's very difficult 15:40:12 Swami, 15:40:44 what do you think about the cleaning up the namespace when no VMs on the host are attached to such namespace router, + a timeout 15:40:52 for the case when you shut off / shut on a VM 15:40:59 amuller: As per my previous discussion with the community the work is in progress, and will be posting the WIP code as soon as we have something that can be tested by others. 15:41:09 if after a configurable timeout, no resource is making use of such namespace, it's cleaned up and disposed 15:41:19 Swami: Thank you 15:41:29 ajo: That's what we are thinking on. 15:41:52 yes - I don't think it is a difficult thing to do 15:41:58 is the question whether we should do it or not? 15:42:18 definitely, we should, resources are not limited, 15:42:27 agreed 15:42:33 and if VMs are moving around in a production environment, you could end up with a machine cluttered with namespaces 15:42:42 then sudo degrades, ip netns degrades, ... etc 15:42:51 mrsmith: The question is do we need to handle it and will there be a race condition when we delete a namespace and a VM comes back again. 15:42:55 swami: did you have timing/churn concerns? 15:43:00 Will it not create a performance issue. 15:43:00 ok - right 15:43:12 I do have concerns on performance. 15:43:29 Swami, I'd leave that tuneable... 15:43:40 timeout could be infinite... 15:43:59 ajo: thanks 15:44:07 ok, before we run of time. 15:44:14 but here we need keep on monitiring if someone is using the namespace or not for every change in VM 15:44:25 neutron, definitely has many problems at this stage regarding this, which will eventually be mitigated by better nova/neutron synchronization, but we're having also problems with resources/starvation 15:44:26 I need to discuss about the arbitrary port. 15:44:34 sure 15:44:35 thanks Swami 15:44:49 #topic Router arbitrary port. 15:45:17 Hi folks, in havana, a subnet can be connected to two different routers. 15:45:56 vivek: can you update the status on this 15:46:03 yes swami 15:46:15 for a given router, a subnet could be attached as an interface 15:46:37 similarly for another router by the same tenant, a handcrafted 'port' on the same subnet can be attached as an interface 15:46:53 this would be done by the tenant to typically have multiple gateways for his VMs. 15:47:17 one router dealing with routing some set of internal networks and another router dealing with routing to different set of internal networks 15:47:29 VivekNarasimhan: each router scheduled on a different agent, then configure source routing on your VMs? 15:47:29 but both routers have one interface on the same subnet 15:47:58 i was mention normal routers 15:48:00 not dvr routers 15:48:12 the above scenario mentioned is available for normal routers today 15:48:15 I know 15:48:20 for the dvr we are pursuing the 15:48:30 source mac information is lost, so on the receiving l2-agent 15:48:50 we cannot decide which gateway-port to emulate in the source mac to send the frame to destination VM 15:48:59 Vivek: what you wanted to know is if this is one thing that we need to support for dVR or not. 15:49:09 correct swami 15:49:24 Sounds like a classic follow up blueprint, shouldn't delay DVR imo 15:49:47 My question to the audience is can this be a phase II and can take up this in the next version or it needs to be supported in the first phase. 15:49:57 amuller: agree 15:50:03 I agree too 15:50:16 It would be too much of work to take on everything and so we should push this to a follow on update . 15:50:18 I think it could be a follow-up bp. But, it would be good to have some sense for the feasibility of the follow-up. 15:50:28 we have a feasible design 15:50:34 But we need tracking... At least file the BP 15:50:35 Hope everyone is on the same page. 15:50:41 I agree on carl_baldwin 15:50:46 Vivek: we should take it up in the next release. 15:50:55 Hope this helps. 15:51:03 OK swami. BTW, the design was to allocate some bits in the unique DVR LMAC for subnet differentiation 15:51:05 even if it's not possible to implement now, be sure if it can be supported somehow. 15:51:07 #topic Any Open Discussions 15:51:29 Sorry we ran out of time today. 15:52:00 Is there any other topic that we wanted to discuss. 15:52:27 the duplicate macs in L2-POP 15:52:30 as i dropped out 15:52:30 amuller: You, myself and sylvain need to sync up on the DVR+HR, we can take that as the first topic next week. 15:52:49 can the community folks let me know if thats L2-Pop bug or just a behavior? 15:53:11 vivek: we will check it with sylvain and let you know. 15:53:18 ok swami, thanks 15:53:19 Swami: Ok, if you could send an email with any questions that would help, let me prepare before the meeting... 15:53:20 vivek: thanks for your feedback and input. 15:53:31 amuller: thanks will do. 15:53:32 np 15:53:44 Thanks for everyone who joined the meeting today. 15:53:48 Thanks everyone, see you in tomorrow's L3 meeting :) 15:53:56 Please review the doc and let us know if you have any questions. 15:54:03 Swami: Will do 15:54:11 btw, tomorrow's l3 meeting is same time. I'll send email. 15:54:14 We will make sure that we push the WIP code as early as possible. 15:54:57 Folks tomorrow at the same time we have the L3 subteam meeting, so any general L3 topics can be discussed, if you are interested please join it. 15:54:58 Thanks 15:55:12 #endmeeting