15:01:06 <carl_baldwin> #startmeeting neutron_l3
15:01:07 <openstack> Meeting started Thu Apr 16 15:01:06 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:01:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:11 <openstack> The meeting name has been set to 'neutron_l3'
15:01:37 <carl_baldwin> #topic Announcements
15:01:47 <carl_baldwin> #link https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
15:01:54 <devvesa> hi
15:02:40 <carl_baldwin> RC1 was cut and the master branch is now open for Liberty
15:03:08 <carl_baldwin> The release is set for the 30th, which is two weeks.
15:03:16 <carl_baldwin> #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule
15:03:36 <carl_baldwin> Also the specs repository is open for Liberty.
15:03:49 * carl_baldwin remembers that happened last week
15:04:19 <mlavalle> carl_baldwin: what's the deadline for Liberty specs?
15:04:34 <carl_baldwin> mlavalle, I haven't heard of one yet.
15:04:39 <mlavalle> :-)
15:04:53 <carl_baldwin> mlavalle, I'd say the sooner the better.
15:05:01 <mlavalle> yeap
15:05:23 <carl_baldwin> The summit begins in less than 5 short weeks.
15:05:29 <carl_baldwin> #link https://www.openstack.org/summit/vancouver-2015/
15:05:35 <carl_baldwin> Any other announcements?
15:06:24 <carl_baldwin> #topic Bugs
15:07:12 * carl_baldwin looking for one to bring up
15:08:01 <carl_baldwin> Just one bug that I know of for Kilo.  Bug 1444146
15:08:02 <openstack> bug 1444146 in neutron "Subnet creation from a subnet pool can get wrong ip_version" [Undecided,In progress] https://launchpad.net/bugs/1444146 - Assigned to Ryan Tidwell (ryan-tidwell)
15:08:41 <carl_baldwin> Any other bugs?
15:10:18 <carl_baldwin> #topic bgp-dynamic-routing
15:10:31 <carl_baldwin> devvesa, vikram:  ping
15:10:40 <devvesa> hi
15:10:42 <vikram> hi
15:10:54 <carl_baldwin> We got the spec proposed again for Liberty.
15:10:59 * carl_baldwin was reading through it last night.
15:11:16 * devvesa has to read it cause he does not remember it
15:11:36 <devvesa> sorry about this, I have a very bad memory
15:11:45 <carl_baldwin> I wonder if we should split up the spec to reduce the scope of any single spec.
15:11:50 <vikram> I just had a glance and gave my comments
15:11:58 <carl_baldwin> devvesa, It has been a while, I had to read through it again myself.
15:12:07 <carl_baldwin> vikram, I saw your comments. Thank you.
15:12:13 <devvesa> vikram: I'll read them as well and answer you
15:12:31 <devvesa> carl_baldwin: do you think the scope is so wide?
15:12:54 <vikram> I also felt the spec could be split:)
15:13:00 <carl_baldwin> devvesa, I didn't think so before but I've learned more about how much scope can really fit in to a single development cycle.
15:13:50 <carl_baldwin> vikram, I'd like to hear your thoughts on how to split it.
15:13:56 <devvesa> carl_baldwin, vikram: My feeling is that it can slow down the process of being accepted... but I'll follow your suggestions. You have more experience than me
15:15:07 <vikram> In my opinion I was thinking of defining a framework first and then writing another spec for BGP Speaker as an example
15:15:40 <vikram> IMHO too much info in one umbrella
15:16:00 <tidwellr> *
15:16:04 <tidwellr> ***********
15:16:10 <tidwellr> ***************
15:16:42 <devvesa> If you think that we can define an abstract model for all the routing protocols, that would be great
15:16:54 <vikram> Yup :)
15:17:10 <vikram> that exactly what i was thinking
15:17:10 <devvesa> but (I'm not a big expert) BGP and OSPF are so different that I had to gave up when I thought about it
15:17:39 <vikram> Spec says support for dynamic protocol routing.. so should not be BGP specific
15:17:45 <devvesa> BGP is L3 and OSPF is L2, there is no concept of peers on OSPF...
15:17:59 <vikram> not exactly..
15:18:05 <vikram> i can help on this..
15:18:07 <devvesa> yes, I am completely with you with this, I'm just highlighting the difficulty
15:18:33 <devvesa> vikram: Your help will be very welcomed
15:19:11 <devvesa> Let's start ASAP! :)
15:19:16 <vikram> My pleasure..
15:19:36 <vikram> Sure:)
15:19:45 <carl_baldwin> I was thinking along the lines of reducing the use case of the first BP a bit.  Maybe go for just announcement of routes first and follow on with another BP to learn.
15:21:09 <carl_baldwin> vikram, devvesa:  I'm all for refining the model to be more extensible.  However, I'm worried that we might be increasing scope if we go after multiple protocols to begin with.
15:21:37 <carl_baldwin> That said, I don't want our design to paint us in to a corner for the future.
15:22:53 <vikram> Carl: Saying a generic framework, I meant to refine the existing proposal a bit and make it flexible for future extensibility
15:24:02 <carl_baldwin> vikram, I look forward to seeing your proposals.  Do you plan to add your feedback to the review?
15:25:16 <vikram> Carl, ok... I will document my proposal and send it across.. then we can decide
15:25:29 <vikram> will do it ASAP
15:25:57 <carl_baldwin> vikram, great.  I look forward to it.
15:26:00 <devvesa> great!
15:26:04 <mlavalle> carl_baldwin: earlier this week you sent a message to ML about this BGP efort. If I understood correctly, you were recruiting volunteers. Is my reading correct?
15:26:08 <vikram> sure
15:26:48 <carl_baldwin> mlavalle, I am looking.
15:27:40 <carl_baldwin> mlavalle, Are you expressing interest?
15:28:22 <mlavalle> carl_baldwin: yeah, in the immediate future I wil, help reviewing  / polishing he bp's and specs and see how else I can help
15:28:24 <carl_baldwin> devvesa, vikram:  I guess that's it for today.  We'll look for vikram's proposal and I'll make notes on the spec review about how I might split it up.
15:28:32 <carl_baldwin> mlavalle, great.
15:28:42 <carl_baldwin> Let's move on.
15:28:50 <mlavalle> carl_baldwin: you know i'll need guidance :-)
15:28:51 <carl_baldwin> #topic neutron-ipam
15:29:17 <johnbelamaric> good morning
15:29:34 <pavel_bondar> hi, john
15:29:37 <carl_baldwin> johnbelamaric, salv-orl_, pavel_bondar, tidwellr_: hi
15:30:22 <johnbelamaric> pavel_bondar: can you provide current status on your patch?
15:30:39 * carl_baldwin just realized he didn't post draft comments on https://review.openstack.org/#/c/172443
15:31:18 <johnbelamaric> carl_baldwin: ah - ok. Based on teh ML discussion this is moving into implementing taskflow it sounded like. it's a pretty major rework
15:31:18 <pavel_bondar> yeah, the number of failures for #link https://review.openstack.org/#/c/153236/ decreased to one digit number, so looks like we are not far from clear pass
15:32:15 <salv-orl_> johnbelamaric: bringing something to the mailing list is like triggering an avalanche
15:32:26 <johnbelamaric> salv-orl_: :(
15:32:57 <salv-orl_> johnbelamaric: taskflow might come in the future not now.
15:33:42 <salv-orl_> btw, did you receive irc feedback - afaict there has been no reply in the past 6 days
15:33:49 <salv-orl_> or is it my mail client hiding mail from me?
15:33:56 <johnbelamaric> salv-orl_: nope. nothing. radio silence
15:34:18 <salv-orl_> johnbelamaric: it was the RC week, that is understandable
15:34:35 <johnbelamaric> savl-orl_: wait, only 2 days
15:34:54 <johnbelamaric> salv-orl_: my last mail was 2 days ago
15:35:30 <carl_baldwin> Right, I see johnbelamaric 's reply from 2 days ago.
15:35:41 * carl_baldwin was finishing his taxes.
15:36:03 <johnbelamaric> carl_baldwin: fun fun - i got mine done early this year
15:36:31 <carl_baldwin> I usually do too.  Busy year.  ;)
15:37:13 <johnbelamaric> carl_baldwin: I haven't had a chance to look at this anymore since then. I should have more time next week. I think create_port is probably the worst one - subnets are probably easier.
15:37:38 <johnbelamaric> carl_baldwin: Still - it's a substantial effort touching a lot of code
15:37:44 <carl_baldwin> johnbelamaric, subnets?
15:38:05 <johnbelamaric> carl_badwin: I mean, create/update/delete subnet
15:38:20 <carl_baldwin> Are you talking about automatic subnet allocation paths?
15:38:28 <johnbelamaric> carl_baldwin: IPAM touches create/update/delete port and create/update/delete subnet + the new pools piece
15:38:51 <johnbelamaric> carl_baldwin: so, if we are going to pull IPAM calls outside the transaction, we will be touching all those areas
15:39:10 <carl_baldwin> johnbelamaric, right.  We have the advantage with subnet allocation that all of that is new and created by us.
15:39:38 <johnbelamaric> carl_baldwin: yep. that one is more easily handled.
15:39:51 <carl_baldwin> afaik, there are no cases where subnet allocation is triggered by anything else but a direct API call.
15:40:09 <johnbelamaric> carl_baldwin: that would be good - it's pretty simple to do that
15:40:33 <salv-orl_> johnbelamaric, carl_baldwin: I bg to differ here... with subnet allocation happening in db_base_plugin_v2 we are supposed to do the call to the driver for allocations pools there
15:40:39 <carl_baldwin> johnbelamaric, There is one snafu with subnet deletion, though that we need to fix.  Delete cascades from a network to a subnet.
15:40:59 <tidwellr_> carl_baldwin: I was looking at that
15:41:10 <tidwellr_> I'm not sure that's really the case
15:41:29 <pavel_bondar> <carl_baldwin>: looks like it explicetely calls delete_subent() from delete_network()
15:41:29 <johnbelamaric> salv-orl_: We would have to do that, yes. The issue is the number of code paths that call into create/update/delete subnets. There are not so many like there are with ports.
15:42:18 <johnbelamaric> salv-orl_: my point is it's probably doesn't touch too much to do it just for subnets (though I have not confirmed this). But for create_port it's a lot of change.
15:42:29 <carl_baldwin> johnbelamaric, right.  We should probably stay focused on the create_port code paths for now.  Granted, we may have some work to do with subnet allocation but I don't want to take a tangeant here.
15:42:42 <carl_baldwin> *tangent
15:43:48 <carl_baldwin> johnbelamaric, are you offering to write the bp for teasing out the transactions?
15:44:05 <salv-orl_> carl_baldwin: what's this bluepritn?
15:44:26 <johnbelamaric> carl_baldwin: I could work on that, yes. I think it will require a lot of community feedback - I think there are lots of decisions on how it may be done.
15:44:44 <carl_baldwin> salv-orl_, http://lists.openstack.org/pipermail/openstack-dev/2015-April/061444.html
15:45:12 <carl_baldwin> ^ Third paragraph.
15:45:29 <salv-orl_> carl_baldwin: this is the email that I missed
15:45:46 <salv-orl_> I think it's still the plugabble-ipam blueprint not a new one
15:46:11 <salv-orl_> even if it's approved for neutron I think we should amend that
15:46:38 <salv-orl_> unless you want to have a blueprint to seek approval and community feedback before doing the code
15:46:48 <salv-orl_> in that case you're in for "add taskflow" feedback
15:47:02 <johnbelamaric> salv-orl_: based on the amount of discussion from the ML (Kevin suggesting taskflow), etc. I thought this was getting to big.
15:47:08 <johnbelamaric> salv-orl_: yes, that's where I saw this going
15:47:30 <salv-orl_> johnbelamaric: if we want to miss liberty that's the direction we should go towards
15:47:33 <johnbelamaric> salv-orl_: If we are re-working that much code, will the community accept it done without more discussion
15:47:52 <salv-orl_> unless your plan is to feed a spec to the community and in the meanwhile merge the work as it is
15:47:53 <johnbelamaric> salv-orl_: I hear you. Which is why I wanted to proceed with pavel_bondar's changes.
15:48:01 <salv-orl_> johnbelamaric: cunning ;)
15:48:04 <johnbelamaric> salv-orl_: that's what I was hoping :)
15:48:12 <salv-orl_> cunning, but smart
15:49:09 <salv-orl_> ok, if that's the plan than let's go ahead with it.
15:49:34 <johnbelamaric> salv-orl_: great, carl_baldwin - sound reasonable to you?
15:49:37 <salv-orl_> johnbelamaric: your 1st priorirty should probably be to champion pavel_bondar patch as it is
15:49:39 <carl_baldwin> salv-orl_, could you restate the plan just to be clear?
15:49:58 <salv-orl_> yeah, merge the work that missed liberty as it is
15:50:01 <carl_baldwin> I agree we can move forward with pavel_bondar 's patch 1st.
15:50:06 <salv-orl_> so that we have pluggable ipam
15:50:08 <johnbelamaric> salv-orl_: Ok, agreed
15:50:19 <salv-orl_> and feed a spec to the community so that they can fight for the best solution
15:50:25 <johnbelamaric> carl_baldwin: Ok, let's do it then
15:50:35 <salv-orl_> that would be the point when johnbelamaric says "mission achieved"
15:50:38 <carl_baldwin> +1
15:50:39 <salv-orl_> ;)
15:50:42 <pavel_bondar> sounds good
15:50:49 <johnbelamaric> salv-orl_: :) yep, thank you
15:51:37 <johnbelamaric> carl_baldwin: salv-orl_: any thoughts on who I should pull into the taskflow spec. I am happy to lead that but not a taskflow expert in any way at all
15:53:41 <carl_baldwin> I know very little about task flow but could learn.
15:54:24 <johnbelamaric> carl_baldwin: salv-orl_: ok, what I will do is start a spec detailing some of the issues and concerns (ie, requirements!) and let the community start to present ideas for the solutions
15:54:39 <carl_baldwin> johnbelamaric, sounds good.
15:54:46 <carl_baldwin> Anything else for spam?
15:55:14 <johnbelamaric> carl_baldwin: lovely auto-correct. No nothing more more IPAM
15:55:52 * carl_baldwin didn't even notice the auto-correct.
15:56:21 <carl_baldwin> #topic Open Discussion
16:07:43 <carl_baldwin> #endmeeting