14:00:53 #startmeeting networking 14:00:53 Meeting started Tue Apr 21 14:00:53 2015 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:54 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:55 hello! 14:00:57 The meeting name has been set to 'networking' 14:01:02 #link https://wiki.openstack.org/wiki/Network/Meetings Agenda 14:01:08 #topic Announcements 14:01:33 #info The RC2 is open now and all backports are proposed and in process of merging 14:01:41 #info Expect RC2 for Neutron to land tomorrow or Thursday at the latest 14:01:48 Thanks to all who worked tirelessly to make this happen! 14:01:54 I have one request 14:01:56 #link https://review.openstack.org/#/c/174228/ 14:02:10 It would be great to land that patch in master today and get it cherry-picked back to stable/kilo today as well 14:02:21 HenryG salv-orlando amotoki: Can you guys review that one ASAP? 14:02:31 mestery: sure 14:02:32 It's a security fix so landing it prior to release woudl be good 14:02:35 * salv-orlando accepts bribes for reviews 14:02:38 hello 14:02:45 lol 14:02:55 armax_: Also, your eyes here would be good https://review.openstack.org/#/c/174228/ 14:03:01 I thought we already approved it last weekend... 14:03:02 See discussion above 14:03:11 mestery: looking 14:03:23 salv-orlando: I guess it didn't make it in 14:03:41 Anyways, lets not bike shed on this one right now, but if we coudl, lets try to get it in shape and merged today and proposed to stable/kilo (whew!) 14:03:48 I'm not sure if we want to ask the author to address pc_m 's comments. anyway 14:04:10 salv-orlando: Me either, I looked and would be fine either way 14:04:23 yeah I think so 14:04:24 pc_m: Would you be ok removing yoru -1 so we can merge https://review.openstack.org/#/c/174228/ 14:04:28 that’s user input we’re talking about 14:04:35 armax_: Makes sense 14:04:51 mestery: Checking, but should be able to. 14:04:53 OK, lets keep moving 14:05:02 We're still in announcements 14:05:03 :) 14:05:10 A reminder on the mid-cycle(s) 14:05:11 #link http://lists.openstack.org/pipermail/openstack-dev/2015-April/060713.html 14:05:17 And one more announcement 14:05:29 #info sc68cal has volunteered to be our Nova liaison 14:05:43 He'll be attending nova meetings and working as the go-to for nova/neutron things 14:05:46 mestery: Is agenda for mid-cycle defined yet? 14:05:46 Thanks for volunteering sc68cal! 14:05:52 awesome 14:05:54 +1 14:05:55 Sukhdev: It's on the etherpad and forming now 14:06:02 :) 14:06:13 o/ 14:06:25 go for it sc68cal 14:06:25 mestery: I want to suggest an item for agenda - will ping you off line 14:06:32 Any other announcements from anyone? If not, we'll move to bugs in 60 seconds. 14:06:36 Sukhdev: Sounds good! 14:06:46 thanks sc68cal it takes some masochism to volunteer for nova liaisoning ;) 14:06:51 mestery: reminder on the Doc Day 14:07:07 emagana_: Good call! Do you ahve a link we can #link? 14:07:12 mestery: Networking Guide needs your love folks! 14:07:15 hold on! 14:07:18 * mestery waits 14:07:26 salv-orlando: :) 14:07:41 Oh one more thing, I'm going to be using this etherpad to collect things - https://etherpad.openstack.org/p/nova-neutron 14:08:18 #link https://etherpad.openstack.org/p/nova-neutron 14:08:39 doc sprint http://lists.openstack.org/pipermail/openstack-dev/2015-April/061850.html and subsequent mails in the thread. 14:08:44 #link http://lists.openstack.org/pipermail/openstack-dev/2015-April/061850.html 14:08:56 Thanks amotoki 14:09:05 The etherpad is: #link https://etherpad.openstack.org/p/networking-guide 14:09:10 #link https://etherpad.openstack.org/p/networking-guide 14:09:12 Thanks emagana! 14:09:18 OK, we'll move on to bugs next. 14:09:21 #topic Bugs 14:09:24 enikanorov enikanorov__: Hi! 14:09:30 back 14:09:37 armax: Is that really you this time? 14:09:39 ;) 14:10:13 OK, in lieu of enikanorov__ enikanorov being here 14:10:23 I wanted to thank pc_m for taking the time to go through all 38 VPN bugs last week 14:10:24 mestery: I know you skipped the last summit 14:10:32 He triaged them, tagged them, and cleaned them up 14:10:32 Thanks pc_m! 14:10:37 sure np 14:11:08 armax: Any gate issues we should be aware of today? OR bugs trackign those gate issues? 14:11:56 I am keeping an eye on it 14:12:06 armax: I'll take that as "we're in good shape!" 14:12:06 ;) 14:12:12 armax: Did you see Jenkins for https://review.openstack.org/#/c/171874/? 14:12:14 there are a few nuisances that cause the functional job to barf, but I don’t have enough data points yet 14:12:23 armax: Yes, I noticed that as well. 14:12:33 pc_m: of course I did, I +2 it 14:12:45 lol 14:12:45 armax: Keeps failing Jenkins... 14:12:51 pc_m: or you mean the functional job? 14:12:58 armax: yes 14:13:07 no, that I haven’t 14:13:32 pc_m: wow, that’s bad 14:13:41 something must’ve screwed up 14:13:46 I’ll look into it 14:13:50 I’m working on bug 1446261 14:13:50 bug 1446261 in neutron "gate-neutron-dsvm-functional race fails HA/DVR tests with network namespace not found" [High,In progress] https://launchpad.net/bugs/1446261 - Assigned to Carl Baldwin (carl-baldwin) 14:14:03 armax: It had a timeout error and I did a recheck, with a bunch other errors now. 14:14:35 so is the gate actually in a terrible shape 14:14:41 armax: pc_m: https://review.openstack.org/#/c/175713/ 14:14:58 salv-orlando: I have seen worse 14:14:59 how did it sneak in 14:15:15 yamamoto: thanks 14:15:17 All of the failure is due to AttributeError: 'ARPSpoofTestCase' object has no attribute '_create_namespace' and the review from yamamoto seems to fix it. 14:15:34 there should be a hole in our gate 14:15:45 lol 14:15:54 oh. it is already in the gate! 14:16:02 amotoki: I was quick 14:16:05 yamamoto: Thanks for that! 14:16:21 mestery: you're welcome! 14:16:47 * mestery waits 30 seconds for any more bugs to pop up in the meeting before moving on 14:16:54 guys it’s 7am here…slow down I can’t keep up! 14:17:03 * mestery gets armax some coffee 14:17:18 armax: I'm on my third cup already, try to keep up! :) 14:17:22 so what is in the gate? 14:17:24 * dougwig upgrades armax to red bull 14:17:45 o/ 14:17:47 * armax scratches his eyes and yawns still 14:17:56 armax: https://review.openstack.org/#/c/175713/ 14:17:58 armax: I hear ya 14:18:22 me too armax :-) 14:18:23 mestery: gotcha, I was also looking at https://review.openstack.org/#/c/175609/ and I got confused 14:18:32 lol 14:18:46 As amotoki said, https://review.openstack.org/#/c/175713/ appears to fix the ARPSoofTestCase failures seen recently 14:18:55 * mestery watches snow fall outside his window 14:19:14 oh I see what’s going on 14:19:21 Can you pls review the following patch: https://review.openstack.org/#/c/175342/ 14:19:32 until we plug the hole with https://review.openstack.org/#/c/171874/ I think we’re exposed 14:20:03 armax: Yeah, I have a VPN commit that depends on that (the fix added in) 14:20:04 armax: Yes, but that one will fail until https://review.openstack.org/#/c/175713/ merges, right? 14:20:14 yes 14:20:29 We also need https://review.openstack.org/175462 but amuller need to update it 14:20:48 * mestery hopes armax is writing all this down 14:21:32 OK, shall we move on? 14:21:43 I have not followed the history of these issues. But can you shed some light on what led us to a situation where we need 3 indepdent patches to get to gate stability? 14:21:55 (if you want, otherwise do not mind) 14:22:02 lol 14:22:34 Is that really unprecedented? 14:22:38 well, let's conclude that it has been an unlucky coincidence of events and move on 14:23:04 salv-orlando: it's all in the functional tests job 14:23:22 Yes, lets keep rolling 14:23:24 the bugs are in the tests 14:23:24 Lots more to cover 14:23:38 HenryG: do you mean that if I look at the functional test job I'll have my answers? Anyway, it does not matter - I was just curious 14:24:06 #topic Docs 14:24:09 * mestery waves at emagana 14:24:21 salv-orlando: there was a problem with discoverability of tests whereby failures made the tests be silently dropped 14:24:23 emagana: Looks like the sprint is coming up quickly! 14:24:24 mestery: nothing more! 14:24:33 emagana: :) 14:24:33 I'll juist link it here 14:24:37 mestery: already mentioned the sprint... 14:24:39 #info Networking Guide Doc Day: April 23rd 2015 14:24:43 salv-orlando: therefore rather than having a failed run, we were only running only the tests that worked 14:24:47 salv-orlando: pretty nasty stuff 14:25:03 #topic Liberty Design Summit 14:25:06 #link https://etherpad.openstack.org/p/liberty-neutron-summit-topics 14:25:06 armax: so multiple failures sneaked it unknowingly 14:25:07 salv-orlando: that led us to the situation were errors were sneaking in undetected 14:25:13 There are ... lots of ideas on that etherpad. 14:25:22 salv-orlando: once marun restored order in the kingdom the errors started to pop up 14:25:25 However, I thought it would be obvious that people should put their names next to ideas 14:25:27 But it wasn't 14:25:33 So, please put your names next to your ideas 14:25:51 Otherwise, it will be hard for me to set the schedule up if I have no idea who proposed an idea 14:26:02 * mestery waits for etherpad.openstack.org to go down as people rush to fill in their names 14:26:11 Once RC2 is out this week, I'll work in earnest to get the schedule setup 14:26:11 armax: thanks, but we moved on now. Just let's make sure that fixes are backported if they need to. 14:26:11 lol 14:26:23 #link https://docs.google.com/spreadsheets/d/1VsFdRYGbX5eCde81XDV7TrPBfEC7cgtOFikruYmqbPY/edit#gid=569963128 14:26:25 salv-orlando: they will 14:26:27 if folks are seeing etherpad issues now, let us know 14:26:29 That's the master blaster spreadsheet for the summit 14:26:43 We have a split schedule 14:26:50 Fishbowls in the morning, working groups in the afternoon 14:27:02 And I'm working with nova folks (including anteaya) on a nova/neutron session around nova-network 14:27:16 Any questions on the Summit? 14:27:37 Nova neutron interaction? 14:27:51 I think he mean joint session 14:27:56 Is there interest from nova this cycle? 14:28:17 marun: Yes 14:28:26 I know beagles started some work, but I lost track of it back in february 14:28:27 marun: I'm working with jonthetubaguy on this right now in fact 14:28:38 Cool 14:28:48 marun: I expect you in attendance at that session now you realize ;) 14:29:03 mestery: if johnthetubaguy does not comply... 14:29:07 that's the session where the first half is nova telling us what they want, and the second half is us telling them they really don't, and why they want something else instead. it's super fun, and not at all dysfunctional. 14:29:08 I know where he lives ;))) 14:29:29 let's have a postive outlook please 14:29:33 dougwig: I expect you and kevinbenton to just keep saying "provider networks" over and over. 14:29:38 And I agree with anteaya 14:29:40 many people wnat to find a solution to this for many reasons 14:29:47 anteaya: ++ 14:29:49 let's be open to finding a solution 14:29:59 indeed, my positivity sounds negative before noon. sorry. :) 14:30:07 okay thanks 14:30:15 mestery, anteaya, dougwig: so we definetely need a fishbowl session ;) 14:30:23 salv-orlando: It's already penciled in ;) 14:30:35 OK folks, if there are no more summit things, lets keep rolling 14:30:37 mestery: thanks a lot for sorting this out. 14:30:38 I'd prefer 12 folks in a locked room but I don't get what I want 14:30:46 lol 14:30:51 #topic Neutron as the default in devstack 14:30:52 anteaya: +1 14:30:54 sc68cal: HEre? 14:31:01 hello 14:31:07 sc68cal: This is your section 14:31:13 mestery: thanks 14:31:49 So, we *do* have linux bridge almost passing at the gate. There is just some things we need to sort out for the ironic job 14:31:59 salv-orlando: yeah, he does know where I live. would love to catch up before the summit so the summit is more productive 14:32:10 #info linux bridge agent passing at the gate, a few issues with the ironic job to sort out 14:32:18 s/he does/you do/ 14:32:28 johnthetubaguy: I've been in meetings all morning, replying to yoru email in a bit to sort that out 14:32:34 johnthetubaguy: anyplace but the pub in cambourne works for me 14:32:56 I've tried to say a couple times on the ML thread that yes, there is controversy about switching to LB as default, but we get nova-network deprecated / not the default anymore 14:33:01 that puts us ahead in my book 14:33:05 salv-orlando: lol, I am good with greens sometime, ping me 14:33:09 anyway sc68cal what's going to be the test matrix for ovs/linux bridge in the gate 14:33:27 salv-orlando: That's really the crux of it I think 14:33:32 salv-orlando: we'd add jobs to test both ovs and lb 14:33:34 sc68cal: i'm not sure I heard disagreement so much as the usual sdn versus flat arguments. 14:33:50 i've spoken with sdague and he thinks that having jobs for ovs and jobs for lb is a good step 14:33:50 sc68cal: the answer to which is 'both', imo, so it's not an issue. 14:33:56 sc68cal: ++ 14:34:03 dougwig: Exactly 14:34:14 And I agree that getting to default to neutron with LB is a good first step 14:34:17 Thanks for driving this sc68cal! 14:34:38 can field further questions, otherwise I yield my time 14:34:55 In the interest of keeping moving, lets take questions to you in #openstack-neutron post meeting 14:35:02 Thanks sc68cal! 14:35:03 good idea 14:35:06 #topic Moving stackforge/networking-* repos into openstack/ and under the Neutron team. 14:35:09 russellb: Hi! 14:35:12 o/ 14:35:28 so ... i'm working on OVN and the stackforge/networking-ovn thing to hook Neutron up to it. 14:35:39 It seems to me that it makes perfect sense for networking-ovn to be considered an OpenStack project 14:35:47 all OpenStack projects are owned by an official team 14:36:03 so, my request is to see what you all think of adopting this under Neutron 14:36:14 and then, if yes to that, what else that implies for the rest of the networking-foo projects 14:36:33 The obvious initial answer is: "All open source networking-foo things under stackforge" 14:36:46 russellb: while I agree that ovn is open source, and it is more suitable to be openstack than some commercial integration thing 14:36:52 as in, networking-foo where foo is an open source thing? 14:36:59 russellb: yeah 14:37:02 russellb: Yeah 14:37:06 I think it needs to mature before we want to take ownership. 14:37:16 For instance, networking-odl 14:37:20 networking-ofagent 14:37:20 etc. 14:37:21 russellb: for instance, why should ovn be openstack and not, for instance, midonet? 14:37:29 why not midonet? 14:37:30 We've been pushing stuff off our plate so we can focus on stabilizing common elements. 14:37:32 salv-orlando: Yes, networking-midonet 14:37:35 i'd argue that they should all be under neutron, personally 14:37:40 all of them that want to be 14:37:52 russellb: someday 14:37:53 Right, we won't just unilaterally acquire them all :) 14:37:55 But not yet 14:38:00 my take would be to defer this type of decision once we can definitely claim that the decomp effort is complete 14:38:01 i'm also not arguing that you should have to pay attention to them 14:38:09 let them be run like they are 14:38:12 I don’t think we’re at that point yet 14:38:13 They have their own core review teams already 14:38:13 Maybe gate move them only at some level of maturity/usability? 14:38:15 but recognize that they're efforts under Neutron 14:38:23 Then why do they need to be under our umbrella? 14:38:25 russellb, mestery: my only argument are that are either all openstack or none. Notwithstanding that being openstack or stackforge is pretty much just a badge for me 14:38:36 salv-orlando: +1 fwiw 14:38:42 +1 14:38:44 If the intent isn't to gain attention away from other more important stuffz 14:38:52 no attention needed 14:38:56 I'm in favor of this proposal to be honest 14:39:01 to me a namespace change makes very little difference, so either openstack or stackforge I am not really swayed one way or another 14:39:02 These projects already have their own core teams 14:39:04 salv-orlando: +1 14:39:08 just think it makes sense to consider it openstack, get ATC status, etc 14:39:09 We just want them in our (bigger) tent 14:39:12 Big Tent! 14:39:20 It's a networking big tent! 14:39:23 can i suggest a spec in gerrit where the discussion can continue? 14:39:34 but I’d rather have less churn for the time being 14:39:35 Or a patch to project-config? 14:39:35 it used to be a tent. Now it's a stadium 14:39:39 lol 14:39:40 what would a spec say 14:39:47 I'd say a patch in gerrit 14:39:51 russellb: What agbout that? 14:39:52 it's a 1 line governance repo patch 14:40:03 Yup 14:40:03 We coudl discuss there? 14:40:04 i can do that .. 14:40:17 russellb: under devref, a new process for networking- stackforge projects to be considered under the neutron project in openstack/ 14:40:32 I sense we won't get to conclusion in this meeting on this issue, thus the patch for discussion? 14:40:39 mestery: yes the discussion should be move there. It's one of those things where people outside of neutron would probably like to chime in 14:40:44 dougwig: So, in neutron not neutron-specs? Interesting. 14:40:45 it’s not about the complexity of the change per se 14:41:26 I just don’t like the idea of changing something like a namespace whilst things in flight 14:41:27 I think it's simply a matter of moving open source thigns from stackforge to neutron 14:41:31 No change to core teams 14:41:34 they already have their own 14:41:37 They just fall into our stadium 14:41:45 What issues do people have with that? 14:41:46 i think they should have all been openstack/* in the first place, personally :) 14:41:54 as defined today, it does add load to these specs team. 14:41:59 anyway, will propose some stuff in gerrit. 14:42:00 /these/the/ 14:42:07 russellb, arista? midonet? bigswitch? cisco? all of them? 14:42:15 hdn? 14:42:17 You called? 14:42:20 all of them that want to be, yes 14:42:21 *sigh* 14:42:24 salv-orlando: of course hdn. 14:42:49 #action russellb to propose patch to governance to move stackforge networking-foo projects under neutron 14:42:53 dougwig: I have also a blueprint for "mmaas" - middle man as a service. 14:42:53 and meet base openstack project criteria, passes the "one of us" test 14:43:11 +1 14:43:19 mestery: i'd prefer to only propose ovn, because others should make a positive action to indicate they want to 14:43:27 russellb: Makes sense 14:43:38 but i can also write some neutron docs around it 14:43:40 Honestly 14:43:45 In the spirit of the giant stadium 14:43:51 I think we'll open the floodgates 14:43:52 But 14:44:02 Maybe that's ok 14:44:03 also because I frankly do not think "benefits" like ATC status should be given to contributors whose only goal is integrating a specific technology with neutron 14:44:03 I don't know 14:44:21 you have to bring some benefits to the project - either to its user, to it developers, or operators. 14:44:29 salv-orlando: +1 14:44:52 but if you do integration only with your technology, and that's commercial, you're likely to be benefiting only your employer and/or your customers 14:44:59 I think the onus is on these projects to justify being in the namespace. 14:45:03 marun: ++ 14:45:05 for instance, would you every take stackforge/vmware-nsx to be an openstack project? 14:45:18 The default, frankly, should be 'no'. 14:45:20 s/every/ever/ 14:45:21 one point I would like to say from another view is what is a difference between dirvers for opensource one and vendor one. For cinder, driver maintainers will get ATC status and for neutron NOT. It is inconsistent. 14:45:39 amotoki: Not true, we still have shims in-tree 14:45:46 Why does consistency matter, exactly? 14:45:49 amotoki: Also, we're a year ahead of cinder 14:45:53 They are lagging us by a year 14:45:59 mestery: right. 14:46:01 amotoki: that is a fair point, but I'm not entirely sure that cinder is doing the right thing. Still we should be consistent. 14:46:03 they will get to decomp once they realize what a mess it is to have everything in-tree 14:46:07 salv-orlando: ++ 14:46:10 i just want to raise a question we will have. 14:46:12 salv-orlando: -- to consistent 14:46:17 Why do we need to be consistent? 14:46:28 I'd rather we do right by our project than be consistent for its own sake. 14:46:32 We can't force cinder to adopt our policies much as they can't force us to adopt theirs. 14:46:33 marun: ++ 14:46:37 mestery: by "we" I meant us and cinder... cinder should be consistent with us, I think ;) 14:46:50 amotoki: I am working to try to bring projects with third party interactions to more consistency but there is work to do 14:46:50 salv-orlando: Fair enough 14:46:52 mestery: because neutron by itself is nothing.. we all together are openstack! 14:46:52 salv-orlando: if it makes sense for them, sure. 14:47:06 emagana: That's great in theory, but each project is also a microcasm 14:47:09 marun, mestery: right. Ultimately it's their call. 14:47:17 But different community, different vendors, maybe the same rules don't make sense? 14:47:17 Lets not get into forcing poilicy and culture from the top down 14:47:20 mestery: well, we need to find the way to influence properly the other teams 14:47:22 That's a shed I have no interest in painting today 14:47:33 OK 14:47:34 Lets move on 14:47:38 as russellb pointed out being "openstack" is just a badge from a technical perspective, but brings some benefits such as ATC status 14:47:38 We're done here with this for now. 14:47:40 #topic LBaaS 14:47:42 ok done 14:47:45 xgerman: You're up! 14:47:51 mestery: in every operators meetup... neutron is the weak link.. and we are doing the best compare with other projects.. mmhh something is wrong! 14:47:57 I am 14:48:24 xgerman: What did you want to discuss today? 14:48:37 So we ran into the problem that you can specify a random (non existant) tenant-id when you are crerating an lb as an admin 14:48:40 from his agenda item: "We ran into the problem that if an admin user adds a loadbalancer he can specify any, even a wrong id. We have been referred to https://bugs.launchpad.net/neutron/+bug/1200585 and we don't agree with the consensus that because an admin knows what they are doing there shouldn't be any validation/verification of that parameter." 14:48:40 Launchpad bug 1200585 in neutron "floatingip-create doesn't check if tenant_id exists or enabled" [Undecided,Invalid] - Assigned to Jian Wen (wenjianhn) 14:48:46 we feel that this tenant-id should be validated 14:49:07 and when we file that bug we always get told that bug already covers it 14:49:18 xgerman: the same applies to every operation 14:49:21 and I disagree that an admin can't make mistakes and we should balidate 14:49:53 salv-orlando: i think he's disagreeing with the general answer, not that it relates. 14:49:55 xgerman: Seems like as salv-orlando indicates, this is the same for every operation 14:49:58 xgerman: that's fine by me. Doing a validation requires an extra round trip to keystone or some sort of cache 14:50:15 if you can make that in a way that it does not affect scalability I'm fine to have it 14:50:25 so that we can go and implement that validation also in nova for instance 14:50:46 Is there any value to an admin being able to create an LB for an ID that is *going* to exist? 14:50:47 #link https://bugs.launchpad.net/neutron/+bug/1200585 14:50:47 Launchpad bug 1200585 in neutron "floatingip-create doesn't check if tenant_id exists or enabled" [Undecided,Invalid] - Assigned to Jian Wen (wenjianhn) 14:50:51 * mestery links the bug for meeting logs 14:50:52 ok, so we all agree it should be done but we don't know how 14:51:08 Admin use isn't likely to cause a scale issue 14:51:10 egon, yes: If you get a support call 14:51:26 marun +1 14:51:36 How does nova handle this? 14:51:52 All openstack projects must have this problem 14:52:00 marun: yeah they have 14:52:27 Some might have added a keystone check in the pipeline in the meanwhile but I'm not aware of that 14:52:30 salv-orlando: they have the problem or already address it? 14:52:42 I think the tenant-id is not validated. 14:52:58 which btw is project-id in most projects now 14:53:08 xgerman: I agree with the support call case, but doesn't that argue for not validating? 14:53:21 people mistype stuff all the time 14:53:36 so I am advocating for validating 14:53:53 this sounds like something keystone middleware should take care of 14:54:01 rather then every project doing it independently 14:54:05 marun_: ++ 14:54:26 What is the action item here then> 14:54:27 ? 14:54:42 xgerman: Are you going to talk to the keystone folks to see what can be done there? 14:54:50 yes, will do 14:54:56 keystone middleware -> keystone client api 14:55:16 #action xgerman talk to keystone about project id validation 14:55:19 Since we won't know whether validation is required until after the initial auth check 14:55:20 Thanks xgerman ! 14:55:32 OK, < 5 minutes left lets move on 14:55:33 #topic neutron-lib 14:55:35