17:31:37 #startmeeting Networking Advanced Services 17:31:37 Meeting started Wed Jul 30 17:31:37 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:39 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:31:41 The meeting name has been set to 'networking_advanced_services' 17:31:46 #info agenda: https://wiki.openstack.org/wiki/Meetings/AdvancedServices 17:32:01 o/ 17:32:18 enikanorov__: there? 17:32:59 #info Juno 3, i believe is 2014-09-04 (#link https://launchpad.net/openstack/+milestones) 17:33:07 SumitNaiksatam: yes 17:33:17 which means we can expect code freeze a couple of weeks prior 17:33:42 so we should be aiming to be ready with our patches submitted say by aug 21st or thereabouts 17:34:05 i think mestery will later annoce what the feature freeze deadline is 17:34:11 *announce 17:34:22 or he might have already, i missed it 17:34:30 #topic Flavors 17:34:32 i think jun-3 is the feature freeze deadline 17:34:37 juno-3 17:35:01 so, we're still waiting for spec update, while i've pushed first step implementation and CLI for that 17:35:19 spec isn't approved still L:( 17:35:19 banix: true, but usually we dont allow new features to land a little before that actualy release milestone date 17:35:27 banix: so that poeple can review 17:35:36 enikanorov__: did notice that 17:35:48 enikanorov__: but you seem to have removed your patch out of WIP 17:35:57 SumitNaiksatam: yes by that day they should have landed meaning much earlier reviews as you mentioned 17:36:07 SumitNaiksatam: basically the flavors patch is ready for review 17:36:19 technically there are few things to discuss 17:36:28 mestery: there? 17:36:36 most noticable is the way driver configuration is pushed 17:36:54 and it's mostly a question of what kind of API attribute to use for that 17:37:20 SumitNaiksatam: Here, reading backscroll around flavors. 17:37:37 mestery: hi, was just pinging you :-) 17:38:01 mestery: so the my question for you was is it okay for the team here to review enikanorov__’s flavor’s implementation patch? 17:38:11 mestery: i believe he is making good progress 17:38:33 We really need that spec approved, that spec and the rootwrap ones are the only ones I'm currently going to allow exceptions for at this point. 17:38:36 mestery: however the spec has not been updated since july 2nd to the best of my recollection 17:38:51 But we need them to close fast, this week, as we're 5 weeks out from the end. 17:38:59 mestery: agree 17:39:04 correct. that still waiting markmcclain's participation 17:39:33 Lets see if we can close this by Friday 17:39:58 mestery: ok, meanwhile let people review enikanorov__’s implementation patch as well? 17:40:19 SumitNaiksatam: i think some folks already started reviewing 17:40:59 SumitNaiksatam: There is no harm in that, sure. 17:41:02 enikanorov__: yes sure, just wanted to make sure we are all on the same page in terms of the process 17:41:06 mestery: ok great 17:41:37 i did not want to get into a situation where people spend a lot of time reviewing the implementation, and then we have to reset it because something else changes in the spec 17:41:54 enikanorov__: definitely commend your persistence on this and for making progress 17:42:08 mestery: thanks for that direction, and for jumping in :-) 17:42:11 mestery: one more questions 17:42:15 *question 17:42:29 mestery: is Aug 21st the feature freeze deadline? 17:42:47 Yes, that's correct. 17:43:17 mestery: okay, so aug 21st is the last day that we can post a review for a feature related patch? 17:43:27 Yes sir 17:43:42 wow so earlier than i thought 17:43:50 mestery: ok great, thanks, wanted to clarify for the rest of the folks here, so there is no confusion 17:43:57 mestery: bug fixes can go in after that, right? 17:44:03 Yes 17:44:23 mestery: ok, thanks 17:44:33 SumitNaiksatam: your welcome :) 17:44:39 mestery: :-) 17:44:45 enikanorov__: sorry to distract from the focus on the flavors discussion 17:44:55 so nw features could get merged upto juno-3 or that is not correct? 17:44:56 enikanorov__: are there any questions for enikanorov__? 17:45:06 new 17:45:13 banix: yes they will, and until 09/04 17:45:33 so what is the aug 21st then? 17:45:38 banix: however a patch can be only submitted against a blueprint by aug 21st 17:45:50 banix: subsequently it will be in review until 09/04 17:45:57 not revised afterward… i see 17:46:03 ok thx 17:46:07 banix: or it can be approved until 09/04 17:46:15 banix: it can be definitely revised 17:46:43 ok got it thx 17:46:44 banix: just that you can post a new patch that references a blueprint (so its an implementtion of a new feature) post aug 21st 17:46:55 can -> cant 17:46:59 yup 17:47:25 enikanorov__: hopefully you and the rest of the team can be out of the limbo by this weekend 17:47:33 wishful thinking! :-) 17:47:39 that would be great 17:47:58 i think nova mid-cycle is ongoing so perhaps wont hear from Mrk right away 17:47:59 enikanorov__: thanks for the update 17:48:34 is s3wong here? 17:48:40 SumitNaiksatam: hello 17:48:43 also SridarK? 17:48:50 #topic Service base and insertion implementation update 17:49:09 s3wong: hi, any update for the team on this topic? 17:49:17 so i have been disctracted this week by something else i'm involved in 17:49:18 marios: as well 17:49:19 yes 17:49:24 Not much update for me, unfortunately. This past week and this week I am focusing on GBP - so nothing, sorry 17:49:28 marios: ok, np 17:49:31 i haven't progressed my side as i wanted to (still wip patch) 17:49:41 s3wong: okay 17:49:44 i kinda anticipated this hapening which is why i started the very early wip a few weeks back 17:49:49 hopefully i get some update for next week 17:49:52 SumitNaiksatam: just got back from PTO yesterday 17:49:53 marios: good 17:50:00 and also looking forward to seeing the base class definitions 17:50:03 from whoever does that 17:50:09 so i can rebase onto 17:50:10 SridarK: okay, so all of you conspired to not work! :-) 17:50:16 :-) 17:50:25 is kanzhe on? 17:50:25 marios: yes, i agree that there is a dependency for you 17:50:39 SumitNaiksatam: have we made a decision on how the serviceInterfacePlugin will get the service instance UUID yet? 17:50:42 LouisF: kanzhe is on vacation 17:50:50 SumitNaiksatam: (dependency yeah but definitely not a blocker by any measure at this point) 17:50:56 marios: ok 17:51:14 s3wong: i had some ideas on that, which i had run by the team last week 17:51:24 SumitNaiksatam: who else is working on service base and insertion? 17:51:41 LouisF: kanzhe is expected to back on this soon 17:51:58 LouisF: besides him, s3wong, marios, SridarK, and kevinbenton are working on it 17:51:59 marios: when it becomes available, the base class code will be here #link https://github.com/noironetworks/neutron-group-policy/tree/service-insertion 17:52:02 LouisF: myself as well 17:52:11 s3wong: perfect thx mate 17:52:16 s3wong: to your earlier questions 17:52:57 s3wong: we can maintain a table in the new service insertion plugin, that will hold a reference to the uuids against their service type 17:53:37 s3wong: and we can leverage the notification mechanism (say when a firewall is created, a notification is sent), to learn that a service is created, and then populate the table accordingly 17:54:08 s3wong: the notifications already exist today, and are being used ceilometer, etc 17:54:25 s3wong: i think kevinbenton had raised some issue with this, but it slips my mind 17:54:36 SumitNaiksatam: is that really for J though? ^^^ 17:54:51 marios: yes, we would need to do this 17:54:58 marios: do you anticipate any issue? 17:55:19 i.e. is that the proposed implementation. i see. no i had thought (from the comments) that interfacing with the service plugins would come later. 17:55:23 marios: this will have the least amount of code churn among other options 17:55:25 marios: the notification mechanism is there already 17:55:27 i guess this way, the plugins can still remain unaware 17:55:36 banix: right 17:55:38 (of service insertion code/framework) 17:55:42 marios: exactly 17:55:57 marios: the other goal was to be as less intrusive as possible 17:56:03 ack 17:56:21 marios: that is the goal, we don't want every service to separately implement and maintain service interface info 17:56:24 i think we will still need the services to implement the service base, but that might be minor refactoring of existing code 17:56:33 s3wong: agree 17:57:22 okay, anything else to discuss on this topic? 17:57:34 for this week that is 17:57:54 i think we need to churn out some code for the rest of the team to understand 17:58:04 LouisF: you had some questions earlier? 17:58:15 LouisF: not sure if we answered those 17:58:48 ok moving on 17:58:53 yes thx 17:59:10 hemanthravi: there? 17:59:22 SumitNaiksatam: hi 17:59:31 #topic Service Chaining implementation update 17:59:48 hemanthravi: do you have an update on this? 17:59:54 i dont see songole 18:00:26 started working on the patch loosely based on GBP plugin/driver model and expect to have the first patch by Mon 18:00:37 hemanthravi: ah good 18:00:38 songole here with me 18:00:45 this will be a WIP patch 18:00:52 hemanthravi: okay, so who is working on this patch, you, songole, or both? 18:01:04 songole and me 18:01:23 hemanthravi: okay, got it, just want to make sure that the rest of the team knows 18:01:52 hemanthravi: are there are any blockers for you at this point? 18:02:20 not yet, will be pinging you with questions later this week 18:02:27 okay 18:02:37 any questions for hemanthravi on this topic? 18:03:18 ok moving on then 18:03:38 when will the horizon work for chaining be done? 18:03:39 i believe this is all we have approved in terms of blueprints for Juno 18:03:59 lets shift gears to our features which are currently targeted for Kilo 18:04:11 #topic Traffic steering update 18:04:15 cgoncalv1s: hi 18:04:31 SumitNaiksatam: hi 18:04:45 cgoncalv1s: i know this is a little difficult to discuss here since its a kind of a limbo situation 18:04:45 LouisF: haven't planned on horizon for chaining, will look at this as we make progress 18:04:52 not much to report this week again 18:05:04 cgoncalves: no worries 18:05:27 SumitNaiksatam: internally we've been testing it, and myself been out of office on business travels 18:05:51 cgoncalves: my suggestion is that we work towards a plan on what we want to do prior to the specs opening up for Kilo, so that we dont lose momentum here 18:06:00 next two weeks I'll be on vacation so don't expect much activity from my end 18:06:07 cgoncalves: sure well deserved break! :-) 18:06:15 SumitNaiksatam: sure 18:06:33 any questions or suggestions for cgoncalves before takes off on vacation? ;-P 18:07:04 I should keep lurking around, don't worry. 18:07:25 cgoncalves: sure, i guess one of the suggestions would have been not to - enjoy your time off! :-) 18:07:28 alright moving on 18:07:38 SumitNaiksatam: I also need to reach out to you and some other folks offline soon. 18:07:44 cgoncalves: sure 18:07:48 anil_rao: there? 18:07:54 yes :) 18:08:02 #topic Tap as a Service 18:08:07 anil_rao: hi 18:08:20 i dont see vinay_yadhav here 18:08:26 Hi. Vinay can't join us today but I can give an update 18:08:34 anil_rao: same questions as cgoncalves for you 18:08:41 anil_rao: sure go ahead 18:09:07 We are planing on how to proceed, most likely another small revision to the spec 18:09:15 anil_rao: sure 18:09:16 https://review.openstack.org/#/c/96149/ 18:09:23 However, we need some help on how to address the objection to the *-aaS issue. 18:09:37 must.not.laugh. 18:09:39 marios: thanks, sorry i should have been posting the links during the discussion 18:10:16 marios: true, except that its not funny to hold up the spec for this reason! :-( 18:10:35 SumitNaiksatam: np (i just had it open so pasted). yes this is true. 18:10:56 anil_rao: please proceed 18:11:16 We are also looking into starting the implementation and uploading some initial code for review as WIP 18:11:20 anil_rao: i do understand the motivation and need for choosing that name 18:11:31 i belive the rest of the team is also aware of that 18:12:07 plus the *-aas issue is much wider reaching than tap-aas (as in the comments, lb, vpn, fw etc) 18:12:25 marios: true, there is already a precedent! 18:12:38 i believe the itention was to expose a rich set of features behind this service endpoint 18:12:48 port-mirroring is the first capablity 18:13:19 Perhaps we will make our intentions more explicit in the spec so that there is no confusion going forward 18:13:28 anil_rao: sure 18:13:48 One question if I may. 18:14:00 the predicament for the authors here is that if they pack too many features they will be dinged for putting too much in 18:14:07 anil_rao: please go ahead 18:14:53 We are currently referencing an older BP called Port-Mirroring Extension. Perhaps that is what is causing the confusion. Do you all suggest that we drop that BP and create a new one for our Spec. 18:15:22 anil_rao: ah, i did not realize that 18:16:00 anil_rao: perhaps, however the new BP should have enough in it to suggest that is it sufficiently different or encompasses the existing one 18:16:23 Ok. 18:16:26 anil_rao: you have done the right thing by referencing and trying to reuse an existing body of work 18:16:45 anil_rao: however if it is causing issues, perhaps something worth considering 18:17:06 Ok. I'll discuss this with Vinay. 18:17:16 anil_rao: it might also be good to send out an email to the -dev mailer explaining this explicitly 18:17:26 Sure. That is a good idea. 18:17:32 SumitNaiksatam: Sorry to chime in late. May I ask one question. Regarding our comment about the direction of the chain on service chaining BP, I did not see a reply on the latest comment. 18:18:02 That is, supposing user request FW then IDS, the service chaining API reqires specifying the port for applying the service and the BP gives an example of a Neutron port between a router and network X. But without the direction, it is ambigous whether the traffic flows through Router->FW->IDP->Network X or the reverse sequence. 18:18:36 cathy_: sure, i think we have some spare time 18:18:53 cathy_: can you hold that question while we wrap up the Tap update? 18:19:01 sure 18:19:07 anil_rao: anything else you wanted to discuss? 18:19:15 any questions for anil_rao on Tap? 18:19:18 No at this time. Thanks 18:19:26 anil_rao: thanks 18:19:52 #topic Open Discussion 18:20:03 hemanthravi: still there? 18:20:14 yes 18:20:23 cathy_: did you post the comment on the approved spec? 18:20:41 cathy_: i believe the list of nodes is intended to be ordered 18:20:51 yes, I posted. Then Louis posted on a new updated version 18:21:03 marios: true, that was my understanding as well (and the original intent) 18:21:09 cathy_: ah ok 18:21:12 i dont see mandeep here 18:21:21 "This creates the ordered-list ["FW", "LB"] as the list of services in the 196 chain. 18:21:32 hemanthravi: can you take a stab at answering cathy_’s question? 18:22:24 currently it's an ordered list and traffic in reverse will the list reversed 18:22:31 cathy_: i believe your question is that you want only traffic from one direction to hit the service chain in that order? 18:22:45 the latest version actually is updated to be more explicit about the direction/ordering https://review.openstack.org/#/c/93524/12..13/specs/juno/service-chaining.rst 18:23:17 marios: true 18:23:31 SumitNaiksatam: what is needed is the explicit, If the latest has that, we cna take a look. 18:24:07 cathy_: ok, we can circle back to this if your query is not satisified 18:24:19 But from the API, how could the user spacify two different sequences of service chain (one the forward sequence, the other the reverse sequence)? 18:24:37 in the lates there is no defintion of what "ingress" and "egress" traffic is 18:24:48 #action hemanthravi to report back on cathy_’s question “from the API, how could the user spacify two different sequences of service chain (one the forward sequence, the other the reverse sequence)?” 18:25:02 LouisF: got it 18:25:25 hemanthravi: see the above action item ^^^ :-) 18:25:37 SumitNaiksatam: hemanthravi : Thanks! 18:25:46 will do, need to work through some of the scenarios 18:25:52 cathy_: np, thanks for brining it up 18:26:11 we are getting close to our time here 18:26:19 hemanthravi: look at my comments on previous patches 18:26:33 LouisF: ok 18:26:41 anything else we need to discuss? 18:27:20 3 minutes early!!! 18:27:28 goodnight all :) 18:27:28 s3wong: yay! 18:27:32 thanks all for attending 18:27:36 keep up the good work 18:27:38 bye 18:27:39 @SumitNaiksatam: a last suggestion 18:27:42 Thanks! 18:27:49 regXboi: just in time 18:27:51 regXboi: shoot 18:28:07 send an email out to openstack-dev with the link to the minutes and a note of any #agreed items 18:28:11 just to be friendly 18:28:15 regXboi: ah ok 18:28:20 I'm going to send mail suggesting that across the board 18:28:25 regXboi: did not have any “agreed” items today 18:28:33 having spent time cross-indexing minutes with ML 18:28:34 regXboi: but good suggestion 18:28:43 thanks 18:29:02 regXboi: i have tried not to bombard the mailing list with too many emails about routine items 18:29:12 regXboi: since i think there is already an overload 18:29:23 regXboi: but will definitely keep that in mind in the context that you mentioned 18:29:32 understood - but a note about a "hey we met, here are the minutes" keeps all abreast 18:29:33 and right on dot 18:29:40 regXboi: sure 18:29:44 #endmeeting