15:00:19 #startmeeting neutron_l3 15:00:21 tidwellr: hi 15:00:24 Meeting started Thu Jan 22 15:00:19 2015 UTC and is due to finish in 60 minutes. The chair is carl_baldwin. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:27 The meeting name has been set to 'neutron_l3' 15:00:41 mrsmith_: hi 15:00:47 hi 15:00:49 o/ 15:00:59 ihrachyshka: hi 15:01:07 #topic Announcements 15:01:12 hi 15:01:25 Kilo-2 is in 2 weeks 15:01:27 mlavalle: hi 15:01:36 Any other announcements? 15:01:55 #link https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam 15:02:32 #topic Bugs 15:03:00 I don’t know of any new bugs that have come up recently. Are there any we should know about? 15:03:23 I was testing migration last night 15:03:29 I think we may have regressed 15:03:42 I'll file a LP if I can confirm 15:04:31 mrsmith_: Let me know. You were testing with the recent refactoring patches merged? 15:04:52 carl_baldwin: correct... latest upstream 15:05:24 mrsmith_: I was worried about that one that removed the mixins and adds the routers. 15:05:45 mrsmith_: Are you talking about the bugs. 15:05:50 carl_baldwin: right... I remember I tested an early version of that 15:05:53 Swami: yes. 15:05:59 carl_baldwin: thanks 15:06:27 mrsmith_: I don’t think it changed much since then. 15:06:35 Swami: did you want to mention one about ml2? 15:06:36 mrsmith_: Let me know what you find. 15:06:50 carl_baldwin: right.... thats why I want to test more to confirm 15:06:58 mrsmith_: Thanks. 15:07:02 The ml2 one I have already filed a bug and pushed a patch. 15:07:22 But for the router not unbinding when router interfaces are removed - i need to file a bug. 15:07:53 did you find some time to verify what' s being claimed here: http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg44008.html ? 15:08:00 Swami: The ml2 one is the one you emailed about yesterday, right? 15:08:02 Also for qrouter namespace existence even when there are no valid router interface ports is another bug. 15:08:14 carl_baldwin: yes 15:10:08 the thing discussed in the email thread seems a bit odd to me because in the gate the pg jobs use metadata rather than config drive. 15:11:24 salv-orlando: The iptables email thread? 15:11:37 carl_baldwin: yup 15:12:38 salv-orlando: I was thinking along the same lines but haven’t had time to look at it yet this week. Very full schedule. There has been some work on metadata recently. 15:13:08 I was hoping haleyb could field that one. Any insight there, Brian? 15:13:11 iptables service not running maybe? 15:13:51 ihrachyshka: that would be an explanation. 15:14:08 ihrachyshka: What exactly is an iptables service? 15:14:25 carl_baldwin: I understood it as netfilter not running 15:14:37 carl_baldwin, in case of rhel, it's systemd service that would load modules etc. 15:14:49 Like, the module not loaded? 15:15:09 yeah 15:15:09 but the reporter did "iptables --list" on the network node - if the module wasn't loaded, that should not work as well. 15:15:36 salv-orlando: agreed. I was going to say essentially the same. 15:15:38 ah ok 15:18:02 Well, we should get a bug reported about the problem anyway. I think we need some more information and to try to reproduce it. 15:19:34 Any more discussion? Swami, mrsmith_: Anything more on the above bugs? 15:19:40 quick note back on my migration prob - 15:19:52 I think I was seeing agent crashes and restarts 15:20:03 even on basic centralized snat operations 15:20:14 thats part of what I want to confirm 15:20:45 I kept seeing the config getting reloaded in the agent log 15:21:08 mrsmith_: That doesn’t sound good. Any backtraces? 15:21:21 no.. just multiple config reloads :) 15:21:28 I'll debug more 15:21:58 mrsmith_: Thank you. 15:22:36 carl_baldwin: agent does not remove namespaces as well. 15:22:50 Even when "router_delete_namespaces" are configured. 15:23:00 Swami: I was just going to ask about that. 15:23:01 I will file a bug on this today. 15:23:26 Swami: Thank you. 15:23:27 if the agent is crashing and unknown points..... we'll get unexpected behavor 15:24:28 Swami: mrsmith_: I will be available tomorrow to look at these in depth. 15:24:40 k - I'll let you know what I find 15:24:58 mrsmith_: Thank you. 15:25:03 ok, mean while I will triage more and provide details on the bugs. 15:25:56 Swami: and thank you. When you file new bug reports, send me the numbers. I’ll try to look at them today but will make them a priority tomorrow morning. 15:26:16 ok 15:26:47 #topic L3 Agent Restructuring 15:27:53 A few things merged this week. We need to step back and resolve these bugs before merging more. 15:28:29 Can we try to get functional tests written to expose the problems? 15:28:38 … that would be ideal. 15:28:44 ideal yes 15:29:24 +1 15:29:27 Either way, we need to take care of the bugs before going further. 15:29:50 mlavalle: Do you have anything to discuss? 15:29:53 on a side note - did you get a chance to look at my inheritance changes in the dvr-ha patch? 15:30:10 for the dvr_ha_router. class? 15:30:16 Is there a list about these bugs? I just came in. 15:30:36 mrsmith_: I haven’t seen them yet. 15:30:47 carl_baldwin: two things. I have been working on https://review.openstack.org/#/c/147744/. I fixed all the unit tests that were broken and currently debbuging some tempest tests that are failing 15:31:12 k - just curious about what people think of how I did the multiple inheritance (removed some __init__ code) 15:31:25 OK. 15:32:12 #link https://review.openstack.org/#/c/139686/13/neutron/agent/l3/dvr_ha_router.py 15:32:16 carl_baldwin: Yesterday I spent the afternoon analyzing namespaces after creating fips and assigned them to instances. It's working fine 15:32:25 mrsmith_: ^ I will look when we get the bugs squared away. 15:32:58 BrianShsng: Some of them do not have bug reports yet. 15:32:58 carl_baldwin: yup - sounds good 15:33:33 The L3 subteam page has links to bug lists for l3 (under the Bugs topic) and dvr (under the neutron-ovs-dvr topic) 15:33:42 OK, thank you carl_baldwin. 15:35:25 I’m still shooting for kilo-2 to have the heavy lifting done in the l3 agent. That may be too optimistic if these bugs prove difficult to resolve but I don’t want it to drag much in to kilo-3. Thank you all for your patience here. 15:35:59 #topic neutron-ipam 15:36:08 salv-orlando: ping 15:36:09 I'm here today for this ;) 15:36:19 hello 15:36:27 so in the past two weeks we really started making progress, i believe 15:37:06 johnbelamaric: hi 15:37:14 from my side I am implementing the reference driver - which I will push in a non-integrated fashion. Meaning that it will be a piece of standlone code with unit tests 15:37:14 yes, pavel_bondar and salv-orlando have both been progressing 15:37:25 then pavel_bondar will provide the necessary glue 15:37:35 yes 15:37:43 at this stage I have over 800 lines of code. I expect the code to reach 2,000 just for the reference driver 15:37:46 salv-orlando: Are there reviews that I should be looking at? 15:37:58 carl_baldwin: I will push some code tomorrow 15:38:13 salv-orlando: Ah, okay. I was afraid I had missed it. 15:38:16 the only current issue I know of is handling of allocation pools - i think we should move their managment to the driver 15:38:19 not yet complete neither working, but it will give pavel_bondar a better idea of what code should be left in db_base_plugin 15:38:35 by "management" I mean auto-generation and validation, NOT db storage - that would still be in db_base 15:39:10 johnbelamaric: yes I think we can leave this decision to the driver. The downside is that we aren't able to make a guarantee at the API level on the pool allocation strategy 15:39:18 but I guess that's fine 15:39:31 salv-orlando: right, driver could return error 15:39:45 I don't think we need to mandate that every neutron deployment allocates IP pools in the same way 15:40:07 salv-orlando: agreed 15:40:08 salv-orlando, agree, some draft version of your code would help me a lot 15:40:17 carl_baldwin: do you have an opinion, either weak or strong, on this matter? 15:40:57 salv-orlando: I’m not sure I understand the issue yet. 15:40:59 * salv-orlando is referring to delegate ip allocation pools to the driver 15:41:22 basically so far the logic is pretty easy. Either the user specified them or neutron allocates them for you 15:41:55 carl_baldwin: so the change would be that the driver can reject the user-specified ones, and that the driver generates them not neutron if not provided 15:41:59 In the first case, there will be an hook to the driver during the validation of the pools, as some drivers have "reserved" zones that users are not allowed to use 15:42:05 salv-orlando: Right. I imagined that they would be delegated to the driver. 15:42:56 carl_baldwin: ok that's fine. This leads me to the next topic where there might be discussion 15:43:13 should the driver be able to access the neutron database? I went back and forth a lot of times 15:43:25 and it seems to me that probably it should. 15:43:38 salv-orlando: my opinion - yes - but probably read-only 15:44:12 johnbelamaric: I was of the same opinion, but in that case it would awkward letting the driver allocate ip pools 15:44:28 anyway this is something for which we don't need to use meeting time 15:44:38 we can take that offline on irc or ml. 15:44:54 salv-orlando: ok let's discuss offline - not seeing it as too awkward but we can discuss later 15:45:07 salv-orlando: I’ll be offline most of today. Maybe an ML would be best. 15:45:32 salv-orlando: ok - i also did CC you on a direct email with Pavel yesterday if you haven't seen it 15:45:37 I just wanted to complete the update on my site stating that the "reference driver" operates similarly to the current code, but I expect to do that in a better way - that is to say, for instance, no locking queries 15:45:44 johnbelamaric: seen 15:45:59 salv-orlando: ok, we can move it to ML 15:46:25 this means the IP allocation logic might be slight different. My question is: do we prefer to stay on the path of what we already know to work even if not perfectly 15:46:29 salv-orlando: No locking queries would be nice. 15:46:53 or do we prefer to also have better code, which however means different and untested code as well? 15:47:34 personally I prefer to also use this refactoring to solve these IPAM long-standing issues 15:47:58 but if the community feels we should not do too much at the same time I can just keep the current allocation algorithms 15:48:03 that's all from me. 15:48:08 salv-orlando: We could do that but if the two come together it may be difficult to resolve issues that come up. 15:48:49 salv-orlando: perhaps start with the current code, you can even subclass the driver and create an alternate with new code, so we always have fallback if new code has issues 15:49:17 salv-orlando: I’d like to see how you suggest changing the allocation logic. 15:50:21 tidwellr: Are you still around? Anything new on subnet allocation? 15:50:35 https://review.openstack.org/#/c/148698/ 15:50:50 very raw, not ready to go, but progressing 15:51:18 I'm tackling basic CRUD on subnetpools first, the meat of of it is still to come 15:51:41 tidwellr: Great to see something up in gerrit. 15:52:03 carl_baldwin: I will share that on the mailing list as well (non l,ocking IP allocation strategy) 15:52:22 salv-orlando: Thank you. I will watch for it. 15:53:30 salv-orlando: I know you’ve got tons more spare time. ;) I was wondering if you could take a high level look at tidwellr ’s patch above to see if it is going in the right direction for the API additions. 15:54:06 "right direction" being the key 15:54:12 still very raw 15:55:06 Anything else on ipam? 15:55:21 carl_baldwin: not from me 15:55:53 nope 15:56:00 #topic neutron-ovs-dvr 15:56:14 mrsmith_: Rajeev_: Anything else here? 15:56:51 carl_baldwin: no, got plenty to do for now. 15:56:59 we need adolfo's functional test patches to get merged 15:57:47 I mentioned the l3-ha patch - that needs some looks 15:58:06 I still see some disagreement on the l2pop patch 15:58:16 mrsmith_: Could you ping marun on that one? I hope to look at it soon but, to be honest, it isn’t looking good for me. 15:58:34 mrsmith_: ^ adolfo’s specifically 15:58:34 adolfo is pinging marun I believe 15:58:40 mrsmith_: Great. 15:58:42 +1 15:59:04 mrsmith_: At this point, I’m ready to say if marun is happy then I’ll probably be happy with the patch. 15:59:39 once that is merged we can all write more dvr functional tests (like ha) 16:00:14 mrsmith_: That would be very good. 16:00:33 Sorry we’re out of time. 16:00:51 #endmeeting