08:00:31 #startmeeting Functest weekly meeting September 20th Colorado-2 08:00:31 Meeting started Tue Sep 20 08:00:31 2016 UTC. The chair is morgan_orange. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:00:31 Useful Commands: #action #agreed #help #info #idea #link #topic. 08:00:31 The meeting name has been set to 'functest_weekly_meeting_september_20th_colorado_2' 08:00:37 #topic call role 08:00:43 #info ollivier 08:00:47 #info Viktor Tikkanen 08:00:47 #info morgan_orange 08:00:58 #info Juha Haapavirta 08:01:04 #info CG_Nokia (Colum Gaynor) 08:01:07 #info agenda https://wiki.opnfv.org/display/functest/Functest+Meeting 08:01:16 anything you want to add to the agenda for today? 08:01:16 #info SerenaFeng 08:01:34 I will speak admin & organiation in the AoB 08:01:36 #info Jose Lausuch 08:01:50 #topic Action point follow-up 08:01:53 #info Luke Hinds 08:01:59 #info AP1: morgan_orange sync with apex/onos 08:02:05 #info mail sent, discussions during the last release meeting, paex contacted onos integration team 08:02:10 #info AP2: morgan_orange wait for merge before enabling it in reporting 08:02:15 #info done 08:02:20 #info AP3: raghav review yardstick 08:02:25 #info done 08:02:30 #info AP4: morgan_orange check arm ref and add them in the doc review for CristinaPauna 08:02:41 #info done section on ARm results added in release note 08:02:46 #info AP5: morgan_orange prepare pool for Functest meetup in Lannion 08:02:51 #link https://framadate.org/sK56myIDT6KGeRNv 08:03:04 #info see next topic 08:03:09 #info AP6: morgan_orange contact bitergia / ELK 08:03:20 #info first contact, possible meeting in Barcelona, first exchanges proposed during the test weekly meeting 08:03:29 any comment on the action point? 08:03:42 nope 08:03:50 #topic Colorado Status 08:04:04 #info Daily Release meeting now 08:04:26 #info last Friday Release manager say we were still on track for the 22nd (so tomorrow) 08:04:50 tomorrow? 08:04:53 thursday 08:04:56 :) 08:05:04 #info Cristina Pauna (Enea) 08:05:06 #info from Functest perspective, the status is green as most of the scenarios have a high score and the errors are known 08:05:08 the day after tomorrow 08:05:17 yep 08:05:39 #info release note: http://artifacts.opnfv.org/functest/colorado/docs/release-notes/index.html 08:06:25 #info note the mention to Arno is due to the label on master (see explanation from fdegir - several options possible new tag or use a variable) 08:06:58 how to use that variable? 08:07:40 nobody answers to fdegir I think it would be like an env variable by opnfvdocs instead of relying on last tag on master 08:08:10 #action morgan_orange answer to fdegir for the tag/master triggering doc issue for "old" projects 08:08:11 ok 08:08:34 regarding the scenarios, do you see problems 08:09:02 problems that are not reported? 08:09:05 apex/onos is a regression egarding brahmaputra but people have been contacted 08:09:32 there are still some issues in some scenarios with tempest 08:09:43 but I think the issues are captured in the release note 08:10:09 yes 08:10:21 I think the release notes captures everything we have observed 08:10:23 so it should be ko 08:10:25 ok 08:10:25 viktor_t: you are in line with this statement? 08:10:39 yes 08:10:42 BTW, will we empty blacklist for D release? 08:10:45 I will also update the sdnvpn project release notes since we disabled parser for bgpvpn 08:11:11 #info raghavendrachari 08:11:13 viktor_t: we wanted 100% working for smoke for Colorado 08:11:23 I think it makes sense to empty black list for new release 08:11:23 so about that, why disable parser from bgpvpn? 08:11:26 so... I dont want to say it :) 08:11:57 SerenaFeng: due to a performance issue we have in that scenario, it is captured in the release notes, we also disabled rally 08:12:14 ok 08:12:16 SerenaFeng: it is not the best solution, but it is to be re-enabled for Colorado 2.0 08:12:27 SerenaFeng: ugly workaround :) 08:12:54 as a reminder the scenario owner is master on board regarding the integration of additional feature tests 08:13:16 ok, I just need to know is it because of parser problem. if it is, I need to ask Parser people to fix it 08:13:25 yes, but there should be a good reason behind and documented 08:13:31 if he/she wants to focus on its feature, he/she may ask to remove some tests, it is captured in the release note, the highest the scoring his the more features are tested 08:13:55 SerenaFeng: it isn't because of parser, it's due to the bgpvpn extension causes some troubles that we can't reproduce locally and think will be fixed with ODL Boron 08:14:11 #info scenarios OK: globally good scoring + errors documented in release note 08:14:20 let's review the Open JIRAs 08:14:26 ok, I understank, thank you 08:14:47 in the release note we mentioned 419, 446, 450, 454, 460 and 462 08:15:11 if you look at https://jira.opnfv.org/secure/RapidBoard.jspa?rapidView=59 08:15:26 419 is the issue on docker we did not reproduce (empty tag) 08:15:50 446 is on odl-sfc cleanup (as far as I know, scenarios are even not run so not cleaned) 08:15:51 I dont have logs to see how I can solve it 08:16:05 450 it was a bug 08:16:14 not sure it was reproducible 08:16:15 462 is not related to functest 08:16:33 ollivier: right 08:16:40 it's related to the deployment 08:16:43 I will close it 08:16:46 we saw this 462 on ARM as well 08:16:52 is it tok? 08:17:18 I think this is an ODL issue 08:17:25 yes 08:17:33 we are reproducing that in our labs 08:17:34 but you are right 08:17:42 so I suggets we clean this one and invite the reporter to open a bug upstream 08:17:42 please send me karaf.log 08:17:48 functest shows the appropriate output, if it fails, it fails 08:18:00 I'll close it 08:18:08 ok summary 08:18:28 419, 450 will be close (not reproducible) 08:18:39 462 closed and reported upstream 08:19:05 #agreed 08:19:56 jose_lausuch: for 446, we keep it open even if we have no more regular run on odl_l2-sfc? 08:20:32 morgan_orange: we can move that to colorado 2.0 08:20:39 is that ok? 08:20:47 for 454 it is also a failure on cleanup so for colorado 2.0 08:20:51 I think it is not an urgent think of colorado 1.0 08:21:11 460 it is assigned to Juha 08:21:18 any idea of the status? 08:21:34 #info 419,450 will be closed (not reproducible) 08:21:41 #info 462 closed and reported upstream 08:21:56 I just closed 450 with a message that I think it solves the issue 08:22:09 #info 446 and 454 set to Colorado 2.0 08:22:20 #action juha give feedback on 460 08:23:07 SerenaFeng: I did not mention 465 and 474 in the release note (kibana enhancement), are you OK with that 08:23:26 and of course 434 and 436 (doc review will also not been considered for release note) 08:23:52 #info Jira status pretty clear: ready for release 08:24:03 any other ocmment/remark for Colorado? 08:24:32 ok, it is D Release work 08:24:46 hello juhak we had a quesiton on the status of https://jira.opnfv.org/browse/FUNCTEST-460 08:25:41 #topic update on Kibana dashboard 08:25:50 SerenaFeng: you want to give an update? 08:26:02 #info dashboard picture changed in release note (Kibana base) 08:26:03 morgan_orange: that's done, I'll close the case 08:26:18 juhak: OK I will remove the JIRA from the release note 08:26:25 I am working on refactoring the current code structure 08:26:29 #action juhak close JIRA 460 08:26:37 #action morgan_orange update release note / JIRAs 08:27:08 as to the display content we want to refactor, I'd like to do it after the discuss with bitgia people 08:27:08 #link http://artifacts.opnfv.org/functest/colorado/docs/userguide/_images/FunctestDashboardColorado.png 08:27:40 we contacted bitergia people who are in charge of the reporting for git/gerrit/irc/mailing list and soon jenkins 08:27:54 yes, I get the email 08:27:56 they moved to ELK (presentation during the Summit in Berlin) 08:28:17 the guy will confirm if he can attend the test weekly meeting on Thursday 08:28:21 and I think due to my English level, a face-to-face meeting is a good idea 08:28:32 if so would you be OK to prepare some slides on the status on Functest side? 08:28:47 because I am afraid during the test meeting, maybe I cannot catch up with his idea 08:28:52 and sorry about that 08:29:15 SerenaFeng: do not be sorry our Chinese is very very poor... 08:29:44 #action SerenaFeng prepare some slide on Kibana dashboard to share with bitergia people and the community 08:29:45 my Chinese is None :) 08:30:02 I hope jesus could join (he is based in Madrid) 08:30:09 for an F2F meeting in barcelona 08:30:13 action SerenaFeng teach Chinese to morgan_orange and jose_lausuch 08:30:15 will the slides be used on this Thur.? 08:30:31 teaching English no problem 08:30:46 possibly, it is just a status, no need to do something nice 08:30:56 Teaching Chinese no problem 08:31:15 we shall plan a session during the next summit in Beijing.. 08:32:03 ok, slides, I will try 08:32:19 Welcome to Beijing 08:32:21 The guy from bitergia shared a link with the new dashboard, it looks great and apparenly they are interested by the tests 08:32:39 SerenaFeng: next year..for the OPNFV Summit we will be in Beijing 08:32:42 I can treat you some authentic delicious Chinese food 08:32:48 :0 08:32:51 :) 08:32:54 you will be our guide 08:33:12 any question on ELK? 08:33:27 #topic Discussion on test criteria and exit condition 08:33:55 #info discussion in gerrit about a bug that was not a bug but showed that we were not fully aligned in the different test cases on the exit conditions 08:34:14 I think we should agree and try to harmonize a little bit 08:34:28 exit -1 only allowed from main 08:34:47 #agreed 08:35:00 agree 08:35:09 we need to do some refactor for Danube 08:35:16 shall we consider if test OK but pushing data to the database fails we also consider that the test fails as pushing is part of the test 08:35:30 because I have detected some scripts (including some I wrote) that use "exit" in functions, not in main 08:35:44 in the case of ARM, their POD was not declared so the jenkins job was -1, which was normal because pushing data was part of the test... 08:35:52 vping, I do it a lot :) 08:36:02 that is something to discuss 08:36:06 because it is very convenient to do it, sorry 08:36:12 #action all Danube review the exit conditions...no more exit -1 out of the main... 08:36:14 I think we exit -1 if push to db arg is set even if tests are ok 08:36:22 if a user runs the test, the push-to-db will not be used and the test works 08:36:39 so my opinion is that if push-to-db fails don't mark the test failed 08:37:03 hmm from a humane perspective I would say yes, but from a CI i would say no 08:37:18 because it could be due to DB offline, something else's problem than functest 08:37:23 what we want is test + push to DB => if somethign is wrong we must report it 08:37:33 So arg should be unset 08:37:40 DB offline is a possible issue it is thus interesting to know it 08:37:57 but we will see it in jenkins console 08:38:36 its good feedback for us, but a false negative for the scenario/test owner 08:38:39 if we have blue ball...we could miss it...not possible to read all the consoles of all the tests...we will see it in the reporting page 08:38:43 my opinion, just logger.error, when push to db failed 08:38:55 it's amazing 08:38:57 yes, I would say so too 08:39:01 I think functest's purpose is to test functionality of the stack, this push-to-db is just infrastructure 08:39:14 I constantly check jenkins logs and look for "error" :) 08:40:21 ollivier: what is amazing? 08:41:19 morgan_orange: if u ask for a report which failed, the script should exit in error 08:42:03 guys, there might be a bit of a trap in releng as well, when manually triggering the job you can opt to push results to DB 08:42:25 can we distinguish test failure from push-to-db failure from the reporting? 08:42:37 that person will have to know that setting it for a non-CI pod will potentially break functest 08:42:55 I mean exit with different error code 08:43:53 ollivier: the issue is that the exit -1 is fine for us (what we want failed so we exit -1) but misleading for the scenario owner (their tests were OK) and can be considered as a false negative for them 08:44:51 and if the reporting fails because DB is offline for example, only vping will be executed and will block all the rest 08:44:55 I think there are two sides of this storry, first is the case where the user tries to push results for a non-CI pod, second is failure to push results (for different reasons) for a CI POD 08:45:00 so I suggest, exit -1 for test failure, exit -2 for push-to-db failure, 08:45:26 ciprian-barbu: a regular user can't push results to db 08:45:52 jose_lausuch: I meant the job, ofc 08:46:16 only -1 will block the rest tests, or else the rest tests will be continued 08:46:28 jose_lausuch: we can if we modify the db url 08:47:51 ollivier: ok 08:49:07 ok I think I got the different views, it is really depending if we have a dev view or integrator view 08:49:26 let's mature it and decide next week, not rush and could be linked to next topic on refactoring 08:49:57 I suggest we close the JIRA anyway and abandon the change on gerrit, the fix (good one) consisted in declaring the POD in the DB 08:50:25 are you OK with that? 08:50:36 #topic Danube: Discussion on framework refactoring / SNAPS 08:50:42 ok 08:50:43 as said it could be connected 08:50:44 yes 08:51:05 would it make sense to create a class with the exceptions (including DB_not_available) 08:51:12 to clean a little bit our exit conditions? 08:51:38 morgan_orange: sounds like a good idea if you were to ask me 08:52:08 if we consider a more Object oriented approach of each test case, it shall be possible to create a list of exceptions and have a better management that wild exit in the middle of the code... 08:53:06 I shared some weeks ago this figure https://wiki.opnfv.org/download/attachments/2925495/Functest-feature-project-interfaces.png?version=1&modificationDate=1473091940000&api=v2 08:53:16 it was my first contribution to the reflexion for the refactoring 08:53:39 I think we should also imagine the APIs we need to declare the tests and run them 08:53:59 we have an API for test result reporting we should have a more global approach 08:54:12 it would be also interesting to discuss with the other test project 08:54:48 we could imagine for instance yardstick cally Functest APi to deploy a VNF and run their perfo tests 08:55:05 and we could imagien also calling Yardstick APi from our docker to run perfo tests 08:55:25 it is still a bit fuzzy but I think there is a risk to create // framework that will do the same 08:55:44 so we need a better view on the API we coudl offer to scenario owners and other test projects 08:56:07 What do you thin? 08:56:09 Did I smoke too much? 08:56:47 regading SNAP integration, we exchange with Steve from Cable labs 08:57:25 main scenario consider SNAPS as an third party library - coexistence with functest, openstack_utils for D, E and let darwinain selection happens 08:57:52 steve ask if we have objection to consider as an upstream lib for Functest 08:58:13 I do not see objection but jose_lausuch you said that LF wanted to limit that for legal issues 08:58:50 OK I am bit lonely - probably smoke too much - 08:58:54 sorry, parallel meeting 08:59:14 we are already late 08:59:18 #topic meetup 08:59:24 sorry, I need to digest your idea first 08:59:30 I agree, what I was thinking is having SNAPS as another way to do things than openstack utils 08:59:31 sorry 08:59:40 #info not lots of answers yet for a possible meetup 08:59:54 * jose_lausuch pending for approval :) 09:00:17 #info meeting in Barcelona (Openstack Summit) but another functest meetup is still possible 09:00:36 #link https://framadate.org/sK56myIDT6KGeRNv 09:00:43 #info any news from Nokia side? 09:01:21 #topic AoB 09:01:51 #info I exchanged with the TSC. I will launch an internal election for Functest PTL 09:02:17 #info all committers can vote, need to send the info by mail and plan a vote on IRC 09:02:37 #info the idea is to organize such elections every 2 release and limit the mandate to 2 09:02:51 limit the mandate to 2? 09:02:52 #info I planned to be candidate for this first one but will no more eligible for the next one 09:02:52 ah ok 09:03:02 so a PTL can be PTL only during 2 releases 09:03:08 yes 09:03:20 so new ideas, new energy, less smoke.. 09:03:35 any objection? 09:03:43 2 release = 1 year? 09:04:02 yes 09:04:13 you think it is too short? 09:04:31 #action morgan_orange send mail to initiate PTL election for Functest 09:05:03 I think its ok 09:05:04 #action all brainstorm on D refactoring API definitions, exceptions,... 09:05:19 any other topic you would like to share in the AoB 09:05:49 nope 09:05:51 #link https://wiki.opnfv.org/display/functest/Functextnexttaks 09:06:27 OK thanks 09:06:44 enjoy last Colorado days and first Danube days 09:06:50 #endmeeting