14:30:09 #startmeeting Brahmaputra Daily Standup 14:30:09 Meeting started Fri Feb 5 14:30:09 2016 UTC. The chair is debrascott. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:30:09 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:30:09 The meeting name has been set to 'brahmaputra_daily_standup' 14:30:29 #link agenda https://wiki.opnfv.org/releases/brahmaputra/minutes 14:30:39 #info Narinder Gupta 14:30:46 #topic roll call 14:30:48 #info Joe Kidder 14:30:55 #info Bin Hu 14:30:57 #info Ana Cunha 14:31:09 #info Narinder Gupta 14:32:39 #topic Test status 14:33:00 morgan_orange: functest progress today? 14:33:10 #info Ashlee Young 14:33:14 #info Chris Price 14:33:17 #info Morgan Richomme 14:33:31 did not check the nightly build, so a bit late for the update 14:33:57 vIMS should work on joid at the end of the day 14:34:10 #info Trevor Cooper 14:34:25 #info tempest info sent to apex (where it is critical to reach the 90%) 14:34:47 #info functest doc updated 14:34:54 morgan_orange: vIMS is good news 14:35:19 basically joid on Orange POD2 (not a CI POD) would probably meet the release criteria 14:35:37 Intel POD5 and 6 will be modified soon, so hopefully we may reach the same results on the target POD 14:36:08 that is all for me today 14:36:14 morgan_orange: is it difference in networking equipment? 14:36:42 surely, but I think they are facing the same issues as on Intel POD2 14:36:53 as far as I understand operations are plan to migrate the PODs 14:37:20 Morgan: POD 2 was migrated a week ago 14:37:26 morgan_orange: interesting. Something that will need to be documented. 14:37:45 morgan_orange: what? that hardware has an influence on results??? 14:37:50 THere is only one known issue POD 5 14:38:13 trevor_intel I was thinking to POD5 as it is the target CI POD for joid/stable 14:39:01 Morgan: What are the issues? 14:39:16 I don't think we are aware of any 14:39:24 trevor_intel narindergupta wrote a Jira on that, I do not have the details 14:40:06 trevor_intel morgan_orange deployment was it is working but when we run test then results were not same. 14:40:11 morgan_orange: yes, that diifferent hardware will change results. I guess I would have thought we were more abstracted away from hardware than that 14:40:42 The issue with POD 2 was an Apex limitation, not a broken POD 14:40:45 it was mentioned to me that it could be network issues in pod and there was a plan to change the switch environment 14:41:41 morgan_orange: in that case can we debug the functest different behavior. even pod5 and pod6 behaving differently 14:42:12 We want to migrate those PODs to a new switch 14:42:44 But need some down time to do so 14:43:13 trevor_intel no issue let me know whenever you are ready 14:44:22 lets come back to pod management in a few. We need to add topic to the agenda: how will we manage migrating all pods to stable as noted in ChrisPriceAB email 14:44:36 narindergupta: trevor_intel so shall we investigate on POD5? or on the most favorable env? on POD5 looking at tempest the success rate is 14%, it is 92% on Orange POD (and 54% on POD6 as far as I remember) 14:45:25 narindergupta: trevor_intel it is probably a network config (more than hardware issue) 14:45:45 morgan_orange: thats what i am thinking. 14:46:20 morgan_orange: i am open for any options. What do you think trevor_intel 14:46:23 ? 14:48:18 How to investigate? 14:48:28 We need a plan 14:48:44 morgan_orange: do we have a standard (ie recommended settings) for setting up network configs as part of setup for functest? Is that possible to do? 14:48:46 We will support whatever you need 14:49:31 trevor_intel question is should we move to new environment first then debug? debrascott from host machine prspective we have same setting in both labs 14:49:51 debrascott: ???? Functest is not testing a system not defining this system, the reference is the Pharos architecture 14:50:22 Functest is testing a system not defining the network env of this system 14:51:37 trevor_intel narindergupta we can also support but when do you plan the operation? it is maybe useless to investigate if the network config is modified in a few days 14:51:38 narindergupta: POD 5 issue with BMC was closed yesterday ... POD 5 and 6 are identical 14:52:03 morgan_orange: just wondering what the setup process is for functest if outcome is dependent on hardware & configurations; Difficult to get high % runs if things are different in the different pods. Not really comparing apples to apples that way between the different installers/scenarios 14:52:49 Its not to be modified just migrated to a new switch 14:52:50 morgan_orange: makes troubleshooting more difficult 14:53:43 Differnt installer have different hw dependencies/assumptions . 14:53:55 debrascott: sure, that is why I mentioned this difference more than a week ago...so far we can see it with joid because we have 3 pods. compass and apex have only 1. For fuel we have 2 pods and we get similar results 14:54:58 Morgan: You mean 1 POD ... no they have 2 14:55:08 connected to CI? 14:55:19 yes 14:55:19 OK let’s continue offline. only 6 minutes left, want to get to yardstick status 14:55:22 https://wiki.opnfv.org/pharos_rls_b_labs 14:55:36 anac1: how is yardstick doing today? 14:55:41 #info Yardstick succesfull run ODL scenario on Compass with ODL Be (no workaround needed) 14:55:51 #info many thanks to Compass for the teamwork 14:56:07 #info will try Apex next 14:56:11 anac1: yeah!!!! 14:56:30 that’s great news! 14:56:44 that's all from me 14:56:52 OK thank you 14:57:14 Next topic 14:57:52 #topic how do we manage getting all available resources to stable as per ChrisPriceAB email? 14:57:54 Narinder / Morgan - I have to run but will be back online in an hour ... lets figure a plan 14:57:54 anac1: that's awesome re: Be and Compass 14:58:05 trevor_intel ok 14:58:10 sure 14:58:11 ashyoung: yes, great teamwork 14:58:33 Why do we want to have all resources on stable, that breaks the whole idea of stable! 14:58:52 Did you see Chris’s email? 14:59:10 idea is to get test running through scenarios 14:59:22 find which scenarios work 14:59:36 put those that don’t work on back of queue 14:59:48 gives each scenario a chance to at least find out if it works 15:00:16 then start back through the queue to troubleshoot and get others working 15:00:54 anac1: It means that we are at least narrowing on a configuration for supporting more scenarios. So I see this as a huge news. 15:01:26 anac1: And in C release, we'll be looking at Be or it's successor anyway. We won't care about Li 15:01:43 I cant find that mail from chris, but is the meaning to get all PODs on stable or not? 15:02:06 ashyoung: agree, trying to fix old faults perhaps not so effective 15:02:26 JonasB: I will forward it. This is a temporary move to get to release 15:02:36 anac1: Agreed 15:03:07 But that is what I dont like, then the idea of stable is lost. 15:03:59 debrascott: anac1: are we ditching Li as release reqs? 15:04:18 JonasB: check your inbox 15:04:47 JonasB: no troubleshooting or fixes to “stable”, just test 15:04:55 radez: yardstick tested successfully on fuel and compass with ODL Be 15:05:12 yes, but does that mean we are changing the release reqs? 15:05:14 but that is shift to genesis requirement 15:05:15 Got the mail, but do not agree! 15:05:19 and we should not be building with Li? 15:05:28 anac1: debrascott: ^ 15:05:33 JonasB: ok, take it up on the thread 15:05:48 radez anac1: yes watching 15:06:01 anac1 will this be ODL only? 15:06:06 debrascott: what do you mean watching? 15:06:17 We have master, stable and the cherry-pick process for good reasons. Do we want to go away from that in the last minute? 15:06:25 radez: two conversations, I’m paying attention 15:06:52 debrascott: we should not be building with Li or Be? 15:07:06 sry that didn't make sense 15:07:13 debrascott: should we be building with Li or Be? 15:07:23 The idea is to make fixes on master, have ci verify it on master before you cherry pick it to stable. If it cant be verified on master, no reason to have stable! 15:07:24 radez: build with ONOS ;) 15:07:32 ashyoung: we are! :) 15:07:33 radez: that a CR should go to genesisreq 15:07:59 radez, anac1 Li is preferred, but if one controller needs Be I’m not sure what impact that might have to other projects. Does it impact installers? 15:08:17 yes it does 15:08:27 The earlier news about Be success on Yardstick w/o workarounds is good news and helps us to narrow working configs 15:08:35 and that decision should not be done here 15:08:38 It just seems confusing for everyone to be asking for Be but for genesis to req Li 15:08:42 radez: agree a CR is needed so proper discussion can be made 15:08:43 That's how I look at it-- not a decision 15:08:57 debrascott, radez: yardstick works on Be without workaround 15:08:58 it is a tsc level discussion 15:09:08 I agree with the issue about confusion 15:09:21 Should be a Genesis decision 15:09:25 Not TSC 15:09:26 anac1: right, and we've sliped to after Be release right? and SFC wants Be 15:09:44 so maybe we should just move to Be? 15:09:45 radez: correct 15:09:54 radez: yes 15:10:06 The issue when we set the requirements was Be was going to be unstable 15:10:13 Li would be "more stable" 15:10:22 Seems flip flopped vs. reality 15:10:24 anac1: did compass wholesale switch to Be or do they just have an alternate build for YS? 15:10:24 and late for the release date ? 15:10:30 I think Genesis first but it also needs to go to TSC for radification, it is a big change for last minute 15:10:54 debrascott: +1 to your view 15:10:58 I disagree, I don't think TSC ever set which versions of which components 15:10:59 radez: not sure, i'd guess alternate build 15:11:06 That was a genesis decision 15:11:26 But I'm all for bringing it to the TSC 15:11:28 ashyoung: +1 15:11:36 It's moving us forward vs. keeping us stuck 15:11:56 radez: following yesterday's discussion, we tested with compass earlier today on Be and it works 15:12:22 ashyoung: we discussed all upstream revisions at TSC at beginning of release 15:12:23 I don't believe compass team really cares what version is used 15:12:41 genesis decided and TSC bought into the Li due to some dependencies 15:12:53 anac1: I think it's less of an issue of if it works and more an issue of what's required by the release 15:12:56 The documented notes was that we would not hold up the release for Be 15:13:10 radez: i can only answer for yardstick 15:13:12 Seems like Be might just get us through 15:13:25 So I'm for going to TSC for clarifying it as a team 15:13:26 ashyoung: agree 15:13:36 We want to all be on the same page 15:13:49 ashyoung: +1 15:13:53 Why work on something we know is broken and which will not fix? 15:14:07 JonasB: that's my very concern 15:14:22 JonasB: agree but need to see what impact it has on the release as a whole 15:14:28 In C release, we will be moving well beyond Li anyway 15:14:46 ashyoung: in C we'll move past Be too probably 15:15:04 The question I have is how many scenarios get supported if we move from Li to Be-- do we gain? 15:15:13 radez: agreed 15:15:20 ashyoung:+1 exactly 15:15:28 It's forward progress and I am concerned about further slips for an old version 15:15:42 Sounds like ODL folks fixed bugs in Be 15:15:53 That's the vibe I get on our email thread on this 15:16:08 yea we've been told by ODL folks that Be is much better than Li 15:16:12 across the board 15:16:13 This is with George Zhao and others 15:16:24 And it supports SFC 15:16:36 But I'm fine having the only SFC support in B release :) 15:16:47 That's a joke 15:16:54 My concern is that we’ll have some scenarios that work only with Be and some with Li 15:17:06 That's what we need to discuss on the tech list 15:17:11 ashyoung: and we're all enjoying the joke :) 15:17:11 debrascott: which ones ? 15:17:12 Shall I start the discussion? 15:17:32 radez: :) 15:17:48 anac1: I don’t know, maybe not an issue but that’s why it should be discussed with the broader community 15:17:53 anac1: I think we need to take it to the list to see the risks 15:18:01 ashyoung: sure 15:18:11 Okay 15:18:26 posting now 15:18:41 Ok way past time for meeting. going to close it out. feel free to hang out on this channel and discuss if needed 15:18:46 #endmeeting