21:02:03 #startmeeting networking 21:02:04 Meeting started Mon Aug 4 21:02:03 2014 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:02:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:02:08 The meeting name has been set to 'networking' 21:02:20 Hello 21:02:23 #link https://wiki.openstack.org/wiki/Network/Meetings Agenda 21:02:24 o/ 21:02:34 #topic Announcements 21:02:55 I would be indecent if I didn't start off the meeting by mentioning our large Juno-3 BP list: https://launchpad.net/neutron/+milestone/juno-3 21:02:57 #link https://launchpad.net/neutron/+milestone/juno-3 21:03:04 We've merged ... 4 BPs so far. 21:03:35 We're making progress, but it's slow, though I do see some activity picking up this week on a few things. 21:03:42 Thanks to all the revewiers and contributors here! 21:04:09 #link https://wiki.openstack.org/wiki/Juno_Release_Schedule 21:04:15 FPF is August 21 21:04:24 Feature Freeze is September 4 21:04:31 Those dates are fast approaching. 21:04:36 Which means Juno is nearing it's end. 21:04:45 #info FPF is August 21 21:04:51 #info Feature Freeze is September 4 21:04:56 Any other announcements from anyone? 21:05:57 OK, our bug czar can't join us today, so we'll skip the bugs section today. 21:06:07 And I'll go into one last announcement: 21:06:16 #info The LB and OVS plugins are due to be removed from the tree this week. 21:06:33 #topic Docs 21:06:35 emagana: Hi there! 21:06:43 mestery: hello! 21:06:45 emagana: You had a nice etherpad last week with doc work, do you have that handy again? 21:06:55 mestery: absolutely 21:06:59 emagana: thanks! 21:07:09 #link https://etherpad.openstack.org/p/neutron-docs-juno 21:07:40 I was expecting a lot of volunteers but.. sadly none 21:08:04 emagana: That's disappointing indeed. :( 21:08:19 mestery: We will make some progress in our end and as we get closer to Juno release, we will cal people directly 21:08:41 Hopefully, folks will have more availability after Juno-3 21:08:44 emagana: I think we may have to go that route, yes. 21:08:49 emagana: ++ 21:09:04 mestery: nothing more to report captain 21:09:20 emagana: Thanks! Hopefully next week we get a few new people to signup for docs items on that etherpad. 21:09:30 #topic Tempest 21:09:32 mlavalle: Hi there! 21:09:41 mestery: hi 21:09:59 mestery: so I have been working with the new LBaaS team, testing the api 21:10:24 mestery: at this point we have confirmed that most of the api works fine 21:10:35 * markmcclain joins late 21:10:52 there is an issue with deleting listerners that might be a problem with testing script 21:10:55 markmcclain: We'll get to the parity items next :) 21:11:10 I will investigate further tonight and report results 21:11:19 mlavalle: I saw your email to the list, are you working with dougwig and/or blogan on that? 21:12:05 yes, he's been on the lbaas channel. 21:12:06 mestery: yeah, I am in contact with both of them in irc. Plus, I have the dubious privilege of seeing blogan every day at the office :-) 21:12:16 mlavalle: Heh :) 21:12:41 #info LBaaS API tests are working except for deleting listeners. 21:12:59 mestery: there is also a couple of api tests being develepode by zzelle that I am tracking 21:13:11 those are for provider networks 21:13:33 next step with new LBaaS is to write a scenario test 21:13:37 #info mlavalle tracking some API tests for provider networks being developed by zzelle 21:13:55 that's all I have this week 21:13:56 mlavalle: For the scenario test, is the plan to use the agentless ha-proxy driver? 21:14:09 mestery: yes, that's my target 21:14:19 mlavalle: OK, thanks! 21:14:32 #topic Parity 21:14:35 markmcclain: hi there! 21:14:42 hi 21:14:45 for the api test I've been using the ha-proxy agentless driver as weel 21:15:09 so we're still making lots of progress on parity work 21:15:34 I'm about read to mark dvr as done for parity 21:15:48 Yes, I think it's reached that point as well! 21:16:11 currently working with the nova team to redefine the migration plan for users 21:16:29 #info DVR work will be marked as complete with regards to parity coverage 21:16:40 markmcclain: So, the plan around migration is to not require it I believe, right? 21:17:26 based on discussion with the Nova team we're heading that way 21:17:42 neutron migration design spec was updated and now includes both live and cold migration approaches 21:17:50 obondarev: Awesome! 21:18:03 #info nova/neutron teams leaning towards not requiring migration from a parity gap perspective 21:18:15 not requiring it, meaning not requiring having a migration path? 21:18:17 #info Migration doc updated to include both live and cold approaches 21:18:22 banix: Correct. 21:18:35 so both cold and live have operational issues 21:18:44 that simplifies things a bit :) 21:18:54 banix: Indeed :) 21:19:02 * salv-orlando not the first time hears this story about migration path not required for parity... 21:19:22 there was broad consensus among the nova team present at the mid-cycle that migration should be a post-parity concern 21:19:27 which is why we're converging on agreeing it might be a bad idea to push one size fits all 21:20:04 markmcclain: I think that's the main problem with the migration idea, so I'm happy to hear this was the consensus last week. 21:20:19 are there any meetings minutes regarding migration form nova mid-cyxle anywhere? 21:20:26 from* 21:20:33 obondarev: just in the etherpad 21:20:42 ok, saw them 21:21:05 link for those who come later? 21:21:10 (i.e. for the minutes?) 21:21:11 #link https://etherpad.openstack.org/p/juno-nova-mid-cycle-meetup 21:21:23 thanks 21:21:39 Did the "nova network as an ML2 mechanism driver" idea get any traction? 21:21:56 HenryG: not really because there are technical downsides to that approach 21:21:57 no 21:21:58 HenryG: I hope not! 21:22:14 It was mostly DOA I believe :) 21:22:27 OK, just wanted to make sure, thanks. 21:22:55 mestery: that's all I've got on parity 21:23:00 markmcclain: Thanks! 21:23:25 Just one more note, markmcclain and I will be presneting the status again this week in the TC and/or release meetings tomorrow. 21:23:33 #topic L3 21:23:34 carl_baldwin: Hi there! 21:23:39 mestery: hi 21:23:50 We’ve made lots of progress on DVr. 21:23:53 *DVR 21:24:11 There is a backlog but many of the issues have already been addressed. 21:24:26 #link https://bugs.launchpad.net/neutron/+bugs?field.tag=l3-dvr-backlog 21:24:34 … or are in progress. 21:25:08 l3-high-availability is in review. 21:25:16 #link https://review.openstack.org/#/q/topic:bp/l3-high-availability,n,z 21:25:52 Oh, on DVR. There is an experimental job that runs tempest with DVR fully enabled. 21:26:04 carl_baldwin: That's really good news! 21:26:08 There are a few tests still not passing but not bad. 21:26:27 most notably the ones around firewall 21:26:31 #info Experimental Tempest job which utilizes DVR is running as experimental 21:26:32 We’ll be looking to convert that job to a non-voting job. 21:26:47 mestery: to kick it off just post ‘check experimental’ on a review of interest 21:26:48 armax SridarK: Any updates on the work to make FWaaS and DVR work together? 21:27:08 #info To kickoff the experimental job, just run "check experimental" on a review of interest. 21:27:10 armax: thanks! 21:27:13 mestery: working thru this - will get a patch out in a few days 21:27:24 SridarK: Cool! 21:27:31 mestery: SridarK and vishnu are working on a DVR setup 21:27:39 SumitNaiksatam: Thanks! 21:27:46 SridarK: super! 21:27:57 mestery: we are in touch with Swami and the DVR team for this 21:27:58 SumitNaiksatam: thanks 21:28:20 #info FWaaS team is working with DVR to close the DVR/FWaaS integration in Juno. 21:28:23 SumitNaiksatam: Thanks for the udpate! 21:28:36 I’m also reaching out about rootwrap daemon mode. I think we’d like to know this week if it has a chance. 21:28:37 mestery: sure, and thanks to SridarK and Vishnu 21:29:01 mestery: That is all from me. The rest of the status is on the wiki. 21:29:08 carl_baldwin: It seems unlikely, given the concerns raised by ttx. 21:29:18 carl_baldwin: But we need to close on that by this week if it has a chance at all. 21:29:29 mestery: I'm also digging into it further 21:29:43 mestery: markmcclain: thanks. 21:30:00 carl_baldwin: Thanks for the updates! 21:30:03 #topic Advanced Services 21:30:06 SumitNaiksatam: Hi there! 21:30:10 mestery: hi 21:30:20 so the flavors spec is still in bit of a limbo 21:30:39 but enikanorov_ has posted an implementation patch: #link https://review.openstack.org/#/c/105982 21:30:50 SumitNaiksatam: Flavors is the only other spec with a chance at an exception at this point, but it appears to e stuck as yousay. 21:30:52 i believe based on teh agreed upon aspects of the spec 21:30:56 enikanorov_: thanks forworking on the implementation 21:30:59 mestery: yeah 21:31:25 other than that hemanthravi and songole are making progress on the service chain implementation, and should be posting a patch soon 21:31:46 #info Flavor Framework spec still at risk of not making Juno. 21:32:02 mestery: thats its from me for this 21:32:21 SumitNaiksatam: thanks! 21:32:30 #topic IPv6 21:32:32 sc68cal: Hi there! 21:33:01 * mestery notes that the final set of IPV6 BPs are close to merging now. 21:33:55 I think, based on reading BPs, that IPV6 support will be complete in Juno if those merge. 21:34:02 In lieu of sc68cal not being here, lets move on though. 21:34:08 #topic ML2 21:34:14 rkukura Sukhdev: Hi! 21:34:16 hi 21:34:22 mestery: hi 21:34:25 not a lot new with ML2 21:34:34 a number of new drivers are in review 21:34:53 and we are working to get the remaining BP implementations into review 21:34:53 rkukura: Was curious on how the extension support was coming along, is that seeing some progress? 21:35:20 nlahouti: do you have an update on that? 21:35:21 mestery: the code is under review 21:35:46 nlahouti: OK, was curious about that one as I was looking at Juno-3 BPs today. 21:35:49 mestery rkukura: https://review.openstack.org/#/c/89211/ 21:36:12 #info Remaining ML2 BPs hope to enter implementation stage soon 21:36:28 Sukhdev: Did we miss anything? 21:36:39 I'm concerned about adding additional attributes to responses… they basically make our API responses random 21:36:39 #link https://review.openstack.org/#/c/89211/ 21:36:42 I was going to ask markmcclain to remove -2 from the review 21:36:46 as the BP is approved 21:37:05 rkukura: you covered good - one thing I'll add is that we hope to close of on hierarchical port binding soon 21:37:18 s/of/off 21:37:29 nlahouti: I recall that -2 was on a previous patch and the current code is an entirely different approach 21:38:05 Sukhdev: Yes, hope to have an initial hierarchical port binding patch later this week. 21:38:14 rkukura: that's correct. 21:38:33 nlahouti: So, there is no -2 on the new approach that you and rkukura worked on> 21:38:34 ? 21:38:45 my -2 is still there 21:38:45 mestery: No 21:38:50 I did review the patch this morning 21:38:54 markmcclain: yes 21:38:55 markmcclain nlahouti: OK, got it. 21:38:58 I have some concerns on the approach 21:38:59 https://review.openstack.org/#/c/89211/ 21:39:02 but more info on the patch 21:39:23 armax: I got your comment and we will address those 21:39:33 I welcome salv-orlando to give his opinion too, as he’s been instrumental in driving the API extension framework and its integration wit hte policy framework 21:39:41 nlahouti: thanks 21:40:10 *the 21:40:42 OK, thanks for the ML2 updates rkukura and Sukhdev! 21:40:53 #topic Group Based Policy 21:40:55 SumitNaiksatam: hi! 21:40:59 mestery: hi again 21:41:11 so, the patches have been in review for a while - https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches - nothing new there 21:41:24 the -2 on the first also persists, so nothing new there either 21:41:36 hence the team sent out an email to the mailer today 21:41:39 SumitNaiksatam: I posted this http://lists.openstack.org/pipermail/openstack-dev/2014-August/041863.html 21:41:48 #link http://lists.openstack.org/pipermail/openstack-dev/2014-August/041864.html 21:41:53 #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches 21:41:57 So we have whole set of patch now? 21:42:06 markmcclain: yes, i saw that just before the meeting 21:42:13 nati_ueno: yes the whole series is present 21:42:37 markmcclain: imho, that proposal looks like a workflow change in the neutron process (something like CI for vendor plugins) 21:42:56 markmcclain: this topic has been discussed in the open for well over a year now 21:43:02 ivar-lazzaro: it is a change 21:43:05 ivar-lazzaro: I'm not sure how you came to that conclusion. 21:43:11 markmcclain: why addressing it this way? I think it should be discussed properly like what happened at that time 21:43:23 markmcclain: so there its mature enough 21:43:41 SumitNaiksatam: Has any of the discussion addressed how the policy initiative is going to evolve? 21:43:54 marun: well, it's kind of asking for all the extensions to be put in stackforge, did I get it wrong? 21:43:56 SumitNaiksatam: It's pretty clear to all involved that the effort is experimental. 21:43:57 marun: huh? 21:44:05 SumitNaiksatam: I've heard from policy contributors that they want the API to experiment and get user feedback 21:44:10 marun: huh^2? 21:44:11 marun: how is GBP different from LBaaS or FWaaS? 21:44:11 markmcclain: there also dont seem to be any outstanding concerns 21:44:12 markmcclain: I hope that I haven’t confused matters in using the word “experimental”. My understanding is that the initial version of any new service API is labelled “experimental”, indicating it is subject to incompatible tweeks and isn’t considered stable. 21:44:32 SumitNaiksatam: And as per Mark's email we don't have a good track record of evolving complex features in-tree. 21:44:40 ivar-lazzaro: the difference is we learned from those experiences 21:44:59 markmcclain: But your email seems to have a completely different interpretation of “experimental”. 21:45:00 markmcclain: right, that's why your proposal… just like CI for vendors 21:45:08 rkukura: right incompatible tweaks is where we get into problems 21:45:21 markmcclain: as such, it should be targeted properly, and discussed like it has been done that time 21:45:21 once the code lands in master our ability to refine is limited 21:45:31 ivar-lazzaro: we can’t really compare GBP with LBaaS or FWaaS, as they sit at a different levels of abstractions 21:45:35 also if we have a defect we have to a full cycle to fix it 21:45:56 markmcclain: this way, it just looks like a new requirement kind of "out of the blue", doesn't it? 21:45:56 rkukura: I'm not sure how you could define 'experimental' other than 'we don't know what a good solution looks like, so we're going to iterate until we find it'. 21:45:58 the deployers do expect some stability even when experimental features in the tree 21:46:30 armax: I cited FWaaS and LBaaS like Mark did in his email 21:46:43 markmcclain: and i believe we are at that stage 21:46:44 ivar-lazzaro: And you think those are examples of how to do things right? 21:47:02 Why is so urgent and important the GBP? Seriously, looks like we are missing the most important staff which is Neutron stability, parity and HA 21:47:15 marun: what? discussing a workflow change with the due time, the whole community, and without targeting already approved patches? 21:47:24 ivar-lazzaro: imo process != API 21:47:40 emagana: you should check with the PTL, this feature has been prioritized as high 21:48:00 mestery: Can you explain why this is so important?? 21:48:01 armax: Sorry armax, I probably said something confusing, I've never talked about API did I? 21:48:04 emagana: and there is demand from both operators and vendors to support it 21:48:17 SumitNaiksatam: 'demand' is a pretty nebulous statement 21:48:28 SumitNaiksatam: since they don't actually know what a good solution looks like either 21:48:39 SumitNaiksatam: hence the need to iterate 21:48:39 SumitNaiksatam_: vendors I do understand it but Operators??? I don't believe it! 21:48:50 ivar-lazzaro: ok, no worries, don’t mind me 21:48:52 marun: but they have all had a chance to review this for a long long time 21:49:11 SumitNaiksatam_: I recognize that we have invested time in this 21:49:13 emagana: you can check the mailing list, i dont have the link handy here 21:49:18 SumitNaiksatam_: We both know that reviewing code and using it in a production scenario are very different things. 21:49:25 so I can speak from both the vendor and operator side on this one 21:49:37 but APIs take time to gel which is why I think StackForge is a good platform to let it solidify with users 21:49:39 and yes, I can say as an operator that without GP neutron gets a bit less interesting 21:49:39 markmcclain: its not just because we have invested time 21:49:41 SumitNaiksatam_: I am attending the Operators meet-up: https://etherpad.openstack.org/p/SAT-ops-meetup 21:50:01 emagana: See regXboi's input above ^^^ 21:50:22 SumitNaiksatam_: If you see the official agenda, there is nothing on GBP.. Actually, "congress" will be discussed 21:50:23 regXboi: There's exactly nothing preventing an operator from simplifying things for users. 21:50:25 * salv-orlando confused. Are we talking about proces, APIs, or users? Or everything at the same time? 21:50:37 marun: that goes for every feature or change we make in neutron 21:50:37 SumitNaiksatam_: Very superficial.. anyway/// 21:50:37 salv-orlando: +1 21:50:38 regXboi: And also nothing to prevent gbp being useful out-of-tree 21:50:39 Hmm I'm not sure why this discussion happening now... 21:50:44 marun: but we dont iterate in stackforge on everythin else 21:50:56 Anyway.. I will shut up! 21:50:58 SumitNaiksatam_: actually we do 21:51:12 stackforge/kite is from Keystone 21:51:24 marun: I would argue that as an operator, if something isn't in-tree it doesn't exist 21:51:25 and several incubated repos have started life in stackforge 21:51:32 Why is it that every indication of support is seen as vindication of your efforts, but you ignore every detractor? 21:51:33 Honestly? 21:51:36 it is why I thought the platform would be a match for us 21:51:37 markmcclain: I’m kind of troubled by your suggestion to develop GP out-of-tree, given the negative reaction we had for even developing a small PoC implementation out-of-tree. We responded to this very valid feedback with several series of much smaller patches, incrementally building on each other. Do you really think if we went off and continued developing GP out-of-tree, there is any realistic chance of it being 21:51:38 merged in one huge piece in the future? 21:51:51 markmcclain: So now all Neutron extensions should go through StackForge? 21:51:53 marun: isn’t the reason of keeping it out of neutron is so that operators don’t use it? 21:52:12 regXboi: You want all the work done for you, fair enough. 21:52:32 regXboi: The point is that iterating on untested features in the tree is painful for both developers and the people that have to review them. 21:52:45 regXboi: Many of us think that the situation could be improved 21:52:45 marun: I grant that point 21:52:48 We have 8 minutes left, how do we as a community move forward together here? 21:53:00 So that important features could be developed faster and to a higher standard of quality 21:53:02 resending my question: mestery: Can you explain why this is so important?? 21:53:14 markmcclain: it might be good for totally new features to go to stackforge, that is a separate discussion (on process) 21:53:21 I think the way forward is stackforge 21:53:25 mestery: We need to discuss about CI as well! 21:53:30 marun: but that does not translate to comments about operators not being interested in GP 21:53:32 markmcclain: but in this case this has been discussed and deliberated for almost an year now 21:53:45 we get the consistency in process and the team get its velocity back 21:54:14 regXboi: The goal isn't to banish potentially important features and render them unusable by operators 21:54:15 mestery: Honestly, I think that what Mark proposed should be discussed generically for all the Neutron extensions (to be fair) 21:54:31 mestery: what is the process for making such decisions 21:54:33 regXboi: The point is to evolve features and then give first-class support to the ones that prove themselves useful 21:54:35 mestery: ? 21:54:52 Look, we as a community need to move forward here, if we can't do that, then we've lost everything IMHO. 21:54:59 I am not going to make a single decision here. 21:55:02 I don't expect others to either. 21:55:05 This is a COMMUNITY. 21:55:08 Got it? 21:55:13 marun: That is why we have structured neutron in terms of a small core plus a set of optional services that can be configured (or not). 21:55:13 We need to work together and move forward. 21:55:17 mestery: absolutely 21:55:23 regXboi: We don't have the resources to treat everyone's new thing as worth supporting in the tree. We need to make sure we are prioritizing our efforts. 21:55:36 ivar-lazzaro: there's some merit to that idea for new services.. older services will have a complicated history to sort out 21:55:40 marun: this is not everyone's new thing either 21:55:44 marun: there is a dangerous assumption in that statement and that is that OpenStack becomes irrelevant if it can't keep up 21:55:57 regXboi: I think you're wrong 21:56:07 marun: we can agree to disagree on that point 21:56:22 regXboi: If that makes you feel better, sure. 21:56:28 rkukura: right we do have optional features but operators depend on us to produce production ready 21:56:30 * mestery notes this all ends in 4 minutes. 21:56:37 markmcclain: that's why this need to be discussed properly. And not being a blocker for patches already "ready" 21:57:03 ivar-lazzaro: i agree, this is completely adhoc 21:57:04 markmcclail: otherwise it just becomes a last minute requirement IMHO 21:57:06 ivar-lazzaro: I think your determination of what 'ready' means differs from mine. 21:57:12 what we learned by the way we introduced other features is that the path was not optimal 21:57:12 mestery: Reminder for the discussion about CI 21:57:15 ivar-lazzaro: that's kind of the crux of the problem. 21:57:24 ivar-lazzaro: this is not a last minute requirement 21:57:32 this is about figuring the right forward 21:57:39 emagana: We may ahve to move that to the ML given the time left. 21:57:43 * armax thinks that this is not to be solved in 3 minutes 21:57:45 experimenting in the master branch does work very well 21:57:47 marun: ready means approved by the community (BP) and by the reviewers on technical side (review board) 21:57:58 marun: (IMHO of course) 21:58:08 what is the point of the specs process when we have to rehash this stuff again after an approval? 21:58:13 markmcclain: We are working hard to make the Juno version of group policy production ready. 21:58:13 markmcclain: is that statement missing a "not"? 21:58:14 ivar-lazzaro: the process is never strictly mechanical. 21:58:27 ivar-lazzaro: that is simply how we channel our efforts, and maybe that's all you're seeing. 21:58:36 * regXboi thinks armax is spot on 21:58:39 kevinbenton: +1 21:58:49 kevinbenton: agile development requires a feeback loop 21:58:52 Look, lets keep this discussion going on the ML given the time left. 21:58:54 armax: +1 21:58:54 rkukura: it is agreed that the API needs users to validate it and that it could change.. production ready mean will support it for a minimum of N+2 cycles 21:58:55 The threads are out there. 21:58:55 markmcclain: everything is blocking something which is ready to merge with a request which was never made for similar patches is a last minute requirement for me… 21:58:56 kevinbenton: we dont use a waterfall model 21:59:01 I encourage everyone to jump in there. 21:59:02 kevinbenton: agree; we need to have these discussions early on 21:59:04 armax: then the specs process should go away 21:59:04 nothing gets carved in stone 21:59:19 armax: because it’s like a guessing ritual 21:59:20 kevinbenton: no 21:59:24 we revise our decisions, refine, iterate and make things better over time 21:59:35 kevinbenton: +1 21:59:38 kevinbenton: it should be enhanced so we iterate on the specs in concert with the code 21:59:39 ivar-lazzaro: if you notice I'm arguing code merits, just where we should experimenting and baking new features 21:59:42 just because a bp is approved doesn’t mean it’s the bible 21:59:49 we need review input to iterate - that will not happen outside the tree 21:59:51 *I'm not arguing code merits* 21:59:54 mestery: i think there needs to be a clearly defined process on how such decisions are made 22:00:03 rkukura: input from who? 22:00:04 mestery: and they should not be applied retroactively 22:00:04 I am talking in the general sense here, not GBP specifically 22:00:15 SumitNaiksatam_: I agree, and again, as a community, we need to decide how that process is defined. 22:00:23 rkukura: who are you needing input from that you won't be getting in stackforge? it's not like you can't ask interested cores to do the same thing they do in-tree. 22:00:24 I don’t think I hve the technical stature to speak about this specific matter, nor I have visibility into user demands. The only thing I would like to point out, is that orthogonal extensions pose a large workload in terms of reviews on the core team. This is tremendously frustating for contributors as well (with some enraged reactions you might have become aware of). 22:00:24 I'll leave folks with this: 22:00:26 armax: +1 22:00:29 Neutron is not a dictatorship. 22:00:40 And with that, lets see everyone next week and on what is sure to be an exciting ML thread. 22:00:42 #endmeeting