From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: "Daniel Sangorrin" References: In-Reply-To: Date: Tue, 22 May 2018 11:21:02 +0900 Message-ID: <003401d3f173$880701d0$98150570$@toshiba.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: ja Subject: Re: [Fuego] [PATCH] core: add log_this function List-Id: Mailing list for the Fuego test framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Tim.Bird@sony.com, fuego@lists.linuxfoundation.org Hi Tim, I noticed that you are appending the log to testlog. It would be nice to = add a separator such as: Fuego: board A testlog ... Fuego: host testlog ....x Also I was thinking that from a systems perspective, it would be nice to = be able to rename the log files. For example, suppose that we have a test that requires 4 boards (A, B, = C, D) and the test is coordinated by board E (it could be "docker" or = the host as well). Initially, we would run ftc run-test on board E (the coordinator). Then = board-E's fuego_test.sh would execute=20 ftc run-test -b boardname --log boardname.log -t ... on boards [A..D]. # it would be nice to have a new category (like Benchmark and = Functional) for monitoring tests that just check the disk usage or = network status. Something like MONITORING.free (check memory usage) etc. Finally, during the post processing phase board E can merge the logs = into one (using a separator) and give it to the parser. # Of course Board E should be able to use Fuego core functions for = switching on the boards, waiting until all of them are ready etc. Thanks, Daniel > -----Original Message----- > From: fuego-bounces@lists.linuxfoundation.org > [mailto:fuego-bounces@lists.linuxfoundation.org] On Behalf Of > Tim.Bird@sony.com > Sent: Tuesday, May 22, 2018 3:40 AM > To: fuego@lists.linuxfoundation.org > Subject: [Fuego] [PATCH] core: add log_this function >=20 > Hey Fuego-ans, >=20 > Here is a patch that I applied to fuego-core last week. I've been = doing > some thinking about some longstanding issues with tests that have a > host-side component to their data gathering. Based on this, and recent > discussions on the list, I implemented a new "log_this" function. > It's like the "report" function, but for a host-side command. >=20 > I believe this will be a new, important architectural feature of = Fuego. >=20 > This is part of a broader effort to expand the scope of Fuego testing, = from just > target-side testing, to more system-wide testing. It's clear that for = some types of > hardware testing, additional off-DUT frameworks will need to be = accessed, > and in some cases controlled. This new function "log_this" is the = start of > support for logging the access to such non-DUT frameworks > (facilities, devices, harnesses, resources, etc.) >=20 > I'm also thinking about what's needed to provide for generalized = control > of such things. This is a tricky subject, due to the incredible = fragmentation > there is in board control hardware, secondary resource control, and = associated > driving software. > However, I'm considering implementing some kind of generic resource > reservation and management system (over the long run - this is not the = highest > priority at the moment). >=20 > In any event, here's the patch for this little bit, which is actually = pretty simple... > -------------- > Some tests need to get information and data from host-side > operations, that needs to be reported and analyzed by Fuego. >=20 > The log_this function captures the output of commands executed > on the host, and puts it (ultimately) into the test log for a run. > Any command executed with "log_this" is saved during test execution, > and placed in the final testlog.txt, after any > board-side log data (from report and report_append) commands. >=20 > There are several tests (especially Fuego self-tests) that could > use this feature, to avoid an awkward sequence of push-to-target, > and report-cat, to get log data from the host into the testlog. >=20 > Signed-off-by: Tim Bird > --- > engine/scripts/functions.sh | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) >=20 > diff --git a/engine/scripts/functions.sh b/engine/scripts/functions.sh > index 0b293db..8fabd85 100755 > --- a/engine/scripts/functions.sh > +++ b/engine/scripts/functions.sh > @@ -226,6 +226,21 @@ function report_append { > return ${RESULT} > } >=20 > +# $1 - local shell command > +function log_this { > + is_empty $1 > + > + RETCODE=3D/tmp/$$-${RANDOM} > + touch $RETCODE > + > + { $1; echo $? > $RETCODE ; } 2>&1 | tee -a ${LOGDIR}/hostlog.txt > + > + RESULT=3D$(cat $RETCODE) > + rm -f $RETCODE > + export REPORT_RETURN_VALUE=3D${RESULT} > + return ${RESULT} > +} > + > function dump_syslogs { > # 1 - tmp dir, 2 - before/after >=20 > @@ -466,6 +481,10 @@ function fetch_results { > get $BOARD_TESTDIR/fuego.$TESTDIR/$TESTDIR.log = ${LOGDIR}/testlog.txt > || \ > echo "INFO: the test did not produce a test log on the = target" | tee > ${LOGDIR}/testlog.txt >=20 > + if [ -f ${LOGDIR}/hostlog.txt ] ; then > + cat ${LOGDIR}/hostlog.txt >> ${LOGDIR}/testlog.txt > + fi > + > # Get syslogs > dump_syslogs ${fuego_test_tmp} "after" > get > ${fuego_test_tmp}/${NODE_NAME}.${BUILD_ID}.${BUILD_NUMBER}.before > ${LOGDIR}/syslog.before.txt > -- > 2.1.4 >=20 > _______________________________________________ > Fuego mailing list > Fuego@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/fuego