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