17:31:39 #startmeeting Networking Advanced Services 17:31:40 Meeting started Wed May 28 17:31:39 2014 UTC and is due to finish in 60 minutes. The chair is SumitNaiksatam. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:31:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:31:43 The meeting name has been set to 'networking_advanced_services' 17:31:51 #info agenda: https://wiki.openstack.org/wiki/Meetings/AdvancedServices 17:32:08 we have a packed agenda 17:32:26 i will like to address some process issues towards the end of the meeting 17:32:26 SumitNaiksatam: there is no news there :-) 17:32:29 in the open discussion 17:32:35 cgoncalves: :-) 17:32:47 lets get rolling 17:32:59 #topic Juno planning and feature tracking 17:33:10 #link https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan 17:33:31 last week we decided to start using this table as record of our priorities 17:33:40 and what we want to track first in this meeting 17:33:46 a couple of items got added to that table 17:34:23 in addition, the PTL has set milestone dates on the blueprints 17:34:35 Juno 1 blueprints (as set by PTL): 17:34:44 #link https://launchpad.net/neutron/+milestone/juno-1 17:34:53 Juno 2 blueprints (as set by PTL): 17:35:05 #link https://launchpad.net/neutron/+milestone/juno-2 17:35:30 most of what we are tracking in this meeting was earlier slated for Juno 1 17:35:46 however, if you see above, it has now been pushed to Juno 2 17:36:00 @Sumit: I assume we can ask about items that are "not set" during the individual project updates? 17:36:07 my understanding is this is on account of the fact that the blueprint specs have not been approved yet 17:36:30 regXboi: i am not sure i completely got that, but please go ahead 17:36:52 Looking at the table I see certain items that are marked "Not Set" for Milestone 17:37:05 I wanted to ask if we could bring those up during the individual project updates 17:37:14 regXboi: oh yeah, definitely 17:37:18 thanks 17:37:30 regXboi: the expectation is that each task owner should set these 17:37:42 ok 17:37:47 regXboi: and we should track them here 17:38:03 regXboi: if these are not set during this week, we have to investigate why 17:38:22 sound good - thanks for the answer 17:38:25 regXboi: we cannot track things without milestones being set (we already well into Juno 1 now) 17:38:50 ok, so summary from the above links, we have already been pushed into Juno 2 17:39:12 realistically, this was going to be the case 17:39:20 SumitNaiksatam: items with BPs not yet approved are no worth setting milestones 17:39:33 however, we have to make sure that we make enough progress in Juno 1 as well 17:39:54 cgoncalves: we should set the milestones as to how we would want to pursue them 17:40:14 cgoncalves: and accordingly socialize with the PTL and the bigger neutron core team 17:40:21 SumitNaiksatam: ok 17:40:26 cgoncalves: if they do not agree, we can reconcile with that 17:40:43 cgoncalves: but as taks owners, the initial esitmate has to come from you 17:40:51 cgoncalves: do others agree? 17:41:05 question for everyone, rather 17:41:16 SumitNaiksatam: ok, agreed. I'll set them after meeting 17:41:22 ok 17:41:47 so i propose that we go through each individual task items on the agenda 17:41:55 and then circle back to the process discussion 17:42:07 i want to spend some time on it 17:42:16 #topic Service base definition and Insertion 17:42:31 we are still in spec review: #link https://review.openstack.org/#/c/93128 17:42:44 is Kanzhe here? 17:42:55 i know s3wong is not 17:43:08 kevinbenton: do you know if kanzhe is around? 17:43:25 looking at the review, does not seem like much progress 17:43:39 if kanzhe, joins we can circle back to this 17:43:55 anything anyone wants to bring up on this? 17:44:00 SumitNaiksatam: that was the first place I wanted to circle back on 17:44:08 regXboi: sure, go ahead 17:44:12 specifically the HEAT line 17:44:24 yeah 17:44:37 SumitNaiksatam: you skipped the flavor framework, no? 17:45:17 cgoncalves: yes i will come to it 17:45:29 Kanzhe: :-) 17:45:30 I believe Kanzhe has joined 17:45:32 regXboi: go ahead 17:45:42 sorry, got stuck in a diffferent meeting. 17:46:08 I'm looking through the BP and wondering if we need to put some more detail relating to heat to get from "Not Set" to a milestone 17:47:15 or is it here and I'm missing it? 17:47:22 Kanzhe: is the Heat owner identified for this? 17:47:46 About ServiceInsertion? not yte. 17:47:49 yet. 17:47:54 Kanzhe: ok 17:48:26 Should I give a quick update? 17:48:34 Kanzhe: can i request that we scope this, and identify the owner by next week? 17:48:54 Yes. 17:48:59 Kanzhe: thanks 17:49:09 regXboi: you want to participate in that? 17:49:22 regXboi: please reach out to Kanzhe if you do (for this item) 17:49:34 Kanzhe: yes please go ahead with the update 17:49:34 If I can shake free, I will 17:49:41 regXboi: :-) 17:50:04 Stephen, Kevin, and I had a meeting to break up the work. 17:50:38 The current plan is to submit servicePort early next week. I am the owner. 17:50:46 Kanzhe: ok 17:50:56 Kevin will finish external port, then start serviceBase class. 17:51:07 Kanzhe: its great to have the implementation going in parallel 17:51:16 Stephen will look into integration with LB and DB migration. 17:51:27 Kanzhe: great 17:51:37 CLI and Horizon will come after that. 17:51:39 i would however suggest that we also pursue getting the gerrit spec approved 17:52:07 we need to put a timeline on getting the gerrit specs approved 17:52:18 Yes. cgoncalves, thank you for your review comment. 17:52:22 and in this meeting figure out how we can get there (or if we cannot) 17:52:23 poo in reading the gerrit spec - is serviceport === serviceattachmentpoint? 17:52:48 regXboi: yes. :-) 17:52:55 thanks 17:53:16 Kanzhe: hope I've provided some useful reviewing 17:53:18 Kanzhe: can you identify a date that we would like this gerrit spec to get approved? 17:53:30 Kanzhe: and put that date on the table 17:53:41 we will discuss during the open discussion on how to get there 17:53:50 Next wednesday? 17:54:08 Kanzhe: we will discuss today 17:54:10 SumitNaiksatam: sure. 17:54:20 cgoncalves: thanks for your review 17:54:32 any more questions for Kanzhe right now? 17:54:52 cgoncalves: I am still going through your comments. May reach out to you if I have any question. 17:55:06 I'll see if I can add a comment about the === question above to the review because that helped clarify it for me 17:55:10 Kanzhe: sure! 17:55:21 regXboi: thanks 17:55:22 Kanzhe: i know the gerrit spec approval is blocking you, apart from that are there any techincal blockers? 17:55:39 SumitNaiksatam: not at the moment. 17:55:49 Kanzhe: ok good 17:56:01 Both stephen and Kevin are out this week. 17:56:10 Kanzhe: ok 17:56:12 I expect more progress next week. 17:56:44 going forward, i would like to use this forum, for discussing not only reviewer input, but the blockers for a particular task owner, so be prepared when we discuss your item 17:56:58 ok next item 17:57:09 i wanted to discuss flavors later, since its takes more time 17:57:14 but since cgoncalves brought it up 17:57:24 #topic Flavors 17:57:33 #link https://review.openstack.org/#/c/90070 17:57:37 enikanorov: there? 17:57:44 enikanorov: i know you were on vacation 17:57:50 yep, i'm here 17:58:03 i'm addressing comments of the spec 17:58:04 enikanorov: are you getting enough reviewer attention? 17:58:08 enikanorov: ok thanks 17:58:18 i also need to discuss the scheduling (or 'selection' process) 17:58:32 enikanorov: can you populate the table: https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan with the milestone dates? 17:58:38 as on design session there was mark mcclains opinion on how to implement it 17:58:44 SumitNaiksatam: ok 17:59:02 enikanorov: yes definitely, we discussed a bit of that last well, when you were not present 17:59:20 oh, i need to find logs then 17:59:27 enikanorov: do you think a separate meeting on just that topic with mark and whoever else is interested, will help? 17:59:32 can you provide a short summary of that discussion? 17:59:54 mark has asked me to start an email thread 18:00:00 enikanorov: we felt that STF would serve the purpose, and were not clear on what the objections were :-) 18:00:07 actually i'm fine with any of implementation option 18:00:18 enikanorov: sure, you can start the implementation thread 18:00:24 ah, you're talking about STF 18:00:36 that's a different matter 18:00:47 did Gary try to talk to Mark on that? 18:00:58 No. I have not 18:01:05 I am not sure what his concern is 18:01:23 my current understanding is that STF has only drawback of public provider attribute 18:01:25 enikanorov garyduan: for both these, i would recommend that we get together in a dedicated IRC meeting, and decide on an agreed upon path forward 18:01:28 once we remove that it should be fine 18:01:47 enikanorov: other blueprints has dependency on flavors 18:01:56 SumitNaiksatam: understand 18:02:11 enikanorov: so we need to get the plan fleshed out at the earliest 18:02:25 ok, i'll try to sort this out sooner 18:02:44 #action enikanorov garyduan SumitNaiksatam to set up an IRC meeting to discuss flavors backend scheduling and STF 18:02:44 SumitNaiksatam: +1 18:02:54 ok, good plan 18:03:08 enikanorov: lets have a plan by next meeting, and lets have the milestone dates populated 18:03:25 enikanorov: we will pull the PTL into the next meeting and get an agreement on the plan 18:03:40 will do 18:03:44 questions for enikanorov? 18:04:12 enikanorov: thanks for the update 18:04:22 Kanzhe: thanks for the earlier update as well, i forgot to mention 18:04:34 #topic Traffic steering 18:04:43 #link https://review.openstack.org/#/c/92477 18:04:51 i believe we have one +1 18:05:19 pcm_: thanks for reviewing 18:05:31 SumitNaiksatam: np 18:05:47 does anyone want to discuss anything specific in the spec here? 18:06:04 I'm sorry I've havent addressed yet the clarification on the BP on there this blueprint differs from the service chain one 18:06:14 cgoncalves: ok 18:06:28 it's on my TODO list, high priority 18:06:42 cgoncalves: i believe you have prototype code as well, to back your spec? 18:06:54 cgoncalves: The service chain blueprint does address this as a potential implementation, so can refer to that (if it helps) 18:07:34 SumitNaiksatam: you're right. I'm quite new to Neutron code architecturing but I've learnt a few things during this past days 18:07:41 mandeep: ok 18:08:07 cgoncalves: one clarification... 18:08:08 SumitNaiksatam: and with that, I've been looking at the ML2 and GP PoC code 18:08:21 regXboi: shoot :-) 18:08:27 cgoncalves: i saw your message 18:08:35 I assume that the list of lists of ports implies that I can pick one from each list 18:08:35 cgoncalves: thats a slightly different topic 18:09:24 regXboi: each port_chain lists are independent from other port_chain lists 18:09:24 I'm reading into the port chain data model 18:09:47 that's not exactly how I read this 18:09:58 a port chain includes a list of lists of ports 18:10:27 there is no indication that I could find how that is to be interpreted 18:10:41 I have an educated guess :) 18:11:12 regXboi: ok, fair point, will surely need to be clarified on the BP 18:11:17 thanks 18:11:21 I'll add a comment now 18:11:21 regXboi: i agree, it was a little confusing for me at first as well (the list of lists) 18:11:48 regXboi: thanks for bringing that up. I'll document that and get back to you 18:11:50 regXboi: this gives more flexibility, but difficult to interpret in an unambiguous way 18:11:54 regXboi: better yet. thanks 18:12:17 cgoncalves: any techincal blockers, or help that you seek from the rest of the team? 18:12:48 SumitNaiksatam: in terms of code? 18:13:01 comment so added 18:13:12 cgoncalves: both in terms of the spec and the code 18:13:23 SumitNaiksatam: if so, I think the email I sent to -dev on the GP mapping driver thread also applies here: http://lists.openstack.org/pipermail/openstack-dev/2014-May/035976.html 18:13:37 regXboi: tks 18:13:57 cgoncalves: i dont see a direct correlation, but i might be missing something 18:14:09 cgoncalves: we can go back to the mailer for that 18:14:18 cgoncalves: thanks for the update 18:14:20 moving on 18:14:23 #topic Service Chaining 18:14:32 #link https://review.openstack.org/#/c/93524 18:14:45 i dont think this got much reviewer attention yet 18:14:48 mandeep: ? 18:15:06 yes not much, but nachi reviewed 18:15:21 mandeep: ah ok, thanks nachi 18:15:23 He has requested for a use-case, and I am adding that 18:15:29 mandeep: ok thanks 18:15:40 any questions for mandeep? 18:15:44 There were a couple of other helpful commnets as well, and 18:15:53 mandeep: good to know 18:16:06 I will be updating the name "ServiceChain" to "ServiceChainSpec" 18:16:13 mandeep: are you blocked on anythig? 18:16:23 mandeep: apart from the reviewer feedback 18:16:34 For the now, the goal is to get the spec reviewed by a few more people 18:16:41 mandeep: ok 18:16:53 let me keep this rolling, got to cover a few more items 18:16:57 mandeep: thanks for the update 18:17:02 ok 18:17:07 #topic L3 Agent Framework 18:17:11 mandeep: let me know after you add a use case and I'll take another look 18:17:13 #link https://review.openstack.org/#/c/91532 18:17:19 regXboi: will do, 18:17:23 i dont think toshi is here 18:17:29 but i want to put this on the radar 18:17:53 i have sent him an email, hopefully he will be able to participate and provide updates in the future 18:18:16 if anyone else wants to proxy for him that will be great (else i will take it up to sync up with him) 18:18:24 #topic Tap as a Service spec 18:18:34 #link https://review.openstack.org/#/c/96149/ 18:18:43 vinay_yadhav: thanks for proposing the spec 18:19:05 since this just landed, i am guessing that not many people got a chance to go through it 18:19:20 i made some more changes to it and commited it but it went as another commit and not as a patch 18:19:26 i had one person review it 18:19:45 i guess other can start the review process too 18:19:46 vinay_yadhav: nice, lets give people some more time, and we can circle back to this next week 18:19:50 I will be adding my review comments too shortly. 18:19:57 thanx 18:20:00 anil_rao: great, thanks 18:20:14 vinay_yadhav: i believe you also have a -dev thread going on this 18:20:23 i need to start it 18:20:27 all please respond there in the interim 18:20:41 i will do that soon 18:20:54 vinay_yadhav: thanks 18:21:01 any pointer on how to start the dev thread 18:21:03 I'm a little concerned that the data model isn't complete, but I'll look at it and drop email/comments if need be 18:21:15 just on the mailing list 18:21:17 regXboi: yes please 18:21:27 #topic NFV and Service VM updates 18:21:39 i believe the NFV meetings have not started 18:21:47 #link https://wiki.openstack.org/wiki/Meetings/NFV 18:22:11 and neither stephen or isaku is here today to provide the update on service VMs 18:22:16 i will wing it 18:22:25 #topic Group Policy Requirements 18:22:32 banix: quick one minute update? 18:22:58 nothing beyond new patches submitted 18:23:06 banix: ok 18:23:23 stephen sent an update on the services’ integration that he has tried 18:23:32 but i will skip it for now 18:23:37 might take more time 18:23:43 banix: thanks 18:23:48 sorry for rushing 18:24:01 #topic Open Discussion 18:24:18 so firstly, an action item for all the task owners - 18:24:56 #action Kanzhe enikanorov cgoncalves mandeep vinay_yadhav toshi to put milestone dates in https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan 18:25:10 ok 18:25:14 +1 18:25:28 we will need the table with your estimated dates to be populated by next meeting 18:25:42 sure 18:25:49 sure 18:25:55 and we will discuss the feasibility of achieving that next week, hopefully by pulling the PTL in 18:26:04 SumitNaiksatam: where devstack fits best? client or have its own row? I'm guessing the latter 18:26:07 mestery: agree ^^^ ? 18:26:17 SumitNaiksatam: agreed 18:26:32 cgoncalves: you can add a separate item for devstack 18:26:32 ok 18:26:52 in fact, please do, thanks for bringing that up 18:26:59 its a separate line item 18:27:05 SumitNaiksatam: +1 18:27:07 and needs to be tracked 18:27:09 SumitNaiksatam: ok, thanks for clarifying 18:27:32 * mestery reads scrollback. 18:27:57 mestery: we were just saying that we would like to pull you into the meeitng next week 18:27:58 SumitNaiksatam: +1 to that idea I think. 18:28:07 mestery: to look at our estimates 18:28:09 SumitNaiksatam: That should be fine, yes. 18:28:09 mestery: thanks 18:28:12 SumitNaiksatam: thanks! 18:28:32 secondly, if you see the recurrent theme during the meeting is that we are blocked on the spec reviews 18:29:00 and people have asked this several times as to how we can speed this up 18:29:14 i would like explore a process that we can make this a little more detereministic 18:29:53 so my first suggestion is that we identify a team of “assigned-reviewers” for this advanced services’ sub team 18:30:13 this can be both +1 and +2 reviewers 18:30:29 you can volunteer your name for this and we will put it on the wiki 18:30:41 SumitNaiksatam: thats what is being done by ML2 subteam 18:30:47 SumitNaiksatam: I'm only +1, but throw my name in 18:30:58 but it means that every week you will need to at least review all the specs that we have identified as priority items 18:31:14 so we want to hold this team accontable 18:31:20 *accountable 18:31:48 currently we have only a few specs that we are tracking as priority 18:31:53 so its should not be as much 18:31:56 and probably more importantly on a known schedule i think 18:31:58 does everyone agree? 18:32:07 banix: yes absolutely 18:32:28 so the schedule will be driven by the dates we put on the milestones in teh table 18:32:31 agree; lets add that to the table maybe? 18:32:43 banix: absolutely, was going to say that 18:33:06 so on that same wiki page, we will add a section at that top, which will have the reviewer’s names 18:33:28 if you want to be included, please add your name to: https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan 18:33:46 i will put a section “Reviewers” at the top 18:34:06 SumitNaiksatam: feel free to put regXboi in - I'll fill in my details later 18:34:16 that way it won't be empty :) 18:34:36 every week, this reviewer team should tell us if we are on track for to approve a particular patch (either spec or code) in time for the milestone set 18:34:39 regXboi: sure 18:34:50 and if we are not on track, what is the blocker 18:34:55 SumitNaiksatam: +1 18:35:24 i would not like the task owners to waste their time, if a particular feature is not going to be reviewed in time or has no chance of merging and getting approved 18:36:20 secondly, i would also like to identify at least 4 cores who can shepherd each blueprint 18:36:34 unfortunately, there I can't help you :( 18:36:35 4 cores? 18:36:43 mandeep: yes 18:36:58 That is a significant request ... but it would be nice to have 18:37:07 mandeep: since on bigger blueprints, sometimes its not enough to just have two, sometimes cores go MIA :-) 18:37:18 ;-) 18:37:30 mandeep: yes, my suggestion is that we identify at least four cores for each patch 18:38:05 mandeep: that increase our chances of making progress 18:38:23 at the end of the day, this is all best effort, so we cant force anyone 18:38:31 but we can try and plan 18:38:35 I agree. I was just worried if that will make it impossible if we ca not find that many core reviewers 18:38:52 But this is a good idea 18:39:06 so if you are a taks owner, please try to identify cores upfront who can help with your patch 18:39:12 ok 18:39:22 if you cannot identify more than 2 cores, then lest bring this up in the meeting, and we can assess 18:39:50 all the above were suggestions to make deterministic/predicatable progress 18:40:01 thoughts/suggestions/opinions? 18:40:07 i know we have run out of time 18:40:20 SumitNaiksatam: +1 for this masterplan of yours 18:40:56 cgoncalves: ok 18:41:26 #action SumitNaiksatam to add reviewers section at the top of https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan 18:41:34 ok anything else? 18:42:09 if you have further thoughts on making the process better, please do chime in on the maling list or in the next meeting 18:42:17 alright, lets call it wrap 18:42:21 thanks all for attending 18:42:27 #endmeeting