14:01:26 #startmeeting networking 14:01:27 Meeting started Tue Mar 24 14:01:26 2015 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:31 The meeting name has been set to 'networking' 14:01:37 o/ 14:01:38 #link https://wiki.openstack.org/wiki/Network/Meetings Agenda 14:01:42 swamireddy: I don't see any listing for ec2-api meeting on the meeting page: https://wiki.openstack.org/wiki/Meetings 14:01:49 #topic Announcements 14:02:01 We're in the feature freeze now, trying to get ready to cut an RC1 14:02:01 mestery: Thanks...will take the next week slot on this. Thanks ..sorry for confusion.. 14:02:20 We'll likely spend most of the meeting going over specs which are in RC1 14:02:28 #info RCs: April 9-23 14:02:38 #info Kilo release: April 30 14:02:55 So, lets move along since I think we'll need most of the time today. 14:03:08 We'll circle back to bugs in a bit 14:03:09 #topic Kilo-RC1 14:03:14 #link https://launchpad.net/neutron/+milestone/kilo-rc1 14:03:14 anteaya: Yet to update here https://wiki.openstack.org/wiki/Meetings, https://wiki.openstack.org/wiki/Meetings/EC2API#Agenda 14:03:17 #info Bryan Sullivan 14:03:31 bryan_att: I think you may be in the wrong meetiong, this is the neutron meeting 14:03:36 O/ 14:03:45 OK, lets walk through the specs we have in RC1 yet 14:03:51 #link https://blueprints.launchpad.net/neutron/+spec/subnet-allocation 14:04:08 salv-orlando: In lieu of carl_baldwin being here, this one looks like it's making some progress. 14:04:15 salv-orlando: Do you think we can land this one in the RC yet? 14:04:39 armax: Any thoughts on this one as well? 14:04:42 mestery: I need to find pavel_bondar 14:04:48 salv-orlando: Ack 14:04:56 I need to sync up with him and rearrange the outstanding patches 14:05:02 mestery: if I look at the list of patches pendind 14:05:07 pending 14:05:07 https://review.openstack.org/#/q/topic:bp/subnet-allocation,n,z 14:05:18 salv-orlando: This is for subnet pool, are you thinking pluggalbe ipam? 14:05:25 which ones are deemed critical in order to have a semi-functional feature? 14:05:38 the picture doesn’t look good 14:05:54 armax: Agree, wish carl_baldwin was here to help answer that :( 14:06:13 OK, I've pinged carl, lets move on and circle back if he joins us in a bit. 14:06:23 carl_baldwin: There you are! 14:06:23 armax: subnet allocation from a subnet pool is the most critical in there 14:06:38 carl_baldwin: We're talking subnet pools and the chances of it merging in RC1 14:06:39 mestery: hi, sorry to be late 14:06:42 carl_baldwin: We need your expertise here :) 14:06:42 armax, mestery: i have the full picture anyway 14:07:02 it's just that I need to speak with Pavel to check whether we can make it or not 14:07:11 * carl_baldwin reading back 14:07:17 salv-orlando: thanks! 14:07:28 salv-orlando: IPAM is dependent on subnet pools? 14:07:33 mestery: nope 14:07:38 salv-orlando: last i spoke with Pavel we expect to be able to make it 14:07:40 salv-orlando: Ack 14:07:52 I think subnet pools is fairly stable and should be able to complete 14:08:11 It's just not yet clear to me how long we are before removing the wip on the allocation patch 14:08:21 salv-orlando: carl_baldwin may have an idea there 14:08:35 It is getting close. 14:08:37 especially now that we've agreed to not have a feature for wildcarded gateway and allocation pools 14:08:54 mestery: rtidwell might too, but he's not around 14:09:01 There are just a few minor things that can be cleaned up this week. 14:09:26 carl_baldwin salv-orlando: Lets assume this one will make it then, and we can circle back next week if it still looks iffy, Sound ok? 14:09:26 rtidwell has been travelling 14:09:40 mestery: Yes. 14:09:52 OK, lets move on 14:09:56 NExt up are the IPAM BPs 14:10:02 #link https://blueprints.launchpad.net/neutron/+spec/neutron-ipam 14:10:08 #link https://blueprints.launchpad.net/neutron/+spec/reference-ipam-driver 14:10:16 salv-orlando carl_baldwin: Back to you guys again here :) 14:11:30 so 14:11:36 * salv-orlando one second please... 14:12:12 salv-orlando: no worries 14:12:15 the situation is fairly simple. We need to tweak again the interface 14:12:36 :D 14:12:37 in order to allow the driver to accept contextes. I and carl_baldwin agree this should not be how it is done, so we would like to make this a transient change 14:12:38 Earlier today pavel_bondar indicated he has resolved most test failures except OpenContrail CI - with the fix discussed on the ML 14:13:03 salv-orlando: +1 14:13:19 that's the fix i mean 14:13:41 now I think we can have code complete by the end of the week 14:13:55 salv-orlando: Ack on that 14:14:00 with an optional driver, and an "experimental" interface - this would be the situation for Kilo 14:14:16 it is now up to the core team to decide whether to allow this in Kilo or not 14:14:20 salv-orlando: Sounds tenuous here, we'd have to mark this as experimental maybe? 14:14:27 I and carl_baldwin do not have a vote here obviously ;) 14:15:12 mestery: yes definetely experimental. We probably manage to add a non-voting job using the ipam driver before the end of kilo, but I am not able to guarantee that now, because this also depends on what infra-core thinks of this 14:15:18 and I've not pinged them yet about it 14:15:30 This all sounds like it will be hard to land in Kilo to be honest salv-orlando. 14:15:46 salv-orlando, will we have a WARNING PLEASE DON'T USE IT in neutron.conf? 14:15:48 mestery: I think we were headed toward making it experimental weeks ago when we decided not to replace the baked in IPAM yet. 14:15:50 so I do think we have to be careful with experimental things.. our track record with experimental items has not been steller 14:16:06 ihrachyshka: see, I have to admit one thing 14:16:18 in the past I've deferred work items in the same conditions as this one 14:16:22 Another option is to move this out of kilo, take the time to fix all of this, and land it early in liberty 14:16:24 as a core reviewer I mean 14:16:43 to reiterate what mark said, if we ship it experimental, and it's buggy, with our historical reputation, i don't think that experimental tag will mean much. 14:17:18 so this is why I'm saying - we can have the work done, and then it's up to you to judge. I do not want to influence in any direction, but I do not feel confident enough to say "here your pluggable IPAM driver, the code is reliable and you can use it without any worry" 14:17:18 salv-orlando: what opinion are you looking for from infra? 14:17:19 what's the benefit of merging it now instead of early L? except obvious contributor frustration 14:17:39 ihrachyshka: Contributor frustration isn't a benefit in fact, but I see what you mean there :) 14:17:41 anteaya: adding yet another non-voting job for neutron. I'm not sure you might be ok with spending another node. 14:17:45 mestery, lol 14:17:46 ihrachyshka: from my point of view we have several customers eagerly awaiting this... 14:17:51 I agree with salv-orlando, I don’t think there is a way we can land this all in one shot and say it is ready. 14:18:05 salv-orlando: we have no policy about how many non-voting jobs a project can have 14:18:23 So based on this input, I think we need to defer this to Liberty then. We don't need to re-approve the spec, and in fact can work to land it once the RC branch is cut. 14:18:24 carl_baldwin: yes, it has to stay experimental 14:18:27 ihrachyshka: good point. I remember arguing with people in the past that since they were not adding any externally visible feature, there was no rush to merge their feature by a given deadline 14:18:28 No one wants to hear that I'm sure though 14:18:36 But it's likely where this headed 14:18:38 I'll let to carl_baldwin and johnbelamaric to explain the benefits 14:18:39 I can't see us wanting to police that, just use what you need 14:18:58 anteaya: thanks1 14:19:06 thank you 14:19:11 johnbelamaric: could we land it all in stackforge as an external, so those customers could get at it? 14:19:13 we should definitely do case-by-case post mortem on why pieces targeted are not shipped... 14:19:38 We're literally in the final weeks of Kilo. 14:19:51 Rather than rushing a big feature like this in at the end, I think it makes sense to do this early in Liberty to be honest. 14:19:53 dougwig, that involves base db plugin refactor, I don't know whether it's reasonable to have it in stackforge 14:19:56 mestery: +1 to deferring.. we did it for IPv6 Icehouse and while frustrating I think we ended up in a better place when it landed in Juno 14:20:02 In my understanding, "experimental" means the minimum feature set is completed and it needs broader testing. if the expected minimum feature set is doen, it is okay to say it experimental. 14:20:13 dougwig: certainly that's a possibility but it complicates things, as several of these customers expect to get the code from distributors (SUSE, RedHat, etc.) which will be much easier if it's in tree 14:20:19 you are discussing adding an untested feature _after_ feature freeze? 14:20:32 anteaya: When you put it that way. 14:20:39 markmcclain, we are actually worse of letting some ipv6 pieces in icehouse at all 14:20:43 just doing a reality check 14:21:00 amotoki: the minimal feature set will be ready 14:21:06 OK, I think we need to admit we can't land this in a decent shape in the next few weeks. 14:21:16 And to do this right, lets just land this early in Liberty. 14:21:25 Thoughts? 14:21:48 dougwig: the way it's been done so far requires a lot of patching in db_base_plugin_v2 14:21:56 I'd rather defer than use stackforge for it 14:22:00 salv-orlando, johnbelamaric - understood. 14:22:02 salv-orlando: +1 14:22:03 we could put the drivers in stackforge 14:22:05 I agree. The blame is hugely on review team 14:22:09 ihrachyshka: we hid all of the IPv6 API changes because they weren't ready 14:22:11 stackforge seems more trouble than it’s worth for this 14:22:25 armax: ++ 14:22:33 ihrachyshka: nah I've been swamped by 1,000 things this release cycle and could not get my hands on it before end of January 14:22:37 armax: agree 14:22:39 mestery: well, clearly this is a big disappointment if we go that way - the plan was to not enable it by default 14:22:46 markmcclain, right, but ipv6 mode flags that were merged in I are not the best design solution, and they bite us often now 14:23:00 I’m not seeing how stack forge will work. The drivers could go in there, but there is code to load and use the drivers that cannot. 14:23:02 johnbelamaric: I think the big issue is taking on new techinical debt for a feature which isn't tested yet ... in the feature freeze timeframe. 14:23:16 mestery: ++ 14:23:23 ++ 14:23:31 mestery: if we're serious about focusing on quality, i think this has to be deferred. i mean, we're after FF here. 14:23:34 ahh, beat me to it. 14:23:37 mestery: +1 14:23:49 mestery: +1 14:24:08 I don't see a need to re-propose the spec, we can literally just move to working to land these (with adequate testing) once the RC branch is cut 14:24:21 #info IPAM is deferred to Liberty 14:24:23 * ihrachyshka side-notes that we also need to shrink dev cycle so that those cases are not so disappointing 14:24:30 OK, lets move on to the next one. 14:24:38 #link https://blueprints.launchpad.net/neutron/+spec/hyper-v-ovs-agent 14:24:38 ihrachyshka: good luck 14:24:43 armax: You've been looking at this one, along with amotoki. Thouughts? 14:24:54 mestery: it is better you announce which blueprints are automatically approved for L. it would be nice. 14:25:03 dougwig: I have nothing to oppose to this decision. If carl_baldwin and johnbelamaric want to appeal we can discuss further on the mailing list 14:25:07 I made a couple of comments yesterday 14:25:19 but last time I chechek didn’t see any feedback from the author 14:25:19 amotoki: Yes, we'll get to that, but I'll do that. 14:25:21 checking now 14:25:26 the split patch has been proposed. but ovs_lib one is still big. 14:25:46 ihrachyshka is checking it too. 14:25:49 atuvenie was going to split it even more 14:25:57 Yes, I think it needs one more split yet. 14:26:15 imho ovs_lib, polling, utils can be split into separate patches. 14:26:18 there are some obvious ways to achieve it (lots of code was just moved around) 14:26:49 i believe we can land it soon. we alrady have all we need for hyper-v. 14:27:24 now the question becomes how confident are we that this reshuffling this late in the cycle is not going to backfire? 14:28:20 if it's mostly line-by-line identical, I'm not too scared of actual reshuffling. 14:28:22 We're almost halfway through the meeitng, so lets assume this one is ok for now, we can re-visit next week if needed. 14:28:24 every day it passes to get this merged makes me increasingly unease 14:28:36 #link https://blueprints.launchpad.net/neutron/+spec/restructure-l3-agent 14:28:38 carl_baldwin: This one only has a few patches left 14:28:49 carl_baldwin: I assume we can safely land these this week, so not much to discuss here. thoughts? 14:29:11 mestery: Yes, we’re past the big ones. 14:29:20 mestery: No, not much to discuss here. 14:29:20 I have been reviewing, it looks good 14:29:25 this one is not feature-ish, so could be easily postponed. but if all is in place and not intrusive, it's also ok merge. 14:29:26 carl_baldwin: Great! An easy one. HenryG, thanks for that! 14:29:38 LEts move on. 14:29:38 #link https://blueprints.launchpad.net/neutron/+spec/ipv6-router 14:29:49 HenryG has been doing great reviews on these BTW. Kudos. 14:29:50 HenryG: This one is dependent on https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes right? 14:30:09 Yes, but it is small (and a big bang for the LOC) 14:30:12 mestery: yes 14:30:53 It needs a functional test added, I believe that is imminent 14:30:53 HenryG: OK, I think the other one (multiple ipv6 prefixes) is not small and has lots of patche. 14:30:56 *patches 14:31:17 Only one is needed for the feature 14:31:21 mestery, HenryG: yes.. hoping to get that functional test change added by today.. was hitting a few issues with it yesterday 14:31:51 in running the functional tests that is.. not my change :p 14:31:53 OK, lets circle back on these later in the week, we'll need the functional test for V6 routers and HenryG you can let me know which patch is needed for multiple prefixes. 14:32:08 The last two are LBaaS drivers which need working CI, whcih neitehr has. 14:32:14 dougwig: What is the date on those LBaaS ones we gve them? 14:32:18 #link https://blueprints.launchpad.net/neutron/+spec/netscaler-lbass-v2-driver 14:32:22 #link https://blueprints.launchpad.net/neutron/+spec/radware-lbaas-driver 14:32:36 mestery: date was today, though i was going to give them until the end of the week, since they're not mainline code. 14:32:48 dougwig: OK, lets see if htey can get the CI working. 14:33:05 the radware driver is really close, in particular. 14:33:12 OK, 28 minutes left now, lets continue down the agenda, some conentiious things left. 14:33:25 #topic MTU and vlan_transparency recovery mode 14:33:37 armax filed two bugs to track the cleanups here 14:33:40 #link https://bugs.launchpad.net/bugs/1434667 14:33:42 Launchpad bug 1434667 in neutron "VLAN transparent feature cleanup" [High,Confirmed] 14:33:42 garyk is not around 14:33:44 #link https://bugs.launchpad.net/bugs/1434671 14:33:45 Launchpad bug 1434671 in neutron "MTU advertisement feature cleanup" [High,Confirmed] 14:33:48 too bad 14:33:52 armax: Really? *sigh* 14:33:59 Well, lets just see what we can do here. 14:34:20 mestery: I’ve pinged him, let see if he jumps in 14:34:38 I was out last Friday, so armax, can you summarize for me and the meeting minutes where we stand here? 14:34:45 anyway amotoki seems to favor the approach where the vlan_transparent attribute is an extension attribute 14:34:56 and keep the mtu one as is 14:35:09 I thought garyk was in favor of that too? 14:35:15 and salv-orlando as well? 14:35:20 mestery: last time garyk agreed that he was ok with mtu one, the vlan one still needs concensus. 14:35:25 pritesh: Ack 14:35:42 #info Plan is to keep the MTU attribute as-is, and look to make the vlan_transparent an extension attribute 14:35:49 hi, sorry for joining later 14:35:50 that's my opinion on the mtu bit at least. 14:35:51 armax: Looks like we may only need the one bug. 14:35:56 garyk: yo 14:35:57 (hi :) ) 14:36:21 MTU one goes as-is without extension? 14:36:40 amotoki: do you have concerns? 14:36:43 I just wonder how to detect it from API perspective. 14:36:46 i am in favor of the mtu being an extension too 14:37:03 that's the only way we have a chance of having tempest be able to test it 14:37:09 so +1 for extension from me, too 14:37:28 i can go into the detail thursday and friday. 14:37:40 at the moment it is read only and driven by ml2 plugin configurations 14:37:42 I am really not that swayed one way or another 14:38:08 Honestly, me either, but I'd like to resolve it so we can ship these in kilo. If that means extension attributes, lets just make that happen. 14:38:13 can we timebox this, lest we start to rehash last week? it was going in circles. 14:38:14 we can have both as extension attributes, it’ll take more work, so let’s agree now and waste no more time 14:38:31 I think the MTU patch makes sense. 14:38:32 #info move mtu and vlan_transparency to extension attributes 14:38:34 does anyone have alternate view about the testing? 14:38:36 armax: Done 14:38:51 can we sanely test without detecting feature via api extension? 14:38:59 mestery: is anyone going to take it as an action item to do? 14:39:07 marun what's the exact issue with testing? 14:39:10 marun: depends on your definition of sanity. :) 14:39:13 (whithout extension) 14:39:13 garyk: I was hoping htis is where pritesh would jump in :) 14:39:17 without 14:39:23 mestery: ok, thank 14:39:25 marun: we can’t selectively test the feeature if it wasn’t an extension 14:39:27 ajo: the issue is from API perspective. testing is one case. 14:39:32 pritesh: Are you ok with refactorign these to extensions? 14:39:32 dougwig: ^^ 14:39:41 garyk, mestery: I will work with pritesh as well 14:39:53 tiswanso: Awesome! 14:39:54 for the mtu 14:39:56 tiswanso: thanks 14:39:59 mestery: i am ok with vlan one, mtu i thoght should remain in core. 14:40:13 #action tiswanso and pritesh to refactor MTU and vlan_transparent into extension attributes 14:40:20 pritesh: See marun and amotoki's concerns around testing above. 14:40:27 pritesh: +1 --- would prefer it's in core as it makes sense :-) 14:40:42 I think we need to move forward with these quickly to refactor or risk reviving garyk's reverts if we don't solve this. 14:40:49 tiswanso, pritesh: being in core vs extension what difference makes for you? 14:40:54 but defer to the more knowledgeable about test practicalities 14:41:04 just trying to make sure you do not believe that an extension is a 2nd class api 14:41:04 are we intending to start microversioning to avoid this kind of thing in L? 14:41:17 marun: indeed that why core vs extension is a moot point for me now 14:41:23 salv-orlando: agreed 14:41:35 let’s move both to be extension attributes and revisit in L 14:41:41 marun: but there's still lack of consensus on microversioning and saying good riddance to extensions 14:41:42 OK, lets move on then. 14:41:42 I guess that’s the best we can do right now 14:41:43 salv-orlando: I don't have a strong reason... was kind of viewing as 2nd class API but need to learn more details 14:41:54 too bad we didn’t have this conversation a while back 14:41:57 We have more to cover here, and I think the case to moving both to extension attributes has been made. 14:41:59 ok so do we need FFE or do we do it in the bugs filed by armax 14:42:08 pritesh: Use the bugs please :) 14:42:09 tiswanso: do you know that floating ips and security groups are extensons as well? they don't seem 2nd class APIs to me! 14:42:16 tiswanso: this is totally the wrong way to look ait it 14:42:20 mestery: will do thanks. 14:42:27 tiswanso: having API in core or extension is not a big thing. it does not necessarily mean the 2nd class API. 14:42:32 salv-orlando: thanks for the clarification... didn't know that 14:42:51 Folks, 18 minutes left, lets stop bike shedding and move on :) 14:42:53 #topic Pylint -- In or out? 14:42:58 dougwig: This is your yak to shave 14:43:02 I'm fine with the group's opinion.. just wanted to give my vote :-) 14:43:02 oh, thanks. 14:43:28 dougwig: 2 more items after this, so I'll hold this particular yak shaving to 6 minutes ;) 14:43:36 i've been hesitant reviewing pylint patches, because i know the group is split. did we ever make a group decision on pylint? are we full-throttle merging it in, or is it's annoyance not worth it? 14:43:39 I think pylint has to be pinned or out. 14:44:33 I think that with the current arrangement of the jobs, keeping it unpinned it’s not a big deal 14:44:41 pylint++ 14:44:45 we can recover from a failure fairly quickly 14:44:53 it should be on same par as pep8, no difference 14:45:05 could it be non voting? 14:45:07 is it worth the trouble? i like the idea of it, but i've been finding it's annoyance outweighs its usefulness. 14:45:10 garyk: no 14:45:21 there is some push-back against pinning it globally, but that's just wrong and should be pushed forward to avoid random failures 14:45:33 I’m pretty sure that pylint has cost us a couple days of gate time this cycle. 14:45:38 garyk, non-voting == non-caring 14:45:40 ihrachyshka: globally in openstack there seems to be pushback against pylint in general 14:45:40 * HenryG is a fan of a voting pylint 14:45:43 if we can fix failures then legs go with it - unless it is really blocking 14:45:47 carl_baldwin: that’s before the skip-if filter 14:45:49 can't we pin it locally? 14:45:50 that marun did 14:45:55 carl_baldwin, that's because it was not pinned 14:45:55 and the separate job 14:46:08 ajo: no 14:46:11 ihrachyshka: That is why I say pinned or out. 14:46:23 something in global requirements pinned locally creates a mess 14:46:25 ihrachyshka: no, that’s because of the arrangement we had 14:46:27 armax: it will be override when we take the global imports? 14:46:36 if today it broke we could disable it in tox 14:46:40 requirements, sorry 14:46:42 ajo, we can try too, but better handle it globally. we can back up to local pin if nothing goes globally for a month or so 14:46:58 ihrachyshka: See comments from anteaya on local pinning of a global requirement 14:47:01 and the change to disable it will less than 10 mins to merge 14:47:10 anteaya, what's the problem with pin? 14:47:10 with no fuss 14:47:13 * marun is not a fan of pylint. let's spend our time writing better tests! 14:47:15 we have 2 minutes. does anyone feel strongly that it should be *out* ? 14:47:15 mestery, where? anteaya 14:47:22 anteaya, pin as in <=current_version 14:47:43 any diversion from global requirements creates a mess for you 14:47:50 you are async to the rest of openstack 14:47:54 marun: that’s a good reason to make pylint moot 14:47:54 * ihrachyshka notes that we pin hacking locally 14:48:02 anteaya, yes but it's a tool, not a lib.. 14:48:07 being in sync with the rest of openstack is rather the point of global requirements 14:48:14 getting rid of pylint because of infra related problems seems like solving the wrong problem 14:48:17 anteaya, if the problem is the global reqs transposing to local, we could fix that to read some sort of tags we set.. 14:48:22 just put a pin in global requirements 14:48:25 anteaya: global requirements is problematic for some use cases. 14:48:32 clarkb, that wasn't accepted 14:48:34 anteaya: we need to start supporting pinning next cycle 14:48:35 anteaya, the point of pin is to fix new issues on our schedule 14:48:40 anteaya: but that's a debate for another time 14:48:42 ajo it wasnt? thats weird 14:48:44 I’d rather get rid of pylint because we write code that is so great that we no longer need it 14:48:46 We're yak shaving on the logistics of using pylint, but I've not seen if people really *want* it in yet. 14:48:56 its how we do pep8 and pyflakes 14:49:10 mestery: I'd like to see pylint go away 14:49:12 * carl_baldwin agrees with marun, has put his comments in the global pin patch review. 14:49:13 clarkb: https://review.openstack.org/#/c/163506/ 14:49:24 is the yak shaving done in the bike shed? 14:49:30 garyk: Yes 14:49:30 ok, next stop - dropping pep8 I guess 14:49:35 we're at time. 14:49:37 ihrachyshka: hardly 14:49:39 OK, lets move on, we have two more bike sheds full of yaks for htis meeting 14:49:46 We didn't solve pylint here though. 14:49:50 dougwig: ML perhaps? 14:49:58 mestery: ok 14:50:00 #topic DVR Gate Job 14:50:08 armax: You're up! 14:50:28 I looked at this graph 14:50:30 http://graphite.openstack.org/render/?from=-10days&height=500&until=now&width=1200&bgcolor=ffffff&fgcolor=000000&yMax=100&yMin=0&target=color(alias(movingAverage(asPercent(stats.zuul.pipeline.check.job.check-tempest-dsvm-neutron-dvr.FAILURE,sum(stats.zuul.pipeline.check.job.check-tempest-dsvm-neutron-dvr.{SUCCESS,FAILURE})),%2736hours%27),%20%27check-tempest-dsvm-neutron-dvr%27),%27orange%27)&target=color(alias(movingAverag 14:50:30 asPercent(stats.zuul.pipeline.check.job.check-tempest-dsvm-neutron-full.FAILURE,sum(stats.zuul.pipeline.check.job.check-tempest-dsvm-neutron-full.{SUCCESS,FAILURE})),%2736hours%27),%20%27check-tempest-dsvm-neutron-full%27),%27blue%27) 14:50:39 * mestery grumbles about bad paste 14:50:43 to track the reliability of the DVR job 14:50:56 http://goo.gl/jF5zBP 14:51:00 is that better? 14:51:02 mestery: yeah graphite urls are never short 14:51:08 huh, that's neat 14:51:09 armax: yes 14:51:21 so we're down to a reasonable failure rate for the dvr job? 14:51:26 armax: no you could do phishing using url shorteners. and then google is evil :) 14:51:29 the long term plan is to have multi-node voting 14:51:34 swami is working on it 14:51:38 * carl_baldwin has also been tracking this graph. Pleased with the current state. 14:51:46 that would imply actually testing dvr... 14:51:58 the question is: do we want to making the single-node voting as an interim step? 14:52:18 armax: ++, I'm fine with that as the interim step 14:52:21 yes, making it voting means that DVR must be taken into account into any Routing feature and Testing 14:52:26 And continuing down the multi-node tesitng path that swami is doing 14:52:42 armax: I'm fine with that either. possibly after rc1 is out? 14:52:45 With the goal of having the multi-node job up at least non-voting soon 14:52:54 I was going to watch the job for another few days 14:53:00 armax: I'd like to see better docs so that other developers can have a clue as to how to fix problems as they occur. 14:53:04 salv-orlando: I guess we probably need to take this to the ML too 14:53:13 armax: cool 14:53:14 armax: right now, I'm pretty sure dvr is a mystery to most. 14:53:16 marun: that should be true for anything in Neutron 14:53:16 armax: Ack, sounds like it 14:53:17 my vote is to make it voting once Liberty is open. 14:53:21 armax: can you include a shortened link to this graph in the patch to make the job voting please? 14:53:26 I don’t see why DVR should be treated differently 14:53:35 armax: dvr is an order of magnitude more complicated though, if only in implementaiton. 14:53:39 anteaya: can do 14:53:43 armax: thanks 14:53:48 marun: depends where you look from 14:53:55 marun: but I can see what you mean 14:54:01 HA is no piece of cake either 14:54:02 marun: not at mistery at all. everybody knows what a dvr is - the thing you used to record movies back in the '90s 14:54:05 and that doesn’t even have tests 14:54:12 besides a few functional onces 14:54:14 ones 14:54:20 armax: it has pretty good functional ones, fwiw 14:54:36 armax: but no substitute for a proper integration test. 14:54:47 * marun digresses 14:54:55 OK, lets move on here. 14:54:58 One item left 14:55:08 #topic LBaaS 14:55:08 dougwig: Is this one yours too? 14:55:10 Or xgerman's? 14:55:14 xgerman's 14:55:24 mine 14:55:31 xgerman: Please, go ahead. 14:55:37 salv-orlando: lol 14:55:47 ok, we want to make Horizon panels for LBaaS and I was tsrating to collect some use cases 14:56:08 so please add them to the etherpad 14:56:20