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