17:31:32 <SumitNaiksatam> #startmeeting Networking Advanced Services
17:31:33 <openstack> Meeting started Wed Aug 13 17:31:32 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:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:31:36 <openstack> The meeting name has been set to 'networking_advanced_services'
17:31:39 <dougwig> o/
17:31:51 <songole> Hello
17:32:04 <SumitNaiksatam> #chairs s3wong vinay_yadhav marios pcm_ dougwig songole
17:32:11 <marios> lol :)
17:32:15 <marios> getting ready?
17:32:15 <SumitNaiksatam> there, just in case i disconnect ;-)
17:32:27 <SumitNaiksatam> sorry for the fiasco last week with my connection
17:32:34 <SumitNaiksatam> i am still on the same connection though :-P
17:32:39 <SumitNaiksatam> hopefully better this time
17:33:20 <SumitNaiksatam> so like last time, lets first check if we can get the PTL to provide us some high level guidance on the priority and/or feasibility of making progress with the approved blueprints
17:33:25 <SumitNaiksatam> mestery: hi, there?
17:35:24 <s3wong> around 12:30 central time, imagine he is on lunch or something :-)
17:35:53 <SumitNaiksatam> s3wong: o
17:35:55 <SumitNaiksatam> ok
17:36:01 <SumitNaiksatam> yeah perhaps he is not around
17:36:18 <SumitNaiksatam> in that case lets stick to our regular agenda
17:36:28 <LouisF> SumitNaiksatam: are any BPs going to be moved to Kilo?
17:36:47 <SumitNaiksatam> LouisF: thats what i wanted to check with mestery
17:37:04 <SumitNaiksatam> LouisF: not that i am aware of or has been publicly conveyed
17:37:23 <SumitNaiksatam> i guess in the absence of any such direction, we continue to on our path
17:37:33 <songole> SumitNaiksatam: how many days do we have before feature freeze?
17:37:58 <SumitNaiksatam> songole: any patched pertaining to new features have to be pushed to gerrit by aug 21st
17:38:02 <SumitNaiksatam> *patches
17:38:14 <songole> ok. got it.
17:38:35 <SumitNaiksatam> patches will be reviewed and can be revised after that date until the end of J3 (which i believe is Sept 4th)
17:38:47 <marios> SumitNaiksatam: that means 'in review' and not 'merged' right? - right you just answered me
17:38:56 <SumitNaiksatam> marios: right
17:39:10 <marios> i spot a loophole ;)
17:39:15 <SumitNaiksatam> so if you have a blueprint that is approved and dont submit a patch for review by aug 21st, you are out of Juno
17:39:31 <SumitNaiksatam> marios: go ahead
17:39:43 <marios> heh, no i meant 'in review' could mean anything. like a part of the blueprint
17:39:54 <SumitNaiksatam> marios: yeah :-)
17:40:25 <SumitNaiksatam> marios: but the thing is that if its partially implemented, the chances that the review for the complete implementation will finish by sept 4th are minimal
17:40:59 <SumitNaiksatam> there will be huge deluge of patches and hence review pressure for the two weeks following aug 21st
17:41:08 <marios> right
17:41:20 <SumitNaiksatam> and if something does not get reviewed and merged by step 4th, then its likely to be out of J3
17:41:26 <SumitNaiksatam> barring exceptions
17:41:50 <SumitNaiksatam> however bug fixes can continue to be submitted
17:42:13 <SumitNaiksatam> however, even there the criteria will get stricter on the severity of bugs
17:42:46 <SumitNaiksatam> ok any more questions on the timelines?
17:43:12 <SumitNaiksatam> #topic Flavors
17:43:19 <SumitNaiksatam> is enikanorov_ or markmcclain1 here?
17:43:28 <enikanorov_> i'm here
17:43:29 <enikanorov_> hi
17:43:56 <SumitNaiksatam> enikanorov_: hi
17:44:11 <SumitNaiksatam> enikanorov_: so our obligatory question, any progress on the blueprint? :-)
17:44:33 <enikanorov_> no, unfortunately, other than fixing reviewers comments
17:44:40 <enikanorov_> (I mean in impl patch)
17:44:47 <SumitNaiksatam> enikanorov_: yeah, i was just going to ask that
17:45:02 <SumitNaiksatam> #link https://review.openstack.org/#/c/105982
17:45:21 <markmcclain1> SumitNaiksatam: sorry the policy mess has consumed all of my available cycles
17:45:22 <enikanorov_> if markmcclain1 is willing to handover spec patch to me, i will gladly work on it
17:45:44 <SumitNaiksatam> markmcclain1: i saw that coming :-)
17:46:26 <markmcclain1> hoping we get that resolved shortly
17:46:26 <SumitNaiksatam> enikanorov_:  ok, i dont think i or anyone here is in a position to mediate
17:46:46 <SumitNaiksatam> markmcclain1: it seems enikanorov_ has cycles
17:46:57 <SumitNaiksatam> markmcclain1: in case you feel comfortable, he has a suggestion
17:48:02 <markmcclain1> yeah need to revisit only because the last time we ventured too far down a path in wrong direction don't want to repeat
17:48:21 <SumitNaiksatam> enikanorov_: any questions for enikanorov_ on the impl patch?
17:48:50 <SumitNaiksatam> or for markmcclain1 on the spec patch
17:49:29 <enikanorov_> markmcclain1: are you referring to providers now?
17:49:39 <enikanorov_> (as 'wrong direction')
17:50:12 <enikanorov_> I'm asking because i saw  lbaass subteam discussing still using provider attribute in the new API
17:50:21 <enikanorov_> it's better if we could avoid that
17:51:38 <dougwig> enikanorov_: that discussing was relevant to flavors as well.  it wasn't provider specific.  we can talk offline.
17:51:47 <dougwig> /discussing/discussion/
17:52:06 <SumitNaiksatam> ok anything else on flavors?
17:53:02 <SumitNaiksatam> enikanorov_: thanks
17:53:17 <enikanorov_> u're welcome :)
17:53:20 <SumitNaiksatam> #topic Service base and insertion
17:53:33 <SumitNaiksatam> s3wong: kanzhe: there?
17:53:49 <s3wong> Just a short update. WIP patch is up: https://review.openstack.org/113975
17:53:57 <SumitNaiksatam> s3wong: oh ince
17:54:00 <SumitNaiksatam> *nice
17:54:11 <s3wong> as it doesn't have DB migration script, it will fail a bunch of CIs and gate tests
17:54:12 <marios> s3wong: great
17:54:22 <s3wong> but I will work on that soon(ish)
17:54:47 <marun> How on earth did this spec get approved?
17:54:53 <marios> for the record, my wip is still at https://review.openstack.org/#/c/108049/ (vpn), but haven't worked on it this week
17:54:55 <SumitNaiksatam> s3wong: sorry for being pedantic on process, can you add the link to the wiki page: https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan
17:54:55 <marun> I think it needs further discussion.
17:55:16 <s3wong> it is only API and DB for service interface; so the plugin and even service base work has NOT been done
17:55:22 <s3wong> so a lot of work ahead, still
17:55:30 <SumitNaiksatam> marios: yeah great, was going to check next?
17:55:38 <SumitNaiksatam> next? -> next
17:55:50 <marun> s3wong: So, why don't we defer to kilo since it's unlikely to be ready in the next 9 days?
17:56:50 <s3wong> marun: I will defer that decision to the rest of the team
17:57:01 <marios> SumitNaiksatam: so i actually wanted to bring this up - not sure if we need to defer, but I think we need some clarity (I was kinda hoping on comments to my wip that would perhaps help clarify things for me)
17:57:10 <marios> err sorry that wasn't meant just for sumit
17:57:28 <SumitNaiksatam> marios: yes
17:57:34 <marios> so a couple days ago i tried to collect the threads. we've been tlaking about this in the last 3 meetings
17:57:35 <s3wong> if marios , kanzhe, SridharRamaswamy, and SumitNaiksatam are all in agreement with that, I have no objection
17:57:37 <SumitNaiksatam> so there are two aspects at play here
17:57:56 <marios> i looked back over the logs and i'd say at least we need to update the spec to clarify some things
17:58:00 <marios> SumitNaiksatam: sorry, go ahead
17:58:04 <SumitNaiksatam> one is the direction that the project wants to take
17:58:19 <SumitNaiksatam> hence wanted to check with the PTL right at the outset
17:58:28 <SumitNaiksatam> we tried to do that at the beginning of the last meeting as well
17:58:47 <SumitNaiksatam> currently as it stands, the bp spec was approved for J3
17:59:07 <SumitNaiksatam> the second aspect is about the confidence of the author
17:59:13 <SumitNaiksatam> in finishing the patch
17:59:40 <SumitNaiksatam> i believe that the requirement in that the patch should be out of WIP by aug 21st
17:59:56 <marios> SumitNaiksatam: there's a third aspect i believe.
18:00:02 <SumitNaiksatam> marios: sure, please go ahead
18:00:22 <marios> SumitNaiksatam: which is what i was trying to say above. the whole 'defer entry' with the messaging isn't described in the spec
18:00:39 <marios> (as well as some minor details like the db migration aspecs, keeping certain fields that we said we'd nuke)
18:00:54 <SumitNaiksatam> marios: ‘defer entry’?
18:01:32 <marios> sec, i will copy/paste, apolgoies in advance:
18:01:34 <marios> 17:50:39 <s3wong> SumitNaiksatam: have we made a decision on how the serviceInterfacePlugin will get the service instance UUID yet?
18:01:37 <marios> 17:52:57 <SumitNaiksatam> s3wong: we can maintain a table in the new service insertion plugin, that will hold a reference to the uuids against their service type
18:01:47 <marios> (from 2014-07-30-17.31.log.html)
18:02:07 <marun> I'm having a hard time understanding why service insertion should be a part of Neutron.
18:02:11 <SumitNaiksatam> marios: ah, i got a little confused by the ‘defer’ part
18:02:23 <marios> yeah, it started off being described that way in the meeting before that
18:02:24 <marun> All the discussion around NFV has made it clear that we don't want to focus on orchestration at that level.
18:02:36 <marun> We need to support it out-of-band, sure.
18:02:38 <marun> But doing it in-tree?
18:03:01 <marun> That was agreed on at summit as being a non-starter, at least for now.
18:03:21 <SumitNaiksatam> marun: what was agreed at the summit as being non-starter?
18:03:26 <marun> The fact that none of the spec approvers were in the room at the summit session is pretty telling.
18:03:40 <marun> And I think good grounds for revoking approval.
18:03:43 <SumitNaiksatam> marun: which room?
18:03:49 <marun> Neutron room, last session.
18:04:05 <marun> SumitNaiksatam: or where you there?
18:04:10 <marun> where -> were
18:04:32 <SumitNaiksatam> marun: no i wasnt there, i had communitcated to the PTL that i had travel plans which could not be changed at the last minute
18:04:39 <dougwig> i think everyone was on planes home for that meeting; i'm not sure that's indicative of anything.
18:04:59 <SumitNaiksatam> marun: at least i was not aware of any decisions that were made during that meeting that were made public
18:05:06 <marun> Regardless of why, I think the validity of the spec is nonetheless in question.
18:05:15 <SumitNaiksatam> marun: was this conveyed to the mailing list or captured in any etherpad?
18:06:03 <marun> SumitNaiksatam: Given that there has been continual rejection of the ideas conveyed in the spec in successive summits, I'm not sure why you would take spec approval as achievement of consensus around the issue.
18:06:10 <marun> And I seriously doubt it comes as a surprise to you.
18:06:29 <SumitNaiksatam> marun: reject of the idea? by who?
18:06:32 <marun> SumitNaiksatam: And yes, it was captured in the summit etherpad.
18:06:47 <SumitNaiksatam> *rejection
18:07:20 <marun> SumitNaiksatam: https://etherpad.openstack.org/p/servicevm
18:07:20 <hemanthravi> marun, though i'm not a spec approver I was present in the last session and don't remember the decision reg service insertion. will take a look at the etherpad
18:07:23 <SumitNaiksatam> why isnt the spec review process being followed if you are fundamentally in disagreement with the idea?
18:07:46 <marun> SumitNaiksatam: I think you are confusing approval of a spec with consensus.
18:08:21 <SumitNaiksatam> marun: i am not talking about approval or consensus
18:08:39 <emagana> SumitNaiksatam: I think this time the spec process was not mature for Neutron and we are realizing that. Hopefully, next cycle will be better.
18:08:46 <SumitNaiksatam> marun: i am just saying, if you had concerns, why werent they expressed on the blueprint spec during the review process
18:09:01 <SumitNaiksatam> marun: the etherpad you point to is about Service VMs
18:09:24 <SumitNaiksatam> marun: there was an entire design summit session which was on the topics that we are discussing in this meeting
18:09:38 <marun> SumitNaiksatam: I'm not sure about you, but there are more specs than anyone can cover.
18:09:42 <SumitNaiksatam> marun: we are not discussing service VM related insertion in this meeting
18:09:57 <marun> SumitNaiksatam: insertion is the same issue in both casese
18:10:05 <SumitNaiksatam> marun: hence we have sub teams to scale the problem
18:10:12 <SumitNaiksatam> or rather solution to the problem
18:10:36 <SumitNaiksatam> marun: not quite
18:10:40 <marun> SumitNaiksatam: The discussion there made it clear that while we need to support the capability to allow unfiltered or trunked ports, that we did not want to be deciding how that plugging took place within neutron.
18:10:45 <SumitNaiksatam> marun: can you explain why its the same in both cases?
18:10:54 <marun> SumitNaiksatam: The subteams are still responsible to the community as whole.
18:11:12 <SumitNaiksatam> marun: of course
18:11:12 <marun> SumitNaiksatam: There is no good excuse for implementing the wrong things.
18:11:27 <SumitNaiksatam> marun: we are not discussing anything related to trunking in this spec
18:11:27 <marun> SumitNaiksatam: If we figure out later in the cycle, it sucks.  Ideally we would figure it out as soon as possible.
18:11:55 <marun> SumitNaiksatam: I gave those only as examples of things needed to support the service vm use-cases.
18:11:57 <marios> marun: apologies if this is a silly question, but have you read the spec in question? it is quite simple in scope, just trying to introduce a single 'context' that captures where a service 'exists' (e.g. the router a vpn service is associated with) in a centralised manner
18:12:02 <SumitNaiksatam> marun: yes, and hence it was proposed in the design summit session and discussed during the design summit
18:12:21 <marun> SumitNaiksatam: But the issue at hand - whether we need to support service insertion in neutron - is the same.
18:12:40 <SumitNaiksatam> marun: please see marios’ comment, i think you are misunderstanding the spec
18:12:43 <marun> SumitNaiksatam: It should be done outside of the tree to prove its worth before we waste time experimenting in the tree.
18:13:21 <SumitNaiksatam> marun: the team has already iterated once on this idea during the icehouse cycle
18:13:28 <SumitNaiksatam> marun: this is enhancement of that idea
18:13:42 <marios> marun: it _was_ more complex before but was simplified quite a bit in order to land
18:14:00 <SumitNaiksatam> marun: and in my opinion not a new idea that is in early stage of experimentation
18:15:09 <SumitNaiksatam> marun: i am still unable to find any where in the etherpad where this bp spec or the service insertion problem that is being attempted to be solved here is being referenced
18:15:17 <hemanthravi> and serves to provide a common framework for insertion being impl independently by services such as fwaas, vpnaas
18:15:58 <SumitNaiksatam> marun: besides, this is one blueprint of a big framework
18:16:14 <SumitNaiksatam> marun: a separate blueprint was registered for defining that framework
18:16:29 <SumitNaiksatam> marun: that was approved by the PTL as welll among other reviewers
18:16:47 <marun> SumitNaiksatam: I like how you always seem to fall back on procedural arguments.
18:16:52 <marun> SumitNaiksatam: Rather than technical ones.
18:17:05 <SumitNaiksatam> marun: this team hasnt gotten any direction that any of that is invalid or misguided effort until your opinion here
18:17:23 <SumitNaiksatam> marun: what is the technical issue?
18:17:31 <marun> SumitNaiksatam: If we are going to go that route, I would point out that all approvers of the spec in question work for the same company.
18:17:47 <SumitNaiksatam> marun: which spec?
18:17:50 <marun> SumitNaiksatam: Which doesn't imply to me that we are getting the core oversight that we would expect.
18:18:03 <SumitNaiksatam> marun: i am talking about the umbrella spec
18:18:22 <SumitNaiksatam> #link https://review.openstack.org/#/c/92200
18:18:40 <SumitNaiksatam> this blueprint was added per feedback from the PTL
18:18:54 <SumitNaiksatam> that the whole community needs to be aware of the general direction we are taking here
18:19:08 <SumitNaiksatam> this was also in response to the issues raised in the LBaaS discussion
18:19:13 <marun> SumitNaiksatam: this spec: https://review.openstack.org/#/c/93128/22
18:19:33 <SumitNaiksatam> that the necessary clean interfaces do not exist on the neutron side to achive integration of services
18:19:40 * markmcclain1 reads scrollback
18:20:31 <emagana> emagana: uff!
18:20:48 <SumitNaiksatam> s3wong: so what is your comfort level with getting this patch out of WIP?
18:20:59 <SumitNaiksatam> s3wong: and is Kanzhe back from vacation now?
18:21:23 <markmcclain1> Ok… so we're 9days out
18:21:34 <s3wong> SumitNaiksatam: I will be working on this and GBP driver full time over this and next week
18:21:45 <markmcclain1> the majority of the neutron core team has been focused on scaling, stability, and parity
18:21:51 <s3wong> SumitNaiksatam: I see Kanzhe online (via Google chat), but haven't heard from him yet
18:22:27 <markmcclain1> and it seems that we're unlikely to get this delivered for Juno
18:22:54 <SumitNaiksatam> markmcclain1: i would like to see a direction from the PTL on this
18:22:59 <markmcclain1> also I'm not sure that the LBaaS team is even aware that this deprecates part of their API
18:23:05 <hemanthravi> markmcclain1, could we make that decision 8/21 based on the readiness of the patch
18:23:26 <SumitNaiksatam> however it seems unfair to make this judgement even before we reach the FFP deadline
18:23:28 <marun> SumitNaiksatam: I think your attempts to appeal to a higher power are in vain.
18:23:45 <SumitNaiksatam> marun: i am not trying to appeal to anyone
18:23:56 <marun> SumitNaiksatam: We still don't have parity with Nova.
18:24:12 <markmcclain1> SumitNaiksatam: why do we have to have mestery weigh in on everything?  the feature is still in WIP and no of the discussion here seems to indicate that it will leave that status w/o heroic effort before Tuesday
18:24:46 <SumitNaiksatam> markmcclain1: hence checking with the author of the patch himself
18:25:09 <SumitNaiksatam> markmcclain1: if he/they dont feel confident, then there is nothing to be argued or for against
18:25:23 <s3wong> SumitNaiksatam: markmcclain1: so I am still committed to get it ready before next Thursday
18:25:24 <SumitNaiksatam> markmcclain1: it is always the case more work gets done closer to the milestone
18:25:47 <SumitNaiksatam> that said i dont have any interest in wasting anyone’s time here
18:25:51 <markmcclain1> I totally understand that work gets done close to deadline
18:26:14 <SumitNaiksatam> hence we sought clarification last week as well, whether this is going to get blocked by a -2 down the line
18:26:22 <markmcclain1> but posting something that deprecates another team's api so close to milestone-3 is asking for trouble
18:26:26 <s3wong> but if the cores consensus is this won't land anyway, please let us know now
18:26:26 <SumitNaiksatam> if that plan is already in place, then its not work pursuing this effort
18:26:57 <SumitNaiksatam> markmcclain1: i am not sure i understand the part of about deprecate another team’s api
18:27:12 <SumitNaiksatam> markmcclain1: this is certainly new information to me or the team here
18:27:26 <SumitNaiksatam> markmcclain1: which team’s API does this deprecate?
18:27:50 <markmcclain1> https://review.openstack.org/#/c/93128/22
18:28:05 <markmcclain1> line 318
18:28:56 <markmcclain1> also the lbaas team has been iterating all summer on new drivers that take none of thing into account
18:28:56 <SumitNaiksatam> markmcclain1: ok
18:29:23 <markmcclain1> there is clearly duplicative and confusing work occurring because of the two silos
18:29:27 <SumitNaiksatam> markmcclain1: my understanding was that the lbaas team is represented here, and also this team is represented on the lbaas side
18:29:36 <SumitNaiksatam> i believe dougwig is part of the lbaas representation here
18:29:47 <SumitNaiksatam> and s3wong was part of the representation of this team on the lbaas side
18:29:58 <marios> markmcclain1: SumitNaiksatam: to markmcclain1's point, the changes for the services aren't actually going to happen (I mean for ex we already agreed that for vpn, we won't be nuking the router attribute as was stated in the spec)
18:30:07 <SumitNaiksatam> i dont think any issues have been brought up in this forum about this deprecation statement
18:30:16 <dougwig> sorry, i only attend sporadically, and have really only been paying attention to flavors.  i can add some time, but i'm not currently up to speed.
18:30:34 <markmcclain1> obviously cramming this in a the last moment is a bad idea
18:30:50 <s3wong> SumitNaiksatam: markmcclain1: right, and I did go to the LBaaS mid-cycle and had discussions with blogan and susanne on this
18:31:05 <markmcclain1> I don't want folks expending superhuman effort for something we have reconciled ahead of time
18:31:15 <markmcclain1> s/have/have not/
18:31:21 <SumitNaiksatam> markmcclain1: again, if you have already decided to -2 this, then there is not point in pursuing further, however please do not mischaracterize this as being crammed at the last minute
18:31:37 <SumitNaiksatam> not -> no
18:31:40 <markmcclain1> s3wong: to my knowledge none of the planned v2 specs reference this
18:31:57 <markmcclain1> SumitNaiksatam: I haven't decided to -2 this because the code is WIP
18:32:27 <markmcclain1> which is why I'm asking the hard question of whether we can resolve these issues in time
18:32:29 <SumitNaiksatam> markmcclain1: but i think we do get the hint here
18:32:41 <s3wong> markmcclain1: correct, due to their code being ready by J-2 (earlier schedule) while ours is at J-3
18:32:52 <markmcclain1> I'd hate for devs to kill themselves implementing for use in the review period to realize we have a bunch of ill fitting parts
18:32:53 <dougwig> markmcclain1, s3wong: correct, v2 hasn't taken this into account yet.  i think we likely did talk about it, but it didn't make it to any code.
18:33:17 <SumitNaiksatam> dougwig: markmcclain1 its also a chicken and egg problem
18:33:21 <markmcclain1> we went down this road before with provider networks and l3 routers
18:33:22 <s3wong> dougwig: correct
18:33:43 <markmcclain1> delivering two incompatible features took 2+ cycles to clean up
18:34:11 <SumitNaiksatam> ok just a time check, we have run out of time for this meeting
18:34:32 <SumitNaiksatam> can we take an action item to check between s3wong dougwig markmcclain1 if this breaks anything on lbaas?
18:34:40 <emagana> I would love to see devs helping on the priority staff.. nova parity, migration, even docs!
18:34:41 <SumitNaiksatam> and decide whether to proceed or not?
18:35:01 <dougwig> SumitNaiksatam: yes, i'd be happy to discuss with s3wong (or anyone else) offline.
18:35:09 <s3wong> SumitNaiksatam: sure
18:35:15 <s3wong> dougwig: great
18:35:28 <SumitNaiksatam> markmcclain1: sound okay
18:35:29 <SumitNaiksatam> ?
18:35:33 <emagana> Please, use the neutron channel for those "offline" discussions
18:35:51 <dougwig> i'd prefer to use #openstack-lbaas, as it's less noisy.
18:35:57 <dougwig> and also logged.
18:36:04 <SumitNaiksatam> #topic Open Discussion
18:36:16 <SumitNaiksatam> sorry we could not bring up any of the other agenda items
18:36:17 <markmcclain1> yeah just really want to make sure we're all on same page and wasting resources
18:36:23 <emagana> dougwig: I have so many channels open that I can't keep up
18:36:24 <SumitNaiksatam> markmcclain1: absolutely
18:36:25 <markmcclain1> *not wasting resources*
18:36:45 <SumitNaiksatam> any parting thoughts anyone?
18:37:13 <dougwig> s3wong: do you have time in about an hour?
18:37:13 <SumitNaiksatam> thanks all for joining
18:37:19 <SumitNaiksatam> #endmeeting