08:33:03 <kubi001> #startmeeting Yardstick Work Meeting 08:33:03 <collabot`> Meeting started Mon Feb 27 08:33:03 2017 UTC. The chair is kubi001. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:33:03 <collabot`> Useful Commands: #action #agreed #help #info #idea #link #topic. 08:33:03 <collabot`> The meeting name has been set to 'yardstick_work_meeting' 08:33:08 <kubi001> #topic roll call 08:33:11 <kubi001> #info kubi 08:33:19 <JingLu> #info Jing 08:33:26 <Mingjian_> #info Mingjiang 08:33:29 <rbbratta> #info Ross 08:33:36 <Kanglin> #info Kanglin 08:33:43 <kubi001> https://wiki.opnfv.org/display/yardstick/Meetings 08:33:48 <Mingjian_> #info mingjiang->rex 08:33:55 <sdeepak001> #info deepak 08:34:13 <kubi001> today's agenda 08:34:28 <kubi001> #topic action items follows up 08:34:43 <kubi001> http://ircbot.wl.linuxfoundation.org/meetings/opnfv-yardstick/2017/opnfv-yardstick.2017-02-20-08.34.html 08:35:16 <kubi001> #info AP1: deepak_ will clean up and share the script 08:35:32 <kubi001> the script for license check 08:35:49 <kubi001> sdeepak001: any update? 08:36:00 <sdeepak001> kubi001: I have sent the patch https://gerrit.opnfv.org/gerrit/#/c/29413/ 08:36:34 <kubi001> sdeepak001: good job 08:36:47 <kubi001> #info AP1: Done https://gerrit.opnfv.org/gerrit/#/c/29413/ 08:37:04 <kubi001> #info AP2 kubi will send the email to notify the Yardstick MS6 status 08:37:41 <kubi001> #info AP2: Done kubi have replied David's imail about MS6 compliance 08:38:00 <kubi001> #info AP3: kubi will initialize a etherpad to trace the CI issue 08:38:12 <kubi001> #info Done https://etherpad.opnfv.org/p/yardstick_release_d_troubleshooting 08:38:42 <kubi001> I just created the page few minutes ago, so please feel free to update 08:38:57 <kubi001> OK, let's move to next topic 08:39:09 <kubi001> #topic JIRA review 08:40:09 <Mingjian_> #link https://jira.opnfv.org/secure/RapidBoard.jspa?rapidView=145&view=planning&selectedIssue=YARDSTICK-572 08:40:23 <Mingjian_> this is the backlog of jira task in daube 08:41:00 <kubi001> #info we should update the status of JIRA once you start a task or implement task 08:41:47 <Mingjian_> i think we should prioritize the jira task since the release date is approaching 08:42:03 <Mingjian_> and some jira should be update the status 08:43:30 <kubi001> if some JIRA tasks which can't be done within Danube 1.0, please update the "fix version" of the JIRA ticket 08:44:55 <Mingjian_> and in this timewindow, i think the bug jira should be taken care of in a high priority 08:45:06 <kubi001> Mingjian_: agree 08:45:23 <kubi001> #topic Branch close time 08:45:36 <kubi001> #info MS7 is Mar 10th 08:46:02 <Mingjian_> #link https://jira.opnfv.org/issues/?jql=project%20%3D%20YARDSTICK%20and%20type%20%3D%20bug 08:46:22 <Mingjian_> the link is the bug list in yardstick jira task 08:47:38 <kubi001> #info we can checkout the branch before Mar .10th. so we need to decide which date we want to checkout 08:48:52 <kubi001> any ideas from you? which day do you like? 08:49:56 <Mingjian_> It's friday on Mar 10th 08:51:00 <kubi001> Mingjian_: yes, we can decide it at next week if we are not sure at today 08:52:00 <Mingjian_> so we have two weeks for bugfix and ci update 08:52:20 <JingLu> rbbratta: ping 08:52:22 <kubi001> Mingjian_: yes 08:52:29 <kubi001> #topic CI status 08:52:34 <Mingjian_> and some minor refactor if it's needed 08:52:35 <rbbratta> JingLu: hi 08:53:17 <JingLu> rbbratta: hi ross, i saw you comments, is there a particular reason to use python? 08:53:33 <JingLu> rbbratta: what's the benefit? 08:54:17 <rbbratta> JingLu: bash is error prone and hard to maintain, python allows for code re-use 08:54:20 <kubi001> #info keep watch on CI job https://build.opnfv.org/ci/view/yardstick/ 08:55:44 <kubi001> rbbratta: agree, python will be a good choice. 08:55:47 <rbbratta> JingLu: everyone should read http://mywiki.wooledge.org/BashPitfalls before writing bash 08:56:13 <Mingjian_> about ci status, apex currently don't work for nosdn-nofeature scenario for not being able to ssh floating ip 08:56:16 <kubi001> #info everyone should read http://mywiki.wooledge.org/BashPitfalls before writing bash 08:56:48 <JingLu> rbbratta: what python api should be used then? subprocess? 08:57:45 <rbbratta> JingLu: yes, .call() or Popen().communicate() usually, but it depends on what you are doing, try to avoid calling out to the shell 08:58:32 <rbbratta> JingLu: for openstack API, can we assume the python clients are installed already? 08:59:19 <rbbratta> JingLu: if not, then use command line cliens, but use JSON or YAML output. 08:59:59 <rbbratta> JingLu: ideally we should use SNAPS-OO 09:00:14 <sdeepak001> JingLu: We can use check_output/check_call also. This will raise a CalledProcessError if the called process returns a non-zero return code. 09:00:42 <kubi001> #info for openstack API, we can assume the python clients are installed already, if not, then use command line cliens, but use JSON or YAML output, ideally we should use SNAPS-OO 09:00:45 <JingLu> rbbratta: the work is mainly focus on openstack configuration files, e.g., nova.conf and neutron.conf, so I think there were not much openstack api that can be used 09:01:47 <kubi001> #info We can use check_output/check_call also. This will raise a CalledProcessError if the called process returns a non-zero return code. 09:03:00 <sdeepak001> JingLu: Are we modifying the nova.conf/neutron.conf for a given test? 09:04:08 <Mingjian_> rbbratta: Hi, ross, I have a problem about logging in ci 09:04:12 <rbbratta> something like https://gerrit.opnfv.org/gerrit/#/c/29333/1/yardstick/resources/scripts/node/nova_scheduler_filter_setup.bash 09:04:18 <rbbratta> Mingjian_: okay 09:05:08 <rbbratta> are we still on agenda, don't mean to derail the meeting. 09:05:13 <JingLu> sdeepak001: no, It just provide CPU pinning and numa pinning support, since we now have a more powerful node type context. 09:05:38 <sdeepak001> ok got it. 09:05:58 <Mingjian_> I'd like to stream output with INFO level, and log file handler output with Debug level, so the ci log should be INFO level and clean, log file should be DEBUG level and sent to artifacts.opnfv.org. 09:07:16 <Mingjian_> rbbratta: I think the topic on the agenda has been finished 09:08:09 <Mingjian_> since we're now set handler on logging.root, we use LOG(yardstick) in each python, but it didn't work if either we set LOG to be logging.DEBUG or logging.INFO 09:08:10 <kubi001> rbbratta: yes, agenda have been finished 09:08:24 <kubi001> please feel free to discuss 09:08:43 <rbbratta> there is _LOG_STREAM_HDLR 09:08:43 <kubi001> more topics are welcome 09:09:38 <sdeepak001> Mingjian_: I think python supports use multiple log handlers 09:10:16 <rbbratta> yes, code is in __init__.py https://gerrit.opnfv.org/gerrit/gitweb?p=yardstick.git;a=blob;f=yardstick/__init__.py;hb=HEAD 09:10:46 <rbbratta> but I though _LOG_STREAM_HDLR should default to INFO level 09:11:32 <rbbratta> are we always running with --debug? 09:12:19 <Mingjian_> i think i should config _LOG_STREAM_HDLR to be INFO level and then set LOG level to be DEBUG level 09:12:48 <Mingjian_> i have already set _LOG_FILE_HDLR to be DEBUG level 09:13:03 <rbbratta> JingLu: for 29333, are the bash scripts meant to be run remotely? 09:14:15 <JingLu> rbbratta: yes, the scripts are suppose tho run on each nodes in a pod. 09:14:30 <rbbratta> JingLu: ideally we should use the ansible model. create standalone minimal dependency python modules and run remote python 09:15:06 <rbbratta> JingLu: I have code from other projects that does some remote python execution with just ssh. 09:15:40 <JingLu> rbbratta: that will be great 09:16:04 <rbbratta> Mingjian_: _LOG_STREAM_HDLR.setLevel(logging.INFO) should work? 09:16:10 <Mingjian_> rbbratta: from my local test, it seems _LOG_STREAM_HDLR is not default INFO level 09:17:09 <Mingjian_> rbbratta: i've just test it locally 09:17:16 <Mingjian_> it works 09:17:33 <Mingjian_> _LOG_STREAM_HDLR set to be INFO level 09:17:53 <kubi001> Mingjian_: rbbratta: great 09:19:28 <JingLu> rbbratta: can you show me the code, dose it use ansible? 09:19:36 <rbbratta> Mingjian_: ah, level default to NOTSET, 09:20:32 <Mingjian_> but if we do this, -d in cli won't work to sys.output DEBUG info 09:21:00 <Mingjian_> since -d also just set LOG to be DEBUG level 09:21:39 <rbbratta> Mingjian_: the handlers have their own levels 09:21:46 <rbbratta> JingLu: looking for it 09:22:28 <JingLu> rbbratta: thanks in advance 09:22:37 <Mingjian_> rbbratta: so may we should also set the handler level if we use -d in cli, that may works 09:23:18 <rbbratta> JingLu: https://github.com/taf3/taf/blob/master/taf/testlib/multicall.py 09:23:43 <rbbratta> JingLu: we take python source, compress it, send it over ssh command line and then decompress and execute 09:24:07 <rbbratta> JingLu: what ansible does it just write python into | ssh python - 09:25:32 <kubi001> I guess we could end the meeting, and you can discuss with each other after the meeting :) 09:25:37 <kubi001> thanks all for today 09:25:42 <kubi001> #endmeeting