17:31:33 #startmeeting Networking Advanced Services 17:31:34 Meeting started Wed Jul 9 17:31:33 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:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:31:38 The meeting name has been set to 'networking_advanced_services' 17:31:46 #announcements Juno specification submission deadline: July 10th, specification approval deadline: july 17th 17:31:48 o/ 17:32:26 dougwig: hi 17:32:31 hi 17:32:35 how will the decision to approve be taken 17:32:51 vinay_yadhav: based on the reviews 17:33:17 ok... All the +1s on TaaS is hidden in patch set 5 :) 17:33:57 hi all 17:34:04 lets change the order a bit 17:34:16 #topic Service Chaining 17:34:17 did I miss the service chaining part? I had a question there 17:34:28 regXboi: right on cue! :-) 17:34:33 #link #link https://review.openstack.org/#/c/93524 17:34:48 mandeep: there? 17:34:51 SumitNaiksatam: I just updated the commit message as requested 17:35:18 mandeep: thanks, i added a couple of comments as well 17:35:23 regXboi: your question? 17:35:33 Otherwise I have addressed all the questions in the spec and added an example 17:35:34 I was looking for horizon and heat impacts 17:35:46 didn't see them - wondering if i'm looking in the wrong place 17:36:00 The current BP does not address them, I was planning to add them as dependent BPs later 17:36:16 mandeep: is a new bp really required for that? 17:36:47 mandeep: I've not yet had the chance to read the latest spec rev. hope to read it and give some feedback by tomorrow 17:36:49 I can add it to this BP, but I was not sure that we had time to get it done at that same time. 17:37:06 mandeep: i believe the CLI proposal will be required in this spec 17:37:17 I guess I'm asking if we are scoping horizon/heat for Juno 17:37:26 SumitNaiksatam: Is it Ok to merge updated for part of the BP (say chaining API + CLI before HEAT + GUI)? 17:37:40 SumitNaiksatam: CLI was planned. 17:37:45 mandeep: but i agree heat/horizon can be separate proposals in those respective projects 17:37:51 mandeep: yes, we will need CLI 17:38:02 regXboi: does that answer your question? 17:38:06 mandeep: still unclear why there is a port in ServiceChainInstance 17:38:24 I read it as Heat/Horizon will be K 17:38:32 LouisF: Did you get to see the usage example? 17:38:36 which is (afaik) Ok, just needed clarity 17:38:46 (just updated today morning) 17:39:27 now - am I reading it correctly :) 17:39:34 regXboi: More like it is not committed for J, but we will try ... 17:39:36 regXboi: that is the most likely scenario, however we could probably have the horizon/heat ready in PoC form before K 17:39:45 ok... that works 17:39:47 thanks 17:39:48 * cgoncalves notes SumitNaiksatam is reviewing BPs while chairing this meeting. great multi-tasker! 17:39:49 SumitNaiksatam: Correct 17:39:57 songole prasadv: you wanted to comment on the heat/horizon part? 17:40:12 * regXboi goes back to working neutron documentation bugs 17:40:25 cgoncalves: :-) 17:40:38 SumitNaiksatam: we haven't thought about it yet 17:40:39 mandeep: you mean USAGE WORKFLOW #4? 17:40:42 * SumitNaiksatam thinks his sly monouvers have been exposed! :-P 17:40:46 LouisF: Correct 17:40:54 songole: okay 17:41:08 songole prasadv: you plan to take this up later though? 17:41:23 mandeep: that does not explain how port is used 17:41:24 SumitNaiksatam: yes 17:41:29 songole: ok 17:41:36 Also, see my comment on Cathy's question on patchset 7 (which that point was addressing) 17:42:14 in #link https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan#Tasks we have mandeep as owner for heat/horizon, songole you want to update that, if convenient, and provide a projected milestone? 17:42:17 LouisF: The intent is not to prescribe how it is used, except that the semantics are defined as bump-in-the-wire "at that port" 17:42:53 LouisF: The backend is free to do any implementation as long as it honors that semantic 17:42:56 SumitNaiksatam: okay 17:43:28 mandeep: what is the reference impl planned for this? 17:43:31 SumitNaiksatam: do we have until juno-3 to finish heat/horizon ? 17:43:39 hemanthravi: absolutely 17:43:48 hemanthravi: welcome back! 17:44:08 SumitNaiksatam: It is based on the current FWaaS and VPNaaS 17:44:15 mandeep: okay 17:44:24 (existing services based on the router ports) 17:44:42 mandeep: is there a particular order for those two? 17:44:58 mandeep: i mean a particular order that we would plan to support as the ref impl 17:45:33 SumitNaiksatam: Current plan was FW-VPN, but I need to investigate what the VPN service supports today 17:45:42 mandeep: fair enough 17:45:56 mandeep: is songole also working on this bp? 17:46:01 SumitNaiksatam, mandeep: what is the deadline for BP approval for Juno 17:46:10 mandeep: and/or hemanthravi? 17:46:18 10th/20th 17:46:21 SumitNaiksatam: Yes 17:46:33 mandeep: if so it would be good to have them called out in the assignees 17:46:35 songole: Next week Thr 17:46:38 marios_: thanks, yes 17:46:51 thought i would prefer that we use july 17th as the deadline 17:46:56 Yes, we will update the assignments 17:46:56 *though 17:47:15 songole, hemanthravi: fine with that? 17:47:17 mandeep: thanks 17:47:45 anyone else wants to help with the service chaining work, please reach out to mandeep 17:47:51 or me 17:47:58 mandeep: i can help 17:48:05 SumitNaiksatam: is this for a separate bp for heat/horizon? 17:48:05 LouisF: OK 17:48:31 hemanthravi: for now, this is neutron but bleeds into other things as well 17:48:39 any more questions for mandeep? 17:48:41 hemanthravi: We can update this BP, if that makes it easier to manage 17:49:00 i guess cathy is not around, she had questions before 17:49:02 mandeep: ok, that'll be better 17:49:11 mandeep: any blockers at your end? 17:50:17 mandeep: thanks for the update and revised spec, i think it reads very well! 17:50:19 SumitNaiksatam: No we are OK now 17:50:42 mandeep: obviously I'm interested in the service chaining work. please let me know if I can be of any assistance to you on developing any part of the system 17:51:14 #topic Traffic steering 17:51:24 cgoncalves: Will do. Thanks. 17:51:31 #link https://review.openstack.org/#/c/92477 17:51:39 cgoncalves: thanks for the new rev 17:51:47 cgoncalves: there are some more comments 17:51:54 a new spec rev was submitted last friday 17:52:26 some people have reviewing it and provided comments. I've just replied to all of them 17:52:53 good news here is: we got +1 from cathy :) 17:53:26 cgoncalves: :-) 17:53:49 any questions for cgoncalves, or anything we need to discuss here? 17:53:58 so unless there are any questions I can answer to now, I'm ok and we can move on 17:54:15 cgoncalves: so no blockers (apart from reviewer attention) for you? 17:54:21 so that we still have time to discuss the flavor bp :-P 17:54:35 cgoncalves: thats very considerate of you :-P 17:54:37 SumitNaiksatam: correct 17:54:49 cgoncalves: thanks for all the hard work on this and the update today! 17:55:15 #topic Tap as a Service spec 17:55:17 SumitNaiksatam: no problem. I was out of office until today so lots to catch up yet 17:55:25 cgoncalves: sure no 17:55:30 no problem 17:55:36 #link https://review.openstack.org/#/c/96149 17:55:53 vinay_yadhav, anil_rao: any major updates on this? 17:55:59 no 17:56:10 pactch set 6 is up for review 17:56:15 i see that there havent been negative comments on this, so i would imagine most people are in agreement? 17:56:27 vinay_yadhav: thanks for the new rev 17:56:41 i guess too, since we got a lot of +1s in the last rev 17:56:49 any questions for vinay_yadhav or anil_rao? 17:57:03 at your end, vinay_yadhav anil_rao you are all set? 17:57:10 yes 17:57:12 yes 17:57:18 we want to start on the dev work soon 17:57:22 vinay_yadhav: I'll do my best to review it again soon, and hopefully give a +1 17:57:22 vinay_yadhav anil_rao: good 17:57:28 cgoncalves: thanks! 17:57:33 thanks! 17:57:36 vinay_yadhav: you can start the dev in parallel 17:57:43 if you feel comfortable 17:57:47 sure... we will start out 17:57:52 regarding NSAaaS 17:57:52 great 17:58:06 i think we should probably leave that option open to the operator? 17:58:20 there might be cases where the tenant might need the operator help in debugging, right? 17:58:29 operator can publish his policy 17:58:40 SumitNaiksatam: you mean allow admin to monitor all ports but this is a config setting? 17:58:45 well NSAaaS can be done by the operator by bypassing tap anyways 17:58:51 marios_: yeah, in policy.json 17:59:00 vinay_yadhav: :-) 17:59:09 vinay_yadhav: would tap be one of the action values in GBP? 17:59:10 we in TaaS dont want to have it as a feature 17:59:12 NSAaaS will disregard any policy operators enforce 17:59:20 yah just saw your comment reply in the spec 17:59:26 SumitNaiksatam: ^^ 17:59:28 songole: good question! 17:59:36 marios_: okay 17:59:50 pardon me GBP? 17:59:59 i dont understant the term :) 18:00:00 songole: i have looked closely into this 18:00:10 group-based policy 18:00:29 ha ok... 18:00:43 i need to think on this... but what is your opinion sumit 18:00:46 vinay_yadhav: #link https://wiki.openstack.org/wiki/Neutron/GroupPolicy 18:01:16 sumit: thanks i will check it out 18:01:22 vinay_yadhav: i think it will be good if you can consider songole’s question 18:01:28 Or we could just add admin capability in at a later time 18:01:30 sure sumit 18:01:55 anil_rao: +1 i would go with this option - if for nothing else, so we can aland the spec in time 18:02:04 vinay_yadhav: we cannot two different tap implementations 18:02:36 vinay_yadhav: i mean for taas and for the GBP action 18:02:42 so best to reconcile 18:02:53 sumit: i can check on this 18:02:53 anything else for vinay_yadhav or anil_rao? 18:03:11 vinay_yadhav: thanks 18:03:21 sumit, All: thanks 18:03:24 #topic Service base definition and Insertion 18:03:35 #link https://review.openstack.org/#/c/93128 18:03:52 i dont think either kanzhe or s3wong are in today 18:04:00 so i will fill in 18:04:20 s3wong provided the update that he has updated the spec and addressed review comments 18:04:44 he is also looking at the API and DB implelentation which Kanzhe has started 18:04:50 kanzhe is on vacation 18:04:59 however, after that i reviewed and have put a -1 18:05:14 anyone else has thoughts/questions on this? 18:05:19 i can relay to s3wong 18:05:21 i have a question about the necessity to remove attributes 18:05:25 i put a comment in v15 18:05:40 marios_: ah, yeah regarding router_id in vpnaas 18:05:50 right 18:06:01 i think from the response the intention is 'its ok because we won't change the API' 18:06:13 marios_: need to think a little more on this 18:06:23 but i think it is still risky. we not only have to implement this stuff but also fix all the places in code where we do .router_id 18:06:33 marios_: at some point though we would need to deprecate that attribute 18:06:37 why can't we just add the attribute and then remove in another cycle 18:06:48 marios_: so i guess we are discussng the transition 18:06:49 well yes and by doing this we can also deprecate properly 18:07:00 marios_: yes 18:07:11 marios_: i guess we are saying the same thing :-) 18:07:17 works for me :) 18:07:24 SumitNaiksatam: yes i think so too 18:07:27 marios_: lets also look for the closest precedent in this regard and follow it 18:07:36 didn't want to push it too much on the spec as i seemed to be a lone voice 18:07:44 ok sounds good 18:07:44 marios_: i believe we might find one with lbaas or service type framework 18:07:55 marios_: i agree thats a valid concern 18:08:03 lets check with nati_ueno as well 18:08:06 nati_ueno: there? 18:09:13 marios_: ok lets follow with nati_ueno and pcm 18:09:43 #action marios_ SumitNaiksatam s3wong to follow up with nati_ueno and pcm on VPNaaS router_id attribute deprecation 18:09:50 anything else on this? 18:10:03 enikanorov_: are you back? 18:10:10 yes 18:10:16 enikanorov_: nice 18:10:28 and drum roll! 18:10:31 #topic Flavors 18:10:32 hehe 18:10:40 #link https://review.openstack.org/102723 18:10:56 ok, so i've started implementation based on most of points of this proposal 18:10:58 so per enikanorov_’s confirmation, we are now looking at the above spec (not the older one) 18:11:04 enikanorov_: great thanks 18:11:14 i think to make it land in juno we need to limit the scope of the first commit as much as possible 18:11:27 and also postponed any features that create discussion contention 18:11:35 enikanorov_: on the process front, since you mention that you are already implementing this, but i dont see you as being one of the assignees in the above spec 18:11:57 enikanorov_: is this something we need to follow up with markmcclain or thats just a minor detail? 18:12:01 markmcclain asked me if i can impl that 18:12:06 so i think we're good on that front 18:12:16 enikanorov_: just want to make sure that you and markmcclain are in sync 18:12:20 enikanorov_: okay great 18:12:42 so, I'm planning the first step impkementation to consist with the following items: 18:12:57 Flavor API: flavors, service profiles 18:13:04 DB plugin for that 18:13:09 DB migration 18:13:13 unit tests 18:13:22 that's pretty much it... 18:13:43 enikanorov_: okay 18:13:49 there is also one point left on which i think we haven't reach full consensus 18:13:57 is an extension list in the flavor resource 18:14:08 i still need to follow up on that with markmcclain 18:14:08 enikanorov_: okay 18:14:21 enikanorov_: is that something we need to follow up on the -dev mailer? 18:14:38 can't think of anything at this point 18:15:13 enikanorov_: regarding the extensions list 18:15:44 do you have the question? 18:15:52 enikanorov_: if possible, can you summarize here for the benefit for everyone, what are the pros and cons of having exposing the extensions list? 18:16:24 ok, so the intent of having extension list on the flavor is to be able to turn on or of certain features for the flavor 18:16:39 say, you, as admin, want certain flavor with advanced features turned off 18:16:50 and it will be cheaper 18:17:08 but technically, it's usually not possible to turn API parts with flavors 18:17:22 enikanorov_: turn off? 18:17:49 SumitNaiksatam: yes, like you try to access SSL and it's disabled because the resource is created with the flavor that doesn't support it 18:18:02 enikanorov_: this is true in general for the Neutron API/extensions’ framework, i believe, not limited to the flavors resource, right? 18:18:16 the problem is that such API parts like SSL might not be connected to flavors in anyway 18:18:52 so you can't really disable/turn off anything with extension list on the flavor just because flavor is not used when accessing this API 18:19:10 enikanorov_: did markmcclain indicate if he has a workaround for this? 18:19:25 enikanorov_: i believe that would have to be in the extensions’ framework? 18:19:33 that's yet to be discussed 18:19:50 and yes, also this feature requires some stuff to be done for extension framework 18:19:58 enikanorov_: ok perhaps, assessing what it takes to implement this would make it clear whether its achievable or not, right? 18:20:07 but still i think it will not solve the issue from user perspective 18:20:13 achievable in the short Juno time frame that is 18:20:17 enikanorov_: ah ok 18:20:38 afaik there are no extensions for fwaas and vpnaas 18:20:39 enikanorov_: there was also a comment from salvatore on the service_type 18:20:46 so the only consumer is going to be lbaas so far 18:21:03 enikanorov_: but we will have in the future, at least for fwaas, in fact they are in review now 18:21:12 enikanorov_: i am not trying to justify the need 18:21:18 good to know 18:21:33 anyway, extension list in fact is a subset of tag functionality 18:21:40 enikanorov_: ah okay 18:21:50 although i think that doing any kind of dispatching based on ext list/tags is an overkill 18:22:02 enikanorov_: so the service type has to be pre-defined/enumerated? 18:22:17 what do you mean? 18:22:24 enikanorov_: or we can drop it from the flavor definition? 18:22:50 enikanorov_: it is currently enumerated right - LB, FW, VPN 18:22:53 i'm not sure... let me recollect my concerns about it... 18:22:59 ah 18:23:29 yeah, so i think it's doable 18:23:54 enikanorov_: okay 18:23:57 it puts some requirements for the drivers then, but requirements are not complex 18:24:04 i'll followup with Slavatore 18:24:11 enikanorov_: ok, i think that makes it more flexible 18:24:21 any other questions for enikanorov_ ? 18:24:26 or markmcclain? 18:26:07 enikanorov_: thanks for the udpate and your work on this! 18:26:13 #topic Open Discussion 18:26:15 does servicebase have any dependency on the serviceVM work? 18:26:39 LouisF: not that i am aware of 18:26:47 i again want to draw your attention to this: 18:26:49 #link https://wiki.openstack.org/wiki/NeutronJunoProjectPlan 18:27:14 at this point, from the PTL perspective, he has only included the flavor’s blueprint as a high prirority 18:27:20 and has assigned cores to review it 18:27:56 more specifically see: #link https://wiki.openstack.org/wiki/NeutronJunoProjectPlan#Juno-2_BP_Assignments 18:28:10 this does not preclude our other blueprints 18:28:32 however, want to make sure that the expectations are conveyed from the PTL and the neutron core team perspective 18:29:00 as a team we will continue to try and work towards the best possible outcome for the blueprints we have been discussing 18:29:06 any questions on this? 18:30:03 alright, thanks everyone for the work on the specs and your reviews 18:30:13 this is the crunch as far as the specs are concerned 18:30:20 good progress, team! 18:30:26 we need to keep a watch on the reviews and +1 18:30:40 we need quick turn around in this week to meet the deadline 18:30:52 thanks all, and for once we are finishing on time! :-) 18:30:55 #endmeeting