15:00:19 <carl_baldwin> #startmeeting neutron_l3
15:00:21 <carl_baldwin> tidwellr: hi
15:00:24 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:27 <openstack> The meeting name has been set to 'neutron_l3'
15:00:41 <carl_baldwin> mrsmith_: hi
15:00:47 <mrsmith_> hi
15:00:49 <ihrachyshka> o/
15:00:59 <carl_baldwin> ihrachyshka: hi
15:01:07 <carl_baldwin> #topic Announcements
15:01:12 <mlavalle> hi
15:01:25 <carl_baldwin> Kilo-2 is in 2 weeks
15:01:27 <carl_baldwin> mlavalle: hi
15:01:36 <carl_baldwin> Any other announcements?
15:01:55 <carl_baldwin> #link https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
15:02:32 <carl_baldwin> #topic Bugs
15:03:00 <carl_baldwin> I don’t know of any new bugs that have come up recently.  Are there any we should know about?
15:03:23 <mrsmith_> I was testing migration last night
15:03:29 <mrsmith_> I think we may have regressed
15:03:42 <mrsmith_> I'll file a LP if I can confirm
15:04:31 <carl_baldwin> mrsmith_: Let me know.  You were testing with the recent refactoring patches merged?
15:04:52 <mrsmith_> carl_baldwin: correct... latest upstream
15:05:24 <carl_baldwin> mrsmith_: I was worried about that one that removed the mixins and adds the routers.
15:05:45 <Swami> mrsmith_: Are you talking about the bugs.
15:05:50 <mrsmith_> carl_baldwin: right... I remember I tested an early version of that
15:05:53 <carl_baldwin> Swami: yes.
15:05:59 <Swami> carl_baldwin: thanks
15:06:27 <carl_baldwin> mrsmith_: I don’t think it changed much since then.
15:06:35 <mrsmith_> Swami:  did you want to mention one about ml2?
15:06:36 <carl_baldwin> mrsmith_: Let me know what you find.
15:06:50 <mrsmith_> carl_baldwin: right.... thats why I want to test more to confirm
15:06:58 <carl_baldwin> mrsmith_: Thanks.
15:07:02 <Swami> The ml2 one I have already filed a bug and pushed a patch.
15:07:22 <Swami> But for the router not unbinding when router interfaces are removed - i need to file a bug.
15:07:53 <salv-orlando> 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 <carl_baldwin> Swami: The ml2 one is the one you emailed about yesterday, right?
15:08:02 <Swami> Also for qrouter namespace existence even when there are no valid router interface ports is another bug.
15:08:14 <Swami> carl_baldwin: yes
15:10:08 <salv-orlando> 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 <carl_baldwin> salv-orlando: The iptables email thread?
15:11:37 <salv-orlando> carl_baldwin: yup
15:12:38 <carl_baldwin> 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 <carl_baldwin> I was hoping haleyb could field that one.  Any insight there, Brian?
15:13:11 <ihrachyshka> iptables service not running maybe?
15:13:51 <salv-orlando> ihrachyshka: that would be an explanation.
15:14:08 <carl_baldwin> ihrachyshka: What exactly is an iptables service?
15:14:25 <salv-orlando> carl_baldwin: I understood it as netfilter not running
15:14:37 <ihrachyshka> carl_baldwin, in case of rhel, it's systemd service that would load modules etc.
15:14:49 <carl_baldwin> Like, the module not loaded?
15:15:09 <ihrachyshka> yeah
15:15:09 <salv-orlando> 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 <carl_baldwin> salv-orlando: agreed.  I was going to say essentially the same.
15:15:38 <ihrachyshka> ah ok
15:18:02 <carl_baldwin> 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 <carl_baldwin> Any more discussion?  Swami, mrsmith_:  Anything more on the above bugs?
15:19:40 <mrsmith_> quick note back on my migration prob -
15:19:52 <mrsmith_> I think I was seeing agent crashes and restarts
15:20:03 <mrsmith_> even on basic centralized snat operations
15:20:14 <mrsmith_> thats part of what I want to confirm
15:20:45 <mrsmith_> I kept seeing the config getting reloaded in the agent log
15:21:08 <carl_baldwin> mrsmith_: That doesn’t sound good.  Any backtraces?
15:21:21 <mrsmith_> no.. just multiple config reloads :)
15:21:28 <mrsmith_> I'll debug more
15:21:58 <carl_baldwin> mrsmith_: Thank you.
15:22:36 <Swami> carl_baldwin: agent does not remove namespaces as well.
15:22:50 <Swami> Even when "router_delete_namespaces" are configured.
15:23:00 <carl_baldwin> Swami: I was just going to ask about that.
15:23:01 <Swami> I will file a bug on this today.
15:23:26 <carl_baldwin> Swami: Thank you.
15:23:27 <mrsmith_> if the agent is crashing and unknown points..... we'll get unexpected behavor
15:24:28 <carl_baldwin> Swami: mrsmith_:  I will be available tomorrow to look at these in depth.
15:24:40 <mrsmith_> k - I'll let you know what I find
15:24:58 <carl_baldwin> mrsmith_: Thank you.
15:25:03 <Swami> ok, mean while I will triage more and provide details on the bugs.
15:25:56 <carl_baldwin> 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 <Swami> ok
15:26:47 <carl_baldwin> #topic L3 Agent Restructuring
15:27:53 <carl_baldwin> A few things merged this week.  We need to step back and resolve these bugs before merging more.
15:28:29 <carl_baldwin> Can we try to get functional tests written to expose the problems?
15:28:38 <carl_baldwin> … that would be ideal.
15:28:44 <mrsmith_> ideal yes
15:29:24 <Swami> +1
15:29:27 <carl_baldwin> Either way, we need to take care of the bugs before going further.
15:29:50 <carl_baldwin> mlavalle: Do you have anything to discuss?
15:29:53 <mrsmith_> on a side note - did you get a chance to look at my inheritance changes in the dvr-ha patch?
15:30:10 <mrsmith_> for the dvr_ha_router. class?
15:30:16 <BrianShsng> Is there a list about these bugs? I just came in.
15:30:36 <carl_baldwin> mrsmith_: I haven’t seen them yet.
15:30:47 <mlavalle> 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 <mrsmith_> k - just curious about what people think of how I did the multiple inheritance (removed some __init__ code)
15:31:25 <BrianShsng> OK.
15:32:12 <carl_baldwin> #link https://review.openstack.org/#/c/139686/13/neutron/agent/l3/dvr_ha_router.py
15:32:16 <mlavalle> carl_baldwin: Yesterday I spent the afternoon analyzing namespaces after creating fips and assigned them to instances. It's working fine
15:32:25 <carl_baldwin> mrsmith_: ^ I will look when we get the bugs squared away.
15:32:58 <carl_baldwin> BrianShsng: Some of them do not have bug reports yet.
15:32:58 <mrsmith_> carl_baldwin: yup - sounds good
15:33:33 <carl_baldwin> 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 <BrianShsng> OK, thank you carl_baldwin.
15:35:25 <carl_baldwin> 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 <carl_baldwin> #topic neutron-ipam
15:36:08 <carl_baldwin> salv-orlando: ping
15:36:09 <salv-orlando> I'm here today for this ;)
15:36:19 <johnbelamaric> hello
15:36:27 <salv-orlando> so in the past two weeks we really started making progress, i believe
15:37:06 <carl_baldwin> johnbelamaric: hi
15:37:14 <salv-orlando> 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 <johnbelamaric> yes, pavel_bondar and salv-orlando have both been progressing
15:37:25 <salv-orlando> then pavel_bondar will provide the necessary glue
15:37:35 <pavel_bondar> yes
15:37:43 <salv-orlando> 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 <carl_baldwin> salv-orlando: Are there reviews that I should be looking at?
15:37:58 <salv-orlando> carl_baldwin: I will push some code tomorrow
15:38:13 <carl_baldwin> salv-orlando: Ah, okay.  I was afraid I had missed it.
15:38:16 <johnbelamaric> 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 <salv-orlando> 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 <johnbelamaric> by "management" I mean auto-generation and validation, NOT db storage - that would still be in db_base
15:39:10 <salv-orlando> 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 <salv-orlando> but I guess that's fine
15:39:31 <johnbelamaric> salv-orlando: right, driver could return error
15:39:45 <salv-orlando> I don't think we need to mandate that every neutron deployment allocates IP pools in the same way
15:40:07 <johnbelamaric> salv-orlando: agreed
15:40:08 <pavel_bondar> salv-orlando, agree, some draft version of your code would help me a lot
15:40:17 <salv-orlando> carl_baldwin: do you have an opinion, either weak or strong, on this matter?
15:40:57 <carl_baldwin> 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 <salv-orlando> basically so far the logic is pretty easy. Either the user specified them or neutron allocates them for you
15:41:55 <johnbelamaric> 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 <salv-orlando> 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 <carl_baldwin> salv-orlando: Right.  I imagined that they would be delegated to the driver.
15:42:56 <salv-orlando> carl_baldwin: ok that's fine. This leads me to the next topic where there might be discussion
15:43:13 <salv-orlando> should the driver be able to access the neutron database? I went back and forth a lot of times
15:43:25 <salv-orlando> and it seems to me that probably it should.
15:43:38 <johnbelamaric> salv-orlando: my opinion - yes - but probably read-only
15:44:12 <salv-orlando> johnbelamaric: I was of the same opinion, but in that case it would awkward letting the driver allocate ip pools
15:44:28 <salv-orlando> anyway this is something for which we don't need to use meeting time
15:44:38 <salv-orlando> we can take that offline on irc or ml.
15:44:54 <johnbelamaric> salv-orlando: ok let's discuss offline - not seeing it as too awkward but we can discuss later
15:45:07 <carl_baldwin> salv-orlando: I’ll be offline most of today.  Maybe an ML would be best.
15:45:32 <johnbelamaric> salv-orlando: ok - i also did CC you on a direct email with Pavel yesterday if you haven't seen it
15:45:37 <salv-orlando> 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 <salv-orlando> johnbelamaric: seen
15:45:59 <johnbelamaric> salv-orlando: ok, we can move it to ML
15:46:25 <salv-orlando> 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 <carl_baldwin> salv-orlando: No locking queries would be nice.
15:46:53 <salv-orlando> or do we prefer to also have better code, which however means different and untested code as well?
15:47:34 <salv-orlando> personally I prefer to also use this refactoring to solve these IPAM long-standing issues
15:47:58 <salv-orlando> 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 <salv-orlando> that's all from me.
15:48:08 <carl_baldwin> 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 <johnbelamaric> 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 <carl_baldwin> salv-orlando: I’d like to see how you suggest changing the allocation logic.
15:50:21 <carl_baldwin> tidwellr: Are you still around?  Anything new on subnet allocation?
15:50:35 <tidwellr> https://review.openstack.org/#/c/148698/
15:50:50 <tidwellr> very raw, not ready to go, but progressing
15:51:18 <tidwellr> I'm tackling basic CRUD on subnetpools first, the meat of of it is still to come
15:51:41 <carl_baldwin> tidwellr: Great to see something up in gerrit.
15:52:03 <salv-orlando> carl_baldwin: I will share that on the mailing list as well (non l,ocking IP allocation strategy)
15:52:22 <carl_baldwin> salv-orlando: Thank you.  I will watch for it.
15:53:30 <carl_baldwin> 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 <tidwellr> "right direction" being the key
15:54:12 <tidwellr> still very raw
15:55:06 <carl_baldwin> Anything else on ipam?
15:55:21 <johnbelamaric> carl_baldwin: not from me
15:55:53 <tidwellr> nope
15:56:00 <carl_baldwin> #topic neutron-ovs-dvr
15:56:14 <carl_baldwin> mrsmith_: Rajeev_:  Anything else here?
15:56:51 <Rajeev_> carl_baldwin: no, got plenty to do for now.
15:56:59 <mrsmith_> we need adolfo's functional test patches to get merged
15:57:47 <mrsmith_> I mentioned the l3-ha patch - that needs some looks
15:58:06 <mrsmith_> I still see some disagreement on the l2pop patch
15:58:16 <carl_baldwin> 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 <carl_baldwin> mrsmith_: ^ adolfo’s specifically
15:58:34 <mrsmith_> adolfo is pinging marun I believe
15:58:40 <carl_baldwin> mrsmith_: Great.
15:58:42 <mrsmith_> +1
15:59:04 <carl_baldwin> 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 <mrsmith_> once that is merged we can all write more dvr functional tests (like ha)
16:00:14 <carl_baldwin> mrsmith_: That would be very good.
16:00:33 <carl_baldwin> Sorry we’re out of time.
16:00:51 <carl_baldwin> #endmeeting