From Tim.Bird at sony.com Thu Feb 1 00:15:18 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 1 Feb 2018 00:15:18 +0000 Subject: [Fuego] [PATCH 1/1] Remove jenkins user created during build time with host's uid/gid In-Reply-To: <20180131152301.20496-2-guicc@profusion.mobi> References: <20180131152301.20496-1-guicc@profusion.mobi> <20180131152301.20496-2-guicc@profusion.mobi> Message-ID: OK - I tried this, using my fuego-clean-install.sh script, and got the following result: %% in front of lines from my test script: ... Step 28/29 : COPY setup/entrypoint.sh / ---> 9afcd663976c Removing intermediate container 9f4e60feccc1 Step 29/29 : ENTRYPOINT /entrypoint.sh ---> Running in 886672f5f6e4 ---> 4a7cf228d727 Removing intermediate container 886672f5f6e4 [Warning] One or more build-args [http_proxy https_proxy] were not consumed Successfully built 4a7cf228d727 Successfully tagged fuego-131:latest %%+ cd fuego-host-scripts %%+ ./docker-create-usb-privileged-container.sh fuego-131 fuego-131-container %%b5f33ad097df02131acd8765423a7a54fd6fb553f23bc86f136bcc165091d85f %%+ cd ../.. %%+ sudo service netperf stop %% * Stopping network benchmark server [fail] %%+ set +x %%After the container starts, run %% 'fuego-finish-install.sh fuego-131-container' to finish the installation %%and start tests. %%Also, You may want to edit ~/bin/fuego-start to use the %% container name: fuego-131-container Starting Fuego container (fuego-131-container) Remapping Fuego's jenkins uid=107 to uid=0... usermod: UID '0' already exists Please create Fuego docker container via docker-create-container.sh script 1000072457 at tlinux:~/work/fuego/next-2018-01-31$ ------- I'm going to try it manually to see if there something about my test script that is causing the UID at the time the entrypoint.sh is called to be 0. I'm about to start work on refactoring this script with a sed line to hard-code the host uid of the building user (or maybe read it from a configuration file in /fuego-ro/conf. Let me know if you see something obvious that wrong with my startup sequence. Did this work for you? -- Tim > -----Original Message----- > From: Guilherme Campos Camargo > Sent: Wednesday, January 31, 2018 7:23 AM > To: fuego at lists.linuxfoundation.org > Subject: [Fuego] [PATCH 1/1] Remove jenkins user created during build time > with host's uid/gid > > Prior to this patch, the fuego-host-scripts/docker-build-image.sh script > was calling docker build passing two `build-arg`s: uid/gid. According to > the comments in the code, it seems that the intention was to make sure > that the jenkins user (needed by Jenkins) would have the same uid/gid as > the user of the host that has called the install script. > > Given that the uid/gid of the jenkins user was being set at build time, > the generated image would be configured only for the machine where it's > built, what would prevent jenkins to change files in the /fuego-rw > mountpoint in different hosts. > > One approach for allowing jenkins to write to fuego-rw, is to chown > /fuego-rw and it's pre-existing subdirectories during execution time, > what can be done in a docker entrypoint script. That approach per se, > solves the problem, by allowing jenkins to write to the mount point, but > generates a side-effect: the user on the host machine will be able to > inspect, but will not be able to delete/modify the files created by > jenkins (unless it forces it as root). > > Another approach would be to change the uid and the gid of the jenkins > user in the first execution, (first call to docker-container-start.sh), > also through the entrypoint. This would solve the problem of the access > from both sides, but has the downside of the need of running a recursive > `chown` in all jenkins files in `/var` (including cache), possibly > taking a long time to be accomplished. > > Since most users will need to edit/remove the files from fuego-rw during > usage and also given that `chowning` would ideally take place only once > (first time that the container starts) for a given user, we decided to > use the second approach. > > On this patch, we create an entrypoint.sh in which the uid/gid of > Jenkins is mapped to the user's. > > Signed-off-by: Guilherme Campos Camargo > --- > Dockerfile | 10 ++++------ > fuego-host-scripts/docker-build-image.sh | 13 +------------ > fuego-host-scripts/docker-create-container.sh | 10 ++++++++++ > setup/entrypoint.sh | 22 ++++++++++++++++++++++ > setup/jenkins/setup.sh | 8 -------- > 5 files changed, 37 insertions(+), 26 deletions(-) > create mode 100755 setup/entrypoint.sh > > diff --git a/Dockerfile b/Dockerfile > index 3dad8b4..cc79351 100644 > --- a/Dockerfile > +++ b/Dockerfile > @@ -96,16 +96,12 @@ RUN echo deb http://emdebian.org/tools/debian/ > jessie main > /etc/apt/sources.li > # Download and Install Jenkins > # > ========================================================== > ==================== > > -ENV uid=1000 > -ENV gid=${uid} > ARG JENKINS_VERSION=2.32.1 > ARG JENKINS_SHA=bfc226aabe2bb089623772950c4cc13aee613af1 > ARG JENKINS_URL=https://pkg.jenkins.io/debian- > stable/binary/jenkins_${JENKINS_VERSION}_all.deb > ENV JENKINS_HOME=/var/lib/jenkins > > -RUN groupadd -g ${gid} jenkins && \ > - useradd -l -m -d "${JENKINS_HOME}" -u ${uid} -g ${gid} -G sudo -s > /bin/bash jenkins && \ > - curl -L -O ${JENKINS_URL} && \ > +RUN curl -L -O ${JENKINS_URL} && \ > echo "${JENKINS_SHA} jenkins_${JENKINS_VERSION}_all.deb" | sha1sum > -c - && \ > dpkg -i jenkins_${JENKINS_VERSION}_all.deb && \ > rm jenkins_${JENKINS_VERSION}_all.deb > @@ -143,4 +139,6 @@ COPY docs/fuego-docs.pdf > $JENKINS_HOME/userContent/docs/fuego-docs.pdf > # Setup startup command > # > ========================================================== > ==================== > > -ENTRYPOINT service jenkins start && service netperf start && /bin/bash > +WORKDIR / > +COPY setup/entrypoint.sh / > +ENTRYPOINT ["/entrypoint.sh"] > diff --git a/fuego-host-scripts/docker-build-image.sh b/fuego-host- > scripts/docker-build-image.sh > index a49ffab..d276ee0 100755 > --- a/fuego-host-scripts/docker-build-image.sh > +++ b/fuego-host-scripts/docker-build-image.sh > @@ -2,17 +2,6 @@ > # $1 - name for the docker image (default: fuego) > DOCKERIMAGE=${1:-fuego} > > -if [ "$(id -u)" == "0" ]; then > - JENKINS_UID=$(id -u $SUDO_USER) > - JENKINS_GID=$(id -g $SUDO_USER) > -else > - JENKINS_UID=$(id -u $USER) > - JENKINS_GID=$(id -g $USER) > -fi > - > sudo docker build -t ${DOCKERIMAGE} \ > --build-arg http_proxy=${http_proxy} \ > - --build-arg https_proxy=${https_proxy} \ > - --build-arg uid=${JENKINS_UID} \ > - --build-arg gid=${JENKINS_GID} \ > - . > + --build-arg https_proxy=${https_proxy} . > diff --git a/fuego-host-scripts/docker-create-container.sh b/fuego-host- > scripts/docker-create-container.sh > index 9e3d61a..cba2c6e 100755 > --- a/fuego-host-scripts/docker-create-container.sh > +++ b/fuego-host-scripts/docker-create-container.sh > @@ -17,6 +17,14 @@ if [ ! -d $DIR/../../fuego-core ]; then > exit 1 > fi > > +if [ "${UID}" == "0" ]; then > + uid=$(id -u "${SUDO_USER}") > + gid=$(id -g "${SUDO_USER}") > +else > + uid="${UID}" > + gid=$(id -g "${USER}") > +fi > + > sudo docker create -it --name ${DOCKERCONTAINER} \ > -v /boot:/boot:ro \ > -v $DIR/../fuego-rw:/fuego-rw \ > @@ -24,5 +32,7 @@ sudo docker create -it --name ${DOCKERCONTAINER} \ > -v $DIR/../../fuego-core:/fuego-core:ro \ > -e http_proxy=${http_proxy} \ > -e https_proxy=${https_proxy:-$http_proxy} \ > + -e UID=${uid} \ > + -e GID=${gid} \ > --net="host" ${DOCKERIMAGE} || \ > echo "Could not create fuego-container. See error messages." > diff --git a/setup/entrypoint.sh b/setup/entrypoint.sh > new file mode 100755 > index 0000000..bbec498 > --- /dev/null > +++ b/setup/entrypoint.sh > @@ -0,0 +1,22 @@ > +#!/bin/bash > +set -e > + > +function map_jenkins_uid_to_host() { > + if [ "$(id -u jenkins)" = "${UID}" ]; then > + return 0 > + fi > + > + echo "Remapping Fuego's jenkins uid=$(id -u jenkins) to uid=${UID}..." > + > + usermod -u "${UID}" jenkins > + groupmod -g "${GID}" jenkins > + chown -R "${UID}":"${GID}" \ > + /var/lib/jenkins /var/cache/jenkins /var/log/jenkins /fuego-rw > +} > + > +service jenkins stop >> /dev/null > +map_jenkins_uid_to_host > +service jenkins start > +service netperf start > + > +exec /bin/bash > diff --git a/setup/jenkins/setup.sh b/setup/jenkins/setup.sh > index 26b7643..b95fa91 100755 > --- a/setup/jenkins/setup.sh > +++ b/setup/jenkins/setup.sh > @@ -2,14 +2,6 @@ > > set -e > > -user=jenkins > -group=jenkins > -uid=1000 > -gid=${uid} > - > -# groupadd -g ${gid} ${group} > -# useradd -l -m -d "${JENKINS_HOME}" -u ${uid} -g ${gid} -G sudo -s > /bin/bash ${user} > - > cp config.xml jenkins.model.JenkinsLocationConfiguration.xml > "${JENKINS_HOME}" > > echo 'JENKINS_ARGS="${JENKINS_ARGS} --prefix=/fuego"' >> > /etc/default/jenkins > -- > 2.16.1 > > _______________________________________________ > Fuego mailing list > Fuego at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/fuego From Tim.Bird at sony.com Thu Feb 1 00:50:35 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 1 Feb 2018 00:50:35 +0000 Subject: [Fuego] [PATCH 1/1] Remove jenkins user created during build time with host's uid/gid In-Reply-To: References: <20180131152301.20496-1-guicc@profusion.mobi> <20180131152301.20496-2-guicc@profusion.mobi> Message-ID: > -----Original Message----- > From Tim.Bird at sony.com > > OK - I tried this, using my fuego-clean-install.sh script, and got the following > result: > > %% in front of lines from my test script: > ... > Step 28/29 : COPY setup/entrypoint.sh / > ---> 9afcd663976c > Removing intermediate container 9f4e60feccc1 > Step 29/29 : ENTRYPOINT /entrypoint.sh > ---> Running in 886672f5f6e4 > ---> 4a7cf228d727 > Removing intermediate container 886672f5f6e4 > [Warning] One or more build-args [http_proxy https_proxy] were not > consumed > Successfully built 4a7cf228d727 > Successfully tagged fuego-131:latest > %%+ cd fuego-host-scripts > %%+ ./docker-create-usb-privileged-container.sh fuego-131 fuego-131- > container > %%b5f33ad097df02131acd8765423a7a54fd6fb553f23bc86f136bcc165091d85f > %%+ cd ../.. > %%+ sudo service netperf stop > %% * Stopping network benchmark server > [fail] > %%+ set +x > %%After the container starts, run > %% 'fuego-finish-install.sh fuego-131-container' to finish the installation > %%and start tests. > %%Also, You may want to edit ~/bin/fuego-start to use the > %% container name: fuego-131-container > Starting Fuego container (fuego-131-container) > Remapping Fuego's jenkins uid=107 to uid=0... > usermod: UID '0' already exists > Please create Fuego docker container via docker-create-container.sh script > 1000072457 at tlinux:~/work/fuego/next-2018-01-31$ > > ------- > I'm going to try it manually to see if there something about my test script > that is causing the UID at the time the entrypoint.sh is called to be 0. > > I'm about to start work on refactoring this script with a sed line to hard-code > the host uid of the building user (or maybe read it from a configuration file > in /fuego-ro/conf. > > Let me know if you see something obvious that wrong with my startup > sequence. OK - I figured this out. It was my use of docker-create-usb-privileged-container.sh rather than docker-create-container.sh that was the culprit. I'm working on a system the will allow modification of this via a global configuration file, any time the container starts. Hopefully I'll finish this today. -- Tim From guicc at profusion.mobi Thu Feb 1 01:02:59 2018 From: guicc at profusion.mobi (Guilherme Camargo) Date: Wed, 31 Jan 2018 23:02:59 -0200 Subject: [Fuego] [PATCH 1/1] Remove jenkins user created during build time with host's uid/gid In-Reply-To: References: <20180131152301.20496-1-guicc@profusion.mobi> <20180131152301.20496-2-guicc@profusion.mobi> Message-ID: Hello, Tim Sorry. I forgot to make the fix in docker-create-usb-priviledged-container.sh as well. UID and GID should be passed to to docker create in that case too. Don't know if it helps, since you're changing the behavior, but this would be the patch that would need to be applied into docker-create-usb-priviledged-container.sh in order to fix the problem: ---------- diff --git a/fuego-host-scripts/docker-create-usb-privileged-container.sh b/fuego-host-scripts/docker-create-usb-privileged-container.sh index 2431214..b4c358b 100755 --- a/fuego-host-scripts/docker-create-usb-privileged-container.sh +++ b/fuego-host-scripts/docker-create-usb-privileged-container.sh @@ -17,6 +17,14 @@ if [ ! -d $DIR/../../fuego-core ]; then exit 1 fi +if [ "${UID}" == "0" ]; then + uid=$(id -u "${SUDO_USER}") + gid=$(id -g "${SUDO_USER}") +else + uid="${UID}" + gid=$(id -g "${USER}") +fi + sudo docker create -it --name ${DOCKERCONTAINER} \ --privileged \ -v /boot:/boot:ro \ @@ -30,5 +38,7 @@ sudo docker create -it --name ${DOCKERCONTAINER} \ -v $DIR/../../fuego-core:/fuego-core:ro \ -e http_proxy=${http_proxy} \ -e https_proxy=${https_proxy:-$http_proxy} \ + -e UID=${uid} \ + -e GID=${gid} \ --net="host" ${DOCKERIMAGE} || \ echo "Could not create fuego-container. See error messages." ------------------- I can send the patch tomorrow if you wish. Thanks -- Guilherme On Wed, Jan 31, 2018 at 10:50 PM, wrote: > > > > -----Original Message----- > > From Tim.Bird at sony.com > > > > OK - I tried this, using my fuego-clean-install.sh script, and got the > following > > result: > > > > %% in front of lines from my test script: > > ... > > Step 28/29 : COPY setup/entrypoint.sh / > > ---> 9afcd663976c > > Removing intermediate container 9f4e60feccc1 > > Step 29/29 : ENTRYPOINT /entrypoint.sh > > ---> Running in 886672f5f6e4 > > ---> 4a7cf228d727 > > Removing intermediate container 886672f5f6e4 > > [Warning] One or more build-args [http_proxy https_proxy] were not > > consumed > > Successfully built 4a7cf228d727 > > Successfully tagged fuego-131:latest > > %%+ cd fuego-host-scripts > > %%+ ./docker-create-usb-privileged-container.sh fuego-131 fuego-131- > > container > > %%b5f33ad097df02131acd8765423a7a54fd6fb553f23bc86f136bcc165091d85f > > %%+ cd ../.. > > %%+ sudo service netperf stop > > %% * Stopping network benchmark server > > [fail] > > %%+ set +x > > %%After the container starts, run > > %% 'fuego-finish-install.sh fuego-131-container' to finish the > installation > > %%and start tests. > > %%Also, You may want to edit ~/bin/fuego-start to use the > > %% container name: fuego-131-container > > Starting Fuego container (fuego-131-container) > > Remapping Fuego's jenkins uid=107 to uid=0... > > usermod: UID '0' already exists > > Please create Fuego docker container via docker-create-container.sh > script > > 1000072457 at tlinux:~/work/fuego/next-2018-01-31$ > > > > ------- > > I'm going to try it manually to see if there something about my test > script > > that is causing the UID at the time the entrypoint.sh is called to be 0. > > > > I'm about to start work on refactoring this script with a sed line to > hard-code > > the host uid of the building user (or maybe read it from a configuration > file > > in /fuego-ro/conf. > > > > Let me know if you see something obvious that wrong with my startup > > sequence. > > OK - I figured this out. It was my use of docker-create-usb-privileged- > container.sh > rather than docker-create-container.sh that was the culprit. > > I'm working on a system the will allow modification of this via a global > configuration > file, any time the container starts. Hopefully I'll finish this today. > -- Tim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Bird at sony.com Thu Feb 1 01:03:17 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 1 Feb 2018 01:03:17 +0000 Subject: [Fuego] [PATCH 1/1] Remove jenkins user created during build time with host's uid/gid In-Reply-To: References: <20180131152301.20496-1-guicc@profusion.mobi> <20180131152301.20496-2-guicc@profusion.mobi> Message-ID: > -----Original Message----- > From: Bird, Timothy > > -----Original Message----- > > From Tim.Bird at sony.com > > > > OK - I tried this, using my fuego-clean-install.sh script, and got the following > > result: > > > > %% in front of lines from my test script: > > ... > > Step 28/29 : COPY setup/entrypoint.sh / > > ---> 9afcd663976c > > Removing intermediate container 9f4e60feccc1 > > Step 29/29 : ENTRYPOINT /entrypoint.sh > > ---> Running in 886672f5f6e4 > > ---> 4a7cf228d727 > > Removing intermediate container 886672f5f6e4 > > [Warning] One or more build-args [http_proxy https_proxy] were not > > consumed > > Successfully built 4a7cf228d727 > > Successfully tagged fuego-131:latest > > %%+ cd fuego-host-scripts > > %%+ ./docker-create-usb-privileged-container.sh fuego-131 fuego-131- > > container > > > %%b5f33ad097df02131acd8765423a7a54fd6fb553f23bc86f136bcc165091d85f > > %%+ cd ../.. > > %%+ sudo service netperf stop > > %% * Stopping network benchmark server > > [fail] > > %%+ set +x > > %%After the container starts, run > > %% 'fuego-finish-install.sh fuego-131-container' to finish the installation > > %%and start tests. > > %%Also, You may want to edit ~/bin/fuego-start to use the > > %% container name: fuego-131-container > > Starting Fuego container (fuego-131-container) > > Remapping Fuego's jenkins uid=107 to uid=0... > > usermod: UID '0' already exists > > Please create Fuego docker container via docker-create-container.sh script > > 1000072457 at tlinux:~/work/fuego/next-2018-01-31$ > > > > ------- > > I'm going to try it manually to see if there something about my test script > > that is causing the UID at the time the entrypoint.sh is called to be 0. > > > > I'm about to start work on refactoring this script with a sed line to hard- > code > > the host uid of the building user (or maybe read it from a configuration file > > in /fuego-ro/conf. > > > > Let me know if you see something obvious that wrong with my startup > > sequence. > > OK - I figured this out. It was my use of docker-create-usb-privileged- > container.sh > rather than docker-create-container.sh that was the culprit. > > I'm working on a system the will allow modification of this via a global > configuration > file, any time the container starts. Hopefully I'll finish this today. Ok - see the latest changes in my 'next' branch, and let me know what you think. -- Tim From guicc at profusion.mobi Thu Feb 1 01:07:04 2018 From: guicc at profusion.mobi (Guilherme Camargo) Date: Wed, 31 Jan 2018 23:07:04 -0200 Subject: [Fuego] [PATCH 1/1] Remove jenkins user created during build time with host's uid/gid In-Reply-To: References: <20180131152301.20496-1-guicc@profusion.mobi> <20180131152301.20496-2-guicc@profusion.mobi> Message-ID: ?I'll take a closer look tomorrow, but seems to work as expected. Thanks. -- Guilherme On Wed, Jan 31, 2018 at 11:03 PM, wrote: > > -----Original Message----- > > From: Bird, Timothy > > > -----Original Message----- > > > From Tim.Bird at sony.com > > > > > > OK - I tried this, using my fuego-clean-install.sh script, and got the > following > > > result: > > > > > > %% in front of lines from my test script: > > > ... > > > Step 28/29 : COPY setup/entrypoint.sh / > > > ---> 9afcd663976c > > > Removing intermediate container 9f4e60feccc1 > > > Step 29/29 : ENTRYPOINT /entrypoint.sh > > > ---> Running in 886672f5f6e4 > > > ---> 4a7cf228d727 > > > Removing intermediate container 886672f5f6e4 > > > [Warning] One or more build-args [http_proxy https_proxy] were not > > > consumed > > > Successfully built 4a7cf228d727 > > > Successfully tagged fuego-131:latest > > > %%+ cd fuego-host-scripts > > > %%+ ./docker-create-usb-privileged-container.sh fuego-131 fuego-131- > > > container > > > > > %%b5f33ad097df02131acd8765423a7a54fd6fb553f23bc86f136bcc165091d85f > > > %%+ cd ../.. > > > %%+ sudo service netperf stop > > > %% * Stopping network benchmark server > > > [fail] > > > %%+ set +x > > > %%After the container starts, run > > > %% 'fuego-finish-install.sh fuego-131-container' to finish the > installation > > > %%and start tests. > > > %%Also, You may want to edit ~/bin/fuego-start to use the > > > %% container name: fuego-131-container > > > Starting Fuego container (fuego-131-container) > > > Remapping Fuego's jenkins uid=107 to uid=0... > > > usermod: UID '0' already exists > > > Please create Fuego docker container via docker-create-container.sh > script > > > 1000072457 at tlinux:~/work/fuego/next-2018-01-31$ > > > > > > ------- > > > I'm going to try it manually to see if there something about my test > script > > > that is causing the UID at the time the entrypoint.sh is called to be > 0. > > > > > > I'm about to start work on refactoring this script with a sed line to > hard- > > code > > > the host uid of the building user (or maybe read it from a > configuration file > > > in /fuego-ro/conf. > > > > > > Let me know if you see something obvious that wrong with my startup > > > sequence. > > > > OK - I figured this out. It was my use of docker-create-usb-privileged- > > container.sh > > rather than docker-create-container.sh that was the culprit. > > > > I'm working on a system the will allow modification of this via a global > > configuration > > file, any time the container starts. Hopefully I'll finish this today. > > Ok - see the latest changes in my 'next' branch, and let me know what > you think. > -- Tim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Bird at sony.com Thu Feb 1 01:27:13 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 1 Feb 2018 01:27:13 +0000 Subject: [Fuego] Add NEED_PROGRAM to need_check In-Reply-To: References: Message-ID: > -----Original Message----- > From Liu, Wenlong > Hi Tim, Daniel and other friends > > > > I didn't add the contents of the attachments in this mail, because I just want > to confirm > > that if it will be better to move those check steps from pre_check to > check_needs. > > If I'm not mistaken, we've talked about it on the maillist before, but I can't > find that mail now. In general, I prefer things to be done as check_needs, which means they are declarative, rather than in test_pre_check, which, strictly speaking, is imperative. Having declarative dependencies means you can do a static dependency checker. This is a welcome addition. Do you want me to just use these patches, or do you want to submit them again more formally? -- Tim From Tim.Bird at sony.com Thu Feb 1 01:30:14 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 1 Feb 2018 01:30:14 +0000 Subject: [Fuego] Split the output and add log links for each testcase In-Reply-To: References: Message-ID: > -----Original Message----- > From: Liu, Wenlong > Sent: Tuesday, January 30, 2018 11:58 PM > Hi Tim, Daniel and other friends > > Functional.LTP has heavy outputs after testing, which makes it difficult for us > to locate the error log easily. > > LTP has the feature that can help us to split the output for different > testcases. > > So, I added some links to those separated log files in the test case summary > page. > > It helped me a lot to investigate different failures. I like this a lot. Fuego has not had very good facilities to isolate the error information for each testcase, and this looks like it will do it. > > Now, I also added a generic function to split the output for different tests > and try to apply it to different tests. > > Please review the patch[01-09] in the maillist. I will do what I can tonight, but I probably won't be able to finish before I stop working today. I'll have to finish up later this week. -- Tim From Tim.Bird at sony.com Thu Feb 1 01:43:45 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 1 Feb 2018 01:43:45 +0000 Subject: [Fuego] [PATCH 1/9] chart: add log links for the tests which have separated log file In-Reply-To: <1517385014-9037-1-git-send-email-liuwl.fnst@cn.fujitsu.com> References: <1517385014-9037-1-git-send-email-liuwl.fnst@cn.fujitsu.com> Message-ID: > -----Original Message----- > From: Liu Wenlong > > Add log links for the tests which have separated log file, > Such as, Functional.LTP in the current Fuego. > > The separated log link can help us to find the error log easily. > This feature indeed helped me a lot. > > I also added link to "testlog.txt" for those tests who don't have the > separated log.(This might be a little unnecessary) > > Signed-off-by: Liu Wenlong > --- > engine/scripts/parser/prepare_chart_data.py | 33 > +++++++++++++++++++++++------ > 1 file changed, 27 insertions(+), 6 deletions(-) > > diff --git a/engine/scripts/parser/prepare_chart_data.py > b/engine/scripts/parser/prepare_chart_data.py > index af5f6d3..ffb042b 100644 > --- a/engine/scripts/parser/prepare_chart_data.py > +++ b/engine/scripts/parser/prepare_chart_data.py > @@ -381,6 +381,8 @@ def cmp_alpha_num(a, b): > def make_testcase_table(test_name, chart_config, entries): > # make a table of testcase results for every testcase > chart_list = [] > + jenkins_web_prefix = "/fuego" I think we can probably use JENKINS_URL instead of this. > + jenkins_root_path = "/var/lib/jenkins/" I'd rather we looked for these logs via the log directory, than the jenkins directory. > > # get a list of (board,test sets) in the data > # FIXTHIS - use list of test sets in chart_config, if present > @@ -421,14 +423,32 @@ def make_testcase_table(test_name, chart_config, > entries): > dprint("making a new row for '%s'" % row_key) > result_map[row_key] = {} > > + # entry.tguid: e.g. math.abs01. > + tguid_parts = entry.tguid.split(".") > + tguid_testset = ".".join(tguid_parts[:-1]) > + tguid_testcase = tguid_parts[-1] > + > + # get the name that contains board, spec, build number. E.g. > porter.default.1.1 > + log_bts_name = '%s.%s.%s.%s' % (entry.board, entry.spec, > str(entry.build_number), str(entry.build_number)) > + # separated log files, e.g. > /var/lib/jenkins/userContent/fuego.logs/Functional.LTP/ubuntu.math.7.7/re > sult/math/outputs/abs01.log This is relative to the URL home, not /var/lib/jenkins, for purposes of this code. This comment is misleading. > + log_file = > '/userContent/fuego.logs/%s/%s/result/%s/outputs/%s.log' % > (entry.testname, log_bts_name, tguid_testset, tguid_testcase) > + # testlog files, e.g. > /fuego/userContent/fuego.logs/Functional.croco/porter.default.${BUILD_N > UMBER}.${BUILD_ID}/testlog.txt > + testlog_file = '/userContent/fuego.logs/%s/%s/testlog.txt' % > (entry.testname, log_bts_name) > + > + # check if the separated log path exist > + if os.path.exists(jenkins_root_path + log_file): > + entry.result = '%s' % (jenkins_web_prefix, > log_file, entry.result) > + elif os.path.exists(jenkins_root_path + testlog_file): > + entry.result = '%s' % (jenkins_web_prefix, > testlog_file, entry.result) > + > # add a data point (result) for this entry > result_map[row_key][entry.build_number] = entry.result > # count the result > - if entry.result=="PASS": > + if "PASS" in entry.result: I'm not sure why this is needed. The result in an entry in this code should always be exactly one of FAIL, PASS, SKIP or ERROR. Using python's 'in' shouldn't be needed, and is a more expensive operation. Did you see the use of '==' for this comparison fail somewhere? If so, that's a bug we should track down. (The same comment applies to the rest of these conversions.) > build_num_map[entry.build_number][0] += 1 > - elif entry.result=="FAIL": > + elif "FAIL" in entry.result: > build_num_map[entry.build_number][1] += 1 > - elif entry.result=="SKIP": > + elif "SKIP" in entry.result: > build_num_map[entry.build_number][2] += 1 > else: > build_num_map[entry.build_number][3] += 1 > @@ -475,12 +495,13 @@ def make_testcase_table(test_name, chart_config, > entries): > value = result_map[tc][bn] > except: > value = "" > - if value=="PASS": > + if "PASS" in value: > cell_attr = 'style="background-color:#ccffcc"' > - elif value=="FAIL": > + elif "FAIL" in value: > cell_attr = 'style="background-color:#ffcccc"' > else: > - cell_attr = '' > + cell_attr = 'align="center"' > + value='-' > row += ("" % cell_attr) + value + "" > row += '' > html += row > -- > 2.7.4 Thanks. -- Tim From daniel.sangorrin at toshiba.co.jp Thu Feb 1 01:48:44 2018 From: daniel.sangorrin at toshiba.co.jp (Daniel Sangorrin) Date: Thu, 1 Feb 2018 10:48:44 +0900 Subject: [Fuego] Split the output and add log links for each testcase In-Reply-To: References: Message-ID: <002e01d39afe$cb2e0d80$618a2880$@toshiba.co.jp> > -----Original Message----- > From: fuego-bounces at lists.linuxfoundation.org [mailto:fuego-bounces at lists.linuxfoundation.org] On Behalf Of Tim.Bird at sony.com > Sent: Thursday, February 01, 2018 10:30 AM > To: liuwl.fnst at cn.fujitsu.com; fuego at lists.linuxfoundation.org > Subject: Re: [Fuego] Split the output and add log links for each testcase > > > -----Original Message----- > > From: Liu, Wenlong > > Sent: Tuesday, January 30, 2018 11:58 PM > > Hi Tim, Daniel and other friends > > > > Functional.LTP has heavy outputs after testing, which makes it difficult for us > > to locate the error log easily. > > > > LTP has the feature that can help us to split the output for different > > testcases. > > > > So, I added some links to those separated log files in the test case summary > > page. > > > > It helped me a lot to investigate different failures. > > I like this a lot. Fuego has not had very good facilities to isolate the > error information for each testcase, and this looks like it will do it. I think that separate log files are good. But if you patch LTP please keep in mind that test case error logs are already separated by the parser. In LTP, the error log for non-successful test cases is in the corresponding row on the output excel sheet. If you double-click on the cell, you will see the complete error log for that specific test case. # Next, I am planning to add another column with a guess on why the test case failed. By the way, normally what I do to investigate a failure is: - set the target_postCleanup flag to False - ssh to the target - execute the test case individually with runltp # ./runltp -f syscalls -s madvise07 - or execute the test directly with strace # strace bin/madvise07 [Note] the arguments required for the test can be obtained from the test group inside runtests/ (e.g. syscalls file) Thanks, Daniel > > Now, I also added a generic function to split the output for different tests > > and try to apply it to different tests. > > > > Please review the patch[01-09] in the maillist. > > I will do what I can tonight, but I probably won't be able to finish > before I stop working today. I'll have to finish up later this week. > -- Tim > > _______________________________________________ > Fuego mailing list > Fuego at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/fuego From liuwl.fnst at cn.fujitsu.com Thu Feb 1 02:22:44 2018 From: liuwl.fnst at cn.fujitsu.com (Liu, Wenlong) Date: Thu, 1 Feb 2018 02:22:44 +0000 Subject: [Fuego] Add NEED_PROGRAM to need_check In-Reply-To: References: Message-ID: > -----Original Message----- > From: Tim.Bird at sony.com [mailto:Tim.Bird at sony.com] > Sent: Thursday, February 01, 2018 9:27 AM > To: Liu, Wenlong/? ?? ; > fuego at lists.linuxfoundation.org > Subject: RE: Add NEED_PROGRAM to need_check > > > -----Original Message----- > > From Liu, Wenlong > > Hi Tim, Daniel and other friends > > > > I didn't add the contents of the attachments in this mail, because I > > just want to confirm > > > > that if it will be better to move those check steps from pre_check to > > check_needs. > > > > If I'm not mistaken, we've talked about it on the maillist before, but > > I can't find that mail now. > > In general, I prefer things to be done as check_needs, which means they > are declarative, rather than in test_pre_check, which, strictly speaking, > is imperative. > > Having declarative dependencies means you can do a static dependency > checker. > > This is a welcome addition. Do you want me to just use these patches, or > do you want to submit them again more formally? OK, those patches can be used(I have tested this). > -- Tim > From liuwl.fnst at cn.fujitsu.com Thu Feb 1 02:25:34 2018 From: liuwl.fnst at cn.fujitsu.com (Liu, Wenlong) Date: Thu, 1 Feb 2018 02:25:34 +0000 Subject: [Fuego] [PATCH 1/9] chart: add log links for the tests which have separated log file In-Reply-To: References: <1517385014-9037-1-git-send-email-liuwl.fnst@cn.fujitsu.com> Message-ID: > -----Original Message----- > From: Tim.Bird at sony.com [mailto:Tim.Bird at sony.com] > Sent: Thursday, February 01, 2018 9:44 AM > To: Liu, Wenlong/? ?? ; > fuego at lists.linuxfoundation.org > Subject: RE: [Fuego] [PATCH 1/9] chart: add log links for the tests which > have separated log file > > > -----Original Message----- > > From: Liu Wenlong > > > > Add log links for the tests which have separated log file, Such as, > > Functional.LTP in the current Fuego. > > > > The separated log link can help us to find the error log easily. > > This feature indeed helped me a lot. > > > > I also added link to "testlog.txt" for those tests who don't have the > > separated log.(This might be a little unnecessary) > > > > Signed-off-by: Liu Wenlong > > --- > > engine/scripts/parser/prepare_chart_data.py | 33 > > +++++++++++++++++++++++------ > > 1 file changed, 27 insertions(+), 6 deletions(-) > > > > diff --git a/engine/scripts/parser/prepare_chart_data.py > > b/engine/scripts/parser/prepare_chart_data.py > > index af5f6d3..ffb042b 100644 > > --- a/engine/scripts/parser/prepare_chart_data.py > > +++ b/engine/scripts/parser/prepare_chart_data.py > > @@ -381,6 +381,8 @@ def cmp_alpha_num(a, b): > > def make_testcase_table(test_name, chart_config, entries): > > # make a table of testcase results for every testcase > > chart_list = [] > > + jenkins_web_prefix = "/fuego" > I think we can probably use JENKINS_URL instead of this. > > > + jenkins_root_path = "/var/lib/jenkins/" > > I'd rather we looked for these logs via the log directory, than the jenkins > directory. OK, I will change it. > > > > # get a list of (board,test sets) in the data > > # FIXTHIS - use list of test sets in chart_config, if present @@ > > -421,14 +423,32 @@ def make_testcase_table(test_name, chart_config, > > entries): > > dprint("making a new row for '%s'" % row_key) > > result_map[row_key] = {} > > > > + # entry.tguid: e.g. math.abs01. > > + tguid_parts = entry.tguid.split(".") > > + tguid_testset = ".".join(tguid_parts[:-1]) > > + tguid_testcase = tguid_parts[-1] > > + > > + # get the name that contains board, spec, build number. E.g. > > porter.default.1.1 > > + log_bts_name = '%s.%s.%s.%s' % (entry.board, entry.spec, > > str(entry.build_number), str(entry.build_number)) > > + # separated log files, e.g. > > > /var/lib/jenkins/userContent/fuego.logs/Functional.LTP/ubuntu.math.7.7 > > /re > > sult/math/outputs/abs01.log > This is relative to the URL home, not /var/lib/jenkins, for purposes of > this code. This comment is misleading. > > > + log_file = > > '/userContent/fuego.logs/%s/%s/result/%s/outputs/%s.log' % > > (entry.testname, log_bts_name, tguid_testset, tguid_testcase) > > + # testlog files, e.g. > > > /fuego/userContent/fuego.logs/Functional.croco/porter.default.${BUILD_ > > N > > UMBER}.${BUILD_ID}/testlog.txt > > + testlog_file = > > + '/userContent/fuego.logs/%s/%s/testlog.txt' % > > (entry.testname, log_bts_name) > > + > > + # check if the separated log path exist > > + if os.path.exists(jenkins_root_path + log_file): > > + entry.result = '%s' % > > + (jenkins_web_prefix, > > log_file, entry.result) > > + elif os.path.exists(jenkins_root_path + testlog_file): > > + entry.result = '%s' % > > + (jenkins_web_prefix, > > testlog_file, entry.result) > > + > > > # add a data point (result) for this entry > > result_map[row_key][entry.build_number] = entry.result > > # count the result > > - if entry.result=="PASS": > > + if "PASS" in entry.result: > I'm not sure why this is needed. The result in an entry in this code > should always be exactly one of FAIL, PASS, SKIP or ERROR. > > Using python's 'in' shouldn't be needed, and is a more expensive > operation. Did you see the use of '==' for this comparison fail > somewhere? If so, that's a bug we should track down. Emm, sorry, I changed the result in an entry above. It's better to use a temporary variable to store this value which contains URL info. And then, "==" will be ok here. I will improve those patches together after your review. > (The same comment applies to the rest of these conversions.) > > > build_num_map[entry.build_number][0] += 1 > > - elif entry.result=="FAIL": > > + elif "FAIL" in entry.result: > > build_num_map[entry.build_number][1] += 1 > > - elif entry.result=="SKIP": > > + elif "SKIP" in entry.result: > > build_num_map[entry.build_number][2] += 1 > > else: > > build_num_map[entry.build_number][3] += 1 @@ -475,12 > > +495,13 @@ def make_testcase_table(test_name, chart_config, > > entries): > > value = result_map[tc][bn] > > except: > > value = "" > > - if value=="PASS": > > + if "PASS" in value: But for this "value" here, it contains the the URL info and not aways be the one of FAIL, PASS, SKIP or ERROR. > > cell_attr = 'style="background-color:#ccffcc"' > > - elif value=="FAIL": > > + elif "FAIL" in value: > > cell_attr = 'style="background-color:#ffcccc"' > > else: > > - cell_attr = '' > > + cell_attr = 'align="center"' > > + value='-' > > row += ("" % cell_attr) + value + "" > > row += '' > > html += row > > -- > > 2.7.4 > > Thanks. > -- Tim > From liuwl.fnst at cn.fujitsu.com Thu Feb 1 02:27:05 2018 From: liuwl.fnst at cn.fujitsu.com (Liu, Wenlong) Date: Thu, 1 Feb 2018 02:27:05 +0000 Subject: [Fuego] Split the output and add log links for each testcase In-Reply-To: <002e01d39afe$cb2e0d80$618a2880$@toshiba.co.jp> References: <002e01d39afe$cb2e0d80$618a2880$@toshiba.co.jp> Message-ID: > -----Original Message----- > From: Daniel Sangorrin [mailto:daniel.sangorrin at toshiba.co.jp] > Sent: Thursday, February 01, 2018 9:49 AM > To: Tim.Bird at sony.com; Liu, Wenlong/? ?? ; > fuego at lists.linuxfoundation.org > Subject: RE: [Fuego] Split the output and add log links for each testcase > > > > > -----Original Message----- > > From: fuego-bounces at lists.linuxfoundation.org > > [mailto:fuego-bounces at lists.linuxfoundation.org] On Behalf Of > > Tim.Bird at sony.com > > Sent: Thursday, February 01, 2018 10:30 AM > > To: liuwl.fnst at cn.fujitsu.com; fuego at lists.linuxfoundation.org > > Subject: Re: [Fuego] Split the output and add log links for each > > testcase > > > > > -----Original Message----- > > > From: Liu, Wenlong > > > Sent: Tuesday, January 30, 2018 11:58 PM Hi Tim, Daniel and other > > > friends > > > > > > Functional.LTP has heavy outputs after testing, which makes it > > > difficult for us to locate the error log easily. > > > > > > LTP has the feature that can help us to split the output for > > > different testcases. > > > > > > So, I added some links to those separated log files in the test case > > > summary page. > > > > > > It helped me a lot to investigate different failures. > > > > I like this a lot. Fuego has not had very good facilities to isolate > > the error information for each testcase, and this looks like it will do > it. > > I think that separate log files are good. But if you patch LTP please keep > in mind that test case error logs are already separated by the parser. In > LTP, the error log for non-successful test cases is in the corresponding > row on the output excel sheet. > If you double-click on the cell, you will see the complete error log for > that specific test case. > # Next, I am planning to add another column with a guess on why the test > case failed. Good. > By the way, normally what I do to investigate a failure is: > - set the target_postCleanup flag to False > - ssh to the target > - execute the test case individually with runltp > # ./runltp -f syscalls -s madvise07 > - or execute the test directly with strace > # strace bin/madvise07 > [Note] the arguments required for the test can be obtained from the > test group inside runtests/ (e.g. syscalls file) Yes, right. Thanks, Daniel, I indeed did the same step with you for most LTP investigation. But for some failures, sometimes, I just want to check if the error log same with before. The excel sheet is very convenient to check and share the all test results, but I think the HTML page is better to compare the results of different builds and that's why I added this. > Thanks, > Daniel > > > > Now, I also added a generic function to split the output for > > > different tests and try to apply it to different tests. > > > > > > Please review the patch[01-09] in the maillist. > > > > I will do what I can tonight, but I probably won't be able to finish > > before I stop working today. I'll have to finish up later this week. > > -- Tim > > > > _______________________________________________ > > Fuego mailing list > > Fuego at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/fuego > > > > From daniel.sangorrin at toshiba.co.jp Fri Feb 2 07:30:12 2018 From: daniel.sangorrin at toshiba.co.jp (Daniel Sangorrin) Date: Fri, 2 Feb 2018 16:30:12 +0900 Subject: [Fuego] Add NEED_PROGRAM to need_check In-Reply-To: References: Message-ID: <007501d39bf7$a94cdad0$fbe69070$@toshiba.co.jp> Hi Tim, > -----Original Message----- > From: fuego-bounces at lists.linuxfoundation.org [mailto:fuego-bounces at lists.linuxfoundation.org] On Behalf Of Liu, Wenlong > > In general, I prefer things to be done as check_needs, which means they > > are declarative, rather than in test_pre_check, which, strictly speaking, > > is imperative. > > > > Having declarative dependencies means you can do a static dependency > > checker. But many times we want a dynamic check as well. For example, we may want to skip some tests if we don't have root permissions but still run the other tests. I was wondering if we could kill 2 birds (no pun intended) with one shot: - during the pre_check phase a script checks for variables that start with NEED_FOO - then, the script calls check_FOO() for each need. NEED_ROOT is currently being checked in a function called check_needs. Instead, we could define a functiona called "check_ROOT" and have it called automatically when NEED_ROOT=1 is declared on the script. The advantage of this approach, is that tests can still call "check_ROOT" dynamically. What do you think? Thanks, Daniel From daniel.sangorrin at toshiba.co.jp Fri Feb 2 07:34:56 2018 From: daniel.sangorrin at toshiba.co.jp (Daniel Sangorrin) Date: Fri, 2 Feb 2018 16:34:56 +0900 Subject: [Fuego] [PATCH 07/18] LTP: reduce the time required for two more tests In-Reply-To: References: <1517306376-6275-1-git-send-email-daniel.sangorrin@toshiba.co.jp> <1517306376-6275-8-git-send-email-daniel.sangorrin@toshiba.co.jp> <007701d39a53$f6093d00$e21bb700$@toshiba.co.jp> Message-ID: <007601d39bf8$52a29de0$f7e7d9a0$@toshiba.co.jp> > -----Original Message----- > From: Tim.Bird at sony.com [mailto:Tim.Bird at sony.com] > Sent: Thursday, February 01, 2018 4:41 AM > To: daniel.sangorrin at toshiba.co.jp; fuego at lists.linuxfoundation.org > Subject: RE: [Fuego] [PATCH 07/18] LTP: reduce the time required for two more tests > > > > > -----Original Message----- > > From: Daniel Sangorrin [mailto:daniel.sangorrin at toshiba.co.jp] > > > -----Original Message----- > > > From: Bird, Timothy [mailto:Tim.Bird at sony.com] > > > > -----Original Message----- > > > > From: Daniel Sangorrin > > > > > > > > Signed-off-by: Daniel Sangorrin > > > > --- > > > > engine/tests/Functional.LTP/fuego_test.sh | 2 ++ > > > > 1 file changed, 2 insertions(+) > > > > > > > > diff --git a/engine/tests/Functional.LTP/fuego_test.sh > > > > b/engine/tests/Functional.LTP/fuego_test.sh > > > > index 8278e98..ae85bac 100755 > > > > --- a/engine/tests/Functional.LTP/fuego_test.sh > > > > +++ b/engine/tests/Functional.LTP/fuego_test.sh > > > > @@ -190,6 +190,8 @@ function test_run { > > > > > > > > # we patch them here because of the different phases > > > > cmd "sed -i 's/^fork13 fork13 -i 1000000/fork13 fork13 -i 100000/' > > > > $LTP_DESTDIR/runtest/syscalls" > > > > + cmd "sed -i 's/^dio30 diotest6 -b 65536 -n 100 -i 100 -o 1024000/dio30 > > > > diotest6 -b 65536 -n 5 -i 100 -o 1024000/' $LTP_DESTDIR/runtest/dio" > > > > + cmd "sed -i 's/^msgctl11 msgctl11/msgctl11 msgctl11 -n 5/' > > > > $LTP_DESTDIR/runtest/syscalls" > > > > > > Can we make this dependent on some spec ARG, like > > > FUNCTIONAL_LTP_SHORT_RUN or something? > > > (other name suggestions are welcome.) > > > > > > I think in general, quite a few tests would benefit from > > > having a spec that allowed for a shorter version of the test > > > to run. > > > > Sure, good idea. > > OK. In the mean time, I've applied this patch. > > One issue with this is what happens if the sed line fails to find the match. > Does this end up causing the test to error out? Having full lines like this is > a bit fragile. If the arguments change upstream, this will break. > > I haven't tested it, but we might want something like the following: > cmd "sed -i 's/^dio30 diotest6 \(.*\) -n 100 \(.*\)/dio30 diotest6 \1 -n 5 \2/' $LTP_DESTDIR/runtest/dio" > > This preserves the other arguments, and only checks to change '-n 100' to '-n 5'. You are right. I will fix that. Thanks, Daniel > > -- Tim From daniel.sangorrin at toshiba.co.jp Fri Feb 2 07:42:51 2018 From: daniel.sangorrin at toshiba.co.jp (Daniel Sangorrin) Date: Fri, 2 Feb 2018 16:42:51 +0900 Subject: [Fuego] LTP prechecks In-Reply-To: References: <1517306376-6275-1-git-send-email-daniel.sangorrin@toshiba.co.jp> Message-ID: <007701d39bf9$6e0c2cd0$4a248670$@toshiba.co.jp> > -----Original Message----- > From: Bird, Timothy [mailto:Tim.Bird at sony.com] > Sent: Wednesday, January 31, 2018 2:16 PM > To: Daniel Sangorrin; fuego at lists.linuxfoundation.org > Subject: RE: [Fuego] LTP prechecks > > > > > -----Original Message----- > > From: Daniel Sangorrin > > Hi Tim, > > > > I send you a batch of patches that do various prechecks and > > autogenerate a skiplist when you run LTP on a target. > > The list is not exhausitive yet but I'd like to have a first > > review and hopefully have other members contribute with > > their experencies or knowledge. > > > > [PATCH 01/18] need_check: correct errata > > [PATCH 02/18] need_check: cache the kconfig file > > [PATCH 03/18] need_check: no need for testing if the file exists > > [PATCH 04/18] need_check: check_kconfig should return 1 on first > > The above were accepted. > > > [PATCH 05/18] LTP: we need root permissions > This one I had a question on - see my email. > > > [PATCH 06/18] LTP: patch runtests before running > > [PATCH 07/18] LTP: reduce the time required for two more tests > These two I also had questions on. In principle I like the approach > of getting rid of patches against the LTP source. > But please see my email. > > > [PATCH 08/18] LTP: put the skiplist on the log directory > > [PATCH 09/18] LTP: show the generated skiplist file on the jenkins > > [PATCH 10/18] LTP: skip a few problematic tests for now > > [PATCH 11/18] LTP: add tests to skip if tmp is mounted on tmpfs > > [PATCH 12/18] LTP: skip tests that depend on specific kernel commits > > [PATCH 13/18] LTP: skip tests depending on the architecture > > [PATCH 14/18] LTP: skip tests depending on the target kernel config > > [PATCH 15/18] LTP: skip tests that depend on unavailable commands > > [PATCH 16/18] LTP: skip tests depending on the config.h generated by > > [PATCH 17/18] LTP: add note about typical LTP build failure on arm > > [PATCH 18/18] LTP: remove trailing space > > I added all these, and will push to my 'master' branch shortly. > > I do have a few questions about whether putting some of these skips > into a spec file, that could be customized per board, would be better. > > I think I need to play around with it for a while to see if I like this style > of runtime determination of skiplist. > > Putting the skiplist in the list of files you can see from the interface is good. > Otherwise users might have a hard time figuring out what a test isn't showing > a status result for a particular run. That's a great idea. I will add a new variable "skipfile" so that instead of having to specify each test case one by one we can specify a file. This would be useful to make sure that you are always skipping the same tests. By the way, it seems that [PATCH 08/18] LTP: put the skiplist on the log directory didn't make it into your repository. Could you check that? Thanks a lot! Daniel From liuwl.fnst at cn.fujitsu.com Fri Feb 2 09:25:47 2018 From: liuwl.fnst at cn.fujitsu.com (Liu, Wenlong) Date: Fri, 2 Feb 2018 09:25:47 +0000 Subject: [Fuego] Add NEED_PROGRAM to need_check In-Reply-To: <007501d39bf7$a94cdad0$fbe69070$@toshiba.co.jp> References: <007501d39bf7$a94cdad0$fbe69070$@toshiba.co.jp> Message-ID: > -----Original Message----- > From: Daniel Sangorrin [mailto:daniel.sangorrin at toshiba.co.jp] > Sent: Friday, February 02, 2018 3:30 PM > To: Liu, Wenlong/? ?? ; Tim.Bird at sony.com; > fuego at lists.linuxfoundation.org > Subject: RE: [Fuego] Add NEED_PROGRAM to need_check > > Hi Tim, > > > -----Original Message----- > > From: fuego-bounces at lists.linuxfoundation.org > > [mailto:fuego-bounces at lists.linuxfoundation.org] On Behalf Of Liu, > > Wenlong > > > In general, I prefer things to be done as check_needs, which means > > > they are declarative, rather than in test_pre_check, which, strictly > > > speaking, is imperative. > > > > > > Having declarative dependencies means you can do a static dependency > > > checker. > > But many times we want a dynamic check as well. For example, we may want > to skip some tests if we don't have root permissions but still run the other > tests. > > I was wondering if we could kill 2 birds (no pun intended) with one shot: > - during the pre_check phase a script checks for variables that start with > NEED_FOO > - then, the script calls check_FOO() for each need. > > NEED_ROOT is currently being checked in a function called check_needs. > Instead, we could define a functiona called "check_ROOT" and have it called > automatically when NEED_ROOT=1 is declared on the script. The advantage > of this approach, is that tests can still call "check_ROOT" dynamically. > > What do you think? Sorry, let me say something here:-). We really need to check something dynamically. Daniel, is my understanding as below the same as you said? ... NEED_PROGRAM="foo1 foo2 foo3" -> static check function test_pre_check { if check_ROOT; then check_PROGRAM "foo4" || ABORT -> dynamic check; foo4 depends on the ROOT permission. else # add "foo4" related test to skip list or fail_ok_list. fi } ... But, maybe oneday we could also use declarative dependencies to do a dynamic check. Something like(just a draft below), ... NEED_PROGRAM="foo1 foo2 foo3" NEED_PROGRAM_dynamic="foo4, check_ROOT, test4" # if not ROOT permission, then skip test4 or add it to fail_ok_list # if ROOT permission but "foo4" not exist; then ABORT ... It may be more complex somewhere than the example above. But anyway, check_FOO() will be needed. Best regards Liu > Thanks, > Daniel > > > > > > > > > > From tuyen.hoangvan at toshiba-tsdv.com Mon Feb 5 12:24:18 2018 From: tuyen.hoangvan at toshiba-tsdv.com (Hoang Van Tuyen) Date: Mon, 5 Feb 2018 19:24:18 +0700 Subject: [Fuego] [PATCH] ftc: Correct info about using --where option Message-ID: <919792b5-4335-70d9-e957-54c0a31ea8ae@toshiba-tsdv.com> In list-runs and gen-report command_helps, It had examples for where option like below: --where test=Benchmark.bonnie,board=beaglebone But, the value of test should be bonnie, not include test type Benchmark. This patch updates the help to avoid misunderstanding for using --where option. Signed-off-by: Hoang Van Tuyen --- engine/scripts/ftc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/engine/scripts/ftc b/engine/scripts/ftc index bde3694..0d162e1 100755 --- a/engine/scripts/ftc +++ b/engine/scripts/ftc @@ -165,8 +165,8 @@ command_help = { Allowed operators are: '=','<','<=','>','>=','!=','=~'. The '=~' operator means the value is a regular expression to match, for the indicated field. Here are some example where options: - --where test=Functional.LTP - --where test=Benchmark.bonnie,board=beaglebone + --where test=LTP + --where test=bonnie,board=beaglebone --where "start_time>2 hours ago" """), @@ -312,8 +312,8 @@ the 'foo' function from the board file, you would use do this: Allowed operators are: '=','<','<=','>','>=','!=','=~'. The '=~' operator means the value is a regular expression to match, for the indicated field. Here are some example where options: - --where test=Functional.LTP - --where test=Benchmark.bonnie,board=beaglebone + --where test=LTP + --where test=bonnie,board=beaglebone --where "start_time>2 hours ago" --where batch_id=12 """), -- 2.1.4 -- ================================================================ Hoang Van Tuyen (Mr.) TOSHIBA SOFTWARE DEVELOPMENT (VIETNAM) CO., LTD. 16th Floor, VIT Building, 519 Kim Ma Str., Ba Dinh Dist., Hanoi, Vietnam Tel: 84-4-22208801 (Company) - Ext.251 Fax: 84-4-22208802 (Company) Email: tuyen.hoangvan at toshiba-tsdv.com ================================================================ -------------- next part -------------- From 0139ac5a91ae97e55b9e5e824ffe00db1a88a862 Mon Sep 17 00:00:00 2001 From: Hoang Van Tuyen Date: Mon, 5 Feb 2018 19:17:57 +0700 Subject: [PATCH] ftc: Correct info about using --where option In list-runs and gen-report command_helps, It had examples for where option like below: --where test=Benchmark.bonnie,board=beaglebone But, the value of test should be bonnie, not include test type Benchmark. This patch updates the help to avoid misunderstanding for using --where option. Signed-off-by: Hoang Van Tuyen --- engine/scripts/ftc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/engine/scripts/ftc b/engine/scripts/ftc index bde3694..0d162e1 100755 --- a/engine/scripts/ftc +++ b/engine/scripts/ftc @@ -165,8 +165,8 @@ command_help = { Allowed operators are: '=','<','<=','>','>=','!=','=~'. The '=~' operator means the value is a regular expression to match, for the indicated field. Here are some example where options: - --where test=Functional.LTP - --where test=Benchmark.bonnie,board=beaglebone + --where test=LTP + --where test=bonnie,board=beaglebone --where "start_time>2 hours ago" """), @@ -312,8 +312,8 @@ the 'foo' function from the board file, you would use do this: Allowed operators are: '=','<','<=','>','>=','!=','=~'. The '=~' operator means the value is a regular expression to match, for the indicated field. Here are some example where options: - --where test=Functional.LTP - --where test=Benchmark.bonnie,board=beaglebone + --where test=LTP + --where test=bonnie,board=beaglebone --where "start_time>2 hours ago" --where batch_id=12 """), -- 2.1.4 -------------- next part -------------- -- This mail was scanned by BitDefender For more information please visit http://www.bitdefender.com From daniel.sangorrin at toshiba.co.jp Tue Feb 6 05:43:59 2018 From: daniel.sangorrin at toshiba.co.jp (Daniel Sangorrin) Date: Tue, 6 Feb 2018 14:43:59 +0900 Subject: [Fuego] Add NEED_PROGRAM to need_check In-Reply-To: References: <007501d39bf7$a94cdad0$fbe69070$@toshiba.co.jp> Message-ID: <003901d39f0d$7cad9be0$7608d3a0$@toshiba.co.jp> Hi Liu, > -----Original Message----- > From: Liu, Wenlong [mailto:liuwl.fnst at cn.fujitsu.com] > Sent: Friday, February 02, 2018 6:26 PM > To: Daniel Sangorrin; Tim.Bird at sony.com; fuego at lists.linuxfoundation.org > Subject: RE: [Fuego] Add NEED_PROGRAM to need_check > > > > -----Original Message----- > > From: Daniel Sangorrin [mailto:daniel.sangorrin at toshiba.co.jp] > > Sent: Friday, February 02, 2018 3:30 PM > > To: Liu, Wenlong/? ?? ; Tim.Bird at sony.com; > > fuego at lists.linuxfoundation.org > > Subject: RE: [Fuego] Add NEED_PROGRAM to need_check > > > > Hi Tim, > > > > > -----Original Message----- > > > From: fuego-bounces at lists.linuxfoundation.org > > > [mailto:fuego-bounces at lists.linuxfoundation.org] On Behalf Of Liu, > > > Wenlong > > > > In general, I prefer things to be done as check_needs, which means > > > > they are declarative, rather than in test_pre_check, which, strictly > > > > speaking, is imperative. > > > > > > > > Having declarative dependencies means you can do a static dependency > > > > checker. > > > > But many times we want a dynamic check as well. For example, we may want > > to skip some tests if we don't have root permissions but still run the other > > tests. > > > > I was wondering if we could kill 2 birds (no pun intended) with one shot: > > - during the pre_check phase a script checks for variables that start with > > NEED_FOO > > - then, the script calls check_FOO() for each need. > > > > NEED_ROOT is currently being checked in a function called check_needs. > > Instead, we could define a functiona called "check_ROOT" and have it called > > automatically when NEED_ROOT=1 is declared on the script. The advantage > > of this approach, is that tests can still call "check_ROOT" dynamically. > > > > What do you think? > > Sorry, let me say something here:-). > We really need to check something dynamically. > Daniel, is my understanding as below the same as you said? > ... > NEED_PROGRAM="foo1 foo2 foo3" -> static check > > function test_pre_check { > if check_ROOT; then > check_PROGRAM "foo4" || ABORT -> dynamic check; foo4 depends on the ROOT permission. > else > # add "foo4" related test to skip list or fail_ok_list. > fi > } > ... Yes, something like that would work for me. > But, maybe oneday we could also use declarative dependencies to do a dynamic check. > Something like(just a draft below), > ... > NEED_PROGRAM="foo1 foo2 foo3" > NEED_PROGRAM_dynamic="foo4, check_ROOT, test4" > # if not ROOT permission, then skip test4 or add it to fail_ok_list > # if ROOT permission but "foo4" not exist; then ABORT > ... > It may be more complex somewhere than the example above. But anyway, check_FOO() will be needed. Mmm I think that it would be hard to create something generic that works for all tests with that approach. Thanks, Daniel > > Best regards > Liu > > > Thanks, > > Daniel > > > > > > > > > > > > > > > > > > > > > > From daniel.sangorrin at toshiba.co.jp Tue Feb 6 08:06:51 2018 From: daniel.sangorrin at toshiba.co.jp (Daniel Sangorrin) Date: Tue, 6 Feb 2018 17:06:51 +0900 Subject: [Fuego] [PATCH 4/5] LTP: fix problem with tests skipped during build In-Reply-To: <1517904412-37193-1-git-send-email-daniel.sangorrin@toshiba.co.jp> References: <1517904412-37193-1-git-send-email-daniel.sangorrin@toshiba.co.jp> Message-ID: <1517904412-37193-5-git-send-email-daniel.sangorrin@toshiba.co.jp> Tests skipped during the build phase get ignored on the second run because build is not called so save them on a different file. Signed-off-by: Daniel Sangorrin --- engine/tests/Functional.LTP/fuego_test.sh | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/engine/tests/Functional.LTP/fuego_test.sh b/engine/tests/Functional.LTP/fuego_test.sh index a4df442..abddf54 100755 --- a/engine/tests/Functional.LTP/fuego_test.sh +++ b/engine/tests/Functional.LTP/fuego_test.sh @@ -120,7 +120,7 @@ function skip_if_config_unavailable { if ! grep "#define $CONFIG" ${WORKSPACE}/${JOB_BUILD_DIR}/include/config.h; then echo "WARNING: $CONFIG is not available." - skip_tests "${TESTS}" + skip_tests "${TESTS}" "${WORKSPACE}/${JOB_BUILD_DIR}/buildskipfile.txt" if [ -n "$MSG" ]; then echo "$MSG" fi @@ -296,6 +296,9 @@ function test_build { cp $TEST_HOME/ltp_target_run.sh target_bin else echo "Skipping LTP build" + if [ -f "${WORKSPACE}/${JOB_BUILD_DIR}/buildskipfile.txt" ]; then + cat "${WORKSPACE}/${JOB_BUILD_DIR}/buildskipfile.txt" >> ${LOGDIR}/skiplist.txt + fi fi } -- 2.7.4 From daniel.sangorrin at toshiba.co.jp Tue Feb 6 08:06:48 2018 From: daniel.sangorrin at toshiba.co.jp (Daniel Sangorrin) Date: Tue, 6 Feb 2018 17:06:48 +0900 Subject: [Fuego] [PATCH 1/5] LTP: add rt parsing In-Reply-To: <1517904412-37193-1-git-send-email-daniel.sangorrin@toshiba.co.jp> References: <1517904412-37193-1-git-send-email-daniel.sangorrin@toshiba.co.jp> Message-ID: <1517904412-37193-2-git-send-email-daniel.sangorrin@toshiba.co.jp> Previously I had added rt parsing for ltp_process.py but not for the general parser. Signed-off-by: Daniel Sangorrin --- engine/tests/Functional.LTP/parser.py | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/engine/tests/Functional.LTP/parser.py b/engine/tests/Functional.LTP/parser.py index f9cc234..2dc44a8 100755 --- a/engine/tests/Functional.LTP/parser.py +++ b/engine/tests/Functional.LTP/parser.py @@ -204,6 +204,22 @@ for line in lines: # hope no posix tests have the same test_ids as regular tests test_results.update(posix_results) +if os.path.exists('rt.log'): + rt_results = {} + with open('rt.log') as f: + rt_testcase_regex = "^--- Running testcase (.*) ---$" + rt_results_regex = "^\s*Result:\s*(.*)$" + for line in f: + m = re.match(rt_testcase_regex, line.rstrip()) + if m: + test_case = m.group(1) + m = re.match(rt_results_regex, line.rstrip()) + if m: + test_result = m.group(1) + test_id = "rt." + test_case + rt_results[test_id] = test_result + test_results.update(rt_results) + os.chdir(SAVEDIR) sys.exit(plib.process(test_results)) -- 2.7.4 From daniel.sangorrin at toshiba.co.jp Tue Feb 6 08:06:52 2018 From: daniel.sangorrin at toshiba.co.jp (Daniel Sangorrin) Date: Tue, 6 Feb 2018 17:06:52 +0900 Subject: [Fuego] [PATCH 5/5] LTP: allow using a file to specify the list of tests to skip In-Reply-To: <1517904412-37193-1-git-send-email-daniel.sangorrin@toshiba.co.jp> References: <1517904412-37193-1-git-send-email-daniel.sangorrin@toshiba.co.jp> Message-ID: <1517904412-37193-6-git-send-email-daniel.sangorrin@toshiba.co.jp> This feature was proposed by Tim Bird. Signed-off-by: Daniel Sangorrin --- engine/tests/Functional.LTP/fuego_test.sh | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/engine/tests/Functional.LTP/fuego_test.sh b/engine/tests/Functional.LTP/fuego_test.sh index abddf54..de9ed27 100755 --- a/engine/tests/Functional.LTP/fuego_test.sh +++ b/engine/tests/Functional.LTP/fuego_test.sh @@ -303,11 +303,17 @@ function test_build { } function test_deploy { - # generate the skip list for this test - echo "# skip these test cases" > skiplist.txt + # Add tests to skip if "skiplist" is defined on the spec. The "skiplist" + # can contain LTP test_case names (e.g.: inotify06) and/or absolute path(s) + # to skipfiles (text files containing a list of LTP test case names) + # usually located under /fuego-rw/boards/ if [ -n "${FUNCTIONAL_LTP_SKIPLIST}" ]; then - for item in $FUNCTIONAL_LTP_SKIPLIST; do - echo "$item" >> ${LOGDIR}/skiplist.txt + for item in "${FUNCTIONAL_LTP_SKIPLIST}"; do + if [ -f "$item" ]; then + cat "$item" >> ${LOGDIR}/skiplist.txt + else + echo "$item" >> ${LOGDIR}/skiplist.txt + fi done fi -- 2.7.4 From daniel.sangorrin at toshiba.co.jp Tue Feb 6 08:06:50 2018 From: daniel.sangorrin at toshiba.co.jp (Daniel Sangorrin) Date: Tue, 6 Feb 2018 17:06:50 +0900 Subject: [Fuego] [PATCH 3/5] LTP: allow specifying the location for the skipfile In-Reply-To: <1517904412-37193-1-git-send-email-daniel.sangorrin@toshiba.co.jp> References: <1517904412-37193-1-git-send-email-daniel.sangorrin@toshiba.co.jp> Message-ID: <1517904412-37193-4-git-send-email-daniel.sangorrin@toshiba.co.jp> This will be used on the next patch. Signed-off-by: Daniel Sangorrin --- engine/tests/Functional.LTP/fuego_test.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/engine/tests/Functional.LTP/fuego_test.sh b/engine/tests/Functional.LTP/fuego_test.sh index 15bf0fb..a4df442 100755 --- a/engine/tests/Functional.LTP/fuego_test.sh +++ b/engine/tests/Functional.LTP/fuego_test.sh @@ -81,15 +81,17 @@ func/sched_jitter # FUNCTIONAL_LTP_HOMEDIR var # $1: string with tests to skip separated by spaces +# $2: absolute path to the skipfile (default: ${LOGDIR}/skiplist.txt) function skip_tests { # split $1 on whitespace, without file globbing set -f local TESTS=($1) + local SKIPFILE="${2:-${LOGDIR}/skiplist.txt}" set +f echo "Skipping tests: ${TESTS[@]}." for testname in "${TESTS[@]}"; do - echo "$testname" >> ${LOGDIR}/skiplist.txt + echo "$testname" >> ${SKIPFILE} done } -- 2.7.4 From daniel.sangorrin at toshiba.co.jp Tue Feb 6 08:06:47 2018 From: daniel.sangorrin at toshiba.co.jp (Daniel Sangorrin) Date: Tue, 6 Feb 2018 17:06:47 +0900 Subject: [Fuego] LTP: new batch of patches Message-ID: <1517904412-37193-1-git-send-email-daniel.sangorrin@toshiba.co.jp> Hi Tim, A few more patches. I will work on the modifications you proposed too soon. [PATCH 1/5] LTP: add rt parsing [PATCH 2/5] LTP: put the skiplist on the logdir [PATCH 3/5] LTP: allow specifying the location for the skipfile [PATCH 4/5] LTP: fix problem with tests skipped during build [PATCH 5/5] LTP: allow using a file to specify the list of tests to Regards, Daniel From daniel.sangorrin at toshiba.co.jp Tue Feb 6 08:06:49 2018 From: daniel.sangorrin at toshiba.co.jp (Daniel Sangorrin) Date: Tue, 6 Feb 2018 17:06:49 +0900 Subject: [Fuego] [PATCH 2/5] LTP: put the skiplist on the logdir In-Reply-To: <1517904412-37193-1-git-send-email-daniel.sangorrin@toshiba.co.jp> References: <1517904412-37193-1-git-send-email-daniel.sangorrin@toshiba.co.jp> Message-ID: <1517904412-37193-3-git-send-email-daniel.sangorrin@toshiba.co.jp> Note: this is a re-send because the patch didn't make it. Signed-off-by: Daniel Sangorrin --- engine/tests/Functional.LTP/fuego_test.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/engine/tests/Functional.LTP/fuego_test.sh b/engine/tests/Functional.LTP/fuego_test.sh index 9d2fbb0..15bf0fb 100755 --- a/engine/tests/Functional.LTP/fuego_test.sh +++ b/engine/tests/Functional.LTP/fuego_test.sh @@ -302,7 +302,7 @@ function test_deploy { echo "# skip these test cases" > skiplist.txt if [ -n "${FUNCTIONAL_LTP_SKIPLIST}" ]; then for item in $FUNCTIONAL_LTP_SKIPLIST; do - echo $item >> skiplist.txt + echo "$item" >> ${LOGDIR}/skiplist.txt done fi @@ -319,7 +319,7 @@ function test_deploy { awk '/^[^#]/ { print "rm -f ltp/testcases/bin/" $2 }' ltp/runtest/syscalls | sh fi - cp skiplist.txt ltp + cp ${LOGDIR}/skiplist.txt ltp put ltp/* $LTP_DESTDIR rm -rf ltp @@ -340,7 +340,7 @@ function test_deploy { cmd "mkdir -p $FUNCTIONAL_LTP_HOMEDIR/testcases/realtime/scripts" put testcases/realtime/scripts/setenv.sh $FUNCTIONAL_LTP_HOMEDIR/testcases/realtime/scripts put $TEST_HOME/ltp_target_run.sh $FUNCTIONAL_LTP_HOMEDIR - put skiplist.txt $FUNCTIONAL_LTP_HOMEDIR + put ${LOGDIR}/skiplist.txt $FUNCTIONAL_LTP_HOMEDIR fi } -- 2.7.4 From Tim.Bird at sony.com Wed Feb 7 00:33:36 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Wed, 7 Feb 2018 00:33:36 +0000 Subject: [Fuego] LTP prechecks In-Reply-To: <007701d39bf9$6e0c2cd0$4a248670$@toshiba.co.jp> References: <1517306376-6275-1-git-send-email-daniel.sangorrin@toshiba.co.jp> <007701d39bf9$6e0c2cd0$4a248670$@toshiba.co.jp> Message-ID: > -----Original Message----- > From: Daniel Sangorrin [mailto:daniel.sangorrin at toshiba.co.jp] ... > By the way, it seems that > [PATCH 08/18] LTP: put the skiplist on the log directory > didn't make it into your repository. > > Could you check that? You're right. I missed that one! Applied and pushed. Sorry about that. -- Tim From Tim.Bird at sony.com Wed Feb 7 00:42:20 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Wed, 7 Feb 2018 00:42:20 +0000 Subject: [Fuego] Add NEED_PROGRAM to need_check In-Reply-To: <007501d39bf7$a94cdad0$fbe69070$@toshiba.co.jp> References: <007501d39bf7$a94cdad0$fbe69070$@toshiba.co.jp> Message-ID: > -----Original Message----- > From: Daniel Sangorrin > > Hi Tim, > > > -----Original Message----- > > From: fuego-bounces at lists.linuxfoundation.org [mailto:fuego- > bounces at lists.linuxfoundation.org] On Behalf Of Liu, Wenlong > > > In general, I prefer things to be done as check_needs, which means they > > > are declarative, rather than in test_pre_check, which, strictly speaking, > > > is imperative. > > > > > > Having declarative dependencies means you can do a static dependency > > > checker. > > But many times we want a dynamic check as well. For example, we may want > to > skip some tests if we don't have root permissions but still run the other tests. > > I was wondering if we could kill 2 birds (no pun intended) with one shot: Personally, I've never cared for that expression. ;-) > - during the pre_check phase a script checks for variables that start with > NEED_FOO > - then, the script calls check_FOO() for each need. > > NEED_ROOT is currently being checked in a function called check_needs. > Instead, > we could define a functiona called "check_ROOT" and have it called > automatically > when NEED_ROOT=1 is declared on the script. The advantage of this > approach, is > that tests can still call "check_ROOT" dynamically. > > What do you think? I don't mind restructuring the code so that some of these dependencies could be called both explicitly and implicitly. However, I think the mixed case is a bit ugly, and I'd rather we just used: check_root, and NEED_ROOT. -- Tim From Tim.Bird at sony.com Wed Feb 7 01:14:51 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Wed, 7 Feb 2018 01:14:51 +0000 Subject: [Fuego] [PATCH] ftc: Correct info about using --where option In-Reply-To: <919792b5-4335-70d9-e957-54c0a31ea8ae@toshiba-tsdv.com> References: <919792b5-4335-70d9-e957-54c0a31ea8ae@toshiba-tsdv.com> Message-ID: > -----Original Message----- > From: Hoang Van Tuyen > > In list-runs and gen-report command_helps, It had examples for where > option > like below: > --where test=Benchmark.bonnie,board=beaglebone > But, the value of test should be bonnie, not include test type Benchmark. > This patch updates the help to avoid misunderstanding for using --where > option. Thanks. I knew about this problem for some time, but did nothing to fix it. I applied this patch, and in another patch, made a change to ftc to allow specifying either just the base name of the test, or the full name - with "Benchmark." or "Functional." prefix. There are some tests with the same test name (such as Benchmark.netperf and Functional.netperf), so just specifying the base test name might not show you what you want. Now you can do: --where test=Functional.netperf or --where test=netperf The second one will show both Functional and Benchmark results. Applied. Thanks, -- Tim > Signed-off-by: Hoang Van Tuyen > --- > engine/scripts/ftc | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/engine/scripts/ftc b/engine/scripts/ftc > index bde3694..0d162e1 100755 > --- a/engine/scripts/ftc > +++ b/engine/scripts/ftc > @@ -165,8 +165,8 @@ command_help = { > Allowed operators are: '=','<','<=','>','>=','!=','=~'. The '=~' > operator > means the value is a regular expression to match, for the indicated > field. > Here are some example where options: > - --where test=Functional.LTP > - --where test=Benchmark.bonnie,board=beaglebone > + --where test=LTP > + --where test=bonnie,board=beaglebone > --where "start_time>2 hours ago" > """), > > @@ -312,8 +312,8 @@ the 'foo' function from the board file, you would > use do this: > Allowed operators are: '=','<','<=','>','>=','!=','=~'. The '=~' > operator > means the value is a regular expression to match, for the indicated > field. > Here are some example where options: > - --where test=Functional.LTP > - --where test=Benchmark.bonnie,board=beaglebone > + --where test=LTP > + --where test=bonnie,board=beaglebone > --where "start_time>2 hours ago" > --where batch_id=12 > """), > -- > 2.1.4 From Tim.Bird at sony.com Wed Feb 7 01:56:41 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Wed, 7 Feb 2018 01:56:41 +0000 Subject: [Fuego] LTP: new batch of patches In-Reply-To: <1517904412-37193-1-git-send-email-daniel.sangorrin@toshiba.co.jp> References: <1517904412-37193-1-git-send-email-daniel.sangorrin@toshiba.co.jp> Message-ID: Some comments here to save from having to respond individually. > -----Original Message----- > From: Daniel Sangorrin > > Hi Tim, > > A few more patches. I will work on the modifications you proposed too soon. These look good. > > [PATCH 1/5] LTP: add rt parsing > [PATCH 2/5] LTP: put the skiplist on the logdir Wish I had read ahead in my e-mail. I put this in ahead of the other 1/5, based on your earlier e-mail that I missed it. But I don't think patch order matters here. > [PATCH 3/5] LTP: allow specifying the location for the skipfile > [PATCH 4/5] LTP: fix problem with tests skipped during build > [PATCH 5/5] LTP: allow using a file to specify the list of tests to > Looks good. Applied. -- Tim From daniel.sangorrin at toshiba.co.jp Wed Feb 7 01:57:09 2018 From: daniel.sangorrin at toshiba.co.jp (Daniel Sangorrin) Date: Wed, 7 Feb 2018 10:57:09 +0900 Subject: [Fuego] Add NEED_PROGRAM to need_check In-Reply-To: References: <007501d39bf7$a94cdad0$fbe69070$@toshiba.co.jp> Message-ID: <003c01d39fb6$f6e6ee30$e4b4ca90$@toshiba.co.jp> > -----Original Message----- > From: Tim.Bird at sony.com [mailto:Tim.Bird at sony.com] > Sent: Wednesday, February 07, 2018 9:42 AM > To: daniel.sangorrin at toshiba.co.jp; liuwl.fnst at cn.fujitsu.com; fuego at lists.linuxfoundation.org > Subject: RE: [Fuego] Add NEED_PROGRAM to need_check > > > > > -----Original Message----- > > From: Daniel Sangorrin > > > > Hi Tim, > > > > > -----Original Message----- > > > From: fuego-bounces at lists.linuxfoundation.org [mailto:fuego- > > bounces at lists.linuxfoundation.org] On Behalf Of Liu, Wenlong > > > > In general, I prefer things to be done as check_needs, which means they > > > > are declarative, rather than in test_pre_check, which, strictly speaking, > > > > is imperative. > > > > > > > > Having declarative dependencies means you can do a static dependency > > > > checker. > > > > But many times we want a dynamic check as well. For example, we may want > > to > > skip some tests if we don't have root permissions but still run the other tests. > > > > I was wondering if we could kill 2 birds (no pun intended) with one shot: > Personally, I've never cared for that expression. ;-) > > > - during the pre_check phase a script checks for variables that start with > > NEED_FOO > > - then, the script calls check_FOO() for each need. > > > > NEED_ROOT is currently being checked in a function called check_needs. > > Instead, > > we could define a functiona called "check_ROOT" and have it called > > automatically > > when NEED_ROOT=1 is declared on the script. The advantage of this > > approach, is > > that tests can still call "check_ROOT" dynamically. > > > > What do you think? > > I don't mind restructuring the code so that some of these dependencies > could be called both explicitly and implicitly. However, I think the mixed > case is a bit ugly, and I'd rather we just used: > check_root, and NEED_ROOT. OK. Actually, I realized that check_needs is already calling to the corresponding check_xxx function so both explicit and implicit calls are currently supported. I was thinking that check_needs could be rewritten with a more object-oriented approach. But I should rather focus on fixing more important stuff. Thanks, Daniel From Tim.Bird at sony.com Wed Feb 7 03:16:55 2018 From: Tim.Bird at sony.com (Bird, Timothy) Date: Wed, 7 Feb 2018 03:16:55 +0000 Subject: [Fuego] Add NEED_PROGRAM to need_check In-Reply-To: References: Message-ID: Applied and pushed. Thanks, -- Tim > -----Original Message----- > From: fuego-bounces at lists.linuxfoundation.org [mailto:fuego- > bounces at lists.linuxfoundation.org] On Behalf Of Liu, Wenlong > Sent: Tuesday, January 30, 2018 11:58 PM > To: fuego at lists.linuxfoundation.org > Subject: [Fuego] Add NEED_PROGRAM to need_check > > Hi Tim, Daniel and other friends > > > > I didn't add the contents of the attachments in this mail, because I just want > to confirm > > that if it will be better to move those check steps from pre_check to > check_needs. > > > > If I'm not mistaken, we've talked about it on the maillist before, but I can't > find that mail now. > > > > Best regards > > Liu > > From Tim.Bird at sony.com Wed Feb 7 03:26:04 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Wed, 7 Feb 2018 03:26:04 +0000 Subject: [Fuego] Split the output and add log links for each testcase In-Reply-To: References: Message-ID: Liu, Just double-checking... Are you planning on submitting this whole series again? I like the feature, but lost track of the status. Thanks, -- Tim > -----Original Message----- > From: Liu, Wenlong > > Functional.LTP has heavy outputs after testing, which makes it difficult for us > to locate the error log easily. > > > > LTP has the feature that can help us to split the output for different > testcases. > > So, I added some links to those separated log files in the test case summary > page. > > It helped me a lot to investigate different failures. > > > > Now, I also added a generic function to split the output for different tests > and try to apply it to different tests. > > Please review the patch[01-09] in the maillist. From Tim.Bird at sony.com Wed Feb 7 04:04:18 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Wed, 7 Feb 2018 04:04:18 +0000 Subject: [Fuego] [PATCH v2] need_check: add linux distro automatic detection In-Reply-To: <1515721962-6252-1-git-send-email-daniel.sangorrin@toshiba.co.jp> References: <1515721962-6252-1-git-send-email-daniel.sangorrin@toshiba.co.jp> Message-ID: OK - it should be obvious by now that I'm going back and catching up on old e-mails that I should have applied weeks ago. Sorry for the delay. Some of these outstanding patches fell through the cracks. This is now applied. Thanks, -- Tim > -----Original Message----- > From: Daniel Sangorrin on Thursday, January 11, 2018 5:53 PM > > This function can be used by tests that need to know the > distribution in the target board. The automatic detection > can be disabled/overriden by manually setting the variables > BOARD_DISTRO_ID and BOARD_DISTRO_VERSION_ID in the board > file. > > IMPORTANT: this is not a substitute for individual command > checks. For example, even if the BOARD_DISTRO_ID is "debian" > test writers should still check for the existance of "apt-get" > in case they want to use it. > > Signed-off-by: Daniel Sangorrin > --- > engine/scripts/need_check.sh | 27 +++++++++++++++++++++++++++ > 1 file changed, 27 insertions(+) > > diff --git a/engine/scripts/need_check.sh b/engine/scripts/need_check.sh > index 1fd6d6d..2b00d46 100755 > --- a/engine/scripts/need_check.sh > +++ b/engine/scripts/need_check.sh > @@ -123,6 +123,33 @@ function get_free_storage { > echo $result > } > > +# This function detects the Linux distribution used on the target board and > +# exports the following variables: > +# BOARD_DISTRO_ID (e.g. ubuntu, debian, centos) > +# BOARD_DISTRO_VERSION_ID (e.g. "16.04", "8", "7") > +# > +# If the distribution cannot be automatically detected it will return 1. > +# Defining BOARD_DISTRO_ID and BOARD_DISTRO_VERSION_ID on the > board file > +# disables automatic detection. > +function check_distro { > + if [ -z "$BOARD_DISTRO_ID" ] || [ -z "$BOARD_DISTRO_VERSION_ID" ]; > then > + os_release_tmpfile=$(mktemp) > + if get "/etc/os-release" $os_release_tmpfile ; then > + export BOARD_DISTRO_ID="$(grep ^ID= $os_release_tmpfile | cut -c > 4-)" > + export BOARD_DISTRO_VERSION_ID="$(grep ^VERSION_ID= > $os_release_tmpfile | cut -c 12-)" > + fi > + rm $os_release_tmpfile > + fi > + > + if [ -z "$BOARD_DISTRO_ID" ] || [ -z "$BOARD_DISTRO_VERSION_ID" ]; > then > + echo "ERROR: could not detect the distribution running on the board." > + echo "Define BOARD_DISTRO_ID and BOARD_DISTRO_VERSION_ID in > your board file." > + return 1 > + else > + echo "Board distribution is $BOARD_DISTRO_ID > $BOARD_DISTRO_VERSION_ID" > + fi > +} > + > # $1 has a single string holding a space-separated args: > # arg1 = size > # arg2 = directory to check > -- > 2.7.4 > > > _______________________________________________ > Fuego mailing list > Fuego at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/fuego From tuyen.hoangvan at toshiba-tsdv.com Wed Feb 7 07:36:22 2018 From: tuyen.hoangvan at toshiba-tsdv.com (Hoang Van Tuyen) Date: Wed, 7 Feb 2018 14:36:22 +0700 Subject: [Fuego] [PATCH] hwlatdetect: Add a new test program for rt-tests Message-ID: <3a191302-89f8-7a5c-c1ba-2fba9e24ea53@toshiba-tsdv.com> The hwlatdetect is a program to control the kernel hardware latency detection module. Target boards have to support hwlat_detector module. Signed-off-by: Hoang Van Tuyen --- ...1-hwlatdetect-cleaned-up-exception-raises.patch | 37 ++++++++++++++++++++++ .../tests/Benchmark.hwlatdetect/chart_config.json | 4 +++ engine/tests/Benchmark.hwlatdetect/criteria.json | 12 +++++++ engine/tests/Benchmark.hwlatdetect/fuego_test.sh | 23 ++++++++++++++ engine/tests/Benchmark.hwlatdetect/parser.py | 13 ++++++++ engine/tests/Benchmark.hwlatdetect/reference.json | 18 +++++++++++ engine/tests/Benchmark.hwlatdetect/spec.json | 14 ++++++++ 7 files changed, 121 insertions(+) create mode 100644 engine/tests/Benchmark.hwlatdetect/0001-hwlatdetect-cleaned-up-exception-raises.patch create mode 100644 engine/tests/Benchmark.hwlatdetect/chart_config.json create mode 100644 engine/tests/Benchmark.hwlatdetect/criteria.json create mode 100755 engine/tests/Benchmark.hwlatdetect/fuego_test.sh create mode 100755 engine/tests/Benchmark.hwlatdetect/parser.py create mode 100644 engine/tests/Benchmark.hwlatdetect/reference.json create mode 100644 engine/tests/Benchmark.hwlatdetect/spec.json diff --git a/engine/tests/Benchmark.hwlatdetect/0001-hwlatdetect-cleaned-up-exception-raises.patch b/engine/tests/Benchmark.hwlatdetect/0001-hwlatdetect-cleaned-up-exception-raises.patch new file mode 100644 index 0000000..23b5e96 --- /dev/null +++ b/engine/tests/Benchmark.hwlatdetect/0001-hwlatdetect-cleaned-up-exception-raises.patch @@ -0,0 +1,37 @@ +From 679c56ddcf83c67517d208d0fe9c60cdc45606d0 Mon Sep 17 00:00:00 2001 +From: Hoang Van Tuyen +Date: Wed, 7 Feb 2018 11:42:56 +0700 +Subject: [PATCH] hwlatdetect: cleaned up exception raises + +Fix issue: TypeError: raise: arg 3 must be a traceback or None +and correct typing mistake by using Hwlat instead of HwLat + +Signed-off-by: Hoang Van Tuyen +--- + src/hwlatdetect/hwlatdetect.py | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/src/hwlatdetect/hwlatdetect.py b/src/hwlatdetect/hwlatdetect.py +index 5ebd4f1..5106bfb 100755 +--- a/src/hwlatdetect/hwlatdetect.py ++++ b/src/hwlatdetect/hwlatdetect.py +@@ -306,7 +306,7 @@ class Tracer(Detector): + super(Tracer, self).__init__() + path = self.debugfs.getpath('tracing/hwlat_detector') + if not os.path.exists(path): +- raise DetectorNotAvailable, "hwlat", "hwlat tracer not available" ++ raise DetectorNotAvailable("hwlat", "hwlat tracer not available") + self.type = "tracer" + self.samples = [] + self.set("enable", 0) +@@ -545,7 +545,7 @@ if __name__ == '__main__': + try: + detect = Tracer() + except DetectorNotAvailable, err: +- detect = HwLat() ++ detect = Hwlat() + + if o.threshold: + t = microseconds(o.threshold) +-- +2.1.4 diff --git a/engine/tests/Benchmark.hwlatdetect/chart_config.json b/engine/tests/Benchmark.hwlatdetect/chart_config.json new file mode 100644 index 0000000..71c8238 --- /dev/null +++ b/engine/tests/Benchmark.hwlatdetect/chart_config.json @@ -0,0 +1,4 @@ +{ + "chart_type": "measure_plot", + "measures": ["default.latencies.max_latency"] +} diff --git a/engine/tests/Benchmark.hwlatdetect/criteria.json b/engine/tests/Benchmark.hwlatdetect/criteria.json new file mode 100644 index 0000000..0520968 --- /dev/null +++ b/engine/tests/Benchmark.hwlatdetect/criteria.json @@ -0,0 +1,12 @@ +{ + "schema_version":"1.0", + "criteria":[ + { + "tguid":"default.latencies.max_latency", + "reference":{ + "value":15000, + "operator":"le" + } + } + ] +} diff --git a/engine/tests/Benchmark.hwlatdetect/fuego_test.sh b/engine/tests/Benchmark.hwlatdetect/fuego_test.sh new file mode 100755 index 0000000..d1ab59e --- /dev/null +++ b/engine/tests/Benchmark.hwlatdetect/fuego_test.sh @@ -0,0 +1,23 @@ +tarball=../rt-tests/rt-tests-v1.1.1.tar.gz + +# This test requires the hwlat_detector driver. +# The hwlatdetect executable test file have many actions for checking and loading +# the hwlat_detector. So, We do not add a pre_check for hwlat_detector driver. +NEED_ROOT=1 +function test_pre_check { + assert_define BENCHMARK_HWLATDETECT_PARAMS +} + +function test_build { + patch -p1 -N -s < $TEST_HOME/../rt-tests/0001-Add-scheduling-policies-for-old-kernels.patch + patch -p1 -N -s < $TEST_HOME/0001-hwlatdetect-cleaned-up-exception-raises.patch + make hwlatdetect +} + +function test_deploy { + put hwlatdetect $BOARD_TESTDIR/fuego.$TESTDIR/ +} + +function test_run { + report "cd $BOARD_TESTDIR/fuego.$TESTDIR; ./hwlatdetect $BENCHMARK_HWLATDETECT_PARAMS" +} diff --git a/engine/tests/Benchmark.hwlatdetect/parser.py b/engine/tests/Benchmark.hwlatdetect/parser.py new file mode 100755 index 0000000..32c23ce --- /dev/null +++ b/engine/tests/Benchmark.hwlatdetect/parser.py @@ -0,0 +1,13 @@ +#!/usr/bin/python +import os, re, sys +sys.path.insert(0, os.environ['FUEGO_CORE'] + '/engine/scripts/parser') +import common as plib + +regex_string = "^Max Latency:\s+(\d+)us" +measurements = {} +matches = plib.parse_log(regex_string) + +if matches: + measurements['default.latencies'] = [{"name": "max_latency", "measure" : float(matches[0])}] + +sys.exit(plib.process(measurements)) diff --git a/engine/tests/Benchmark.hwlatdetect/reference.json b/engine/tests/Benchmark.hwlatdetect/reference.json new file mode 100644 index 0000000..ba61c77 --- /dev/null +++ b/engine/tests/Benchmark.hwlatdetect/reference.json @@ -0,0 +1,18 @@ +{ + "test_sets":[ + { + "name":"default", + "test_cases":[ + { + "name":"latencies", + "measurements":[ + { + "name":"max_latency", + "unit":"us" + } + ] + } + ] + } + ] +} diff --git a/engine/tests/Benchmark.hwlatdetect/spec.json b/engine/tests/Benchmark.hwlatdetect/spec.json new file mode 100644 index 0000000..c59f5ff --- /dev/null +++ b/engine/tests/Benchmark.hwlatdetect/spec.json @@ -0,0 +1,14 @@ +{ + "testName": "Benchmark.hwlatdetect", + "specs": { + "default": { + "PARAMS": "--duration=1m --hardlimit=15000" + }, + "latest": { + "PER_JOB_BUILD": "true", + "gitrepo": "https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git", + "gitref": "unstable/devel/v1.1.1", + "PARAMS": "--duration=1m --report=smi.txt" + } + } +} -- 2.1.4 -- ================================================================ Hoang Van Tuyen (Mr.) TOSHIBA SOFTWARE DEVELOPMENT (VIETNAM) CO., LTD. 16th Floor, VIT Building, 519 Kim Ma Str., Ba Dinh Dist., Hanoi, Vietnam Tel: 84-4-22208801 (Company) - Ext.251 Fax: 84-4-22208802 (Company) Email: tuyen.hoangvan at toshiba-tsdv.com ================================================================ -------------- next part -------------- From 2578640eb402b7fb36daad3b6adcf254c6951fbe Mon Sep 17 00:00:00 2001 From: Hoang Van Tuyen Date: Wed, 7 Feb 2018 14:10:59 +0700 Subject: [PATCH] hwlatdetect: Add a new test program for rt-tests The hwlatdetect is a program to control the kernel hardware latency detection module. Target boards have to support hwlat_detector module. Signed-off-by: Hoang Van Tuyen --- ...1-hwlatdetect-cleaned-up-exception-raises.patch | 37 ++++++++++++++++++++++ .../tests/Benchmark.hwlatdetect/chart_config.json | 4 +++ engine/tests/Benchmark.hwlatdetect/criteria.json | 12 +++++++ engine/tests/Benchmark.hwlatdetect/fuego_test.sh | 23 ++++++++++++++ engine/tests/Benchmark.hwlatdetect/parser.py | 13 ++++++++ engine/tests/Benchmark.hwlatdetect/reference.json | 18 +++++++++++ engine/tests/Benchmark.hwlatdetect/spec.json | 14 ++++++++ 7 files changed, 121 insertions(+) create mode 100644 engine/tests/Benchmark.hwlatdetect/0001-hwlatdetect-cleaned-up-exception-raises.patch create mode 100644 engine/tests/Benchmark.hwlatdetect/chart_config.json create mode 100644 engine/tests/Benchmark.hwlatdetect/criteria.json create mode 100755 engine/tests/Benchmark.hwlatdetect/fuego_test.sh create mode 100755 engine/tests/Benchmark.hwlatdetect/parser.py create mode 100644 engine/tests/Benchmark.hwlatdetect/reference.json create mode 100644 engine/tests/Benchmark.hwlatdetect/spec.json diff --git a/engine/tests/Benchmark.hwlatdetect/0001-hwlatdetect-cleaned-up-exception-raises.patch b/engine/tests/Benchmark.hwlatdetect/0001-hwlatdetect-cleaned-up-exception-raises.patch new file mode 100644 index 0000000..23b5e96 --- /dev/null +++ b/engine/tests/Benchmark.hwlatdetect/0001-hwlatdetect-cleaned-up-exception-raises.patch @@ -0,0 +1,37 @@ +From 679c56ddcf83c67517d208d0fe9c60cdc45606d0 Mon Sep 17 00:00:00 2001 +From: Hoang Van Tuyen +Date: Wed, 7 Feb 2018 11:42:56 +0700 +Subject: [PATCH] hwlatdetect: cleaned up exception raises + +Fix issue: TypeError: raise: arg 3 must be a traceback or None +and correct typing mistake by using Hwlat instead of HwLat + +Signed-off-by: Hoang Van Tuyen +--- + src/hwlatdetect/hwlatdetect.py | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/src/hwlatdetect/hwlatdetect.py b/src/hwlatdetect/hwlatdetect.py +index 5ebd4f1..5106bfb 100755 +--- a/src/hwlatdetect/hwlatdetect.py ++++ b/src/hwlatdetect/hwlatdetect.py +@@ -306,7 +306,7 @@ class Tracer(Detector): + super(Tracer, self).__init__() + path = self.debugfs.getpath('tracing/hwlat_detector') + if not os.path.exists(path): +- raise DetectorNotAvailable, "hwlat", "hwlat tracer not available" ++ raise DetectorNotAvailable("hwlat", "hwlat tracer not available") + self.type = "tracer" + self.samples = [] + self.set("enable", 0) +@@ -545,7 +545,7 @@ if __name__ == '__main__': + try: + detect = Tracer() + except DetectorNotAvailable, err: +- detect = HwLat() ++ detect = Hwlat() + + if o.threshold: + t = microseconds(o.threshold) +-- +2.1.4 diff --git a/engine/tests/Benchmark.hwlatdetect/chart_config.json b/engine/tests/Benchmark.hwlatdetect/chart_config.json new file mode 100644 index 0000000..71c8238 --- /dev/null +++ b/engine/tests/Benchmark.hwlatdetect/chart_config.json @@ -0,0 +1,4 @@ +{ + "chart_type": "measure_plot", + "measures": ["default.latencies.max_latency"] +} diff --git a/engine/tests/Benchmark.hwlatdetect/criteria.json b/engine/tests/Benchmark.hwlatdetect/criteria.json new file mode 100644 index 0000000..0520968 --- /dev/null +++ b/engine/tests/Benchmark.hwlatdetect/criteria.json @@ -0,0 +1,12 @@ +{ + "schema_version":"1.0", + "criteria":[ + { + "tguid":"default.latencies.max_latency", + "reference":{ + "value":15000, + "operator":"le" + } + } + ] +} diff --git a/engine/tests/Benchmark.hwlatdetect/fuego_test.sh b/engine/tests/Benchmark.hwlatdetect/fuego_test.sh new file mode 100755 index 0000000..d1ab59e --- /dev/null +++ b/engine/tests/Benchmark.hwlatdetect/fuego_test.sh @@ -0,0 +1,23 @@ +tarball=../rt-tests/rt-tests-v1.1.1.tar.gz + +# This test requires the hwlat_detector driver. +# The hwlatdetect executable test file have many actions for checking and loading +# the hwlat_detector. So, We do not add a pre_check for hwlat_detector driver. +NEED_ROOT=1 +function test_pre_check { + assert_define BENCHMARK_HWLATDETECT_PARAMS +} + +function test_build { + patch -p1 -N -s < $TEST_HOME/../rt-tests/0001-Add-scheduling-policies-for-old-kernels.patch + patch -p1 -N -s < $TEST_HOME/0001-hwlatdetect-cleaned-up-exception-raises.patch + make hwlatdetect +} + +function test_deploy { + put hwlatdetect $BOARD_TESTDIR/fuego.$TESTDIR/ +} + +function test_run { + report "cd $BOARD_TESTDIR/fuego.$TESTDIR; ./hwlatdetect $BENCHMARK_HWLATDETECT_PARAMS" +} diff --git a/engine/tests/Benchmark.hwlatdetect/parser.py b/engine/tests/Benchmark.hwlatdetect/parser.py new file mode 100755 index 0000000..32c23ce --- /dev/null +++ b/engine/tests/Benchmark.hwlatdetect/parser.py @@ -0,0 +1,13 @@ +#!/usr/bin/python +import os, re, sys +sys.path.insert(0, os.environ['FUEGO_CORE'] + '/engine/scripts/parser') +import common as plib + +regex_string = "^Max Latency:\s+(\d+)us" +measurements = {} +matches = plib.parse_log(regex_string) + +if matches: + measurements['default.latencies'] = [{"name": "max_latency", "measure" : float(matches[0])}] + +sys.exit(plib.process(measurements)) diff --git a/engine/tests/Benchmark.hwlatdetect/reference.json b/engine/tests/Benchmark.hwlatdetect/reference.json new file mode 100644 index 0000000..ba61c77 --- /dev/null +++ b/engine/tests/Benchmark.hwlatdetect/reference.json @@ -0,0 +1,18 @@ +{ + "test_sets":[ + { + "name":"default", + "test_cases":[ + { + "name":"latencies", + "measurements":[ + { + "name":"max_latency", + "unit":"us" + } + ] + } + ] + } + ] +} diff --git a/engine/tests/Benchmark.hwlatdetect/spec.json b/engine/tests/Benchmark.hwlatdetect/spec.json new file mode 100644 index 0000000..c59f5ff --- /dev/null +++ b/engine/tests/Benchmark.hwlatdetect/spec.json @@ -0,0 +1,14 @@ +{ + "testName": "Benchmark.hwlatdetect", + "specs": { + "default": { + "PARAMS": "--duration=1m --hardlimit=15000" + }, + "latest": { + "PER_JOB_BUILD": "true", + "gitrepo": "https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git", + "gitref": "unstable/devel/v1.1.1", + "PARAMS": "--duration=1m --report=smi.txt" + } + } +} -- 2.1.4 -------------- next part -------------- -- This mail was scanned by BitDefender For more information please visit http://www.bitdefender.com From tuyen.hoangvan at toshiba-tsdv.com Wed Feb 7 10:41:22 2018 From: tuyen.hoangvan at toshiba-tsdv.com (Hoang Van Tuyen) Date: Wed, 7 Feb 2018 17:41:22 +0700 Subject: [Fuego] [PATCH] rt-migrate-test: Add a new rt-tests Message-ID: <15837926-7284-b7f5-914e-a716ace4bcb0@toshiba-tsdv.com> Description of the test: Test real-time multiprocessor scheduling of tasks to ensure the highest priority tasks are running on all available CPUs. Signed-off-by: Hoang Van Tuyen --- .../tests/Benchmark.migratetest/chart_config.json | 5 ++++ engine/tests/Benchmark.migratetest/criteria.json | 26 +++++++++++++++++++ engine/tests/Benchmark.migratetest/fuego_test.sh | 21 ++++++++++++++++ engine/tests/Benchmark.migratetest/parser.py | 29 ++++++++++++++++++++++ engine/tests/Benchmark.migratetest/reference.json | 26 +++++++++++++++++++ engine/tests/Benchmark.migratetest/spec.json | 14 +++++++++++ 6 files changed, 121 insertions(+) create mode 100644 engine/tests/Benchmark.migratetest/chart_config.json create mode 100644 engine/tests/Benchmark.migratetest/criteria.json create mode 100755 engine/tests/Benchmark.migratetest/fuego_test.sh create mode 100755 engine/tests/Benchmark.migratetest/parser.py create mode 100644 engine/tests/Benchmark.migratetest/reference.json create mode 100644 engine/tests/Benchmark.migratetest/spec.json diff --git a/engine/tests/Benchmark.migratetest/chart_config.json b/engine/tests/Benchmark.migratetest/chart_config.json new file mode 100644 index 0000000..3cbaef2 --- /dev/null +++ b/engine/tests/Benchmark.migratetest/chart_config.json @@ -0,0 +1,5 @@ +{ + "chart_type": "measure_plot", + "measures": ["default.intervals.max_interval", + "default.intervals.avg_interval"] +} diff --git a/engine/tests/Benchmark.migratetest/criteria.json b/engine/tests/Benchmark.migratetest/criteria.json new file mode 100644 index 0000000..ad3df6b --- /dev/null +++ b/engine/tests/Benchmark.migratetest/criteria.json @@ -0,0 +1,26 @@ +{ + "schema_version":"1.0", + "criteria":[ + { + "tguid":"default.intervals.max_interval", + "reference":{ + "value":30000, + "operator":"le" + } + }, + { + "tguid":"default.intervals.min_interval", + "reference":{ + "value":30000, + "operator":"le" + } + }, + { + "tguid":"default.intervals.avg_interval", + "reference":{ + "value":30000, + "operator":"le" + } + } + ] +} diff --git a/engine/tests/Benchmark.migratetest/fuego_test.sh b/engine/tests/Benchmark.migratetest/fuego_test.sh new file mode 100755 index 0000000..bc3627a --- /dev/null +++ b/engine/tests/Benchmark.migratetest/fuego_test.sh @@ -0,0 +1,21 @@ +tarball=../rt-tests/rt-tests-v1.1.1.tar.gz + +NEED_ROOT=1 +TEST_COMMAND="rt-migrate-test" + +function test_pre_check { + assert_define BENCHMARK_RT_MIGRATE_TEST_PARAMS +} + +function test_build { + patch -p1 -N -s < $TEST_HOME/../rt-tests/0001-Add-scheduling-policies-for-old-kernels.patch + make NUMA=0 ${TEST_COMMAND} +} + +function test_deploy { + put ${TEST_COMMAND} $BOARD_TESTDIR/fuego.$TESTDIR/ +} + +function test_run { + report "cd $BOARD_TESTDIR/fuego.$TESTDIR; ./${TEST_COMMAND} $BENCHMARK_RT_MIGRATE_TEST_PARAMS" +} diff --git a/engine/tests/Benchmark.migratetest/parser.py b/engine/tests/Benchmark.migratetest/parser.py new file mode 100755 index 0000000..ae88f04 --- /dev/null +++ b/engine/tests/Benchmark.migratetest/parser.py @@ -0,0 +1,29 @@ +#!/usr/bin/python +import os, re, sys +sys.path.insert(0, os.environ['FUEGO_CORE'] + '/engine/scripts/parser') +import common as plib + +regex_string_max = "Max:\s+(\d+)\s+us" +regex_string_min = "Min:\s+(\d+)\s+us" +regex_string_avg = "Avg:\s+(\d+)\s+us" +measurements = {} +matches_max = plib.parse_log(regex_string_max) +matches_min = plib.parse_log(regex_string_min) +matches_avg = plib.parse_log(regex_string_avg) + +if matches_max and matches_min and matches_avg: + min_intervals = [] + avg_intervals = [] + max_intervals = [] + for thread_max in matches_max: + max_intervals.append(float(thread_max[0])) + for thread_min in matches_min: + min_intervals.append(float(thread_min[0])) + for thread_avg in matches_avg: + avg_intervals.append(float(thread_avg[0])) + measurements['default.intervals'] = [ + {"name": "max_interval", "measure" : max(max_intervals)}, + {"name": "min_interval", "measure" : min(min_intervals)}, + {"name": "avg_interval", "measure" : sum(avg_intervals)/len(avg_intervals)}] + +sys.exit(plib.process(measurements)) diff --git a/engine/tests/Benchmark.migratetest/reference.json b/engine/tests/Benchmark.migratetest/reference.json new file mode 100644 index 0000000..d1dd0bc --- /dev/null +++ b/engine/tests/Benchmark.migratetest/reference.json @@ -0,0 +1,26 @@ +{ + "test_sets":[ + { + "name":"default", + "test_cases":[ + { + "name":"intervals", + "measurements":[ + { + "name":"max_interval", + "unit":"us" + }, + { + "name":"min_interval", + "unit":"us" + }, + { + "name":"avg_interval", + "unit":"us" + } + ] + } + ] + } + ] +} diff --git a/engine/tests/Benchmark.migratetest/spec.json b/engine/tests/Benchmark.migratetest/spec.json new file mode 100644 index 0000000..6d42f36 --- /dev/null +++ b/engine/tests/Benchmark.migratetest/spec.json @@ -0,0 +1,14 @@ +{ + "testName": "Benchmark.rt_migrate_test", + "specs": { + "default": { + "PARAMS": "-l 10" + }, + "latest": { + "PER_JOB_BUILD": "true", + "gitrepo": "https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git", + "gitref": "unstable/devel/v1.1.1", + "PARAMS": " " + } + } +} -- 2.1.4 -- ================================================================ Hoang Van Tuyen (Mr.) TOSHIBA SOFTWARE DEVELOPMENT (VIETNAM) CO., LTD. 16th Floor, VIT Building, 519 Kim Ma Str., Ba Dinh Dist., Hanoi, Vietnam Tel: 84-4-22208801 (Company) - Ext.251 Fax: 84-4-22208802 (Company) Email: tuyen.hoangvan at toshiba-tsdv.com ================================================================ -------------- next part -------------- From c58d26c2ec69c6efd709aa893ad187f81258f6d6 Mon Sep 17 00:00:00 2001 From: Hoang Van Tuyen Date: Thu, 1 Feb 2018 13:59:35 +0700 Subject: [PATCH] rt-migrate-test: Add a new rt-tests Description of the test: Test real-time multiprocessor scheduling of tasks to ensure the highest priority tasks are running on all available CPUs. Signed-off-by: Hoang Van Tuyen --- .../tests/Benchmark.migratetest/chart_config.json | 5 ++++ engine/tests/Benchmark.migratetest/criteria.json | 26 +++++++++++++++++++ engine/tests/Benchmark.migratetest/fuego_test.sh | 21 ++++++++++++++++ engine/tests/Benchmark.migratetest/parser.py | 29 ++++++++++++++++++++++ engine/tests/Benchmark.migratetest/reference.json | 26 +++++++++++++++++++ engine/tests/Benchmark.migratetest/spec.json | 14 +++++++++++ 6 files changed, 121 insertions(+) create mode 100644 engine/tests/Benchmark.migratetest/chart_config.json create mode 100644 engine/tests/Benchmark.migratetest/criteria.json create mode 100755 engine/tests/Benchmark.migratetest/fuego_test.sh create mode 100755 engine/tests/Benchmark.migratetest/parser.py create mode 100644 engine/tests/Benchmark.migratetest/reference.json create mode 100644 engine/tests/Benchmark.migratetest/spec.json diff --git a/engine/tests/Benchmark.migratetest/chart_config.json b/engine/tests/Benchmark.migratetest/chart_config.json new file mode 100644 index 0000000..3cbaef2 --- /dev/null +++ b/engine/tests/Benchmark.migratetest/chart_config.json @@ -0,0 +1,5 @@ +{ + "chart_type": "measure_plot", + "measures": ["default.intervals.max_interval", + "default.intervals.avg_interval"] +} diff --git a/engine/tests/Benchmark.migratetest/criteria.json b/engine/tests/Benchmark.migratetest/criteria.json new file mode 100644 index 0000000..ad3df6b --- /dev/null +++ b/engine/tests/Benchmark.migratetest/criteria.json @@ -0,0 +1,26 @@ +{ + "schema_version":"1.0", + "criteria":[ + { + "tguid":"default.intervals.max_interval", + "reference":{ + "value":30000, + "operator":"le" + } + }, + { + "tguid":"default.intervals.min_interval", + "reference":{ + "value":30000, + "operator":"le" + } + }, + { + "tguid":"default.intervals.avg_interval", + "reference":{ + "value":30000, + "operator":"le" + } + } + ] +} diff --git a/engine/tests/Benchmark.migratetest/fuego_test.sh b/engine/tests/Benchmark.migratetest/fuego_test.sh new file mode 100755 index 0000000..bc3627a --- /dev/null +++ b/engine/tests/Benchmark.migratetest/fuego_test.sh @@ -0,0 +1,21 @@ +tarball=../rt-tests/rt-tests-v1.1.1.tar.gz + +NEED_ROOT=1 +TEST_COMMAND="rt-migrate-test" + +function test_pre_check { + assert_define BENCHMARK_RT_MIGRATE_TEST_PARAMS +} + +function test_build { + patch -p1 -N -s < $TEST_HOME/../rt-tests/0001-Add-scheduling-policies-for-old-kernels.patch + make NUMA=0 ${TEST_COMMAND} +} + +function test_deploy { + put ${TEST_COMMAND} $BOARD_TESTDIR/fuego.$TESTDIR/ +} + +function test_run { + report "cd $BOARD_TESTDIR/fuego.$TESTDIR; ./${TEST_COMMAND} $BENCHMARK_RT_MIGRATE_TEST_PARAMS" +} diff --git a/engine/tests/Benchmark.migratetest/parser.py b/engine/tests/Benchmark.migratetest/parser.py new file mode 100755 index 0000000..ae88f04 --- /dev/null +++ b/engine/tests/Benchmark.migratetest/parser.py @@ -0,0 +1,29 @@ +#!/usr/bin/python +import os, re, sys +sys.path.insert(0, os.environ['FUEGO_CORE'] + '/engine/scripts/parser') +import common as plib + +regex_string_max = "Max:\s+(\d+)\s+us" +regex_string_min = "Min:\s+(\d+)\s+us" +regex_string_avg = "Avg:\s+(\d+)\s+us" +measurements = {} +matches_max = plib.parse_log(regex_string_max) +matches_min = plib.parse_log(regex_string_min) +matches_avg = plib.parse_log(regex_string_avg) + +if matches_max and matches_min and matches_avg: + min_intervals = [] + avg_intervals = [] + max_intervals = [] + for thread_max in matches_max: + max_intervals.append(float(thread_max[0])) + for thread_min in matches_min: + min_intervals.append(float(thread_min[0])) + for thread_avg in matches_avg: + avg_intervals.append(float(thread_avg[0])) + measurements['default.intervals'] = [ + {"name": "max_interval", "measure" : max(max_intervals)}, + {"name": "min_interval", "measure" : min(min_intervals)}, + {"name": "avg_interval", "measure" : sum(avg_intervals)/len(avg_intervals)}] + +sys.exit(plib.process(measurements)) diff --git a/engine/tests/Benchmark.migratetest/reference.json b/engine/tests/Benchmark.migratetest/reference.json new file mode 100644 index 0000000..d1dd0bc --- /dev/null +++ b/engine/tests/Benchmark.migratetest/reference.json @@ -0,0 +1,26 @@ +{ + "test_sets":[ + { + "name":"default", + "test_cases":[ + { + "name":"intervals", + "measurements":[ + { + "name":"max_interval", + "unit":"us" + }, + { + "name":"min_interval", + "unit":"us" + }, + { + "name":"avg_interval", + "unit":"us" + } + ] + } + ] + } + ] +} diff --git a/engine/tests/Benchmark.migratetest/spec.json b/engine/tests/Benchmark.migratetest/spec.json new file mode 100644 index 0000000..6d42f36 --- /dev/null +++ b/engine/tests/Benchmark.migratetest/spec.json @@ -0,0 +1,14 @@ +{ + "testName": "Benchmark.rt_migrate_test", + "specs": { + "default": { + "PARAMS": "-l 10" + }, + "latest": { + "PER_JOB_BUILD": "true", + "gitrepo": "https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git", + "gitref": "unstable/devel/v1.1.1", + "PARAMS": " " + } + } +} -- 2.1.4 -------------- next part -------------- -- This mail was scanned by BitDefender For more information please visit http://www.bitdefender.com From tuyen.hoangvan at toshiba-tsdv.com Wed Feb 7 10:43:41 2018 From: tuyen.hoangvan at toshiba-tsdv.com (Hoang Van Tuyen) Date: Wed, 7 Feb 2018 17:43:41 +0700 Subject: [Fuego] [PATCH] deadlinetest: Add a new test for rt-tests Message-ID: <129ae3be-c53d-84a5-de26-ac3ff3608dbd@toshiba-tsdv.com> The deadlinetest program is used to test the deadline scheduler. Signed-off-by: Hoang Van Tuyen --- .../tests/Benchmark.deadlinetest/chart_config.json | 5 +++++ engine/tests/Benchmark.deadlinetest/criteria.json | 26 ++++++++++++++++++++++ engine/tests/Benchmark.deadlinetest/fuego_test.sh | 20 +++++++++++++++++ engine/tests/Benchmark.deadlinetest/parser.py | 24 ++++++++++++++++++++ engine/tests/Benchmark.deadlinetest/reference.json | 26 ++++++++++++++++++++++ engine/tests/Benchmark.deadlinetest/spec.json | 14 ++++++++++++ 6 files changed, 115 insertions(+) create mode 100644 engine/tests/Benchmark.deadlinetest/chart_config.json create mode 100644 engine/tests/Benchmark.deadlinetest/criteria.json create mode 100755 engine/tests/Benchmark.deadlinetest/fuego_test.sh create mode 100755 engine/tests/Benchmark.deadlinetest/parser.py create mode 100644 engine/tests/Benchmark.deadlinetest/reference.json create mode 100644 engine/tests/Benchmark.deadlinetest/spec.json diff --git a/engine/tests/Benchmark.deadlinetest/chart_config.json b/engine/tests/Benchmark.deadlinetest/chart_config.json new file mode 100644 index 0000000..3cbaef2 --- /dev/null +++ b/engine/tests/Benchmark.deadlinetest/chart_config.json @@ -0,0 +1,5 @@ +{ + "chart_type": "measure_plot", + "measures": ["default.intervals.max_interval", + "default.intervals.avg_interval"] +} diff --git a/engine/tests/Benchmark.deadlinetest/criteria.json b/engine/tests/Benchmark.deadlinetest/criteria.json new file mode 100644 index 0000000..605f09e --- /dev/null +++ b/engine/tests/Benchmark.deadlinetest/criteria.json @@ -0,0 +1,26 @@ +{ + "schema_version":"1.0", + "criteria":[ + { + "tguid":"default.intervals.max_interval", + "reference":{ + "value":50000, + "operator":"le" + } + }, + { + "tguid":"default.intervals.min_interval", + "reference":{ + "value":50000, + "operator":"le" + } + }, + { + "tguid":"default.intervals.avg_interval", + "reference":{ + "value":50000, + "operator":"le" + } + } + ] +} diff --git a/engine/tests/Benchmark.deadlinetest/fuego_test.sh b/engine/tests/Benchmark.deadlinetest/fuego_test.sh new file mode 100755 index 0000000..ab3daae --- /dev/null +++ b/engine/tests/Benchmark.deadlinetest/fuego_test.sh @@ -0,0 +1,20 @@ +tarball=../rt-tests/rt-tests-v1.1.1.tar.gz + +NEED_ROOT=1 + +function test_pre_check { + assert_define BENCHMARK_DEADLINE_TEST_PARAMS +} + +function test_build { + patch -p1 -N -s < $TEST_HOME/../rt-tests/0001-Add-scheduling-policies-for-old-kernels.patch + make NUMA=0 deadline_test +} + +function test_deploy { + put deadline_test $BOARD_TESTDIR/fuego.$TESTDIR/ +} + +function test_run { + report "cd $BOARD_TESTDIR/fuego.$TESTDIR; ./deadline_test $BENCHMARK_DEADLINE_TEST_PARAMS" +} diff --git a/engine/tests/Benchmark.deadlinetest/parser.py b/engine/tests/Benchmark.deadlinetest/parser.py new file mode 100755 index 0000000..2f3893e --- /dev/null +++ b/engine/tests/Benchmark.deadlinetest/parser.py @@ -0,0 +1,24 @@ +#!/usr/bin/python +import os, re, sys +sys.path.insert(0, os.environ['FUEGO_CORE'] + '/engine/scripts/parser') +import common as plib + +regex_string = "^max_time:\s+(\d+)us\smin_time:\s+(\d+)us\savg_time:\s+(\d+)us" + +measurements = {} +matches = plib.parse_log(regex_string) + +if matches: + min_intervals = [] + avg_intervals = [] + max_intervals = [] + for thread in matches: + min_intervals.append(float(thread[0])) + avg_intervals.append(float(thread[1])) + max_intervals.append(float(thread[2])) + measurements['default.intervals'] = [ + {"name": "max_interval", "measure" : max(max_intervals)}, + {"name": "min_interval", "measure" : min(min_intervals)}, + {"name": "avg_interval", "measure" : sum(avg_intervals)/len(avg_intervals)}] + +sys.exit(plib.process(measurements)) diff --git a/engine/tests/Benchmark.deadlinetest/reference.json b/engine/tests/Benchmark.deadlinetest/reference.json new file mode 100644 index 0000000..d1dd0bc --- /dev/null +++ b/engine/tests/Benchmark.deadlinetest/reference.json @@ -0,0 +1,26 @@ +{ + "test_sets":[ + { + "name":"default", + "test_cases":[ + { + "name":"intervals", + "measurements":[ + { + "name":"max_interval", + "unit":"us" + }, + { + "name":"min_interval", + "unit":"us" + }, + { + "name":"avg_interval", + "unit":"us" + } + ] + } + ] + } + ] +} diff --git a/engine/tests/Benchmark.deadlinetest/spec.json b/engine/tests/Benchmark.deadlinetest/spec.json new file mode 100644 index 0000000..422783a --- /dev/null +++ b/engine/tests/Benchmark.deadlinetest/spec.json @@ -0,0 +1,14 @@ +{ + "testName": "Benchmark.deadline_test", + "specs": { + "default": { + "PARAMS": "-t 4" + }, + "latest": { + "PER_JOB_BUILD": "true", + "gitrepo": "https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git", + "gitref": "unstable/devel/v1.1.1", + "PARAMS": " " + } + } +} -- 2.1.4 -- ================================================================ Hoang Van Tuyen (Mr.) TOSHIBA SOFTWARE DEVELOPMENT (VIETNAM) CO., LTD. 16th Floor, VIT Building, 519 Kim Ma Str., Ba Dinh Dist., Hanoi, Vietnam Tel: 84-4-22208801 (Company) - Ext.251 Fax: 84-4-22208802 (Company) Email: tuyen.hoangvan at toshiba-tsdv.com ================================================================ -------------- next part -------------- From 7f10f0c5392e2f65f13ae62c31a16ccd916ef6b0 Mon Sep 17 00:00:00 2001 From: Hoang Van Tuyen Date: Wed, 7 Feb 2018 17:37:19 +0700 Subject: [PATCH] deadlinetest: Add a new test for rt-tests The deadlinetest program is used to test the deadline scheduler. Signed-off-by: Hoang Van Tuyen --- .../tests/Benchmark.deadlinetest/chart_config.json | 5 +++++ engine/tests/Benchmark.deadlinetest/criteria.json | 26 ++++++++++++++++++++++ engine/tests/Benchmark.deadlinetest/fuego_test.sh | 20 +++++++++++++++++ engine/tests/Benchmark.deadlinetest/parser.py | 24 ++++++++++++++++++++ engine/tests/Benchmark.deadlinetest/reference.json | 26 ++++++++++++++++++++++ engine/tests/Benchmark.deadlinetest/spec.json | 14 ++++++++++++ 6 files changed, 115 insertions(+) create mode 100644 engine/tests/Benchmark.deadlinetest/chart_config.json create mode 100644 engine/tests/Benchmark.deadlinetest/criteria.json create mode 100755 engine/tests/Benchmark.deadlinetest/fuego_test.sh create mode 100755 engine/tests/Benchmark.deadlinetest/parser.py create mode 100644 engine/tests/Benchmark.deadlinetest/reference.json create mode 100644 engine/tests/Benchmark.deadlinetest/spec.json diff --git a/engine/tests/Benchmark.deadlinetest/chart_config.json b/engine/tests/Benchmark.deadlinetest/chart_config.json new file mode 100644 index 0000000..3cbaef2 --- /dev/null +++ b/engine/tests/Benchmark.deadlinetest/chart_config.json @@ -0,0 +1,5 @@ +{ + "chart_type": "measure_plot", + "measures": ["default.intervals.max_interval", + "default.intervals.avg_interval"] +} diff --git a/engine/tests/Benchmark.deadlinetest/criteria.json b/engine/tests/Benchmark.deadlinetest/criteria.json new file mode 100644 index 0000000..605f09e --- /dev/null +++ b/engine/tests/Benchmark.deadlinetest/criteria.json @@ -0,0 +1,26 @@ +{ + "schema_version":"1.0", + "criteria":[ + { + "tguid":"default.intervals.max_interval", + "reference":{ + "value":50000, + "operator":"le" + } + }, + { + "tguid":"default.intervals.min_interval", + "reference":{ + "value":50000, + "operator":"le" + } + }, + { + "tguid":"default.intervals.avg_interval", + "reference":{ + "value":50000, + "operator":"le" + } + } + ] +} diff --git a/engine/tests/Benchmark.deadlinetest/fuego_test.sh b/engine/tests/Benchmark.deadlinetest/fuego_test.sh new file mode 100755 index 0000000..ab3daae --- /dev/null +++ b/engine/tests/Benchmark.deadlinetest/fuego_test.sh @@ -0,0 +1,20 @@ +tarball=../rt-tests/rt-tests-v1.1.1.tar.gz + +NEED_ROOT=1 + +function test_pre_check { + assert_define BENCHMARK_DEADLINE_TEST_PARAMS +} + +function test_build { + patch -p1 -N -s < $TEST_HOME/../rt-tests/0001-Add-scheduling-policies-for-old-kernels.patch + make NUMA=0 deadline_test +} + +function test_deploy { + put deadline_test $BOARD_TESTDIR/fuego.$TESTDIR/ +} + +function test_run { + report "cd $BOARD_TESTDIR/fuego.$TESTDIR; ./deadline_test $BENCHMARK_DEADLINE_TEST_PARAMS" +} diff --git a/engine/tests/Benchmark.deadlinetest/parser.py b/engine/tests/Benchmark.deadlinetest/parser.py new file mode 100755 index 0000000..2f3893e --- /dev/null +++ b/engine/tests/Benchmark.deadlinetest/parser.py @@ -0,0 +1,24 @@ +#!/usr/bin/python +import os, re, sys +sys.path.insert(0, os.environ['FUEGO_CORE'] + '/engine/scripts/parser') +import common as plib + +regex_string = "^max_time:\s+(\d+)us\smin_time:\s+(\d+)us\savg_time:\s+(\d+)us" + +measurements = {} +matches = plib.parse_log(regex_string) + +if matches: + min_intervals = [] + avg_intervals = [] + max_intervals = [] + for thread in matches: + min_intervals.append(float(thread[0])) + avg_intervals.append(float(thread[1])) + max_intervals.append(float(thread[2])) + measurements['default.intervals'] = [ + {"name": "max_interval", "measure" : max(max_intervals)}, + {"name": "min_interval", "measure" : min(min_intervals)}, + {"name": "avg_interval", "measure" : sum(avg_intervals)/len(avg_intervals)}] + +sys.exit(plib.process(measurements)) diff --git a/engine/tests/Benchmark.deadlinetest/reference.json b/engine/tests/Benchmark.deadlinetest/reference.json new file mode 100644 index 0000000..d1dd0bc --- /dev/null +++ b/engine/tests/Benchmark.deadlinetest/reference.json @@ -0,0 +1,26 @@ +{ + "test_sets":[ + { + "name":"default", + "test_cases":[ + { + "name":"intervals", + "measurements":[ + { + "name":"max_interval", + "unit":"us" + }, + { + "name":"min_interval", + "unit":"us" + }, + { + "name":"avg_interval", + "unit":"us" + } + ] + } + ] + } + ] +} diff --git a/engine/tests/Benchmark.deadlinetest/spec.json b/engine/tests/Benchmark.deadlinetest/spec.json new file mode 100644 index 0000000..422783a --- /dev/null +++ b/engine/tests/Benchmark.deadlinetest/spec.json @@ -0,0 +1,14 @@ +{ + "testName": "Benchmark.deadline_test", + "specs": { + "default": { + "PARAMS": "-t 4" + }, + "latest": { + "PER_JOB_BUILD": "true", + "gitrepo": "https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git", + "gitref": "unstable/devel/v1.1.1", + "PARAMS": " " + } + } +} -- 2.1.4 -------------- next part -------------- -- This mail was scanned by BitDefender For more information please visit http://www.bitdefender.com From guicc at profusion.mobi Wed Feb 7 20:45:59 2018 From: guicc at profusion.mobi (Guilherme Campos Camargo) Date: Wed, 7 Feb 2018 18:45:59 -0200 Subject: [Fuego] [PATCH 0/1] Allow ftc script to properly use Jenkins configured port Message-ID: <20180207204600.21587-1-guicc@profusion.mobi> Please see the commit messages for more details. Guilherme Campos Camargo (1): Allow ftc script to properly use Jenkins configured port engine/scripts/ftc | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) -- 2.16.1 From guicc at profusion.mobi Wed Feb 7 20:46:00 2018 From: guicc at profusion.mobi (Guilherme Campos Camargo) Date: Wed, 7 Feb 2018 18:46:00 -0200 Subject: [Fuego] [PATCH 1/1] Allow ftc script to properly use Jenkins configured port In-Reply-To: <20180207204600.21587-1-guicc@profusion.mobi> References: <20180207204600.21587-1-guicc@profusion.mobi> Message-ID: <20180207204600.21587-2-guicc@profusion.mobi> With the possibility of configuring jenkins porth through fuego/ro/conf/fuego.conf, a change on ftc script is needed so that it uses the configured port and not the default one (8080). This patch solves that issue by using the ${jenkins_port} environment variable (set on entrypoint.sh) instead of the hardcoded 8080. Signed-off-by: Guilherme Campos Camargo --- engine/scripts/ftc | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/engine/scripts/ftc b/engine/scripts/ftc index bde3694..af5a2a7 100755 --- a/engine/scripts/ftc +++ b/engine/scripts/ftc @@ -63,6 +63,8 @@ VERSION = (1,2,1) # define these as globals log = None tail_fd = None +jenkins_port = os.getenv('jenkins_port', 8080) +fuego_url = 'http://localhost:' + str(jenkins_port) + '/fuego' # here's a utility routine to print a variable with it's name and value def pvar(name): @@ -72,7 +74,8 @@ def pvar(name): quiet = 0 verbose = 0 use_statusouput = 1 -server = jenkins.Jenkins('http://localhost:8080/fuego') +server = jenkins.Jenkins(fuego_url) + # keep configuration file in /fuego-ro/conf area config_dir = "/fuego-ro" @@ -413,7 +416,7 @@ class config_class: # fuegotest.com is at: 52.88.166.49 self.SERVER_URL_BASE = "http://52.88.166.49/server/Fuego_Server?action=Fuego." - self.JENKINS_URL = "http://localhost:8080/fuego" + self.JENKINS_URL = fuego_url # end of default configs @@ -1159,7 +1162,7 @@ timeout --signal=9 {timeout} /bin/bash $FUEGO_CORE/engine/scripts/main.sh job_name=board+"."+test.spec+"."+test.name print("Creating job " + job_name) try: - subprocess.call('java -jar /var/cache/jenkins/war/WEB-INF/jenkins-cli.jar -s http://localhost:8080/fuego create-job ' + + subprocess.call('java -jar /var/cache/jenkins/war/WEB-INF/jenkins-cli.jar -s' + fuego_url + 'create-job ' + job_name + ' < ' + tmp, shell=True) os.unlink(tmp) except Exception as e: @@ -1207,7 +1210,7 @@ def create_batch_job(board, testplan, plan_tests): print("Creating batch job ") try: job_name = board+'.'+testplan+'.batch' - subprocess.call('java -jar /var/cache/jenkins/war/WEB-INF/jenkins-cli.jar -s http://localhost:8080/fuego create-job ' + + subprocess.call('java -jar /var/cache/jenkins/war/WEB-INF/jenkins-cli.jar -s' + fuego_url + 'create-job ' + job_name + '< ' + tmp, shell=True) os.unlink(tmp) except Exception as e: @@ -3581,7 +3584,7 @@ def user_check(): new_user = "jenkins" if getpass.getuser() == "root": - cmd = ["sudo", "-u", new_user, "python"] + sys.argv + cmd = ["sudo", "-u", new_user, "-E", "python"] + sys.argv rcode = subprocess.call(cmd) sys.exit(rcode) -- 2.16.1 From Tim.Bird at sony.com Thu Feb 8 00:16:41 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 8 Feb 2018 00:16:41 +0000 Subject: [Fuego] [PATCH 1/1] Allow ftc script to properly use Jenkins configured port In-Reply-To: <20180207204600.21587-2-guicc@profusion.mobi> References: <20180207204600.21587-1-guicc@profusion.mobi> <20180207204600.21587-2-guicc@profusion.mobi> Message-ID: > -----Original Message----- > From: Guilherme Campos Camargo > > With the possibility of configuring jenkins porth through > fuego/ro/conf/fuego.conf, a change on ftc script is needed so that it > uses the configured port and not the default one (8080). > > This patch solves that issue by using the ${jenkins_port} environment > variable (set on entrypoint.sh) instead of the hardcoded 8080. Thanks. This was on my list of things to do. I made an attempt to add this support to ftc, but came up with something much more complicated, because I tried to do too much other stuff at the same time. Comments inline below. > Signed-off-by: Guilherme Campos Camargo > --- > engine/scripts/ftc | 13 ++++++++----- > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/engine/scripts/ftc b/engine/scripts/ftc > index bde3694..af5a2a7 100755 > --- a/engine/scripts/ftc > +++ b/engine/scripts/ftc > @@ -63,6 +63,8 @@ VERSION = (1,2,1) > # define these as globals > log = None > tail_fd = None > +jenkins_port = os.getenv('jenkins_port', 8080) The environment variable 'jenkins_port' is not defined in anything but the main container shell. ftc can be run from outside the container, and it calls itself inside the container such that jenkins_port is not defined. Also: $ sudo docker exec -I -t fuego-container bash starts a new shell, where ftc can be run, but jenkins_port is not defined (I believe). It would be better to read the port value from the configuration file, in /fuego_ro/conf/fuego.conf. > +fuego_url = 'http://localhost:' + str(jenkins_port) + '/fuego' > > # here's a utility routine to print a variable with it's name and value > def pvar(name): > @@ -72,7 +74,8 @@ def pvar(name): > quiet = 0 > verbose = 0 > use_statusouput = 1 > -server = jenkins.Jenkins('http://localhost:8080/fuego') > +server = jenkins.Jenkins(fuego_url) > + > > # keep configuration file in /fuego-ro/conf area > config_dir = "/fuego-ro" > @@ -413,7 +416,7 @@ class config_class: > > # fuegotest.com is at: 52.88.166.49 > self.SERVER_URL_BASE = > "http://52.88.166.49/server/Fuego_Server?action=Fuego." > - self.JENKINS_URL = "http://localhost:8080/fuego" > + self.JENKINS_URL = fuego_url > > # end of default configs > > @@ -1159,7 +1162,7 @@ timeout --signal=9 {timeout} /bin/bash > $FUEGO_CORE/engine/scripts/main.sh > job_name=board+"."+test.spec+"."+test.name > print("Creating job " + job_name) > try: > - subprocess.call('java -jar /var/cache/jenkins/war/WEB-INF/jenkins- > cli.jar -s http://localhost:8080/fuego create-job ' + > + subprocess.call('java -jar /var/cache/jenkins/war/WEB-INF/jenkins- > cli.jar -s' + fuego_url + 'create-job ' + > job_name + ' < ' + tmp, shell=True) > os.unlink(tmp) > except Exception as e: > @@ -1207,7 +1210,7 @@ def create_batch_job(board, testplan, plan_tests): > print("Creating batch job ") > try: > job_name = board+'.'+testplan+'.batch' > - subprocess.call('java -jar /var/cache/jenkins/war/WEB-INF/jenkins- > cli.jar -s http://localhost:8080/fuego create-job ' + > + subprocess.call('java -jar /var/cache/jenkins/war/WEB-INF/jenkins- > cli.jar -s' + fuego_url + 'create-job ' + > job_name + '< ' + tmp, shell=True) > os.unlink(tmp) > except Exception as e: > @@ -3581,7 +3584,7 @@ def user_check(): > > new_user = "jenkins" > if getpass.getuser() == "root": > - cmd = ["sudo", "-u", new_user, "python"] + sys.argv > + cmd = ["sudo", "-u", new_user, "-E", "python"] + sys.argv > rcode = subprocess.call(cmd) > sys.exit(rcode) > > -- > 2.16.1 Other than that - looks good. Can you please make the requested change? -- Tim From Tim.Bird at sony.com Thu Feb 8 01:09:26 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 8 Feb 2018 01:09:26 +0000 Subject: [Fuego] [PATCH] rt-migrate-test: Add a new rt-tests In-Reply-To: <15837926-7284-b7f5-914e-a716ace4bcb0@toshiba-tsdv.com> References: <15837926-7284-b7f5-914e-a716ace4bcb0@toshiba-tsdv.com> Message-ID: > -----Original Message----- > From: Hoang Van Tuyen > > Description of the test: Test real-time multiprocessor scheduling of tasks > to ensure the highest priority tasks are running on all available CPUs. > > Signed-off-by: Hoang Van Tuyen > --- > .../tests/Benchmark.migratetest/chart_config.json | 5 ++++ > engine/tests/Benchmark.migratetest/criteria.json | 26 > +++++++++++++++++++ > engine/tests/Benchmark.migratetest/fuego_test.sh | 21 > ++++++++++++++++ > engine/tests/Benchmark.migratetest/parser.py | 29 > ++++++++++++++++++++++ > engine/tests/Benchmark.migratetest/reference.json | 26 > +++++++++++++++++++ > engine/tests/Benchmark.migratetest/spec.json | 14 +++++++++++ > 6 files changed, 121 insertions(+) > create mode 100644 > engine/tests/Benchmark.migratetest/chart_config.json > create mode 100644 engine/tests/Benchmark.migratetest/criteria.json > create mode 100755 engine/tests/Benchmark.migratetest/fuego_test.sh > create mode 100755 engine/tests/Benchmark.migratetest/parser.py > create mode 100644 engine/tests/Benchmark.migratetest/reference.json > create mode 100644 engine/tests/Benchmark.migratetest/spec.json > > diff --git a/engine/tests/Benchmark.migratetest/chart_config.json > b/engine/tests/Benchmark.migratetest/chart_config.json > new file mode 100644 > index 0000000..3cbaef2 > --- /dev/null > +++ b/engine/tests/Benchmark.migratetest/chart_config.json > @@ -0,0 +1,5 @@ > +{ > + "chart_type": "measure_plot", > + "measures": ["default.intervals.max_interval", > + "default.intervals.avg_interval"] > +} > diff --git a/engine/tests/Benchmark.migratetest/criteria.json > b/engine/tests/Benchmark.migratetest/criteria.json > new file mode 100644 > index 0000000..ad3df6b > --- /dev/null > +++ b/engine/tests/Benchmark.migratetest/criteria.json > @@ -0,0 +1,26 @@ > +{ > + "schema_version":"1.0", > + "criteria":[ > + { > + "tguid":"default.intervals.max_interval", > + "reference":{ > + "value":30000, > + "operator":"le" > + } > + }, > + { > + "tguid":"default.intervals.min_interval", > + "reference":{ > + "value":30000, > + "operator":"le" > + } > + }, > + { > + "tguid":"default.intervals.avg_interval", > + "reference":{ > + "value":30000, > + "operator":"le" > + } > + } > + ] > +} > diff --git a/engine/tests/Benchmark.migratetest/fuego_test.sh > b/engine/tests/Benchmark.migratetest/fuego_test.sh > new file mode 100755 > index 0000000..bc3627a > --- /dev/null > +++ b/engine/tests/Benchmark.migratetest/fuego_test.sh > @@ -0,0 +1,21 @@ > +tarball=../rt-tests/rt-tests-v1.1.1.tar.gz > + > +NEED_ROOT=1 > +TEST_COMMAND="rt-migrate-test" I like the use of TEST_COMMAND to avoid duplication. It helps to see the connection between build, deploy and run. We should make that a convention in other Fuego tests. > + > +function test_pre_check { > + assert_define BENCHMARK_RT_MIGRATE_TEST_PARAMS > +} > + > +function test_build { > + patch -p1 -N -s < > $TEST_HOME/../rt-tests/0001-Add-scheduling-policies-for-old-kernels.patch > + make NUMA=0 ${TEST_COMMAND} > +} > + > +function test_deploy { > + put ${TEST_COMMAND} $BOARD_TESTDIR/fuego.$TESTDIR/ > +} > + > +function test_run { > + report "cd $BOARD_TESTDIR/fuego.$TESTDIR; ./${TEST_COMMAND} > $BENCHMARK_RT_MIGRATE_TEST_PARAMS" > +} > diff --git a/engine/tests/Benchmark.migratetest/parser.py > b/engine/tests/Benchmark.migratetest/parser.py > new file mode 100755 > index 0000000..ae88f04 > --- /dev/null > +++ b/engine/tests/Benchmark.migratetest/parser.py > @@ -0,0 +1,29 @@ > +#!/usr/bin/python > +import os, re, sys > +sys.path.insert(0, os.environ['FUEGO_CORE'] + '/engine/scripts/parser') > +import common as plib > + > +regex_string_max = "Max:\s+(\d+)\s+us" > +regex_string_min = "Min:\s+(\d+)\s+us" > +regex_string_avg = "Avg:\s+(\d+)\s+us" > +measurements = {} > +matches_max = plib.parse_log(regex_string_max) > +matches_min = plib.parse_log(regex_string_min) > +matches_avg = plib.parse_log(regex_string_avg) > + > +if matches_max and matches_min and matches_avg: > + min_intervals = [] > + avg_intervals = [] > + max_intervals = [] > + for thread_max in matches_max: > + max_intervals.append(float(thread_max[0])) > + for thread_min in matches_min: > + min_intervals.append(float(thread_min[0])) > + for thread_avg in matches_avg: > + avg_intervals.append(float(thread_avg[0])) > + measurements['default.intervals'] = [ > + {"name": "max_interval", "measure" : max(max_intervals)}, > + {"name": "min_interval", "measure" : min(min_intervals)}, > + {"name": "avg_interval", "measure" : > sum(avg_intervals)/len(avg_intervals)}] > + > +sys.exit(plib.process(measurements)) > diff --git a/engine/tests/Benchmark.migratetest/reference.json > b/engine/tests/Benchmark.migratetest/reference.json > new file mode 100644 > index 0000000..d1dd0bc > --- /dev/null > +++ b/engine/tests/Benchmark.migratetest/reference.json > @@ -0,0 +1,26 @@ > +{ > + "test_sets":[ > + { > + "name":"default", > + "test_cases":[ > + { > + "name":"intervals", > + "measurements":[ > + { > + "name":"max_interval", > + "unit":"us" > + }, > + { > + "name":"min_interval", > + "unit":"us" > + }, > + { > + "name":"avg_interval", > + "unit":"us" > + } > + ] > + } > + ] > + } > + ] > +} > diff --git a/engine/tests/Benchmark.migratetest/spec.json > b/engine/tests/Benchmark.migratetest/spec.json > new file mode 100644 > index 0000000..6d42f36 > --- /dev/null > +++ b/engine/tests/Benchmark.migratetest/spec.json > @@ -0,0 +1,14 @@ > +{ > + "testName": "Benchmark.rt_migrate_test", > + "specs": { > + "default": { > + "PARAMS": "-l 10" > + }, > + "latest": { > + "PER_JOB_BUILD": "true", > + "gitrepo": > "https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git", > + "gitref": "unstable/devel/v1.1.1", > + "PARAMS": " " > + } > + } > +} > -- > 2.1.4 Looks great. Applied and pushed. -- Tim From tuyen.hoangvan at toshiba-tsdv.com Thu Feb 8 03:47:13 2018 From: tuyen.hoangvan at toshiba-tsdv.com (Hoang Van Tuyen) Date: Thu, 8 Feb 2018 10:47:13 +0700 Subject: [Fuego] [PATCH 1/2] migratetest: parser.py: Correct getting value of, measurements Message-ID: <18f3a69c-d4fa-8bc6-5930-63e482aec171@toshiba-tsdv.com> We want to get the whole number like 20499 but the issue is that it just got the first digit like 2. This commit fixs this problem. Signed-off-by: Hoang Van Tuyen --- engine/tests/Benchmark.migratetest/parser.py | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/engine/tests/Benchmark.migratetest/parser.py b/engine/tests/Benchmark.migratetest/parser.py index ae88f04..968163a 100755 --- a/engine/tests/Benchmark.migratetest/parser.py +++ b/engine/tests/Benchmark.migratetest/parser.py @@ -16,11 +16,11 @@ if matches_max and matches_min and matches_avg: avg_intervals = [] max_intervals = [] for thread_max in matches_max: - max_intervals.append(float(thread_max[0])) + max_intervals.append(float(thread_max)) for thread_min in matches_min: - min_intervals.append(float(thread_min[0])) + min_intervals.append(float(thread_min)) for thread_avg in matches_avg: - avg_intervals.append(float(thread_avg[0])) + avg_intervals.append(float(thread_avg)) measurements['default.intervals'] = [ {"name": "max_interval", "measure" : max(max_intervals)}, {"name": "min_interval", "measure" : min(min_intervals)}, -- 2.1.4 -- ================================================================ Hoang Van Tuyen (Mr.) TOSHIBA SOFTWARE DEVELOPMENT (VIETNAM) CO., LTD. 16th Floor, VIT Building, 519 Kim Ma Str., Ba Dinh Dist., Hanoi, Vietnam Tel: 84-4-22208801 (Company) - Ext.251 Fax: 84-4-22208802 (Company) Email: tuyen.hoangvan at toshiba-tsdv.com ================================================================ -- This mail was scanned by BitDefender For more information please visit http://www.bitdefender.com From tuyen.hoangvan at toshiba-tsdv.com Thu Feb 8 03:49:24 2018 From: tuyen.hoangvan at toshiba-tsdv.com (Hoang Van Tuyen) Date: Thu, 8 Feb 2018 10:49:24 +0700 Subject: [Fuego] [PATCH 2/2] deadlinetest: parser.py: Correct putting in order several, fields Message-ID: The ordering of thread array is max_intervals, min_intervals and avg_intervals. Correct getting the value for the fields in this commit. Signed-off-by: Hoang Van Tuyen --- engine/tests/Benchmark.deadlinetest/parser.py | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/engine/tests/Benchmark.deadlinetest/parser.py b/engine/tests/Benchmark.deadlinetest/parser.py index 2f3893e..2462022 100755 --- a/engine/tests/Benchmark.deadlinetest/parser.py +++ b/engine/tests/Benchmark.deadlinetest/parser.py @@ -13,9 +13,9 @@ if matches: avg_intervals = [] max_intervals = [] for thread in matches: - min_intervals.append(float(thread[0])) - avg_intervals.append(float(thread[1])) - max_intervals.append(float(thread[2])) + max_intervals.append(float(thread[0])) + min_intervals.append(float(thread[1])) + avg_intervals.append(float(thread[2])) measurements['default.intervals'] = [ {"name": "max_interval", "measure" : max(max_intervals)}, {"name": "min_interval", "measure" : min(min_intervals)}, -- 2.1.4 -- ================================================================ Hoang Van Tuyen (Mr.) TOSHIBA SOFTWARE DEVELOPMENT (VIETNAM) CO., LTD. 16th Floor, VIT Building, 519 Kim Ma Str., Ba Dinh Dist., Hanoi, Vietnam Tel: 84-4-22208801 (Company) - Ext.251 Fax: 84-4-22208802 (Company) Email: tuyen.hoangvan at toshiba-tsdv.com ================================================================ -- This mail was scanned by BitDefender For more information please visit http://www.bitdefender.com From Tim.Bird at sony.com Thu Feb 8 05:48:55 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 8 Feb 2018 05:48:55 +0000 Subject: [Fuego] [PATCH 1/2] migratetest: parser.py: Correct getting value of, measurements In-Reply-To: <18f3a69c-d4fa-8bc6-5930-63e482aec171@toshiba-tsdv.com> References: <18f3a69c-d4fa-8bc6-5930-63e482aec171@toshiba-tsdv.com> Message-ID: > -----Original Message----- > From: Hoang Van Tuyen > > We want to get the whole number like 20499 but the issue is that > it just got the first digit like 2. This commit fixs this problem. > > Signed-off-by: Hoang Van Tuyen > --- > engine/tests/Benchmark.migratetest/parser.py | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/engine/tests/Benchmark.migratetest/parser.py > b/engine/tests/Benchmark.migratetest/parser.py > index ae88f04..968163a 100755 > --- a/engine/tests/Benchmark.migratetest/parser.py > +++ b/engine/tests/Benchmark.migratetest/parser.py > @@ -16,11 +16,11 @@ if matches_max and matches_min and matches_avg: > avg_intervals = [] > max_intervals = [] > for thread_max in matches_max: > - max_intervals.append(float(thread_max[0])) > + max_intervals.append(float(thread_max)) > for thread_min in matches_min: > - min_intervals.append(float(thread_min[0])) > + min_intervals.append(float(thread_min)) > for thread_avg in matches_avg: > - avg_intervals.append(float(thread_avg[0])) > + avg_intervals.append(float(thread_avg)) > measurements['default.intervals'] = [ > {"name": "max_interval", "measure" : max(max_intervals)}, > {"name": "min_interval", "measure" : min(min_intervals)}, > -- > 2.1.4 That appears to have fixed it. Thanks. Applied and pushed. Any idea why the task 0 numbers are so bad? I'm not running an RT kernel - is that the reason? Task 0 (prio 2) (pid 26981): Max: 20036 us Min: 20013 us Tot: 200187 us Avg: 20018 us Task 1 (prio 3) (pid 26982): Max: 102 us Min: 14 us Tot: 473 us Avg: 47 us Task 2 (prio 4) (pid 26983): Max: 26 us Min: 9 us Tot: 135 us Avg: 13 us -- Tim From Tim.Bird at sony.com Thu Feb 8 05:55:12 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 8 Feb 2018 05:55:12 +0000 Subject: [Fuego] [PATCH 2/2] deadlinetest: parser.py: Correct putting in order several, fields In-Reply-To: References: Message-ID: OK - that's better. The numbers on the one board that this works on now make sense. Thanks. Applied. -- Tim > -----Original Message----- > From: fuego-bounces at lists.linuxfoundation.org [mailto:fuego- > bounces at lists.linuxfoundation.org] On Behalf Of Hoang Van Tuyen > Sent: Wednesday, February 07, 2018 7:49 PM > To: fuego at lists.linuxfoundation.org > Subject: [Fuego] [PATCH 2/2] deadlinetest: parser.py: Correct putting in > order several, fields > > The ordering of thread array is max_intervals, min_intervals and > avg_intervals. > Correct getting the value for the fields in this commit. > > Signed-off-by: Hoang Van Tuyen > --- > engine/tests/Benchmark.deadlinetest/parser.py | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/engine/tests/Benchmark.deadlinetest/parser.py > b/engine/tests/Benchmark.deadlinetest/parser.py > index 2f3893e..2462022 100755 > --- a/engine/tests/Benchmark.deadlinetest/parser.py > +++ b/engine/tests/Benchmark.deadlinetest/parser.py > @@ -13,9 +13,9 @@ if matches: > avg_intervals = [] > max_intervals = [] > for thread in matches: > - min_intervals.append(float(thread[0])) > - avg_intervals.append(float(thread[1])) > - max_intervals.append(float(thread[2])) > + max_intervals.append(float(thread[0])) > + min_intervals.append(float(thread[1])) > + avg_intervals.append(float(thread[2])) > measurements['default.intervals'] = [ > {"name": "max_interval", "measure" : max(max_intervals)}, > {"name": "min_interval", "measure" : min(min_intervals)}, > -- > 2.1.4 > > > -- > ========================================================== > ====== > Hoang Van Tuyen (Mr.) > TOSHIBA SOFTWARE DEVELOPMENT (VIETNAM) CO., LTD. > 16th Floor, VIT Building, 519 Kim Ma Str., Ba Dinh Dist., Hanoi, Vietnam > Tel: 84-4-22208801 (Company) - Ext.251 > Fax: 84-4-22208802 (Company) > Email: tuyen.hoangvan at toshiba-tsdv.com > ========================================================== > ====== > > > -- > This mail was scanned by BitDefender > For more information please visit http://www.bitdefender.com > > _______________________________________________ > Fuego mailing list > Fuego at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/fuego From Tim.Bird at sony.com Thu Feb 8 06:28:42 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 8 Feb 2018 06:28:42 +0000 Subject: [Fuego] RFC - test/set/case documentation generation Message-ID: Hello all, I'm writing to let you know about a project that I've started, having to do with documenting tests, testsets, and test cases, as well as feeding into capabilities for report generation. It's a bit hard to describe the overall scope of the project, but it's quite big. I want to document every testcase that Fuego performs. This include a mixture of human-written documentation, and reports of results from tests performed on both local boards and eventually remote boards. My plan is to add a 'docs' directory under each test directory. Inside that there will be template files, which describe tests, test sets, and individual test cases. My plan is that the fuego system can combine test result data, with human-written text, in both HTML format (for use via the Jenkins intereface), and PDF format (for use in PDFs that are generated as test reports). The templates are written in reStructuredText, with macro directives to indicate what dynamic data to add to the templates. The template is processed by Fuego, and is output as an .rst file, which can be used as is as a straight text file, or further processed by sphynx to convert into either HTML (for access via the Jenkins interface) or latex (for publication in PDF test reports). It will likely take years to fill in all the testcases, but I expect that the list of documented testcases will likely always be sparse. Only the most important testcases will be documented at first, and they can be filled in as we go along. Having some testcases documented will be more useful than having no testcases documented. The first instance of this is not quite ready for usage yet, but you can get an idea of what I have planned by looking at: /fuego-core/engine/tests/Functional.LTP/docs/Functional.LTP.ftmp ('ftmp' stands for 'Fuego template') This is processed by Fuego (by a program called gen-page.py) and the output is placed in: /fuego-rw/docs/Functional.LTP.rst The intent is to further process this into /fuego-rw/logs/Fucntional.LTP/Functional.LTP.html and make that accessible via the Jenkins interface. This is in my 'master' branch, at commit 0eba4e6 Note that the information in Functional.LTP.ftmp is a little out-of-date, and the plan is to gather more information automatically (such as dependencies, spec list, etc.) over time. My idea is that using the same mechanisms, we will be able to generate reports from test data, that are a mixture of testcase results, summary data, detailed error reports, and human-written explanations of test operation and intent. One problem this is intended to solve has to do with report generation. But another problem is that many of our tests are very opaque. There's no human-readable documentation on the operation of the tests, what the results are supposed to mean, and what to do to resolve reported failures. Creating a documentation system like this will allow such human-generated text to be presented alongside results, hopefully making results interpretation much easier. Work on this is progressing slowly, due to other demands on my time. But I wanted to present the idea to allow people to give feedback on it. Please let me know what you think. Regards, -- Tim From barbieri at profusion.mobi Thu Feb 8 15:47:19 2018 From: barbieri at profusion.mobi (Gustavo Sverzut Barbieri) Date: Thu, 8 Feb 2018 13:47:19 -0200 Subject: [Fuego] RFC - test/set/case documentation generation In-Reply-To: References: Message-ID: On Thu, Feb 8, 2018 at 4:28 AM, wrote: > > Hello all, > > I'm writing to let you know about a project that I've started, having to do with > documenting tests, testsets, and test cases, as well as feeding into capabilities > for report generation. > > It's a bit hard to describe the overall scope of the project, but it's quite big. > I want to document every testcase that Fuego performs. This include a mixture > of human-written documentation, and reports of results from tests performed > on both local boards and eventually remote boards. > > My plan is to add a 'docs' directory under each test directory. Inside that > there will be template files, which describe tests, test sets, and individual test > cases. My plan is that the fuego system can combine test result data, with > human-written text, in both HTML format (for use via the Jenkins intereface), > and PDF format (for use in PDFs that are generated as test reports). > The templates are written in reStructuredText, with macro directives > to indicate what dynamic data to add to the templates. > > The template is processed by Fuego, and is output as an .rst file, which can > be used as is as a straight text file, or further processed by sphynx to convert > into either HTML (for access via the Jenkins interface) or latex (for publication > in PDF test reports). > > It will likely take years to fill in all the testcases, but I expect that the list of > documented testcases will likely always be sparse. Only the most important > testcases will be documented at first, and they can be filled in as we go along. > Having some testcases documented will be more useful than having no > testcases documented. > > The first instance of this is not quite ready for usage yet, but you can get an idea > of what I have planned by looking at: > /fuego-core/engine/tests/Functional.LTP/docs/Functional.LTP.ftmp > ('ftmp' stands for 'Fuego template') > This is processed by Fuego (by a program called gen-page.py) and > the output is placed in: > /fuego-rw/docs/Functional.LTP.rst > The intent is to further process this into > /fuego-rw/logs/Fucntional.LTP/Functional.LTP.html > and make that accessible via the Jenkins interface. > > This is in my 'master' branch, at commit 0eba4e6 > > Note that the information in Functional.LTP.ftmp is a little out-of-date, and > the plan is to gather more information automatically (such as dependencies, > spec list, etc.) over time. > > My idea is that using the same mechanisms, we will be able to generate reports > from test data, that are a mixture of testcase results, summary data, detailed > error reports, and human-written explanations of test operation and intent. > > One problem this is intended to solve has to do with report generation. But > another problem is that many of our tests are very opaque. There's no > human-readable documentation on the operation of the tests, what the results > are supposed to mean, and what to do to resolve reported failures. Creating a > documentation system like this will allow such human-generated text to be > presented alongside results, hopefully making results interpretation much easier. > > Work on this is progressing slowly, due to other demands on my time. > But I wanted to present the idea to allow people to give feedback on it. > > Please let me know what you think. Hi Tim, looks nice but my advice is to avoid pre-processing the rst (your ftmp format) and instead use reStructuredText and add your own directives, it's already meant for that. I'd even go further and say that's better to setup an sphinx for the project and create your own extension, then you can provide those as needed AND scan for files in the directory structure. For example Python's autodoc and the does something like that for python modules. Initially you can avoid much of the burden by: - start sphinx project in the root directory - manually link the child .rst until you create your own autoindex kind of function - in the child .rst you .. literalinclude:: results from some directory until you create your own directives or roles with that, no gen-pages is needed, just run the tests (to populate the directories with results you're including as "literalinclude") and it should produce the contents. then you can create your sphinx extension (inside this repository, just list it in the sphinx config) and start to provide the directives and macros... they can do lots of stuff, like generate tables and other sphinx formatting (ie: there are modules that does syntax highlight using pygments). You can receive parameters in them, and you can get the file/path of the file being processed, so you can discover the test name and all. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN, GTalk, FaceTime: barbieri at gmail.com Skype: gsbarbieri Mobile: +55 (16) 99354-9890 From Tim.Bird at sony.com Thu Feb 8 18:22:23 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 8 Feb 2018 18:22:23 +0000 Subject: [Fuego] RFC - test/set/case documentation generation In-Reply-To: References: Message-ID: Response at the bottom... > -----Original Message----- > From: Gustavo Sverzut Barbieri > On Thu, Feb 8, 2018 at 4:28 AM, wrote: > > > > Hello all, > > > > I'm writing to let you know about a project that I've started, having to do > with > > documenting tests, testsets, and test cases, as well as feeding into > capabilities > > for report generation. > > > > It's a bit hard to describe the overall scope of the project, but it's quite big. > > I want to document every testcase that Fuego performs. This include a > mixture > > of human-written documentation, and reports of results from tests > performed > > on both local boards and eventually remote boards. > > > > My plan is to add a 'docs' directory under each test directory. Inside that > > there will be template files, which describe tests, test sets, and individual > test > > cases. My plan is that the fuego system can combine test result data, with > > human-written text, in both HTML format (for use via the Jenkins > intereface), > > and PDF format (for use in PDFs that are generated as test reports). > > The templates are written in reStructuredText, with macro directives > > to indicate what dynamic data to add to the templates. > > > > The template is processed by Fuego, and is output as an .rst file, which can > > be used as is as a straight text file, or further processed by sphynx to > convert > > into either HTML (for access via the Jenkins interface) or latex (for > publication > > in PDF test reports). > > > > It will likely take years to fill in all the testcases, but I expect that the list of > > documented testcases will likely always be sparse. Only the most > important > > testcases will be documented at first, and they can be filled in as we go > along. > > Having some testcases documented will be more useful than having no > > testcases documented. > > > > The first instance of this is not quite ready for usage yet, but you can get an > idea > > of what I have planned by looking at: > > /fuego-core/engine/tests/Functional.LTP/docs/Functional.LTP.ftmp > > ('ftmp' stands for 'Fuego template') > > This is processed by Fuego (by a program called gen-page.py) and > > the output is placed in: > > /fuego-rw/docs/Functional.LTP.rst > > The intent is to further process this into > > /fuego-rw/logs/Fucntional.LTP/Functional.LTP.html > > and make that accessible via the Jenkins interface. > > > > This is in my 'master' branch, at commit 0eba4e6 > > > > Note that the information in Functional.LTP.ftmp is a little out-of-date, and > > the plan is to gather more information automatically (such as > dependencies, > > spec list, etc.) over time. > > > > My idea is that using the same mechanisms, we will be able to generate > reports > > from test data, that are a mixture of testcase results, summary data, > detailed > > error reports, and human-written explanations of test operation and > intent. > > > > One problem this is intended to solve has to do with report generation. > But > > another problem is that many of our tests are very opaque. There's no > > human-readable documentation on the operation of the tests, what the > results > > are supposed to mean, and what to do to resolve reported failures. > Creating a > > documentation system like this will allow such human-generated text to be > > presented alongside results, hopefully making results interpretation much > easier. > > > > Work on this is progressing slowly, due to other demands on my time. > > But I wanted to present the idea to allow people to give feedback on it. > > > > Please let me know what you think. > > Hi Tim, looks nice but my advice is to avoid pre-processing the rst > (your ftmp format) and instead use reStructuredText and add your own > directives, it's already meant for that. You may notice that my "macro" actually has the same syntax as an reStructuredText directive. This was done specifically to allow the possibility of converting over to the flow of processing that you mention below. As an aside, what does Sphynx do with directives it doesn't recognize? (Sorry - I'm too lazy to go test is right now, but if someone knows off the top of their head please let me know.) > > I'd even go further and say that's better to setup an sphinx for the > project and create your own extension, then you can provide those as > needed AND scan for files in the directory structure. For example > Python's autodoc and the does something like that for python modules. > > Initially you can avoid much of the burden by: > > - start sphinx project in the root directory > - manually link the child .rst until you create your own autoindex > kind of function > - in the child .rst you .. literalinclude:: results from some > directory until you create your own directives or roles > > with that, no gen-pages is needed, just run the tests (to populate the > directories with results you're including as "literalinclude") and it > should produce the contents. > > then you can create your sphinx extension (inside this repository, > just list it in the sphinx config) and start to provide the directives > and macros... they can do lots of stuff, like generate tables and > other sphinx formatting (ie: there are modules that does syntax > highlight using pygments). You can receive parameters in them, and you > can get the file/path of the file being processed, so you can discover > the test name and all. Thanks very much for the feedback. I am by no means sure that the approach I have taken is optimal, so I really appreciate other ideas for implementing this. With regard to sphynx, I definitely want to make it a first-class tool in our container, and possibly add fuego-specific extensions (directives) to it. I took a look yesterday at how to write extensions for it, and they look powerful, and straightforward to write. I've already started moving the regular Fuego documentation over to reStructuredText, but I don't recall if I've made the changes to include sphynx in the Dockerfile yet. I'll think more about your suggestion as I keep working on this. -- Tim From guicc at profusion.mobi Thu Feb 8 18:51:33 2018 From: guicc at profusion.mobi (Guilherme Campos Camargo) Date: Thu, 8 Feb 2018 16:51:33 -0200 Subject: [Fuego] [PATCH] Allow ftc script to properly use Jenkins configured port Message-ID: <20180208185133.9092-1-guicc@profusion.mobi> Hello, Tim. Please see my modifications below. I was looking for an utils directory/submodule with existing python stuff where I could store the newly added read_conf function, but haven't found any. Given that the function file is very straightforward, I just left it in here, right next to your other utility function. Please let me know if you'd rather have it moved somewhere else. Anyway, I think it would be nice if we could keep these and other python utility funcions in a separate submodule in the future, so that they can be easily imported by different python scripts. Please let me know what you think about that. Thanks -- Commit Message: With the possibility of configuring jenkins porth through fuego/ro/conf/fuego.conf, a change on ftc script is needed so that it uses the configured port and not the default one (8080). This patch solves that issue by using the ${jenkins_port} environment variable (set on entrypoint.sh) instead of the hardcoded 8080. Signed-off-by: Guilherme Campos Camargo --- engine/scripts/ftc | 30 ++++++++++++++++++++++-------- 1 file changed, 22 insertions(+), 8 deletions(-) diff --git a/engine/scripts/ftc b/engine/scripts/ftc index 06dadcf..2cf0019 100755 --- a/engine/scripts/ftc +++ b/engine/scripts/ftc @@ -60,19 +60,33 @@ import glob # MAJOR, MINOR, REVISION VERSION = (1,2,1) -# define these as globals -log = None -tail_fd = None - # here's a utility routine to print a variable with it's name and value def pvar(name): caller = sys._getframe(1) print "DEBUG: python var %s=%s" % (name, caller.f_locals[name]) +# here's a utility routine that reads from a configuration file where configs +# are stored as KEY=VALUE pairs (as .env files) +def read_conf(fname): + def split_pair(line): + return line.strip().split('=', 1) + with open(fname) as f: + pairs = [split_pair(line) for line in f.readlines()] + return dict(pairs) + +# define these as globals +log = None +tail_fd = None + +FUEGO_CFG_PATH = '/fuego-ro/conf/fuego.conf' +fuego_config = read_conf(FUEGO_CFG_PATH) +jenkins_port = fuego_config.get('jenkins_port', 8080) +fuego_url = 'http://localhost:' + str(jenkins_port) + '/fuego' + quiet = 0 verbose = 0 use_statusouput = 1 -server = jenkins.Jenkins('http://localhost:8080/fuego') +server = jenkins.Jenkins(fuego_url) # keep configuration file in /fuego-ro/conf area config_dir = "/fuego-ro" @@ -413,7 +427,7 @@ class config_class: # fuegotest.com is at: 52.88.166.49 self.SERVER_URL_BASE = "http://52.88.166.49/server/Fuego_Server?action=Fuego." - self.JENKINS_URL = "http://localhost:8080/fuego" + self.JENKINS_URL = fuego_url # end of default configs @@ -1159,7 +1173,7 @@ timeout --signal=9 {timeout} /bin/bash $FUEGO_CORE/engine/scripts/main.sh job_name=board+"."+test.spec+"."+test.name print("Creating job " + job_name) try: - subprocess.call('java -jar /var/cache/jenkins/war/WEB-INF/jenkins-cli.jar -s http://localhost:8080/fuego create-job ' + + subprocess.call('java -jar /var/cache/jenkins/war/WEB-INF/jenkins-cli.jar -s' + fuego_url + 'create-job ' + job_name + ' < ' + tmp, shell=True) os.unlink(tmp) except Exception as e: @@ -1207,7 +1221,7 @@ def create_batch_job(board, testplan, plan_tests): print("Creating batch job ") try: job_name = board+'.'+testplan+'.batch' - subprocess.call('java -jar /var/cache/jenkins/war/WEB-INF/jenkins-cli.jar -s http://localhost:8080/fuego create-job ' + + subprocess.call('java -jar /var/cache/jenkins/war/WEB-INF/jenkins-cli.jar -s' + fuego_url + 'create-job ' + job_name + '< ' + tmp, shell=True) os.unlink(tmp) except Exception as e: -- 2.16.1 From barbieri at profusion.mobi Thu Feb 8 18:53:46 2018 From: barbieri at profusion.mobi (Gustavo Sverzut Barbieri) Date: Thu, 8 Feb 2018 16:53:46 -0200 Subject: [Fuego] RFC - test/set/case documentation generation In-Reply-To: References: Message-ID: >> > Please let me know what you think. >> >> Hi Tim, looks nice but my advice is to avoid pre-processing the rst >> (your ftmp format) and instead use reStructuredText and add your own >> directives, it's already meant for that. > > You may notice that my "macro" actually has the same syntax as > an reStructuredText directive. This was done specifically to allow > the possibility of converting over to the flow of processing that > you mention below. sure, but then keep the same extension (so github/bitucket...) handle it properly. And also note the final "::" (two), otherwise it's handled as comment (leading ".." without trailing "::") > As an aside, what does Sphynx do with directives it doesn't recognize? > (Sorry - I'm too lazy to go test is right now, but if someone knows > off the top of their head please let me know.) not sure, I never tried that... but I guess it will report errors and keep going. Github/Bitbucket keep it untouched (you see the actual text). >> I'd even go further and say that's better to setup an sphinx for the >> project and create your own extension, then you can provide those as >> needed AND scan for files in the directory structure. For example >> Python's autodoc and the does something like that for python modules. >> >> Initially you can avoid much of the burden by: >> >> - start sphinx project in the root directory >> - manually link the child .rst until you create your own autoindex >> kind of function >> - in the child .rst you .. literalinclude:: results from some >> directory until you create your own directives or roles >> >> with that, no gen-pages is needed, just run the tests (to populate the >> directories with results you're including as "literalinclude") and it >> should produce the contents. >> >> then you can create your sphinx extension (inside this repository, >> just list it in the sphinx config) and start to provide the directives >> and macros... they can do lots of stuff, like generate tables and >> other sphinx formatting (ie: there are modules that does syntax >> highlight using pygments). You can receive parameters in them, and you >> can get the file/path of the file being processed, so you can discover >> the test name and all. > > Thanks very much for the feedback. I am by no means sure that the > approach I have taken is optimal, so I really appreciate other ideas > for implementing this. > > With regard to sphynx, I definitely want to make it a first-class tool > in our container, and possibly add fuego-specific extensions (directives) to it. > I took a look yesterday at how to write extensions for it, and they > look powerful, and straightforward to write. I've already started moving > the regular Fuego documentation over to reStructuredText, but I don't > recall if I've made the changes to include sphynx in the Dockerfile yet. > > I'll think more about your suggestion as I keep working on this. you're welcome. It's a bit steep learning curve to get started (compared to plain python + readlines + regexp), but at the end it pays off. With some days looking into that, you can get it going. There's not much documentation, but you can look the source of similar extensions to see how things work (that's how i learnt). you get called with a list of options + body... after that, just return the rst "ast"... you can either create on manually, using elements such as "paragraph" or generate a text string and ask it to be parsed (ie: when you do a quote block: generate a new toplevel element yourself (blockquote) then ask it to parse the contents), this is self.state.nested_parse() from your directive... then everything else is handled for you, output to LaTeX/PDF, HTML, manpage, etc... -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN, GTalk, FaceTime: barbieri at gmail.com Skype: gsbarbieri Mobile: +55 (16) 99354-9890 From Tim.Bird at sony.com Thu Feb 8 19:17:21 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 8 Feb 2018 19:17:21 +0000 Subject: [Fuego] [PATCH] Allow ftc script to properly use Jenkins configured port In-Reply-To: <20180208185133.9092-1-guicc@profusion.mobi> References: <20180208185133.9092-1-guicc@profusion.mobi> Message-ID: > -----Original Message----- > From: Guilherme Campos Camargo > > Hello, Tim. Please see my modifications below. I was looking for an > utils directory/submodule with existing python stuff where I could store > the newly added read_conf function, but haven't found any. Given that > the function file is very straightforward, I just left it in here, right > next to your other utility function. Please let me know if you'd rather > have it moved somewhere else. Probably, but I'm not sure where yet > > Anyway, I think it would be nice if we could keep these and other python > utility funcions in a separate submodule in the future, so that they can > be easily imported by different python scripts. Please let me know what > you think about that. I agree completely. I suspect other files may have the hardcoded 8080 in them, and sharing a utility routine to read the configuration will be good. Also, it's unknown what other features and data we'll add to conf file, so it would be nice to have a single routine that reads it, in case it gets gnarly later. This is OK placement for now, though. > > Thanks > > -- > Commit Message: > > With the possibility of configuring jenkins porth through > fuego/ro/conf/fuego.conf, a change on ftc script is needed so that it > uses the configured port and not the default one (8080). > > This patch solves that issue by using the ${jenkins_port} environment > variable (set on entrypoint.sh) instead of the hardcoded 8080. > > Signed-off-by: Guilherme Campos Camargo > --- > engine/scripts/ftc | 30 ++++++++++++++++++++++-------- > 1 file changed, 22 insertions(+), 8 deletions(-) > > diff --git a/engine/scripts/ftc b/engine/scripts/ftc > index 06dadcf..2cf0019 100755 > --- a/engine/scripts/ftc > +++ b/engine/scripts/ftc > @@ -60,19 +60,33 @@ import glob > # MAJOR, MINOR, REVISION > VERSION = (1,2,1) > > -# define these as globals > -log = None > -tail_fd = None > - > # here's a utility routine to print a variable with it's name and value > def pvar(name): > caller = sys._getframe(1) > print "DEBUG: python var %s=%s" % (name, caller.f_locals[name]) > > +# here's a utility routine that reads from a configuration file where configs > +# are stored as KEY=VALUE pairs (as .env files) > +def read_conf(fname): > + def split_pair(line): > + return line.strip().split('=', 1) > + with open(fname) as f: > + pairs = [split_pair(line) for line in f.readlines()] > + return dict(pairs) I'll probably expand this a bit, to handle blank lines and lines preceded with '#'. It might be good to get one more strip in there as well, on the split items to handle stuff like: ' foo = bar ' But I'll do that in a separate patch (and as a lower priority change). I love the simplicity of this routine, by the way. > + > +# define these as globals > +log = None > +tail_fd = None > + > +FUEGO_CFG_PATH = '/fuego-ro/conf/fuego.conf' > +fuego_config = read_conf(FUEGO_CFG_PATH) This needs to be done after the check for whether we're inside the docker container, or check the environment for FUEGO_RO. ftc run outside the container won't be able to read the configuration file from under /fuego-ro (that is, at the root). See the code for checking inside_docker() at the top of the 'main' function. If it's too complicated to move the read_conf, then for now, I'd be satisfied with checking for the existence of '/fuego-ro', and just returning an empty dictionary. The only thing that an outside-the-container 'ftc' does is immediately call 'ftc' inside the container. So it shouldn't need any configuration values. (cross our fingers and hope it stays that way....) We don't really have a mechanism to figure out where the conf file is when 'ftc' is outside the container (especially if there are multiple fuegos running around), so we don't have much choice. > +jenkins_port = fuego_config.get('jenkins_port', 8080) > +fuego_url = 'http://localhost:' + str(jenkins_port) + '/fuego' > + > quiet = 0 > verbose = 0 > use_statusouput = 1 > -server = jenkins.Jenkins('http://localhost:8080/fuego') > +server = jenkins.Jenkins(fuego_url) > > # keep configuration file in /fuego-ro/conf area > config_dir = "/fuego-ro" > @@ -413,7 +427,7 @@ class config_class: > > # fuegotest.com is at: 52.88.166.49 > self.SERVER_URL_BASE = > "http://52.88.166.49/server/Fuego_Server?action=Fuego." > - self.JENKINS_URL = "http://localhost:8080/fuego" > + self.JENKINS_URL = fuego_url > > # end of default configs > > @@ -1159,7 +1173,7 @@ timeout --signal=9 {timeout} /bin/bash > $FUEGO_CORE/engine/scripts/main.sh > job_name=board+"."+test.spec+"."+test.name > print("Creating job " + job_name) > try: > - subprocess.call('java -jar /var/cache/jenkins/war/WEB-INF/jenkins- > cli.jar -s http://localhost:8080/fuego create-job ' + > + subprocess.call('java -jar /var/cache/jenkins/war/WEB-INF/jenkins- > cli.jar -s' + fuego_url + 'create-job ' + > job_name + ' < ' + tmp, shell=True) > os.unlink(tmp) > except Exception as e: > @@ -1207,7 +1221,7 @@ def create_batch_job(board, testplan, plan_tests): > print("Creating batch job ") > try: > job_name = board+'.'+testplan+'.batch' > - subprocess.call('java -jar /var/cache/jenkins/war/WEB-INF/jenkins- > cli.jar -s http://localhost:8080/fuego create-job ' + > + subprocess.call('java -jar /var/cache/jenkins/war/WEB-INF/jenkins- > cli.jar -s' + fuego_url + 'create-job ' + > job_name + '< ' + tmp, shell=True) > os.unlink(tmp) > except Exception as e: > -- > 2.16.1 The rest of this is fine. -- Tim From barbieri at profusion.mobi Thu Feb 8 19:28:48 2018 From: barbieri at profusion.mobi (Gustavo Sverzut Barbieri) Date: Thu, 8 Feb 2018 17:28:48 -0200 Subject: [Fuego] [PATCH] Allow ftc script to properly use Jenkins configured port In-Reply-To: References: <20180208185133.9092-1-guicc@profusion.mobi> Message-ID: On Thu, Feb 8, 2018 at 5:17 PM, wrote: >> -----Original Message----- >> From: Guilherme Campos Camargo >> >> Hello, Tim. Please see my modifications below. I was looking for an >> utils directory/submodule with existing python stuff where I could store >> the newly added read_conf function, but haven't found any. Given that >> the function file is very straightforward, I just left it in here, right >> next to your other utility function. Please let me know if you'd rather >> have it moved somewhere else. > Probably, but I'm not sure where yet > >> >> Anyway, I think it would be nice if we could keep these and other python >> utility funcions in a separate submodule in the future, so that they can >> be easily imported by different python scripts. Please let me know what >> you think about that. > I agree completely. I suspect other files may have the hardcoded 8080 in > them, and sharing a utility routine to read the configuration will be good. > Also, it's unknown what other features and data we'll add to conf file, so it would > be nice to have a single routine that reads it, in case it gets gnarly later. > > This is OK placement for now, though. >> >> Thanks >> >> -- >> Commit Message: >> >> With the possibility of configuring jenkins porth through >> fuego/ro/conf/fuego.conf, a change on ftc script is needed so that it >> uses the configured port and not the default one (8080). >> >> This patch solves that issue by using the ${jenkins_port} environment >> variable (set on entrypoint.sh) instead of the hardcoded 8080. >> >> Signed-off-by: Guilherme Campos Camargo >> --- >> engine/scripts/ftc | 30 ++++++++++++++++++++++-------- >> 1 file changed, 22 insertions(+), 8 deletions(-) >> >> diff --git a/engine/scripts/ftc b/engine/scripts/ftc >> index 06dadcf..2cf0019 100755 >> --- a/engine/scripts/ftc >> +++ b/engine/scripts/ftc >> @@ -60,19 +60,33 @@ import glob >> # MAJOR, MINOR, REVISION >> VERSION = (1,2,1) >> >> -# define these as globals >> -log = None >> -tail_fd = None >> - >> # here's a utility routine to print a variable with it's name and value >> def pvar(name): >> caller = sys._getframe(1) >> print "DEBUG: python var %s=%s" % (name, caller.f_locals[name]) >> >> +# here's a utility routine that reads from a configuration file where configs >> +# are stored as KEY=VALUE pairs (as .env files) >> +def read_conf(fname): >> + def split_pair(line): >> + return line.strip().split('=', 1) >> + with open(fname) as f: >> + pairs = [split_pair(line) for line in f.readlines()] >> + return dict(pairs) > I'll probably expand this a bit, to handle blank lines and lines preceded with '#'. > It might be good to get one more strip in there as well, on the split items > to handle stuff like: > ' foo = bar ' > But I'll do that in a separate patch (and as a lower priority change). hi tim, so could you consider moving to Python's ConfigParser? Saves code, uniform file format... just misses the "source conf" in bash, but I wonder if that will be needed. In any case you can provide a tool such as others do (docker-machine env, etc), which would convert to plain shell variables (basically read and print as "%s=%r" % (key, value)) > I love the simplicity of this routine, by the way. > >> + >> +# define these as globals >> +log = None >> +tail_fd = None >> + >> +FUEGO_CFG_PATH = '/fuego-ro/conf/fuego.conf' >> +fuego_config = read_conf(FUEGO_CFG_PATH) > This needs to be done after the check for whether we're inside the > docker container, or check the environment for FUEGO_RO. > > ftc run outside the container won't be able to read the configuration > file from under /fuego-ro (that is, at the root). > > See the code for checking inside_docker() at the top of the 'main' function. > > If it's too complicated to move the read_conf, then for now, I'd be satisfied > with checking for the existence of '/fuego-ro', and just returning an empty dictionary. > The only thing that an outside-the-container 'ftc' does is immediately call 'ftc' > inside the container. So it shouldn't need any configuration values. > (cross our fingers and hope it stays that way....) > We don't really have a mechanism to figure out where the conf file is when > 'ftc' is outside the container (especially if there are multiple fuegos running > around), so we don't have much choice. something that I'm wondering: why do we ever need to run ftc *outside* of the container? shouldn't a bash-alias solve this issue for people that want to do that? for instance, when using docker-swarm you have the same issue to select which host you're talking to... then they offer this eval `docker-machine env` to setup variables and you can also do aliases or functions... -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN, GTalk, FaceTime: barbieri at gmail.com Skype: gsbarbieri Mobile: +55 (16) 99354-9890 From Tim.Bird at sony.com Thu Feb 8 19:29:54 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 8 Feb 2018 19:29:54 +0000 Subject: [Fuego] RFC - test/set/case documentation generation In-Reply-To: References: Message-ID: > -----Original Message----- > From: Gustavo Sverzut Barbieri > > You may notice that my "macro" actually has the same syntax as > > an reStructuredText directive. This was done specifically to allow > > the possibility of converting over to the flow of processing that > > you mention below. > > sure, but then keep the same extension (so github/bitucket...) handle > it properly. And also note the final "::" (two), otherwise it's > handled as comment (leading ".." without trailing "::") I saw your comment on the commit. Thanks for catching that. I just fixed it. Thanks! -- Tim From guicc at profusion.mobi Thu Feb 8 19:44:09 2018 From: guicc at profusion.mobi (Guilherme Camargo) Date: Thu, 8 Feb 2018 17:44:09 -0200 Subject: [Fuego] Release process steps/scripts Message-ID: Hi, Tim. In Fuego's release process Wiki ( http://fuegotest.org/wiki/Fuego_release_process) the "Test changes since last release" section refers to fuego-clean-install.sh and fuego-finish-install.sh. From my understanding those would replace the legacy steps that are described right below, in the next section. I searched for those scripts in Fuego's repositories, but couldn't find them anywhere. Maybe I looking at the wrong place - or not getting the instructions right? If they're still used, could you please provide me a link to them? Thanks. -- Guilherme -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Bird at sony.com Thu Feb 8 19:48:21 2018 From: Tim.Bird at sony.com (Bird, Timothy) Date: Thu, 8 Feb 2018 19:48:21 +0000 Subject: [Fuego] Release process steps/scripts In-Reply-To: References: Message-ID: > -----Original Message----- > From: Guilherme Camargo > Hi, Tim. > > In Fuego's release process Wiki > (http://fuegotest.org/wiki/Fuego_release_process) the "Test changes since > last release" section refers to fuego-clean-install.sh and fuego-finish- > install.sh. From my understanding those would replace the legacy steps that > are described right below, in the next section. > > I searched for those scripts in Fuego's repositories, but couldn't find them > anywhere. Maybe I looking at the wrong place - or not getting the > instructions right? If they're still used, could you please provide me a link to > them? Yeah - those wiki pages were originally just my personal notes for doing release management, and the scripts were my own personal scripts to automate it. They're not very pretty, so I never checked them in. Sorry about that. I haven't scanned these to see if there's any personal information I should extract, so I'm going to send them to you privately. -- Tim From guicc at profusion.mobi Thu Feb 8 19:50:05 2018 From: guicc at profusion.mobi (Guilherme Camargo) Date: Thu, 8 Feb 2018 17:50:05 -0200 Subject: [Fuego] Release process steps/scripts In-Reply-To: References: Message-ID: No problem, Tim. Thanks On Thu, Feb 8, 2018 at 5:48 PM, Bird, Timothy wrote: > > > > -----Original Message----- > > From: Guilherme Camargo > > Hi, Tim. > > > > In Fuego's release process Wiki > > (http://fuegotest.org/wiki/Fuego_release_process) the "Test changes > since > > last release" section refers to fuego-clean-install.sh and fuego-finish- > > install.sh. From my understanding those would replace the legacy steps > that > > are described right below, in the next section. > > > > I searched for those scripts in Fuego's repositories, but couldn't find > them > > anywhere. Maybe I looking at the wrong place - or not getting the > > instructions right? If they're still used, could you please provide me a > link to > > them? > > Yeah - those wiki pages were originally just my personal notes for doing > release management, and the scripts were my own personal scripts to > automate it. They're not very pretty, so I never checked them in. > Sorry about that. > > I haven't scanned these to see if there's > any personal information I should extract, so I'm going to send them to > you privately. > -- Tim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Bird at sony.com Thu Feb 8 20:02:43 2018 From: Tim.Bird at sony.com (Bird, Timothy) Date: Thu, 8 Feb 2018 20:02:43 +0000 Subject: [Fuego] [PATCH] Allow ftc script to properly use Jenkins configured port In-Reply-To: References: <20180208185133.9092-1-guicc@profusion.mobi> Message-ID: > hi tim, so could you consider moving to Python's ConfigParser? Saves > code, uniform file format... just misses the "source conf" in bash, > but I wonder if that will be needed. In any case you can provide a > tool such as others do (docker-machine env, etc), which would convert > to plain shell variables (basically read and print as "%s=%r" % (key, > value)) Actually, thinking about this more... Maybe we should add an 'ftc config' command, similar to 'git config', that would allow reading one variable. Then we could do something like: jenkins_port="$(ftc config jenkins_port)" in entrypoint.sh (and similar code in other places in fuego). Then we could switch to some standard parser like Python's. -- Tim From Tim.Bird at sony.com Thu Feb 8 20:33:35 2018 From: Tim.Bird at sony.com (Bird, Timothy) Date: Thu, 8 Feb 2018 20:33:35 +0000 Subject: [Fuego] [PATCH] Allow ftc script to properly use Jenkins configured port In-Reply-To: References: <20180208185133.9092-1-guicc@profusion.mobi> Message-ID: > -----Original Message----- > From: Gustavo Sverzut Barbieri > On Thu, Feb 8, 2018 at 5:17 PM, wrote: > >> -----Original Message----- > >> From: Guilherme Campos Camargo > >> > >> Hello, Tim. Please see my modifications below. I was looking for an > >> utils directory/submodule with existing python stuff where I could store > >> the newly added read_conf function, but haven't found any. Given that > >> the function file is very straightforward, I just left it in here, right > >> next to your other utility function. Please let me know if you'd rather > >> have it moved somewhere else. > > Probably, but I'm not sure where yet > > > >> > >> Anyway, I think it would be nice if we could keep these and other python > >> utility funcions in a separate submodule in the future, so that they can > >> be easily imported by different python scripts. Please let me know what > >> you think about that. > > I agree completely. I suspect other files may have the hardcoded 8080 in > > them, and sharing a utility routine to read the configuration will be good. > > Also, it's unknown what other features and data we'll add to conf file, so it > would > > be nice to have a single routine that reads it, in case it gets gnarly later. > > > > This is OK placement for now, though. > >> > >> Thanks > >> > >> -- > >> Commit Message: > >> > >> With the possibility of configuring jenkins porth through > >> fuego/ro/conf/fuego.conf, a change on ftc script is needed so that it > >> uses the configured port and not the default one (8080). > >> > >> This patch solves that issue by using the ${jenkins_port} environment > >> variable (set on entrypoint.sh) instead of the hardcoded 8080. > >> > >> Signed-off-by: Guilherme Campos Camargo > >> --- > >> engine/scripts/ftc | 30 ++++++++++++++++++++++-------- > >> 1 file changed, 22 insertions(+), 8 deletions(-) > >> > >> diff --git a/engine/scripts/ftc b/engine/scripts/ftc > >> index 06dadcf..2cf0019 100755 > >> --- a/engine/scripts/ftc > >> +++ b/engine/scripts/ftc > >> @@ -60,19 +60,33 @@ import glob > >> # MAJOR, MINOR, REVISION > >> VERSION = (1,2,1) > >> > >> -# define these as globals > >> -log = None > >> -tail_fd = None > >> - > >> # here's a utility routine to print a variable with it's name and value > >> def pvar(name): > >> caller = sys._getframe(1) > >> print "DEBUG: python var %s=%s" % (name, caller.f_locals[name]) > >> > >> +# here's a utility routine that reads from a configuration file where > configs > >> +# are stored as KEY=VALUE pairs (as .env files) > >> +def read_conf(fname): > >> + def split_pair(line): > >> + return line.strip().split('=', 1) > >> + with open(fname) as f: > >> + pairs = [split_pair(line) for line in f.readlines()] > >> + return dict(pairs) > > I'll probably expand this a bit, to handle blank lines and lines preceded with > '#'. > > It might be good to get one more strip in there as well, on the split items > > to handle stuff like: > > ' foo = bar ' > > But I'll do that in a separate patch (and as a lower priority change). > > hi tim, so could you consider moving to Python's ConfigParser? Saves > code, uniform file format... just misses the "source conf" in bash, Yeah, that source conf in bash seems like a bit of a hack. But I do like the simplicity of handling it in entrypoint.sh directly. > but I wonder if that will be needed. In any case you can provide a > tool such as others do (docker-machine env, etc), which would convert > to plain shell variables (basically read and print as "%s=%r" % (key, > value)) That's possible. How would entrypoint.sh read this without going through a byzantine process of read the config, save envs to a file, sourcing the file? I mean I could have done something like this, for just this simple line: (and ignored the format of the rest of the file) jenkins_port=$(grep jenkins_port /fuego-ro/conf/fuego.conf | sed "s/^jenkins_port=//") That has its own ugliness, when the shell supports reading this format directly. > > > > > I love the simplicity of this routine, by the way. > > > >> + > >> +# define these as globals > >> +log = None > >> +tail_fd = None > >> + > >> +FUEGO_CFG_PATH = '/fuego-ro/conf/fuego.conf' > >> +fuego_config = read_conf(FUEGO_CFG_PATH) > > This needs to be done after the check for whether we're inside the > > docker container, or check the environment for FUEGO_RO. > > > > ftc run outside the container won't be able to read the configuration > > file from under /fuego-ro (that is, at the root). > > > > See the code for checking inside_docker() at the top of the 'main' function. > > > > If it's too complicated to move the read_conf, then for now, I'd be satisfied > > with checking for the existence of '/fuego-ro', and just returning an empty > dictionary. > > The only thing that an outside-the-container 'ftc' does is immediately call > 'ftc' > > inside the container. So it shouldn't need any configuration values. > > (cross our fingers and hope it stays that way....) > > We don't really have a mechanism to figure out where the conf file is when > > 'ftc' is outside the container (especially if there are multiple fuegos running > > around), so we don't have much choice. > > something that I'm wondering: why do we ever need to run ftc *outside* > of the container? shouldn't a bash-alias solve this issue for people > that want to do that? No. It's not a given that fuego will always be running in a container. Some people have complained about the overhead of the container. If you have the necessary stuff installed on your host, and don't want to use Jenkins as your front end, there actually only a few things required to allow you to run Fuego on the command line as a regular host process. (e.g. you could do 'ftc run-test' and not talk to a container). This is an incomplete feature now, that I wanted to allow for in the future. (Of course, figuring out where the FUEGO_RO, FUEGO_CORE and FUEGO_RW dirs. would be essential for this. My plan was to put these into a section of the conf file, and thus reduce the required explicit information down to one path.) -- Tim From barbieri at profusion.mobi Thu Feb 8 21:56:07 2018 From: barbieri at profusion.mobi (Gustavo Sverzut Barbieri) Date: Thu, 8 Feb 2018 19:56:07 -0200 Subject: [Fuego] [PATCH] Allow ftc script to properly use Jenkins configured port In-Reply-To: References: <20180208185133.9092-1-guicc@profusion.mobi> Message-ID: On Thu, Feb 8, 2018 at 6:33 PM, Bird, Timothy wrote: > > >> -----Original Message----- >> From: Gustavo Sverzut Barbieri >> On Thu, Feb 8, 2018 at 5:17 PM, wrote: >> >> -----Original Message----- >> >> From: Guilherme Campos Camargo >> >> >> >> Hello, Tim. Please see my modifications below. I was looking for an >> >> utils directory/submodule with existing python stuff where I could store >> >> the newly added read_conf function, but haven't found any. Given that >> >> the function file is very straightforward, I just left it in here, right >> >> next to your other utility function. Please let me know if you'd rather >> >> have it moved somewhere else. >> > Probably, but I'm not sure where yet >> > >> >> >> >> Anyway, I think it would be nice if we could keep these and other python >> >> utility funcions in a separate submodule in the future, so that they can >> >> be easily imported by different python scripts. Please let me know what >> >> you think about that. >> > I agree completely. I suspect other files may have the hardcoded 8080 in >> > them, and sharing a utility routine to read the configuration will be good. >> > Also, it's unknown what other features and data we'll add to conf file, so it >> would >> > be nice to have a single routine that reads it, in case it gets gnarly later. >> > >> > This is OK placement for now, though. >> >> >> >> Thanks >> >> >> >> -- >> >> Commit Message: >> >> >> >> With the possibility of configuring jenkins porth through >> >> fuego/ro/conf/fuego.conf, a change on ftc script is needed so that it >> >> uses the configured port and not the default one (8080). >> >> >> >> This patch solves that issue by using the ${jenkins_port} environment >> >> variable (set on entrypoint.sh) instead of the hardcoded 8080. >> >> >> >> Signed-off-by: Guilherme Campos Camargo >> >> --- >> >> engine/scripts/ftc | 30 ++++++++++++++++++++++-------- >> >> 1 file changed, 22 insertions(+), 8 deletions(-) >> >> >> >> diff --git a/engine/scripts/ftc b/engine/scripts/ftc >> >> index 06dadcf..2cf0019 100755 >> >> --- a/engine/scripts/ftc >> >> +++ b/engine/scripts/ftc >> >> @@ -60,19 +60,33 @@ import glob >> >> # MAJOR, MINOR, REVISION >> >> VERSION = (1,2,1) >> >> >> >> -# define these as globals >> >> -log = None >> >> -tail_fd = None >> >> - >> >> # here's a utility routine to print a variable with it's name and value >> >> def pvar(name): >> >> caller = sys._getframe(1) >> >> print "DEBUG: python var %s=%s" % (name, caller.f_locals[name]) >> >> >> >> +# here's a utility routine that reads from a configuration file where >> configs >> >> +# are stored as KEY=VALUE pairs (as .env files) >> >> +def read_conf(fname): >> >> + def split_pair(line): >> >> + return line.strip().split('=', 1) >> >> + with open(fname) as f: >> >> + pairs = [split_pair(line) for line in f.readlines()] >> >> + return dict(pairs) >> > I'll probably expand this a bit, to handle blank lines and lines preceded with >> '#'. >> > It might be good to get one more strip in there as well, on the split items >> > to handle stuff like: >> > ' foo = bar ' >> > But I'll do that in a separate patch (and as a lower priority change). >> >> hi tim, so could you consider moving to Python's ConfigParser? Saves >> code, uniform file format... just misses the "source conf" in bash, > Yeah, that source conf in bash seems like a bit of a hack. But I do like the > simplicity of handling it in entrypoint.sh directly. > >> but I wonder if that will be needed. In any case you can provide a >> tool such as others do (docker-machine env, etc), which would convert >> to plain shell variables (basically read and print as "%s=%r" % (key, >> value)) > That's possible. How would entrypoint.sh read this without going through > a byzantine process of read the config, save envs to a file, sourcing the > file? > > I mean I could have done something like this, for just this simple line: > (and ignored the format of the rest of the file) > jenkins_port=$(grep jenkins_port /fuego-ro/conf/fuego.conf | sed "s/^jenkins_port=//") > > That has its own ugliness, when the shell supports reading this format directly. well, the `ftc env` that produces "shell-evaluatable output" (analogous to gpg-agent, docker-machine, etc...) is good, or simply `ftc config get` as you said.... more reliable than trying to grep/sed, as things like escapes, quotes would be handled properly. >> > I love the simplicity of this routine, by the way. >> > >> >> + >> >> +# define these as globals >> >> +log = None >> >> +tail_fd = None >> >> + >> >> +FUEGO_CFG_PATH = '/fuego-ro/conf/fuego.conf' >> >> +fuego_config = read_conf(FUEGO_CFG_PATH) >> > This needs to be done after the check for whether we're inside the >> > docker container, or check the environment for FUEGO_RO. >> > >> > ftc run outside the container won't be able to read the configuration >> > file from under /fuego-ro (that is, at the root). >> > >> > See the code for checking inside_docker() at the top of the 'main' function. >> > >> > If it's too complicated to move the read_conf, then for now, I'd be satisfied >> > with checking for the existence of '/fuego-ro', and just returning an empty >> dictionary. >> > The only thing that an outside-the-container 'ftc' does is immediately call >> 'ftc' >> > inside the container. So it shouldn't need any configuration values. >> > (cross our fingers and hope it stays that way....) >> > We don't really have a mechanism to figure out where the conf file is when >> > 'ftc' is outside the container (especially if there are multiple fuegos running >> > around), so we don't have much choice. >> >> something that I'm wondering: why do we ever need to run ftc *outside* >> of the container? shouldn't a bash-alias solve this issue for people >> that want to do that? > > No. It's not a given that fuego will always be running in a container. > Some people have complained about the overhead of the container. > If you have the necessary stuff installed on your host, and don't want > to use Jenkins as your front end, there actually only a few things > required to allow you to run Fuego on the command line as a regular host > process. (e.g. you could do 'ftc run-test' and not talk to a container). > > This is an incomplete feature now, that I wanted to allow for in the future. > (Of course, figuring out where the FUEGO_RO, FUEGO_CORE and FUEGO_RW > dirs. would be essential for this. My plan was to put these into a section > of the conf file, and thus reduce the required explicit information down to one > path.) ok, but in this case, AFAIU, there is no need to communicate or handle specially. running ftc inside the container should be the same as running ftc outside of the container, given that outside of the container you properly configured the environment. Basically "inside the container" is just a way to get everything configured for you. However running the ftc outside the container, expecting it to proxy to inside the container, IMO, it's something we can avoid. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN, GTalk, FaceTime: barbieri at gmail.com Skype: gsbarbieri Mobile: +55 (16) 99354-9890 From Tim.Bird at sony.com Mon Feb 12 23:55:20 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Mon, 12 Feb 2018 23:55:20 +0000 Subject: [Fuego] [PATCH] Allow ftc script to properly use Jenkins configured port In-Reply-To: References: <20180208185133.9092-1-guicc@profusion.mobi> Message-ID: > -----Original Message----- > From: Gustavo Sverzut on Thursday, February 08, 2018 1:56 PM > > On Thu, Feb 8, 2018 at 6:33 PM, Bird, Timothy wrote: > > > > > >> -----Original Message----- > >> From: Gustavo Sverzut Barbieri > >> On Thu, Feb 8, 2018 at 5:17 PM, wrote: ... > >> something that I'm wondering: why do we ever need to run ftc *outside* > >> of the container? shouldn't a bash-alias solve this issue for people > >> that want to do that? > > > > No. It's not a given that fuego will always be running in a container. > > Some people have complained about the overhead of the container. > > If you have the necessary stuff installed on your host, and don't want > > to use Jenkins as your front end, there actually only a few things > > required to allow you to run Fuego on the command line as a regular host > > process. (e.g. you could do 'ftc run-test' and not talk to a container). > > > > This is an incomplete feature now, that I wanted to allow for in the future. > > (Of course, figuring out where the FUEGO_RO, FUEGO_CORE and > FUEGO_RW > > dirs. would be essential for this. My plan was to put these into a section > > of the conf file, and thus reduce the required explicit information down to > one > > path.) > > ok, but in this case, AFAIU, there is no need to communicate or handle > specially. > > running ftc inside the container should be the same as running ftc > outside of the container, given that outside of the container you > properly configured the environment. Basically "inside the container" > is just a way to get everything configured for you. It's that, but also a way to have things containerized for you. There's some security isolation provided by the container. There would be a tradeoff of different attributes when running inside the container vs. outside, so I think we'd want to keep both methods. (That is, when we actually have both methods. Running Fuego without a container is not currently supported.) I will actually admit here that it's a kind of bad form on my part to try to preserve a feature that doesn't exist yet. But it's on my long-term roadmap. -- Tim From Tim.Bird at sony.com Thu Feb 15 19:45:48 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 15 Feb 2018 19:45:48 +0000 Subject: [Fuego] RFC - new board-control interface Message-ID: Hello fellow Fuegoans! As if I didn't have enough sticks in the fire already (ha ha, pun intended), here is another RFC for a new feature I'm adding to Fuego, to create an interface for hardware control of the device under test. This has been prompted by several issues: 1) We need a hardware interface for provisioning boards, for some test scenarios, and 2) Fuego really needs to be able to recover from tests that hang the device under test (For me, LTP's inotify06 does this for my beaglebone board, as the board is currently configured.) The general idea is that I am introducing a new board variable called: BOARD_CONTROL. This defines the system used for managing a board in someone's farm (e.g. r4d, labgrid, ttc, or something else). This is different from, and orthogonal to the PLATFORM (which really should be renamed to DISTRO), which specifies a set of runtime capabilities and programs on the device under test, and TRANSPORT, which specifies communications mechanisms between Fuego and the device under test. Currently, the only supported BOARD_CONTROL is 'ttc', because that's what I have in my lab. However, I'm open to support for other people's board control management interfaces. Also currently, the only supported board control function is: ov_board_control_reboot. After defining this, I then go on to add support to Fuego, in the post_test function, for attempting to recover (reboot a board) after it hangs due to a test. That Fuego has been missing this for so long is indicative of Fuego's positioning in the Open Source test landscape. For other systems, which integrate boot-time and provisioning testing (like kernelci and lava), rebooting the board is fundamental and inescapable to their test procedures. Fuego is positioned much more as a runtime test system, which assumes the board is up, and that few tests actually put the board into a non-responsive condition. Below is the patch which introduces these concepts. Note that I have not written the documentation for this yet, or provided any example boards with BOARD_CONTROL support (although I have some unpublished board files in my lab that use this new board variable). Note that Fuego's interface to the board management software is via the Linux command line (as opposed to, say, using a C, python, or shell library). Fuego has a very 'Unix-y' approach to interfacing with external software. The patch itself is surprisingly short, but please consider carefully the concepts, and let me know what you think. Thanks and regards, -- Tim Here's the patch, which is already in my master branch (but I'm open to making changes based on feedback on the principles here). ----------- Subject: [PATCH] core: add support for hardware reset Support performing a hardware reboot of a board, if the system detects that the board is no longer responsive. Introduce a new hardware reboot function, which requires that the board provide a BOARD_CONTROL variable, indicating the board control system being used. Other board variables may be required by the board control software. The only board control system supported currently is 'ttc'. Signed-off-by: Tim Bird --- engine/overlays/base/base-board.fuegoclass | 12 ++++++++++++ engine/scripts/functions.sh | 19 ++++++++++++++++++- 2 files changed, 30 insertions(+), 1 deletion(-) diff --git a/engine/overlays/base/base-board.fuegoclass b/engine/overlays/base/base-board.fuegoclass index bdda9c3..8c9b5f8 100644 --- a/engine/overlays/base/base-board.fuegoclass +++ b/engine/overlays/base/base-board.fuegoclass @@ -188,3 +188,15 @@ function ov_transport_cmd() { ;; esac } + +# function to reboot the board +function ov_board_control_reboot() { + case "$BOARD_CONTROL" in + "ttc") + $TTC $TTC_TARGET reboot + ;; + *) + abort_job "Error reason: unsupported BOARD_CONTROL ${BOARD_CONTROL}" + ;; + esac +} diff --git a/engine/scripts/functions.sh b/engine/scripts/functions.sh index 46c3d8e..1eee444 100755 --- a/engine/scripts/functions.sh +++ b/engine/scripts/functions.sh @@ -29,6 +29,7 @@ function signal_handler { # if we got here, something went wrong. Let's clean up and leave echo "in signal_handler" unlock_build_dir + export FUEGO_RECEIVED_SIGNAL="true" if [[ "$FUEGO_TEST_PHASES" == *post_test* ]] ; then echo "##### doing fuego phase: post_test (from signal handler) #####" post_test @@ -618,6 +619,22 @@ function post_test { trap post_term_handler SIGTERM trap - SIGHUP SIGALRM SIGINT ERR EXIT + if [ "${FUEGO_RECEIVED_SIGNAL}" = "true" ] ; then + # the board may have hung (a kernel oops) + # see if the board is responsive, and if not, try to reboot it + set +e + if ! cmd "true" ; then + if [ -n "${BOARD_CONTROL}" ] ; then + ov_board_control_reboot + ov_transport_connect ${MAX_REBOOT_RETRIES:-20} + cmd "true" || abort_job "ERROR: Cannot connect to board after reboot\n" + else + abort_job "ERROR: Cannot connect to board for test post-processing" + fi + fi + set -e + fi + # log test completion message. # but don't let user confuse termination with success ov_logger "Test $TESTDIR is finished - maybe successfully" @@ -671,7 +688,7 @@ function target_reboot { # pass max_retries to ov_transport_connect ov_transport_connect $1 set -e - cmd "true" || abort_job "FAIL: Cannot connect to board after reboot\n" + cmd "true" || abort_job "ERROR: Cannot connect to board after reboot\n" } # $1 - tarball template -- 1.9.1 From dhinakar.k at samsung.com Fri Feb 16 04:38:12 2018 From: dhinakar.k at samsung.com (Dhinakar Kalyanasundaram) Date: Fri, 16 Feb 2018 10:08:12 +0530 Subject: [Fuego] RFC - new board-control interface In-Reply-To: References: Message-ID: <20180216043812epcms5p6dc01c0ebca9f67aa3d3553e61d923a50@epcms5p6> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 201602111742151_N3WZA6X7.png Type: image/png Size: 33527 bytes Desc: not available URL: From Tim.Bird at sony.com Fri Feb 16 17:56:41 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Fri, 16 Feb 2018 17:56:41 +0000 Subject: [Fuego] RFC - new board-control interface In-Reply-To: <20180216043812epcms5p6dc01c0ebca9f67aa3d3553e61d923a50@epcms5p6> References: <20180216043812epcms5p6dc01c0ebca9f67aa3d3553e61d923a50@epcms5p6> Message-ID: > -----Original Message----- > From: Dhinakar Kalyanasundaram > > Thanks for the board-control feature release. Is this released in the 'master' > branch? Yes. This is available now in my 'master' branch. > This will be really useful as reboot and many other tests can now be > executed uninterrupted. > > I am also looking forward to the LAVA integration in Fuego. Do you already use LAVA in your test lab? I would be interested to hear more about your configuration, to see if we can add appropriate support in Fuego for what you are doing. -- Tim From guicc at profusion.mobi Fri Feb 16 21:42:20 2018 From: guicc at profusion.mobi (Guilherme Campos Camargo) Date: Fri, 16 Feb 2018 19:42:20 -0200 Subject: [Fuego] [PATCH] Fuego Release Test Repository Message-ID: <20180216214220.23806-1-guicc@profusion.mobi> Hello, everyone This repository has been created to store the resources needed for the generation of a Docker image, based on fuego-base, that has all the tools needed for the automation of the tests that are required for validating a new Fuego release with Fuego itself. It consists basically of: * A Dockerfile containing the installation of additional dependencies. * A new fuego-test board (fuego-ro/boards/fuego-test) * A functional test (tests/Functional.fuegotest) that will download a specific branch of Fuego from a repository provided by the user, start an inner container running that specific fuego release and run basic tests on it. The functional test currently just adds a board and a test plan to the Fuego-Under-Test, reporting success if everything goes well and failure if not. Please check the documentation (README.md) for instructions in how to build/run the image with the helper script `build_and_run.sh`. Also, it's important to note that this patch represents a sort of paradigm shift in the way that tests are added to Fuego, given that: - The software requirements are being installed through a Dockerfile that extends fuego-base. - The test routines/plans and the new boards are moved to Fuego during build time, acting almost as an "overlay". For that reason, it's imperative that current users/contributors provide their feedback regarding this new approach before we move on. Also, since I just started contributing with and using fuego, it's likely that I missed something, specially related to Fuego usability. So please, kindly add your comments and correct me if so. Please also see a few more comments in the code below. --- Dockerfile | 30 ++++++++++++++ README.md | 38 ++++++++++++++++++ build_and_run.sh | 67 ++++++++++++++++++++++++++++++++ fuego-ro/boards/README | 4 ++ fuego-ro/boards/fuego-test.board | 13 +++++++ fuego-ro/conf/README | 1 + fuego-ro/conf/fuego.conf | 3 ++ fuego-rt-entrypoint.sh | 26 +++++++++++++ tests/Functional.fuegotest/fuego_test.sh | 36 +++++++++++++++++ tests/Functional.fuegotest/spec.json | 9 +++++ tests/Functional.fuegotest/test_run.py | 19 +++++++++ 11 files changed, 246 insertions(+) create mode 100644 Dockerfile create mode 100644 README.md create mode 100755 build_and_run.sh create mode 100644 fuego-ro/boards/README create mode 100644 fuego-ro/boards/fuego-test.board create mode 100644 fuego-ro/conf/README create mode 100644 fuego-ro/conf/fuego.conf create mode 100755 fuego-rt-entrypoint.sh create mode 100755 tests/Functional.fuegotest/fuego_test.sh create mode 100644 tests/Functional.fuegotest/spec.json create mode 100755 tests/Functional.fuegotest/test_run.py diff --git a/Dockerfile b/Dockerfile new file mode 100644 index 0000000..5dcb755 --- /dev/null +++ b/Dockerfile @@ -0,0 +1,30 @@ +from fuegotest/fuego-base:latest + +ARG DEBIAN_FRONTEND=noninteractive +RUN apt-get update && \ + apt-get -yV install \ + apt-transport-https \ + ca-certificates \ + curl \ + gnupg2 \ + python3 \ + python3-pip \ + software-properties-common && \ + curl -fsSL \ + https://download.docker.com/linux/$(\ + source /etc/os-release; echo "$ID")/gpg \ + | sudo apt-key add - && \ + add-apt-repository \ + "deb [arch=amd64] https://download.docker.com/linux/$(\ + source /etc/os-release; echo "$ID") \ + $(lsb_release -cs) stable" && \ + apt-get update && \ + apt-get -yV install \ + docker-ce && \ + pip3 install pexpect + +RUN echo "jenkins ALL = (root) NOPASSWD: /usr/bin/docker, /bin/sh" >> /etc/sudoers + +COPY fuego-ro /fuego-ro +COPY tests /fuego-core/engine/tests +COPY fuego-rt-entrypoint.sh / diff --git a/README.md b/README.md new file mode 100644 index 0000000..faa4d83 --- /dev/null +++ b/README.md @@ -0,0 +1,38 @@ +# Fuego Release Test + +This Fuego Image has all the tools needed for the automation of the tests that +are required for validating a new Fuego release with Fuego itself. + +It consists basically of: +* A Dockerfile containing the installation of additional dependencies. +* A new fuego-test board (fuego-ro/boards/fuego-test) +* A functional test (tests/Functional.fuegotest) that will download a specific + branch of Fuego from a repository provided by the user, start an inner + container running that specific fuego release and run basic tests on it. + +## Build and Run Instructions + +In order to build and run the tests with minimal effort, just use the given +`build_and_run.sh` script with the following parameters: + +``` +$ build_and_run.sh -r ${fuego-repo:-FUEGO_OFFICIAL_REPO} -b ${branch:-MASTER} -p ${fuego_port} up +``` + +In order to stop and save your session simply execute. + +``` +$ build_and_run.sh down +``` + +Please see `$ build_and_run.sh -h` for more options. + + +## Additional Instructions + +By running fuego-release-test, as explained above, you should be able to access +fuego through `http://localhost:${fuego_port}/fuego/` + +There you will see that the fuego-test board is already available and that the +default test has been added to it. Simply use Fuego's Jenkins interface as +usual to test Fuego itself. diff --git a/build_and_run.sh b/build_and_run.sh new file mode 100755 index 0000000..e448ddf --- /dev/null +++ b/build_and_run.sh @@ -0,0 +1,67 @@ +#!/bin/bash + +source ./fuego-ro/conf/fuego.conf + +readonly internal_fuego_port=${jenkins_port:-8080} +readonly fuego_rt_image=fuego-rt +readonly fuego_rt_container=fuego-rt-container +detached_mode_opts="--interactive --attach" +port_opts="-p 8080:${internal_fuego_port}" + +usage() { + echo "usage: $0 [OPTIONS] up|down" + grep " .)\\ #" "${0}" + exit 0 +} + +[ $# -eq 0 ] && usage +while getopts "hdcr:b:p:" arg; do + case $arg in + d) # Run in detached mode + detached_mode_opts="" + ;; + c) # Start from scratch, rebuilding image + clean_start="true" + ;; + r) # Fuego Repository to be tested (default: Fuego Official Repo) + fuego_repo_opts="-e TEST_REPO=${OPTARG}" + ;; + b) # Fuego Branch to be tested (default: Master) + fuego_branch_opts="-e TEST_BRANCH=${OPTARG}" + ;; + p) # Fuego (the stable, not the one under test) port mapped on Host (default: 8090) + port_opts="-p ${OPTARG}:${internal_fuego_port}" + ;; + h | *) # Display help. + usage + exit 0 + ;; + esac +done +shift "$((OPTIND - 1))" + +if [ "${1}" != "up" ] && [ "${1}" != "down" ]; then + usage +fi + +if [ "$1" = "down" ]; then + docker stop ${fuego_rt_container} +fi + +if [ "$1" = "up" ]; then + if [ -v clean_start ]; then + docker build -t "${fuego_rt_image}" . + docker rm -f "${fuego_rt_container}" + docker run -dit --name ${fuego_rt_container} \ + -v /var/run/docker.sock:/var/run/docker.sock \ + --net=bridge \ + ${port_opts} ${fuego_rt_image} + docker exec \ + ${fuego_repo_opts} \ + ${fuego_branch_opts} \ + -e FUEGO_PORT="${internal_fuego_port}" \ + ${fuego_rt_container} /fuego-rt-entrypoint.sh + docker stop ${fuego_rt_container} + fi + docker start ${detached_mode_opts} ${fuego_rt_container} +fi diff --git a/fuego-ro/boards/README b/fuego-ro/boards/README new file mode 100644 index 0000000..bf20dc8 --- /dev/null +++ b/fuego-ro/boards/README @@ -0,0 +1,4 @@ +This directory contains board files. + +See docs for reference on what variables should they define. + diff --git a/fuego-ro/boards/fuego-test.board b/fuego-ro/boards/fuego-test.board new file mode 100644 index 0000000..185e0b4 --- /dev/null +++ b/fuego-ro/boards/fuego-test.board @@ -0,0 +1,13 @@ +inherit "base-board" +include "base-params" + +IPADDR=127.0.0.1 +SRV_IP=127.0.0.1 +#LOGIN="root" +#PASSWORD="root" +#SSH_KEY="path/to/id_rsa" +BOARD_TESTDIR="$FUEGO_RW/tests" +PLATFORM="x86_64" +TRANSPORT="local" +ARCHITECTURE="x86_64" +DISTRIB="nosyslogd.dist" diff --git a/fuego-ro/conf/README b/fuego-ro/conf/README new file mode 100644 index 0000000..83942d4 --- /dev/null +++ b/fuego-ro/conf/README @@ -0,0 +1 @@ +This directory is for configuration files for Fuego and associated tools. diff --git a/fuego-ro/conf/fuego.conf b/fuego-ro/conf/fuego.conf new file mode 100644 index 0000000..0c95eae --- /dev/null +++ b/fuego-ro/conf/fuego.conf @@ -0,0 +1,3 @@ +docker_jenkins_uid=1000 +docker_jenkins_gid=987 +jenkins_port=8090 diff --git a/fuego-rt-entrypoint.sh b/fuego-rt-entrypoint.sh new file mode 100755 index 0000000..3c680dd --- /dev/null +++ b/fuego-rt-entrypoint.sh @@ -0,0 +1,26 @@ +#!/bin/bash + +set -e + +function wait_for_fuego { + readonly fuego_port=${FUEGO_PORT:-8080} + readonly jenkins_url="http://localhost:${fuego_port}/fuego/" + + echo "Waiting for Jenkins on ${jenkins_url}..." + while ! curl --output /dev/null --silent --head --fail "${jenkins_url}"; + do + sleep 1 + done +} + +test_repo=${TEST_REPO:-https://bitbucket.org/profusionmobi/fuego} +test_repo_escaped=$(sed 's/[&/\]/\\&/g' <<< "${test_repo}") +sed -i "s/FUEGOTEST_REPO/${test_repo_escaped}/" /fuego-core/engine/tests/Functional.fuegotest/spec.json As you can see, I'm using placeholders (FUEGOTEST_REPO and FUEGOTEST_BRANCH) in order to parametrize the test (those are passed by the user when running build_and_run.sh). I feel that there might be a better way of doing this. Does anyone have any suggestion? Also, note that we're using our own repo/branch for the fuego-under-test. This is necessary for now because there are some required changes that have not been merged yet either on master or next of the official repo (I'm sending that patch for review in a separate e-mail). The idea is to use the official repo and next as default. + +test_branch=${TEST_BRANCH:-"fuego-base"} +test_branch_escaped=$(sed 's/[&/\]/\\&/g' <<< "${test_branch}") +sed -i "s/FUEGOTEST_BRANCH/${test_branch_escaped}/" /fuego-core/engine/tests/Functional.fuegotest/spec.json + +wait_for_fuego +ftc add-nodes fuego-test +ftc add-jobs -b fuego-test -t Functional.fuegotest diff --git a/tests/Functional.fuegotest/fuego_test.sh b/tests/Functional.fuegotest/fuego_test.sh new file mode 100755 index 0000000..6843b00 --- /dev/null +++ b/tests/Functional.fuegotest/fuego_test.sh @@ -0,0 +1,36 @@ +#!/bin/bash + +set -e + +readonly fuego_release_dir=fuego-release +readonly fuego_release_img_name=fuego-release +readonly fuego_release_container_name=fuego-release-container + +function test_build { + if [ -d ${fuego_release_dir} ]; then + rm -r ${fuego_release_dir} + fi + git clone --quiet --depth 1 --single-branch \ + --branch "${FUNCTIONAL_FUEGOTEST_BRANCH}" \ + "${FUNCTIONAL_FUEGOTEST_REPO}" \ + "${fuego_release_dir}" + cd "${fuego_release_dir}" + git submodule update --init --recursive + cd - +} + +function test_run { + cd "${fuego_release_dir}" + ./install.sh "${fuego_release_img_name}" + sudo -n docker rm -f "${fuego_release_container_name}" || true + sudo -n docker create -it --name "${fuego_release_container_name}" \ + -p 8081:8080 \ + --net="bridge" "${fuego_release_img_name}" + + python3 ${TEST_HOME}/test_run.py + report "echo ok 1 minimal test on target" +} + +function test_processing { + log_compare "$TESTDIR" "1" "^ok" "p" +} diff --git a/tests/Functional.fuegotest/spec.json b/tests/Functional.fuegotest/spec.json new file mode 100644 index 0000000..703cb0d --- /dev/null +++ b/tests/Functional.fuegotest/spec.json @@ -0,0 +1,9 @@ +{ + "testName": "Functional.fuegotest", + "specs": { + "default": { + "REPO":"FUEGOTEST_REPO", + "BRANCH":"FUEGOTEST_BRANCH" + } + } +} diff --git a/tests/Functional.fuegotest/test_run.py b/tests/Functional.fuegotest/test_run.py new file mode 100755 index 0000000..139ad9e --- /dev/null +++ b/tests/Functional.fuegotest/test_run.py @@ -0,0 +1,19 @@ +#!/usr/bin/env python + +import pexpect + +# TODO: Check for errors As you see, this test is just a very simple bootstrap. The plan is to include many more steps in it in the future. + +c = pexpect.spawnu('sudo docker start --interactive --attach fuego-release-container') +c.sendline('\r\n') +c.expect('# $') + +print('Adding Node') +c.sendline('ftc add-nodes docker') +c.expect('# $', timeout=120) + +print('Adding Jobs') +c.sendline('ftc add-jobs -b docker -p testplan_docker') +c.expect('# $', timeout=120) + +print('Node and Jobs have been added') -- 2.16.1 From guicc at profusion.mobi Fri Feb 16 21:45:57 2018 From: guicc at profusion.mobi (Guilherme Campos Camargo) Date: Fri, 16 Feb 2018 19:45:57 -0200 Subject: [Fuego] [PATCH] Move fuego-ro/core to image during build and keep core as submodule Message-ID: <20180216214557.27540-1-guicc@profusion.mobi> Hello, everyone Those directories ideally shoud be copied to the image during build time given that Fuego would not run if their content is not available. By doing this, we're also making sure that a user that plans to use fuego-base docker image directly (or as a base image for his own docker images) will be able to do it straightforwardly, without the need of cloning other repositories or bind-mounting host's directories. It's also a good idea to keep fuego-core locked in a fixed release, what we can enforce easily by using git submodules. This is desired if we want to use a stable version of fuego to test new versions of fuego. On this patch we configure fuego-core as a submodule and make the changes needed for copying the required contents of the mentioned directories. -- Tim, please let us know what you think about it. Thanks Signed-off-by: Guilherme Campos Camargo --- .dockerignore | 2 -- .gitmodules | 3 +++ Dockerfile | 7 +++++++ fuego-core | 1 + fuego-host-scripts/docker-build-image.sh | 14 ++++++++++++++ fuego-host-scripts/docker-create-container.sh | 7 ------- 6 files changed, 25 insertions(+), 9 deletions(-) create mode 100644 .gitmodules create mode 160000 fuego-core diff --git a/.dockerignore b/.dockerignore index d73e89c..6af69cd 100644 --- a/.dockerignore +++ b/.dockerignore @@ -1,4 +1,2 @@ -fuego-rw -fuego-ro fuego-host-scripts .git diff --git a/.gitmodules b/.gitmodules new file mode 100644 index 0000000..d1adb2a --- /dev/null +++ b/.gitmodules @@ -0,0 +1,3 @@ +[submodule "fuego-core"] + path = fuego-core + url = https://bitbucket.org/tbird20d/fuego-core.git diff --git a/Dockerfile b/Dockerfile index cc79351..fc394ad 100644 --- a/Dockerfile +++ b/Dockerfile @@ -106,6 +106,13 @@ RUN curl -L -O ${JENKINS_URL} && \ dpkg -i jenkins_${JENKINS_VERSION}_all.deb && \ rm jenkins_${JENKINS_VERSION}_all.deb +# ============================================================================== +# Install fuego-core and fuego-ro +# ============================================================================== +COPY fuego-ro /fuego-ro +COPY fuego-rw /fuego-rw +COPY fuego-core /fuego-core + # ============================================================================== # Post installation # ============================================================================== diff --git a/fuego-core b/fuego-core new file mode 160000 index 0000000..5bf5f81 --- /dev/null +++ b/fuego-core @@ -0,0 +1 @@ +Subproject commit 5bf5f81baba3ae107d4316a628825e38f1f98094 diff --git a/fuego-host-scripts/docker-build-image.sh b/fuego-host-scripts/docker-build-image.sh index d276ee0..b345f0a 100755 --- a/fuego-host-scripts/docker-build-image.sh +++ b/fuego-host-scripts/docker-build-image.sh @@ -1,5 +1,19 @@ #!/bin/bash # $1 - name for the docker image (default: fuego) + +SOURCE="${BASH_SOURCE[0]}" +while [ -h "$SOURCE" ]; do # resolve $SOURCE until the file is no longer a symlink + DIR="$( cd -P "$( dirname "$SOURCE" )" && pwd )" + SOURCE="$(readlink "$SOURCE")" + [[ $SOURCE != /* ]] && SOURCE="$DIR/$SOURCE" # if $SOURCE was a relative symlink, we need to resolve it relative to the path where the symlink file was located +done +DIR="$( cd -P "$( dirname "$SOURCE" )" && pwd )" + +echo "${DIR}"/../fuego-core/.git +if [ ! -e "${DIR}"/../fuego-core/.git ]; then + git submodule update --init +fi + DOCKERIMAGE=${1:-fuego} sudo docker build -t ${DOCKERIMAGE} \ diff --git a/fuego-host-scripts/docker-create-container.sh b/fuego-host-scripts/docker-create-container.sh index 3d133bd..53a7a7a 100755 --- a/fuego-host-scripts/docker-create-container.sh +++ b/fuego-host-scripts/docker-create-container.sh @@ -12,11 +12,6 @@ DIR="$( cd -P "$( dirname "$SOURCE" )" && pwd )" DOCKERIMAGE=${1:-fuego} DOCKERCONTAINER=${2:-fuego-container} -if [ ! -d $DIR/../../fuego-core ]; then - echo "You need to clone fuego-core at $DIR/../../fuego-core" - exit 1 -fi - if [ "${UID}" == "0" ]; then uid=$(id -u "${SUDO_USER}") gid=$(id -g "${SUDO_USER}") @@ -31,8 +26,6 @@ sed -i "s/docker_jenkins_gid=500/docker_jenkins_gid=$gid/" $DIR/../fuego-ro/conf sudo docker create -it --name ${DOCKERCONTAINER} \ -v /boot:/boot:ro \ -v $DIR/../fuego-rw:/fuego-rw \ - -v $DIR/../fuego-ro:/fuego-ro:ro \ - -v $DIR/../../fuego-core:/fuego-core:ro \ -e http_proxy=${http_proxy} \ -e https_proxy=${https_proxy:-$http_proxy} \ --net="host" ${DOCKERIMAGE} || \ -- 2.16.1 From barbieri at profusion.mobi Sat Feb 17 14:24:20 2018 From: barbieri at profusion.mobi (Gustavo Sverzut Barbieri) Date: Sat, 17 Feb 2018 12:24:20 -0200 Subject: [Fuego] [PATCH] Fuego Release Test Repository In-Reply-To: <20180216214220.23806-1-guicc@profusion.mobi> References: <20180216214220.23806-1-guicc@profusion.mobi> Message-ID: On Fri, Feb 16, 2018 at 7:42 PM, Guilherme Campos Camargo wrote: ... > Also, it's important to note that this patch represents a sort of > paradigm shift in the way that tests are added to Fuego, given that: > - The software requirements are being installed through a Dockerfile > that extends fuego-base. > - The test routines/plans and the new boards are moved to Fuego during > build time, acting almost as an "overlay". > For that reason, it's imperative that current users/contributors provide > their feedback regarding this new approach before we move on. Also, > since I just started contributing with and using fuego, it's likely that > I missed something, specially related to Fuego usability. So please, > kindly add your comments and correct me if so. Tim, I discussed this with Guilherme and we'll formalize a proposal around the spec.json file, something along the lines: 1) test specify the debian repositories, packages and even gpg/keys (for repos). Instead of always adding the packages to the container, either by modifying the official docker image (as done before) or creating an overlay (as done by Guilherme), Fuego would make sure the repositories are added and packages are added prior to executing the tests. JSON object would look like: "packages-dependencies": { "repositories": ["deb https://download.docker.com/linux/debian jessie"], "keys": ["https://download.docker.com/linux/debian/gpg"], "packages": ["docker-ce", "libxpto-dev"], } Which would manage /etc/apt/sources.d/fuego.conf + apt-get install 2) in addition to the test scenarios variables that are pre-defined, allow user to redefined/override those when executing the test using the command line. For example fuego-release-test (fuego-rt) would default to test official repository with the branch "next", but one could override to test a private repo with a custom branch. This would solve the need to "patch" the correct value at entrypoint.sh: sed -i "s/FUEGOTEST_REPO/${test_repo_escaped}/" /fuego-core/engine/tests/Functional.fuegotest/spec.json ... ftc add-jobs -b fuego-test -t Functional.fuegotest With something like: ftc add-jobs -b fuego-test -t Functional.fuegotest -v FUEGOTEST_REPO=${test_repo_escaped} -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN, GTalk, FaceTime: barbieri at gmail.com Skype: gsbarbieri Mobile: +55 (16) 99354-9890gpg From Tim.Bird at sony.com Tue Feb 20 00:56:55 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Tue, 20 Feb 2018 00:56:55 +0000 Subject: [Fuego] [PATCH] Fuego Release Test Repository In-Reply-To: <20180216214220.23806-1-guicc@profusion.mobi> References: <20180216214220.23806-1-guicc@profusion.mobi> Message-ID: > -----Original Message----- > From: Guilherme Campos Camargo > Hello, everyone > > This repository What repository? https://bitbucket.org/profusionmobi/fuego? I see a repository on bitbucket, under profusionmobi, called 'fuego-release-test'? Is that the one? I can find no mention of the repository below... I presume I clone something, then run build_and_run.sh? Do I need to have any fuego materials pre-installed? (the 'driving' fuego?) Thanks, -- Tim > has been created to store the resources needed for the > generation of a Docker image, based on fuego-base, that has all the > tools needed for the automation of the tests that are required for > validating a new Fuego release with Fuego itself. > > It consists basically of: > > * A Dockerfile containing the installation of additional dependencies. > * A new fuego-test board (fuego-ro/boards/fuego-test) > * A functional test (tests/Functional.fuegotest) that will download a > specific branch of Fuego from a repository provided by the user, start > an inner container running that specific fuego release and run basic > tests on it. > > The functional test currently just adds a board and a test plan to the > Fuego-Under-Test, reporting success if everything goes well and failure > if not. > > Please check the documentation (README.md) for instructions in how to > build/run the image with the helper script `build_and_run.sh`. > > Also, it's important to note that this patch represents a sort of > paradigm shift in the way that tests are added to Fuego, given that: > - The software requirements are being installed through a Dockerfile > that extends fuego-base. > - The test routines/plans and the new boards are moved to Fuego during > build time, acting almost as an "overlay". > For that reason, it's imperative that current users/contributors provide > their feedback regarding this new approach before we move on. Also, > since I just started contributing with and using fuego, it's likely that > I missed something, specially related to Fuego usability. So please, > kindly add your comments and correct me if so. > > Please also see a few more comments in the code below. > > --- > Dockerfile | 30 ++++++++++++++ > README.md | 38 ++++++++++++++++++ > build_and_run.sh | 67 ++++++++++++++++++++++++++++++++ > fuego-ro/boards/README | 4 ++ > fuego-ro/boards/fuego-test.board | 13 +++++++ > fuego-ro/conf/README | 1 + > fuego-ro/conf/fuego.conf | 3 ++ > fuego-rt-entrypoint.sh | 26 +++++++++++++ > tests/Functional.fuegotest/fuego_test.sh | 36 +++++++++++++++++ > tests/Functional.fuegotest/spec.json | 9 +++++ > tests/Functional.fuegotest/test_run.py | 19 +++++++++ > 11 files changed, 246 insertions(+) > create mode 100644 Dockerfile > create mode 100644 README.md > create mode 100755 build_and_run.sh > create mode 100644 fuego-ro/boards/README > create mode 100644 fuego-ro/boards/fuego-test.board > create mode 100644 fuego-ro/conf/README > create mode 100644 fuego-ro/conf/fuego.conf > create mode 100755 fuego-rt-entrypoint.sh > create mode 100755 tests/Functional.fuegotest/fuego_test.sh > create mode 100644 tests/Functional.fuegotest/spec.json > create mode 100755 tests/Functional.fuegotest/test_run.py > > diff --git a/Dockerfile b/Dockerfile > new file mode 100644 > index 0000000..5dcb755 > --- /dev/null > +++ b/Dockerfile > @@ -0,0 +1,30 @@ > +from fuegotest/fuego-base:latest > + > +ARG DEBIAN_FRONTEND=noninteractive > +RUN apt-get update && \ > + apt-get -yV install \ > + apt-transport-https \ > + ca-certificates \ > + curl \ > + gnupg2 \ > + python3 \ > + python3-pip \ > + software-properties-common && \ > + curl -fsSL \ > + https://download.docker.com/linux/$(\ > + source /etc/os-release; echo "$ID")/gpg \ > + | sudo apt-key add - && \ > + add-apt-repository \ > + "deb [arch=amd64] https://download.docker.com/linux/$(\ > + source /etc/os-release; echo "$ID") \ > + $(lsb_release -cs) stable" && \ > + apt-get update && \ > + apt-get -yV install \ > + docker-ce && \ > + pip3 install pexpect > + > +RUN echo "jenkins ALL = (root) NOPASSWD: /usr/bin/docker, /bin/sh" >> > /etc/sudoers > + > +COPY fuego-ro /fuego-ro > +COPY tests /fuego-core/engine/tests > +COPY fuego-rt-entrypoint.sh / > diff --git a/README.md b/README.md > new file mode 100644 > index 0000000..faa4d83 > --- /dev/null > +++ b/README.md > @@ -0,0 +1,38 @@ > +# Fuego Release Test > + > +This Fuego Image has all the tools needed for the automation of the tests > that > +are required for validating a new Fuego release with Fuego itself. > + > +It consists basically of: > +* A Dockerfile containing the installation of additional dependencies. > +* A new fuego-test board (fuego-ro/boards/fuego-test) > +* A functional test (tests/Functional.fuegotest) that will download a specific > + branch of Fuego from a repository provided by the user, start an inner > + container running that specific fuego release and run basic tests on it. > + > +## Build and Run Instructions > + > +In order to build and run the tests with minimal effort, just use the given > +`build_and_run.sh` script with the following parameters: > + > +``` > +$ build_and_run.sh -r ${fuego-repo:-FUEGO_OFFICIAL_REPO} -b ${branch:- > MASTER} -p ${fuego_port} up > +``` > + > +In order to stop and save your session simply execute. > + > +``` > +$ build_and_run.sh down > +``` > + > +Please see `$ build_and_run.sh -h` for more options. > + > + > +## Additional Instructions > + > +By running fuego-release-test, as explained above, you should be able to > access > +fuego through `http://localhost:${fuego_port}/fuego/` > + > +There you will see that the fuego-test board is already available and that > the > +default test has been added to it. Simply use Fuego's Jenkins interface as > +usual to test Fuego itself. > diff --git a/build_and_run.sh b/build_and_run.sh > new file mode 100755 > index 0000000..e448ddf > --- /dev/null > +++ b/build_and_run.sh > @@ -0,0 +1,67 @@ > +#!/bin/bash > + > +source ./fuego-ro/conf/fuego.conf > + > +readonly internal_fuego_port=${jenkins_port:-8080} > +readonly fuego_rt_image=fuego-rt > +readonly fuego_rt_container=fuego-rt-container > +detached_mode_opts="--interactive --attach" > +port_opts="-p 8080:${internal_fuego_port}" > + > +usage() { > + echo "usage: $0 [OPTIONS] up|down" > + grep " .)\\ #" "${0}" > + exit 0 > +} > + > +[ $# -eq 0 ] && usage > +while getopts "hdcr:b:p:" arg; do > + case $arg in > + d) # Run in detached mode > + detached_mode_opts="" > + ;; > + c) # Start from scratch, rebuilding image > + clean_start="true" > + ;; > + r) # Fuego Repository to be tested (default: Fuego Official Repo) > + fuego_repo_opts="-e TEST_REPO=${OPTARG}" > + ;; > + b) # Fuego Branch to be tested (default: Master) > + fuego_branch_opts="-e TEST_BRANCH=${OPTARG}" > + ;; > + p) # Fuego (the stable, not the one under test) port mapped on Host > (default: 8090) > + port_opts="-p ${OPTARG}:${internal_fuego_port}" > + ;; > + h | *) # Display help. > + usage > + exit 0 > + ;; > + esac > +done > +shift "$((OPTIND - 1))" > + > +if [ "${1}" != "up" ] && [ "${1}" != "down" ]; then > + usage > +fi > + > +if [ "$1" = "down" ]; then > + docker stop ${fuego_rt_container} > +fi > + > +if [ "$1" = "up" ]; then > + if [ -v clean_start ]; then > + docker build -t "${fuego_rt_image}" . > + docker rm -f "${fuego_rt_container}" > + docker run -dit --name ${fuego_rt_container} \ > + -v /var/run/docker.sock:/var/run/docker.sock \ > + --net=bridge \ > + ${port_opts} ${fuego_rt_image} > + docker exec \ > + ${fuego_repo_opts} \ > + ${fuego_branch_opts} \ > + -e FUEGO_PORT="${internal_fuego_port}" \ > + ${fuego_rt_container} /fuego-rt-entrypoint.sh > + docker stop ${fuego_rt_container} > + fi > + docker start ${detached_mode_opts} ${fuego_rt_container} > +fi > diff --git a/fuego-ro/boards/README b/fuego-ro/boards/README > new file mode 100644 > index 0000000..bf20dc8 > --- /dev/null > +++ b/fuego-ro/boards/README > @@ -0,0 +1,4 @@ > +This directory contains board files. > + > +See docs for reference on what variables should they define. > + > diff --git a/fuego-ro/boards/fuego-test.board b/fuego-ro/boards/fuego- > test.board > new file mode 100644 > index 0000000..185e0b4 > --- /dev/null > +++ b/fuego-ro/boards/fuego-test.board > @@ -0,0 +1,13 @@ > +inherit "base-board" > +include "base-params" > + > +IPADDR=127.0.0.1 > +SRV_IP=127.0.0.1 > +#LOGIN="root" > +#PASSWORD="root" > +#SSH_KEY="path/to/id_rsa" > +BOARD_TESTDIR="$FUEGO_RW/tests" > +PLATFORM="x86_64" > +TRANSPORT="local" > +ARCHITECTURE="x86_64" > +DISTRIB="nosyslogd.dist" > diff --git a/fuego-ro/conf/README b/fuego-ro/conf/README > new file mode 100644 > index 0000000..83942d4 > --- /dev/null > +++ b/fuego-ro/conf/README > @@ -0,0 +1 @@ > +This directory is for configuration files for Fuego and associated tools. > diff --git a/fuego-ro/conf/fuego.conf b/fuego-ro/conf/fuego.conf > new file mode 100644 > index 0000000..0c95eae > --- /dev/null > +++ b/fuego-ro/conf/fuego.conf > @@ -0,0 +1,3 @@ > +docker_jenkins_uid=1000 > +docker_jenkins_gid=987 > +jenkins_port=8090 > diff --git a/fuego-rt-entrypoint.sh b/fuego-rt-entrypoint.sh > new file mode 100755 > index 0000000..3c680dd > --- /dev/null > +++ b/fuego-rt-entrypoint.sh > @@ -0,0 +1,26 @@ > +#!/bin/bash > + > +set -e > + > +function wait_for_fuego { > + readonly fuego_port=${FUEGO_PORT:-8080} > + readonly jenkins_url="http://localhost:${fuego_port}/fuego/" > + > + echo "Waiting for Jenkins on ${jenkins_url}..." > + while ! curl --output /dev/null --silent --head --fail "${jenkins_url}"; > + do > + sleep 1 > + done > +} > + > +test_repo=${TEST_REPO:-https://bitbucket.org/profusionmobi/fuego} > +test_repo_escaped=$(sed 's/[&/\]/\\&/g' <<< "${test_repo}") > +sed -i "s/FUEGOTEST_REPO/${test_repo_escaped}/" /fuego- > core/engine/tests/Functional.fuegotest/spec.json > > As you can see, I'm using placeholders (FUEGOTEST_REPO and > FUEGOTEST_BRANCH) in order to parametrize the test (those are passed by > the user when running build_and_run.sh). > > I feel that there might be a better way of doing this. Does anyone have > any suggestion? > > Also, note that we're using our own repo/branch for the > fuego-under-test. This is necessary for now because there are some > required changes that have not been merged yet either on master or next > of the official repo (I'm sending that patch for review in a separate > e-mail). The idea is to use the official repo and next as default. > > + > +test_branch=${TEST_BRANCH:-"fuego-base"} > +test_branch_escaped=$(sed 's/[&/\]/\\&/g' <<< "${test_branch}") > +sed -i "s/FUEGOTEST_BRANCH/${test_branch_escaped}/" /fuego- > core/engine/tests/Functional.fuegotest/spec.json > + > +wait_for_fuego > +ftc add-nodes fuego-test > +ftc add-jobs -b fuego-test -t Functional.fuegotest > diff --git a/tests/Functional.fuegotest/fuego_test.sh > b/tests/Functional.fuegotest/fuego_test.sh > new file mode 100755 > index 0000000..6843b00 > --- /dev/null > +++ b/tests/Functional.fuegotest/fuego_test.sh > @@ -0,0 +1,36 @@ > +#!/bin/bash > + > +set -e > + > +readonly fuego_release_dir=fuego-release > +readonly fuego_release_img_name=fuego-release > +readonly fuego_release_container_name=fuego-release-container > + > +function test_build { > + if [ -d ${fuego_release_dir} ]; then > + rm -r ${fuego_release_dir} > + fi > + git clone --quiet --depth 1 --single-branch \ > + --branch "${FUNCTIONAL_FUEGOTEST_BRANCH}" \ > + "${FUNCTIONAL_FUEGOTEST_REPO}" \ > + "${fuego_release_dir}" > + cd "${fuego_release_dir}" > + git submodule update --init --recursive > + cd - > +} > + > +function test_run { > + cd "${fuego_release_dir}" > + ./install.sh "${fuego_release_img_name}" > + sudo -n docker rm -f "${fuego_release_container_name}" || true > + sudo -n docker create -it --name "${fuego_release_container_name}" \ > + -p 8081:8080 \ > + --net="bridge" "${fuego_release_img_name}" > + > + python3 ${TEST_HOME}/test_run.py > + report "echo ok 1 minimal test on target" > +} > + > +function test_processing { > + log_compare "$TESTDIR" "1" "^ok" "p" > +} > diff --git a/tests/Functional.fuegotest/spec.json > b/tests/Functional.fuegotest/spec.json > new file mode 100644 > index 0000000..703cb0d > --- /dev/null > +++ b/tests/Functional.fuegotest/spec.json > @@ -0,0 +1,9 @@ > +{ > + "testName": "Functional.fuegotest", > + "specs": { > + "default": { > + "REPO":"FUEGOTEST_REPO", > + "BRANCH":"FUEGOTEST_BRANCH" > + } > + } > +} > diff --git a/tests/Functional.fuegotest/test_run.py > b/tests/Functional.fuegotest/test_run.py > new file mode 100755 > index 0000000..139ad9e > --- /dev/null > +++ b/tests/Functional.fuegotest/test_run.py > @@ -0,0 +1,19 @@ > +#!/usr/bin/env python > + > +import pexpect > + > +# TODO: Check for errors > > As you see, this test is just a very simple bootstrap. The plan is to > include many more steps in it in the future. > > + > +c = pexpect.spawnu('sudo docker start --interactive --attach fuego-release- > container') > +c.sendline('\r\n') > +c.expect('# $') > + > +print('Adding Node') > +c.sendline('ftc add-nodes docker') > +c.expect('# $', timeout=120) > + > +print('Adding Jobs') > +c.sendline('ftc add-jobs -b docker -p testplan_docker') > +c.expect('# $', timeout=120) > + > +print('Node and Jobs have been added') > -- > 2.16.1 > > _______________________________________________ > Fuego mailing list > Fuego at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/fuego From Tim.Bird at sony.com Tue Feb 20 01:12:06 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Tue, 20 Feb 2018 01:12:06 +0000 Subject: [Fuego] [PATCH] Fuego Release Test Repository In-Reply-To: References: <20180216214220.23806-1-guicc@profusion.mobi> Message-ID: > -----Original Message----- > From: Tim.Bird > > -----Original Message----- > > From: Guilherme Campos Camargo > > Hello, everyone > > > > This repository > What repository? https://bitbucket.org/profusionmobi/fuego? > > I see a repository on bitbucket, under profusionmobi, called > 'fuego-release-test'? Is that the one? I can find no mention > of the repository below... > > I presume I clone something, then run build_and_run.sh? > Do I need to have any fuego materials pre-installed? > (the 'driving' fuego?) I have several instances of Fuego available on my machine, but I wasn't sure if one of these was supposed to be running when I ran build_and_run.sh. I did this: $ git clone https://bitbucket.org/profusionmobi/fuego-release-test $ cd fuego-release-test $ ./build_and_run.sh -p 8080 up Error: no such container: fuego-rt-container ---- Am I supposed to have a container named 'fuego-rt-container'? I see other command line options: -c to start from scratch -d to run in detached mode Should I be using these? What is the meaning of 'up' and 'down'. Sorry, but I'm confused about how this works. Please help. -- Tim From Tim.Bird at sony.com Tue Feb 20 01:18:12 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Tue, 20 Feb 2018 01:18:12 +0000 Subject: [Fuego] [PATCH] Move fuego-ro/core to image during build and keep core as submodule In-Reply-To: <20180216214557.27540-1-guicc@profusion.mobi> References: <20180216214557.27540-1-guicc@profusion.mobi> Message-ID: > -----Original Message----- > From: Guilherme Campos Camargo > Those directories ideally shoud be copied to the image during build time > given that Fuego would not run if their content is not available. By > doing this, we're also making sure that a user that plans to use > fuego-base docker image directly (or as a base image for his own docker > images) will be able to do it straightforwardly, without the need of > cloning other repositories or bind-mounting host's directories. > > It's also a good idea to keep fuego-core locked in a fixed release, what > we can enforce easily by using git submodules. This is desired if we > want to use a stable version of fuego to test new versions of fuego. > > On this patch we configure fuego-core as a submodule and make the > changes needed for copying the required contents of the mentioned > directories. I understand virtually none of what you wrote here. Is this patch for tbird20d/fuego? Is it against profusionmobil/fuego-release-test? I haven't figured out how the fuego-release-test works yet, so I don't understand what you're referring to when you say "those directories", or "fuego-base docker image". > > -- > Tim, please let us know what you think about it. I need to understand what's going on, and how all these repositories interact, before I can give any coherent answer. I think that once I've run the release test successfully, I will be able to figure out what you're talking about here. -- Tim From Tim.Bird at sony.com Tue Feb 20 01:25:34 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Tue, 20 Feb 2018 01:25:34 +0000 Subject: [Fuego] [PATCH] Fuego Release Test Repository In-Reply-To: References: <20180216214220.23806-1-guicc@profusion.mobi> Message-ID: > -----Original Message----- > From: Gustavo Sverzut Barbieri > On Fri, Feb 16, 2018 at 7:42 PM, Guilherme Campos Camargo > wrote: > ... > > Also, it's important to note that this patch represents a sort of > > paradigm shift in the way that tests are added to Fuego, given that: > > - The software requirements are being installed through a Dockerfile > > that extends fuego-base. > > - The test routines/plans and the new boards are moved to Fuego during > > build time, acting almost as an "overlay". > > For that reason, it's imperative that current users/contributors provide > > their feedback regarding this new approach before we move on. Also, > > since I just started contributing with and using fuego, it's likely that > > I missed something, specially related to Fuego usability. So please, > > kindly add your comments and correct me if so. > > Tim, I discussed this with Guilherme and we'll formalize a proposal > around the spec.json file, something along the lines: > > 1) test specify the debian repositories, packages and even gpg/keys > (for repos). Instead of always adding the packages to the container, > either by modifying the official docker image (as done before) or > creating an overlay (as done by Guilherme), Fuego would make sure the > repositories are added and packages are added prior to executing the > tests. > Since I haven't been able to run the release-test yet, this is also going over my head. What problem is this solving? Is this for a test to specify additional packages for the base distribution in the docker container, that the test needs on the host? Or is it referring to a new -dev package used for building the software for the target (but again, something that needs to be in the docker container, but is part of the toolchain)? Would this be used for something like: lib-cairo-dev, or netperf-server? > JSON object would look like: > > "packages-dependencies": { > "repositories": ["deb https://download.docker.com/linux/debian > jessie"], > "keys": ["https://download.docker.com/linux/debian/gpg"], > "packages": ["docker-ce", "libxpto-dev"], > } > > Which would manage /etc/apt/sources.d/fuego.conf + apt-get install > > > 2) in addition to the test scenarios variables that are pre-defined, > allow user to redefined/override those when executing the test using > the command line. For example fuego-release-test (fuego-rt) would > default to test official repository with the branch "next", but one > could override to test a private repo with a custom branch. > > This would solve the need to "patch" the correct value at entrypoint.sh: > > sed -i "s/FUEGOTEST_REPO/${test_repo_escaped}/" > /fuego-core/engine/tests/Functional.fuegotest/spec.json > ... > ftc add-jobs -b fuego-test -t Functional.fuegotest > > With something like: > > ftc add-jobs -b fuego-test -t Functional.fuegotest -v > FUEGOTEST_REPO=${test_repo_escaped} We've talked about adding the ability to define a test variable on the command line, when adding jobs or running tests, that would override the value contained in a spec file. This is highly desirable. I'm still, however, wrapping my head around the fuego release self-test case, which I don't understand yet. Talking about this feature in that context may be too much for my little brain to handle, at the moment. -- Tim From guicc at profusion.mobi Tue Feb 20 02:25:34 2018 From: guicc at profusion.mobi (Guilherme Camargo) Date: Mon, 19 Feb 2018 23:25:34 -0300 Subject: [Fuego] [PATCH] Fuego Release Test Repository In-Reply-To: References: <20180216214220.23806-1-guicc@profusion.mobi> Message-ID: Hello, Tim On Mon, Feb 19, 2018 at 9:56 PM, wrote: > > > > -----Original Message----- > > From: Guilherme Campos Camargo > > Hello, everyone > > > > This repository > What repository? https://bitbucket.org/profusionmobi/fuego? > ?Not this one. ? > > I see a repository on bitbucket, under profusionmobi, called > 'fuego-release-test'? Is that the one? I can find no mention > of the repository below... > ?Yes. That's the one. I'm sorry for not being clear on my first e-mail. https://bitbucket.org/profusionmobi/fuego-release-test? > > I presume I clone something, then run build_and_run.sh? > Do I need to have any fuego materials pre-installed? > (the 'driving' fuego?) > ?You shouldn't need anything ?besides what's in fuego-release-test. And you're right. After cloning the repo, you just need to run build_and_run.sh to start a new fuego instance with a pre-installed fuego-test board and with a Functional.fuegotest job added to it. The basic command is: ./build_and_run.sh -b YOUR_PREFERRED_PORT up But I just noticed (as you mentioned in your next e-mail) that there's a bug that's requiring you to 'execute from scratch' at least once with. ./build_and_run.sh -c -b YOUR_PREFERRED_PORT up Sorry. I'll fix that. Then you can just open fuego-jenkins' interface through localhost:YOUR_PREF_PORT/fuego and will you see that there's a fuego-test board defined (with a functional test added to it). ? > > Thanks, > -- Tim > > > > has been created to store the resources needed for the > > generation of a Docker image, based on fuego-base, that has all the > > tools needed for the automation of the tests that are required for > > validating a new Fuego release with Fuego itself. > > > > It consists basically of: > > > > * A Dockerfile containing the installation of additional dependencies. > > * A new fuego-test board (fuego-ro/boards/fuego-test) > > * A functional test (tests/Functional.fuegotest) that will download a > > specific branch of Fuego from a repository provided by the user, start > > an inner container running that specific fuego release and run basic > > tests on it. > > > > The functional test currently just adds a board and a test plan to the > > Fuego-Under-Test, reporting success if everything goes well and failure > > if not. > > > > Please check the documentation (README.md) for instructions in how to > > build/run the image with the helper script `build_and_run.sh`. > > > > Also, it's important to note that this patch represents a sort of > > paradigm shift in the way that tests are added to Fuego, given that: > > - The software requirements are being installed through a Dockerfile > > that extends fuego-base. > > - The test routines/plans and the new boards are moved to Fuego during > > build time, acting almost as an "overlay". > > For that reason, it's imperative that current users/contributors provide > > their feedback regarding this new approach before we move on. Also, > > since I just started contributing with and using fuego, it's likely that > > I missed something, specially related to Fuego usability. So please, > > kindly add your comments and correct me if so. > > > > Please also see a few more comments in the code below. > > > > --- > > Dockerfile | 30 ++++++++++++++ > > README.md | 38 ++++++++++++++++++ > > build_and_run.sh | 67 > ++++++++++++++++++++++++++++++++ > > fuego-ro/boards/README | 4 ++ > > fuego-ro/boards/fuego-test.board | 13 +++++++ > > fuego-ro/conf/README | 1 + > > fuego-ro/conf/fuego.conf | 3 ++ > > fuego-rt-entrypoint.sh | 26 +++++++++++++ > > tests/Functional.fuegotest/fuego_test.sh | 36 +++++++++++++++++ > > tests/Functional.fuegotest/spec.json | 9 +++++ > > tests/Functional.fuegotest/test_run.py | 19 +++++++++ > > 11 files changed, 246 insertions(+) > > create mode 100644 Dockerfile > > create mode 100644 README.md > > create mode 100755 build_and_run.sh > > create mode 100644 fuego-ro/boards/README > > create mode 100644 fuego-ro/boards/fuego-test.board > > create mode 100644 fuego-ro/conf/README > > create mode 100644 fuego-ro/conf/fuego.conf > > create mode 100755 fuego-rt-entrypoint.sh > > create mode 100755 tests/Functional.fuegotest/fuego_test.sh > > create mode 100644 tests/Functional.fuegotest/spec.json > > create mode 100755 tests/Functional.fuegotest/test_run.py > > > > diff --git a/Dockerfile b/Dockerfile > > new file mode 100644 > > index 0000000..5dcb755 > > --- /dev/null > > +++ b/Dockerfile > > @@ -0,0 +1,30 @@ > > +from fuegotest/fuego-base:latest > > + > > +ARG DEBIAN_FRONTEND=noninteractive > > +RUN apt-get update && \ > > + apt-get -yV install \ > > + apt-transport-https \ > > + ca-certificates \ > > + curl \ > > + gnupg2 \ > > + python3 \ > > + python3-pip \ > > + software-properties-common && \ > > + curl -fsSL \ > > + https://download.docker.com/linux/$(\ > > + source /etc/os-release; echo "$ID")/gpg \ > > + | sudo apt-key add - && \ > > + add-apt-repository \ > > + "deb [arch=amd64] https://download.docker.com/linux/$(\ > > + source /etc/os-release; echo "$ID") \ > > + $(lsb_release -cs) stable" && \ > > + apt-get update && \ > > + apt-get -yV install \ > > + docker-ce && \ > > + pip3 install pexpect > > + > > +RUN echo "jenkins ALL = (root) NOPASSWD: /usr/bin/docker, /bin/sh" >> > > /etc/sudoers > > + > > +COPY fuego-ro /fuego-ro > > +COPY tests /fuego-core/engine/tests > > +COPY fuego-rt-entrypoint.sh / > > diff --git a/README.md b/README.md > > new file mode 100644 > > index 0000000..faa4d83 > > --- /dev/null > > +++ b/README.md > > @@ -0,0 +1,38 @@ > > +# Fuego Release Test > > + > > +This Fuego Image has all the tools needed for the automation of the > tests > > that > > +are required for validating a new Fuego release with Fuego itself. > > + > > +It consists basically of: > > +* A Dockerfile containing the installation of additional dependencies. > > +* A new fuego-test board (fuego-ro/boards/fuego-test) > > +* A functional test (tests/Functional.fuegotest) that will download a > specific > > + branch of Fuego from a repository provided by the user, start an inner > > + container running that specific fuego release and run basic tests on > it. > > + > > +## Build and Run Instructions > > + > > +In order to build and run the tests with minimal effort, just use the > given > > +`build_and_run.sh` script with the following parameters: > > + > > +``` > > +$ build_and_run.sh -r ${fuego-repo:-FUEGO_OFFICIAL_REPO} -b ${branch:- > > MASTER} -p ${fuego_port} up > > +``` > > + > > +In order to stop and save your session simply execute. > > + > > +``` > > +$ build_and_run.sh down > > +``` > > + > > +Please see `$ build_and_run.sh -h` for more options. > > + > > + > > +## Additional Instructions > > + > > +By running fuego-release-test, as explained above, you should be able to > > access > > +fuego through `http://localhost:${fuego_port}/fuego/` > > + > > +There you will see that the fuego-test board is already available and > that > > the > > +default test has been added to it. Simply use Fuego's Jenkins interface > as > > +usual to test Fuego itself. > > diff --git a/build_and_run.sh b/build_and_run.sh > > new file mode 100755 > > index 0000000..e448ddf > > --- /dev/null > > +++ b/build_and_run.sh > > @@ -0,0 +1,67 @@ > > +#!/bin/bash > > + > > +source ./fuego-ro/conf/fuego.conf > > + > > +readonly internal_fuego_port=${jenkins_port:-8080} > > +readonly fuego_rt_image=fuego-rt > > +readonly fuego_rt_container=fuego-rt-container > > +detached_mode_opts="--interactive --attach" > > +port_opts="-p 8080:${internal_fuego_port}" > > + > > +usage() { > > + echo "usage: $0 [OPTIONS] up|down" > > + grep " .)\\ #" "${0}" > > + exit 0 > > +} > > + > > +[ $# -eq 0 ] && usage > > +while getopts "hdcr:b:p:" arg; do > > + case $arg in > > + d) # Run in detached mode > > + detached_mode_opts="" > > + ;; > > + c) # Start from scratch, rebuilding image > > + clean_start="true" > > + ;; > > + r) # Fuego Repository to be tested (default: Fuego Official Repo) > > + fuego_repo_opts="-e TEST_REPO=${OPTARG}" > > + ;; > > + b) # Fuego Branch to be tested (default: Master) > > + fuego_branch_opts="-e TEST_BRANCH=${OPTARG}" > > + ;; > > + p) # Fuego (the stable, not the one under test) port mapped on Host > > (default: 8090) > > + port_opts="-p ${OPTARG}:${internal_fuego_port}" > > + ;; > > + h | *) # Display help. > > + usage > > + exit 0 > > + ;; > > + esac > > +done > > +shift "$((OPTIND - 1))" > > + > > +if [ "${1}" != "up" ] && [ "${1}" != "down" ]; then > > + usage > > +fi > > + > > +if [ "$1" = "down" ]; then > > + docker stop ${fuego_rt_container} > > +fi > > + > > +if [ "$1" = "up" ]; then > > + if [ -v clean_start ]; then > > + docker build -t "${fuego_rt_image}" . > > + docker rm -f "${fuego_rt_container}" > > + docker run -dit --name ${fuego_rt_container} \ > > + -v /var/run/docker.sock:/var/run/docker.sock \ > > + --net=bridge \ > > + ${port_opts} ${fuego_rt_image} > > + docker exec \ > > + ${fuego_repo_opts} \ > > + ${fuego_branch_opts} \ > > + -e FUEGO_PORT="${internal_fuego_port}" \ > > + ${fuego_rt_container} /fuego-rt-entrypoint.sh > > + docker stop ${fuego_rt_container} > > + fi > > + docker start ${detached_mode_opts} ${fuego_rt_container} > > +fi > > diff --git a/fuego-ro/boards/README b/fuego-ro/boards/README > > new file mode 100644 > > index 0000000..bf20dc8 > > --- /dev/null > > +++ b/fuego-ro/boards/README > > @@ -0,0 +1,4 @@ > > +This directory contains board files. > > + > > +See docs for reference on what variables should they define. > > + > > diff --git a/fuego-ro/boards/fuego-test.board b/fuego-ro/boards/fuego- > > test.board > > new file mode 100644 > > index 0000000..185e0b4 > > --- /dev/null > > +++ b/fuego-ro/boards/fuego-test.board > > @@ -0,0 +1,13 @@ > > +inherit "base-board" > > +include "base-params" > > + > > +IPADDR=127.0.0.1 > > +SRV_IP=127.0.0.1 > > +#LOGIN="root" > > +#PASSWORD="root" > > +#SSH_KEY="path/to/id_rsa" > > +BOARD_TESTDIR="$FUEGO_RW/tests" > > +PLATFORM="x86_64" > > +TRANSPORT="local" > > +ARCHITECTURE="x86_64" > > +DISTRIB="nosyslogd.dist" > > diff --git a/fuego-ro/conf/README b/fuego-ro/conf/README > > new file mode 100644 > > index 0000000..83942d4 > > --- /dev/null > > +++ b/fuego-ro/conf/README > > @@ -0,0 +1 @@ > > +This directory is for configuration files for Fuego and associated > tools. > > diff --git a/fuego-ro/conf/fuego.conf b/fuego-ro/conf/fuego.conf > > new file mode 100644 > > index 0000000..0c95eae > > --- /dev/null > > +++ b/fuego-ro/conf/fuego.conf > > @@ -0,0 +1,3 @@ > > +docker_jenkins_uid=1000 > > +docker_jenkins_gid=987 > > +jenkins_port=8090 > > diff --git a/fuego-rt-entrypoint.sh b/fuego-rt-entrypoint.sh > > new file mode 100755 > > index 0000000..3c680dd > > --- /dev/null > > +++ b/fuego-rt-entrypoint.sh > > @@ -0,0 +1,26 @@ > > +#!/bin/bash > > + > > +set -e > > + > > +function wait_for_fuego { > > + readonly fuego_port=${FUEGO_PORT:-8080} > > + readonly jenkins_url="http://localhost:${fuego_port}/fuego/" > > + > > + echo "Waiting for Jenkins on ${jenkins_url}..." > > + while ! curl --output /dev/null --silent --head --fail > "${jenkins_url}"; > > + do > > + sleep 1 > > + done > > +} > > + > > +test_repo=${TEST_REPO:-https://bitbucket.org/profusionmobi/fuego} > > +test_repo_escaped=$(sed 's/[&/\]/\\&/g' <<< "${test_repo}") > > +sed -i "s/FUEGOTEST_REPO/${test_repo_escaped}/" /fuego- > > core/engine/tests/Functional.fuegotest/spec.json > > > > As you can see, I'm using placeholders (FUEGOTEST_REPO and > > FUEGOTEST_BRANCH) in order to parametrize the test (those are passed by > > the user when running build_and_run.sh). > > > > I feel that there might be a better way of doing this. Does anyone have > > any suggestion? > > > > Also, note that we're using our own repo/branch for the > > fuego-under-test. This is necessary for now because there are some > > required changes that have not been merged yet either on master or next > > of the official repo (I'm sending that patch for review in a separate > > e-mail). The idea is to use the official repo and next as default. > > > > + > > +test_branch=${TEST_BRANCH:-"fuego-base"} > > +test_branch_escaped=$(sed 's/[&/\]/\\&/g' <<< "${test_branch}") > > +sed -i "s/FUEGOTEST_BRANCH/${test_branch_escaped}/" /fuego- > > core/engine/tests/Functional.fuegotest/spec.json > > + > > +wait_for_fuego > > +ftc add-nodes fuego-test > > +ftc add-jobs -b fuego-test -t Functional.fuegotest > > diff --git a/tests/Functional.fuegotest/fuego_test.sh > > b/tests/Functional.fuegotest/fuego_test.sh > > new file mode 100755 > > index 0000000..6843b00 > > --- /dev/null > > +++ b/tests/Functional.fuegotest/fuego_test.sh > > @@ -0,0 +1,36 @@ > > +#!/bin/bash > > + > > +set -e > > + > > +readonly fuego_release_dir=fuego-release > > +readonly fuego_release_img_name=fuego-release > > +readonly fuego_release_container_name=fuego-release-container > > + > > +function test_build { > > + if [ -d ${fuego_release_dir} ]; then > > + rm -r ${fuego_release_dir} > > + fi > > + git clone --quiet --depth 1 --single-branch \ > > + --branch "${FUNCTIONAL_FUEGOTEST_BRANCH}" \ > > + "${FUNCTIONAL_FUEGOTEST_REPO}" \ > > + "${fuego_release_dir}" > > + cd "${fuego_release_dir}" > > + git submodule update --init --recursive > > + cd - > > +} > > + > > +function test_run { > > + cd "${fuego_release_dir}" > > + ./install.sh "${fuego_release_img_name}" > > + sudo -n docker rm -f "${fuego_release_container_name}" || true > > + sudo -n docker create -it --name "${fuego_release_container_name}" > \ > > + -p 8081:8080 \ > > + --net="bridge" "${fuego_release_img_name}" > > + > > + python3 ${TEST_HOME}/test_run.py > > + report "echo ok 1 minimal test on target" > > +} > > + > > +function test_processing { > > + log_compare "$TESTDIR" "1" "^ok" "p" > > +} > > diff --git a/tests/Functional.fuegotest/spec.json > > b/tests/Functional.fuegotest/spec.json > > new file mode 100644 > > index 0000000..703cb0d > > --- /dev/null > > +++ b/tests/Functional.fuegotest/spec.json > > @@ -0,0 +1,9 @@ > > +{ > > + "testName": "Functional.fuegotest", > > + "specs": { > > + "default": { > > + "REPO":"FUEGOTEST_REPO", > > + "BRANCH":"FUEGOTEST_BRANCH" > > + } > > + } > > +} > > diff --git a/tests/Functional.fuegotest/test_run.py > > b/tests/Functional.fuegotest/test_run.py > > new file mode 100755 > > index 0000000..139ad9e > > --- /dev/null > > +++ b/tests/Functional.fuegotest/test_run.py > > @@ -0,0 +1,19 @@ > > +#!/usr/bin/env python > > + > > +import pexpect > > + > > +# TODO: Check for errors > > > > As you see, this test is just a very simple bootstrap. The plan is to > > include many more steps in it in the future. > > > > + > > +c = pexpect.spawnu('sudo docker start --interactive --attach > fuego-release- > > container') > > +c.sendline('\r\n') > > +c.expect('# $') > > + > > +print('Adding Node') > > +c.sendline('ftc add-nodes docker') > > +c.expect('# $', timeout=120) > > + > > +print('Adding Jobs') > > +c.sendline('ftc add-jobs -b docker -p testplan_docker') > > +c.expect('# $', timeout=120) > > + > > +print('Node and Jobs have been added') > > -- > > 2.16.1 > > > > _______________________________________________ > > Fuego mailing list > > Fuego at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/fuego > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guicc at profusion.mobi Tue Feb 20 02:31:53 2018 From: guicc at profusion.mobi (Guilherme Camargo) Date: Mon, 19 Feb 2018 23:31:53 -0300 Subject: [Fuego] [PATCH] Fuego Release Test Repository In-Reply-To: References: <20180216214220.23806-1-guicc@profusion.mobi> Message-ID: On Mon, Feb 19, 2018 at 10:12 PM, wrote: > > -----Original Message----- > > From: Tim.Bird > > > > -----Original Message----- > > > From: Guilherme Campos Camargo > > > Hello, everyone > > > > > > This repository > > What repository? https://bitbucket.org/profusionmobi/fuego? > > > > I see a repository on bitbucket, under profusionmobi, called > > 'fuego-release-test'? Is that the one? I can find no mention > > of the repository below... > > > > I presume I clone something, then run build_and_run.sh? > > Do I need to have any fuego materials pre-installed? > > (the 'driving' fuego?) > > I have several instances of Fuego available on my machine, but I wasn't > sure if one of these was supposed to be running when I ran > build_and_run.sh. > ?You shouldn't need to have any of them running. fuego-release-test should work standalone. > > I did this: > > $ git clone https://bitbucket.org/profusionmobi/fuego-release-test > $ cd fuego-release-test > $ ./build_and_run.sh -p 8080 up > Error: no such container: fuego-rt-container > > ---- > Am I supposed to have a container named 'fuego-rt-container'? > > I see other command line options: > -c to start from scratch > -d to run in detached mode > > Should I be using these? > ? ?Sorry, Tim. As I explained in my last e-mail, just use $./build_and_run.sh -c -p 8080 up? ?There's a bug that's requiring -c on the first time - to create the container.? > What is the meaning of 'up' and 'down'. Sorry, but I'm confused > about how this works. > 'up' would create the container (if not already present), then start it. 'down' would just 'stop' the container. A user would then be able to restart by running './build_and_run.sh up' again, or 'start from scratch' (erasing all saved data/logs/test results) by using './build_and_run -c up'. > > Please help. > -- Tim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guicc at profusion.mobi Tue Feb 20 03:06:26 2018 From: guicc at profusion.mobi (Guilherme Camargo) Date: Tue, 20 Feb 2018 00:06:26 -0300 Subject: [Fuego] [PATCH] Fuego Release Test Repository In-Reply-To: References: <20180216214220.23806-1-guicc@profusion.mobi> Message-ID: On Mon, Feb 19, 2018 at 10:25 PM, wrote: > > > > -----Original Message----- > > From: Gustavo Sverzut Barbieri > > On Fri, Feb 16, 2018 at 7:42 PM, Guilherme Campos Camargo > > wrote: > > ... > > > Also, it's important to note that this patch represents a sort of > > > paradigm shift in the way that tests are added to Fuego, given that: > > > - The software requirements are being installed through a Dockerfile > > > that extends fuego-base. > > > - The test routines/plans and the new boards are moved to Fuego during > > > build time, acting almost as an "overlay". > > > For that reason, it's imperative that current users/contributors > provide > > > their feedback regarding this new approach before we move on. Also, > > > since I just started contributing with and using fuego, it's likely > that > > > I missed something, specially related to Fuego usability. So please, > > > kindly add your comments and correct me if so. > > > > Tim, I discussed this with Guilherme and we'll formalize a proposal > > around the spec.json file, something along the lines: > > > > 1) test specify the debian repositories, packages and even gpg/keys > > (for repos). Instead of always adding the packages to the container, > > either by modifying the official docker image (as done before) or > > creating an overlay (as done by Guilherme), Fuego would make sure the > > repositories are added and packages are added prior to executing the > > tests. > > > > Since I haven't been able to run the release-test yet, this is also going > over my head. > > What problem is this solving? > > Is this for a test to specify additional packages for the base distribution > in the docker container, that the test needs on the host? Or is it referring to a new -dev package used for building the software > for the target (but again, something that needs to be in the > docker container, but is part of the toolchain)? > ?? > Would this be used for something like: > lib-cairo-dev, or netperf-server? > ? ? ? ?As far as I understand, we should be able to specify packages for both cases you pointed out above. The 'test_build' step, on the fuego test script (fuego_test.sh), would be responsible for making sure all those packages are installed? in the fuego container before ?properly ? executing the test ? steps.? Barbieri might provide more comments to add to the discussion > > > JSON object would look like: > > > > "packages-dependencies": { > > "repositories": ["deb https://download.docker.com/linux/debian > > jessie"], > > "keys": ["https://download.docker.com/linux/debian/gpg"], > > "packages": ["docker-ce", "libxpto-dev"], > > } > > > > Which would manage /etc/apt/sources.d/fuego.conf + apt-get install > > > > > > 2) in addition to the test scenarios variables that are pre-defined, > > allow user to redefined/override those when executing the test using > > the command line. For example fuego-release-test (fuego-rt) would > > default to test official repository with the branch "next", but one > > could override to test a private repo with a custom branch. > > > > This would solve the need to "patch" the correct value at entrypoint.sh: > > > > sed -i "s/FUEGOTEST_REPO/${test_repo_escaped}/" > > /fuego-core/engine/tests/Functional.fuegotest/spec.json > > ... > > ftc add-jobs -b fuego-test -t Functional.fuegotest > > > > With something like: > > > > ftc add-jobs -b fuego-test -t Functional.fuegotest -v > > FUEGOTEST_REPO=${test_repo_escaped} > We've talked about adding the ability to define a test > variable on the command line, when adding jobs > or running tests, that would override the value contained > in a spec file. > > This is highly desirable. > > I'm still, however, wrapping my head around the fuego release > self-test case, which I don't understand yet. Talking > about this feature in that context may be too much for my > little brain to handle, at the moment. > Sure. We can talk about that later. Please ask if you still have questions about the self-test. > -- Tim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guicc at profusion.mobi Tue Feb 20 03:20:10 2018 From: guicc at profusion.mobi (Guilherme Camargo) Date: Tue, 20 Feb 2018 00:20:10 -0300 Subject: [Fuego] [PATCH] Move fuego-ro/core to image during build and keep core as submodule In-Reply-To: References: <20180216214557.27540-1-guicc@profusion.mobi> Message-ID: On Mon, Feb 19, 2018 at 10:18 PM, wrote: > > > > -----Original Message----- > > From: Guilherme Campos Camargo > > Those directories ideally shoud be copied to the image during build time > > given that Fuego would not run if their content is not available. By > > doing this, we're also making sure that a user that plans to use > > fuego-base docker image directly (or as a base image for his own docker > > images) will be able to do it straightforwardly, without the need of > > cloning other repositories or bind-mounting host's directories. > > > > It's also a good idea to keep fuego-core locked in a fixed release, what > > we can enforce easily by using git submodules. This is desired if we > > want to use a stable version of fuego to test new versions of fuego. > > > > On this patch we configure fuego-core as a submodule and make the > > changes needed for copying the required contents of the mentioned > > directories. > > I understand virtually none of what you wrote here. > > Is this patch for tbird20d/fuego? Is it against > profusionmobil/fuego-release-test? > ?This patch is for tbird20d/fuego.? > > I haven't figured out how the fuego-release-test works yet, so I don't > understand what you're referring to when you say "those directories", > or "fuego-base docker image". > ?Sorry about that. On profusionmobi/fuego-release-test Dockerfile, I'm using a stable fuego image as base, with the following directive: FROM fuegotest/fuego-base:latest fuegotest/fuego-base image has been created from tbird20d/fuego:next - with the patch of this e-mail applied - and uploaded to https://hub.docker.com/r/fuegotest/fuego-base/ For fuego-release-test to work as presented (in my other e-mail), we need to have fuego-core and fuego-base as part of the base image (fuegotest/fuego-base). This patch just copies fuego-base and fuego-core to the fuego image during build time. Since fuego-core is in a separate repository, I'm just moving it it inside fuego as a submodule. ? > > > > > -- > > Tim, please let us know what you think about it. > I need to understand what's going on, and how all these repositories > interact, before I can give any coherent answer. > > I think that once I've run the release test successfully, I will be able > to figure out what you're talking about here. > -- Tim > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From barbieri at profusion.mobi Tue Feb 20 14:07:04 2018 From: barbieri at profusion.mobi (Gustavo Sverzut Barbieri) Date: Tue, 20 Feb 2018 11:07:04 -0300 Subject: [Fuego] [PATCH] Fuego Release Test Repository In-Reply-To: References: <20180216214220.23806-1-guicc@profusion.mobi> Message-ID: On Mon, Feb 19, 2018 at 10:25 PM, wrote: > > >> -----Original Message----- >> From: Gustavo Sverzut Barbieri >> On Fri, Feb 16, 2018 at 7:42 PM, Guilherme Campos Camargo >> wrote: >> ... >> > Also, it's important to note that this patch represents a sort of >> > paradigm shift in the way that tests are added to Fuego, given that: >> > - The software requirements are being installed through a Dockerfile >> > that extends fuego-base. >> > - The test routines/plans and the new boards are moved to Fuego during >> > build time, acting almost as an "overlay". >> > For that reason, it's imperative that current users/contributors provide >> > their feedback regarding this new approach before we move on. Also, >> > since I just started contributing with and using fuego, it's likely that >> > I missed something, specially related to Fuego usability. So please, >> > kindly add your comments and correct me if so. >> >> Tim, I discussed this with Guilherme and we'll formalize a proposal >> around the spec.json file, something along the lines: >> >> 1) test specify the debian repositories, packages and even gpg/keys >> (for repos). Instead of always adding the packages to the container, >> either by modifying the official docker image (as done before) or >> creating an overlay (as done by Guilherme), Fuego would make sure the >> repositories are added and packages are added prior to executing the >> tests. >> > > Since I haven't been able to run the release-test yet, this is also going > over my head. > > What problem is this solving? > > Is this for a test to specify additional packages for the base distribution > in the docker container, that the test needs on the host? > > Or is it referring to a new -dev package used for building the software > for the target (but again, something that needs to be in the > docker container, but is part of the toolchain)? > > Would this be used for something like: > lib-cairo-dev, or netperf-server? a bit of all, these are dependencies *inside the fuego container* to build and run the tests. (nothing is installed in the user host machine). so for tests that needs libcairo-dev to build/run, that would be the dependencies. for tests that need the netperf-server, that would be the dependencies. for fuego-rt, we need docker (client inside the container to contact the host to build images), also need python's pexpect, selenium and so on. for cross-compiled tests, it would be the cross compiler toolchain. However, for toolchains/cross-compile, things may be better defined per target board/architecture, not per test... >> JSON object would look like: >> >> "packages-dependencies": { >> "repositories": ["deb https://download.docker.com/linux/debian >> jessie"], >> "keys": ["https://download.docker.com/linux/debian/gpg"], >> "packages": ["docker-ce", "libxpto-dev"], >> } >> >> Which would manage /etc/apt/sources.d/fuego.conf + apt-get install >> >> >> 2) in addition to the test scenarios variables that are pre-defined, >> allow user to redefined/override those when executing the test using >> the command line. For example fuego-release-test (fuego-rt) would >> default to test official repository with the branch "next", but one >> could override to test a private repo with a custom branch. >> >> This would solve the need to "patch" the correct value at entrypoint.sh: >> >> sed -i "s/FUEGOTEST_REPO/${test_repo_escaped}/" >> /fuego-core/engine/tests/Functional.fuegotest/spec.json >> ... >> ftc add-jobs -b fuego-test -t Functional.fuegotest >> >> With something like: >> >> ftc add-jobs -b fuego-test -t Functional.fuegotest -v >> FUEGOTEST_REPO=${test_repo_escaped} > We've talked about adding the ability to define a test > variable on the command line, when adding jobs > or running tests, that would override the value contained > in a spec file. > > This is highly desirable. > > I'm still, however, wrapping my head around the fuego release > self-test case, which I don't understand yet. Talking > about this feature in that context may be too much for my > little brain to handle, at the moment. the big picture is: your-linux-pc (aka: desktop) -> runs fuego-stable (aka: stable-container) -> executes functional test fuego-release-test (ftc add-jobs -b fuego-test -t Functional.fuegotest) - download fuego from $FUEGOTEST_REPO + $FUEGOTEST_BRANCH - generate a new docker image for that - runs a container for that image - executes release tests for that container (ie: calls "ftc" for that container) - remove that container and image - reports back test results <- report if fuego-release-test passed/failed then, the parameters here (git repo and branch) must be passed from your desktop to fuego-stable so it knows what is to be tested. We can provide few fixed test scenarios, such as official git repo and branches: master + next. but say I have my own fork and I want to test that repo+branch, I need a way to specify that. What Guilherme did to address that is to dyamically patch the spec.json, which is bad (just stop-gap so he can test with his own repo). -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN, GTalk, FaceTime: barbieri at gmail.com Skype: gsbarbieri Mobile: +55 (16) 99354-9890 From guicc at profusion.mobi Tue Feb 20 15:45:51 2018 From: guicc at profusion.mobi (Guilherme Camargo) Date: Tue, 20 Feb 2018 12:45:51 -0300 Subject: [Fuego] [PATCH] Fuego Release Test Repository In-Reply-To: References: <20180216214220.23806-1-guicc@profusion.mobi> Message-ID: On Mon, Feb 19, 2018 at 11:31 PM, Guilherme Camargo wrote: > > > On Mon, Feb 19, 2018 at 10:12 PM, wrote: > >> > -----Original Message----- >> > From: Tim.Bird >> >> > > -----Original Message----- >> > > From: Guilherme Campos Camargo >> > > Hello, everyone >> > > >> > > This repository >> > What repository? https://bitbucket.org/profusionmobi/fuego? >> > >> > I see a repository on bitbucket, under profusionmobi, called >> > 'fuego-release-test'? Is that the one? I can find no mention >> > of the repository below... >> > >> > I presume I clone something, then run build_and_run.sh? >> > Do I need to have any fuego materials pre-installed? >> > (the 'driving' fuego?) >> >> I have several instances of Fuego available on my machine, but I wasn't >> sure if one of these was supposed to be running when I ran >> build_and_run.sh. >> > > ?You shouldn't need to have any of them running. fuego-release-test should > work standalone. > >> >> I did this: >> >> $ git clone https://bitbucket.org/profusionmobi/fuego-release-test >> $ cd fuego-release-test >> $ ./build_and_run.sh -p 8080 up >> Error: no such container: fuego-rt-container >> >> ---- >> Am I supposed to have a container named 'fuego-rt-container'? >> >> I see other command line options: >> -c to start from scratch >> -d to run in detached mode >> >> Should I be using these? >> > > ? > ?Sorry, Tim. As I explained in my last e-mail, just use > > $./build_and_run.sh -c -p 8080 up? > > ?There's a bug that's requiring -c on the first time - to create the > container.? > > >> What is the meaning of 'up' and 'down'. Sorry, but I'm confused >> about how this works. >> > > 'up' would create the container (if not already present), then start it. > 'down' would just 'stop' the container. > > A user would then be able to restart by running './build_and_run.sh up' > again, > or 'start from scratch' (erasing all saved data/logs/test results) by using > './build_and_run -c up'. > ?Tim, please sync the repo again (?https://bitbucket.org/ profusionmobi/fuego-release-test?). I've force-pushed some changes. After that, you can just run `./build_and_run -c up`. > > >> >> Please help. >> -- Tim >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Bird at sony.com Wed Feb 21 14:48:20 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Wed, 21 Feb 2018 14:48:20 +0000 Subject: [Fuego] release test issues Message-ID: > -----Original Message----- > From: Guilherme Camargo > ?Tim, please sync the repo again (? > https://bitbucket.org/profusionmobi/fuego-release-test > ?). > I've force-pushed some changes. > > After that, you can just run `./build_and_run -c up`. My container doesn't start Jenkins. I'm not sure if this is a cascade error from some initial problem, but here is some information about my situation. I removed my repository, and did a new 'git clone' of the fuego-release-test repository. It doesn't appear to me to be updated recently: $ git branch -v * master 9d82c80 Initial commit $ git log commit 9d82c80d66a4de24ab97b38a16c8536849fea5bc Author: Guilherme Campos Camargo Date: Tue Feb 6 02:13:20 2018 -0200 Initial commit This repository has been created to store the resources needed for the generation of a Docker image, based on fuego-base, that has all the tools needed for the automation of the tests that are required for validating a new Fuego release with Fuego itself. ... I see that there are other branches with more recent commits (the 'ppa', and the 'fuego-base' branch. Should I be using one of these? Here's the error I saw while trying build_and_run.sh: ----- Downloading/unpacking pexpect Downloading/unpacking ptyprocess>=0.5 (from pexpect) Downloading ptyprocess-0.5.2-py2.py3-none-any.whl Installing collected packages: pexpect, ptyprocess Successfully installed pexpect ptyprocess Cleaning up... ---> fd97e25fac02 Removing intermediate container 5a3a3638cb21 Step 4/7 : RUN echo "jenkins ALL = (root) NOPASSWD: /usr/bin/docker, /bin/sh" >> /etc/sudoers ---> Running in da0a1d824354 ---> fb6468918ab5 Removing intermediate container da0a1d824354 Step 5/7 : COPY fuego-ro /fuego-ro ---> bbe089e90e5f Removing intermediate container 6a4b20b92a4e Step 6/7 : COPY tests /fuego-core/engine/tests ---> 57c7374dd097 Removing intermediate container aa6b4c80255c Step 7/7 : COPY fuego-rt-entrypoint.sh / ---> 9ef063ab4a5b Removing intermediate container 32a90a4f3abb Successfully built 9ef063ab4a5b Successfully tagged fuego-rt:latest Error response from daemon: No such container: fuego-rt-container 6f513d49f117300672e1ba8782f0411448ffdf8e5258dd689797895cd79d8068 Waiting for Jenkins on http://localhost:8090/fuego/... Creating job fuego-test.default.Functional.fuegotest fuego-rt-container [FAIL] Starting Jenkins Continuous Integration Server: jenkins failed! [ ok ] Starting network benchmark server. root at 6f513d49f117:/# ----- And here is some investigation: ----- root at 6f513d49f117:/# tail -n 20 /var/log/jenkins/jenkins.log INFO: Winstone shutdown successfully Feb 21, 2018 2:13:22 PM winstone.Logger logInternal SEVERE: Container startup failed java.io.FileNotFoundException: /var/cache/jenkins/war/META-INF/MANIFEST.MF (Permission denied) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.(FileOutputStream.java:221) at java.io.FileOutputStream.(FileOutputStream.java:171) at winstone.HostConfiguration.getWebRoot(HostConfiguration.java:280) at winstone.HostConfiguration.(HostConfiguration.java:83) at winstone.HostGroup.initHost(HostGroup.java:66) at winstone.HostGroup.(HostGroup.java:45) at winstone.Launcher.(Launcher.java:143) at winstone.Launcher.main(Launcher.java:352) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at Main._main(Main.java:264) at Main.main(Main.java:112) root at 6f513d49f117:/# su - jenkins jenkins at 6f513d49f117:~$ cat /var/cache/jenkins/war/META-INF/MANIFEST.MF cat: /var/cache/jenkins/war/META-INF/MANIFEST.MF: Permission denied jenkins at 6f513d49f117:~$ ls -lad /var /var/cache /var/cache/jenkins /var/cache/jenkins/war /var/cache/jenkins/war/META-INF /var/cache/jenkins/war/META-INF/MANIFEST.MF ls: cannot access /var/cache/jenkins/war: Permission denied ls: cannot access /var/cache/jenkins/war/META-INF: Permission denied ls: cannot access /var/cache/jenkins/war/META-INF/MANIFEST.MF: Permission denied drwxr-xr-x 32 root root 4096 Feb 21 07:12 /var drwxr-xr-x 17 root root 4096 Feb 21 07:12 /var/cache drwxr-x--- 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins jenkins at 6f513d49f117:~$ exit logout root at 6f513d49f117:/# ls -lad /var /var/cache /var/cache/jenkins /var/cache/jenkins/war /var/cache/jenkins/war/META-INF /var/cache/jenkins/war/META-INF/MANIFEST.MF drwxr-xr-x 32 root root 4096 Feb 21 07:12 /var drwxr-xr-x 17 root root 4096 Feb 21 07:12 /var/cache drwxr-x--- 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins drwxr-xr-x 18 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins/war drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins/war/META-INF -rw-r--r-- 1 jenkins jenkins 129535 Feb 15 18:56 /var/cache/jenkins/war/META-INF/MANIFEST.MF root at 6f513d49f117:/# su - jenkins jenkins at 6f513d49f117:~$ id uid=1000(jenkins) gid=987(jenkins) groups=987(jenkins) jenkins at 6f513d49f117:~$ ----- For reasons that escape me, it looks like these permissions are not allowing jenkins in the container to access the 'war' directory: drwxr-x--- 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins ----- root at 6f513d49f117:/var/cache/jenkins# chmod o+rx . root at 6f513d49f117:/var/cache/jenkins# ls -la total 12 drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 . drwxr-xr-x 17 root root 4096 Feb 21 07:12 .. drwxr-xr-x 18 jenkins jenkins 4096 Feb 21 07:12 war root at 6f513d49f117:/var/cache/jenkins# su - jenkins jenkins at 6f513d49f117:~$ ls -lad /var /var/cache /var/cache/jenkins /var/cache/jenkins/war /var/cache/jenkins/war/META-INF /var/cache/jenkins/war/META-INF/MANIFEST.MF drwxr-xr-x 32 root root 4096 Feb 21 07:12 /var drwxr-xr-x 17 root root 4096 Feb 21 07:12 /var/cache drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins drwxr-xr-x 18 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins/war drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins/war/META-INF -rw-r--r-- 1 jenkins jenkins 129535 Feb 15 18:56 /var/cache/jenkins/war/META-INF/MANIFEST.MF ----- However, maybe it's not that simple: ----- jenkins at 6f513d49f117:~$ exit logout root at 6f513d49f117:/var/cache/jenkins# exit exit 1000072457 at tlinux:~/work/fuego/release-test-2018-02-19/fuego-release-test$ ./build_and_run.sh up [FAIL] Starting Jenkins Continuous Integration Server: jenkins failed! [ ok ] Starting network benchmark server. root at 6f513d49f117:/# tail -n 20 /var/log/jenkins/jenkins.log INFO: Winstone shutdown successfully Feb 21, 2018 2:38:41 PM winstone.Logger logInternal SEVERE: Container startup failed java.io.FileNotFoundException: /var/cache/jenkins/war/META-INF/MANIFEST.MF (Permission denied) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.(FileOutputStream.java:221) at java.io.FileOutputStream.(FileOutputStream.java:171) at winstone.HostConfiguration.getWebRoot(HostConfiguration.java:280) at winstone.HostConfiguration.(HostConfiguration.java:83) at winstone.HostGroup.initHost(HostGroup.java:66) at winstone.HostGroup.(HostGroup.java:45) at winstone.Launcher.(Launcher.java:143) at winstone.Launcher.main(Launcher.java:352) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at Main._main(Main.java:264) at Main.main(Main.java:112) root at 6f513d49f117:/# su - jenkins jenkins at 6f513d49f117:~$ ls -lad /var /var/cache /var/cache/jenkins /var/cache/jenkins/war /var/cache/jenkins/war/META-INF /var/cache/jenkins/war/META-INF/MANIFEST.MF ls: cannot access /var/cache/jenkins/war: Permission denied ls: cannot access /var/cache/jenkins/war/META-INF: Permission denied ls: cannot access /var/cache/jenkins/war/META-INF/MANIFEST.MF: Permission denied drwxr-xr-x 32 root root 4096 Feb 21 07:12 /var drwxr-xr-x 17 root root 4096 Feb 21 07:12 /var/cache drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins I'm running this on Ubuntu 14.04, with docker 17.05.0-ce ----- OK - in summary: - I think I might be running the wrong branch of fuego-release-test - I have weird permission problems in my docker container, for the fuego user and group that are preventing jenkins from starting - the jenkins user id and group id don't match my local user's user id and group id Any help would be appreciated. -- Tim From guicc at profusion.mobi Wed Feb 21 17:23:24 2018 From: guicc at profusion.mobi (Guilherme Camargo) Date: Wed, 21 Feb 2018 14:23:24 -0300 Subject: [Fuego] release test issues In-Reply-To: References: Message-ID: Hello, Tim, thanks for trying it out again and thanks for your time in debugging this issue and providing logs. This problem is happening because we're not using fuego-host-scripts in the derived fuego-release-test, what ends up resulting in the jenkins' user not being properly mapped to the host's user. That's my fault, I forgot that this would be required in the derivate image as well. I temporarily added that logic to build_and_run.sh (as a fixup commit) so that you're able to test it out, please see the patch below: diff --git a/build_and_run.sh b/build_and_run.sh index e448ddf..0134759 100755 --- a/build_and_run.sh +++ b/build_and_run.sh @@ -50,6 +50,25 @@ fi if [ "$1" = "up" ]; then if [ -v clean_start ]; then + # FIXME: We should provide a simpler way of mapping jenkins uid with + # hosts uid, that does not require the user (that's extending + # fuego-base) to have this logic in his docker build. + # + # Jenkins' uid/gid should probably be given as a docker-run variable + # (as http_proxy/https_proxy, and set properly through fuego-base + # entrypoint.) + # + if [ "${UID}" == "0" ]; then + uid=$(id -u "${SUDO_USER}") + gid=$(id -g "${SUDO_USER}") + else + uid="${UID}" + gid=$(id -g "${USER}") + fi + + sed -i "s/HOST_UID/${uid}/" ./fuego-ro/conf/fuego.conf + sed -i "s/HOST_GID/${gid}/" ./fuego-ro/conf/fuego.conf + docker build -t "${fuego_rt_image}" . docker rm -f "${fuego_rt_container}" docker run -dit --name ${fuego_rt_container} \ diff --git a/fuego-ro/conf/fuego.conf b/fuego-ro/conf/fuego.conf index 0c95eae..96cdcc9 100644 --- a/fuego-ro/conf/fuego.conf +++ b/fuego-ro/conf/fuego.conf @@ -1,3 +1,3 @@ -docker_jenkins_uid=1000 -docker_jenkins_gid=987 +docker_jenkins_uid=HOST_UID +docker_jenkins_gid=HOST_GID As I mentioned in my FIXME message, its undesirable to require a derivate image to contain specific build steps (as the one that's replacing the id into fuego.conf), so we might need to come up with a better approach to make this work. The patch has already been pushed to ? https://bitbucket.org/profusionmobi/fuego-release-test (master). Can you please re-sync and test again? Thank you -- Guilherme On Wed, Feb 21, 2018 at 11:48 AM, wrote: > > -----Original Message----- > > From: Guilherme Camargo > > ?Tim, please sync the repo again (? > > > ?? > https://bitbucket.org/profusionmobi/fuego-release-test > > ?). > > I've force-pushed some changes. > > > > After that, you can just run `./build_and_run -c up`. > > My container doesn't start Jenkins. I'm not sure if this is > a cascade error from some initial problem, but here is > some information about my situation. > > I removed my repository, and did a new 'git clone' of the > fuego-release-test repository. It doesn't appear to me to > be updated recently: > > $ git branch -v > * master 9d82c80 Initial commit > $ git log > commit 9d82c80d66a4de24ab97b38a16c8536849fea5bc > Author: Guilherme Campos Camargo > Date: Tue Feb 6 02:13:20 2018 -0200 > > Initial commit > > This repository has been created to store the resources needed for the > generation of a Docker image, based on fuego-base, that has all the > tools needed for the automation of the tests that are required for > validating a new Fuego release with Fuego itself. > ... > > I see that there are other branches with more recent commits (the > 'ppa', and the 'fuego-base' branch. Should I be using one of these? > > Here's the error I saw while trying build_and_run.sh: > > ----- > Downloading/unpacking pexpect > Downloading/unpacking ptyprocess>=0.5 (from pexpect) > Downloading ptyprocess-0.5.2-py2.py3-none-any.whl > Installing collected packages: pexpect, ptyprocess > Successfully installed pexpect ptyprocess > Cleaning up... > ---> fd97e25fac02 > Removing intermediate container 5a3a3638cb21 > Step 4/7 : RUN echo "jenkins ALL = (root) NOPASSWD: /usr/bin/docker, > /bin/sh" >> /etc/sudoers > ---> Running in da0a1d824354 > ---> fb6468918ab5 > Removing intermediate container da0a1d824354 > Step 5/7 : COPY fuego-ro /fuego-ro > ---> bbe089e90e5f > Removing intermediate container 6a4b20b92a4e > Step 6/7 : COPY tests /fuego-core/engine/tests > ---> 57c7374dd097 > Removing intermediate container aa6b4c80255c > Step 7/7 : COPY fuego-rt-entrypoint.sh / > ---> 9ef063ab4a5b > Removing intermediate container 32a90a4f3abb > Successfully built 9ef063ab4a5b > Successfully tagged fuego-rt:latest > Error response from daemon: No such container: fuego-rt-container > 6f513d49f117300672e1ba8782f0411448ffdf8e5258dd689797895cd79d8068 > Waiting for Jenkins on http://localhost:8090/fuego/... > Creating job fuego-test.default.Functional.fuegotest > fuego-rt-container > [FAIL] Starting Jenkins Continuous Integration Server: jenkins failed! > [ ok ] Starting network benchmark server. > root at 6f513d49f117:/# > > ----- > > And here is some investigation: > ----- > root at 6f513d49f117:/# tail -n 20 /var/log/jenkins/jenkins.log > INFO: Winstone shutdown successfully > Feb 21, 2018 2:13:22 PM winstone.Logger logInternal > SEVERE: Container startup failed > java.io.FileNotFoundException: /var/cache/jenkins/war/META-INF/MANIFEST.MF > (Permission denied) > at java.io.FileOutputStream.open(Native Method) > at java.io.FileOutputStream.(FileOutputStream.java:221) > at java.io.FileOutputStream.(FileOutputStream.java:171) > at winstone.HostConfiguration.getWebRoot(HostConfiguration. > java:280) > at winstone.HostConfiguration.(HostConfiguration.java:83) > at winstone.HostGroup.initHost(HostGroup.java:66) > at winstone.HostGroup.(HostGroup.java:45) > at winstone.Launcher.(Launcher.java:143) > at winstone.Launcher.main(Launcher.java:352) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke( > NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at Main._main(Main.java:264) > at Main.main(Main.java:112) > > root at 6f513d49f117:/# su - jenkins > jenkins at 6f513d49f117:~$ cat /var/cache/jenkins/war/META-INF/MANIFEST.MF > cat: /var/cache/jenkins/war/META-INF/MANIFEST.MF: Permission denied > jenkins at 6f513d49f117:~$ ls -lad /var /var/cache /var/cache/jenkins > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF > /var/cache/jenkins/war/META-INF/MANIFEST.MF > ls: cannot access /var/cache/jenkins/war: Permission denied > ls: cannot access /var/cache/jenkins/war/META-INF: Permission denied > ls: cannot access /var/cache/jenkins/war/META-INF/MANIFEST.MF: Permission > denied > drwxr-xr-x 32 root root 4096 Feb 21 07:12 /var > drwxr-xr-x 17 root root 4096 Feb 21 07:12 /var/cache > drwxr-x--- 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins > jenkins at 6f513d49f117:~$ exit > logout > root at 6f513d49f117:/# ls -lad /var /var/cache /var/cache/jenkins > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF > /var/cache/jenkins/war/META-INF/MANIFEST.MF > drwxr-xr-x 32 root root 4096 Feb 21 07:12 /var > drwxr-xr-x 17 root root 4096 Feb 21 07:12 /var/cache > drwxr-x--- 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins > drwxr-xr-x 18 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins/war > drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 > /var/cache/jenkins/war/META-INF > -rw-r--r-- 1 jenkins jenkins 129535 Feb 15 18:56 > /var/cache/jenkins/war/META-INF/MANIFEST.MF > root at 6f513d49f117:/# su - jenkins > jenkins at 6f513d49f117:~$ id > uid=1000(jenkins) gid=987(jenkins) groups=987(jenkins) > jenkins at 6f513d49f117:~$ > ----- > For reasons that escape me, it looks like these permissions are not > allowing jenkins in the container to access the 'war' directory: > drwxr-x--- 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins > > ----- > root at 6f513d49f117:/var/cache/jenkins# chmod o+rx . > root at 6f513d49f117:/var/cache/jenkins# ls -la > total 12 > drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 . > drwxr-xr-x 17 root root 4096 Feb 21 07:12 .. > drwxr-xr-x 18 jenkins jenkins 4096 Feb 21 07:12 war > root at 6f513d49f117:/var/cache/jenkins# su - jenkins > jenkins at 6f513d49f117:~$ ls -lad /var /var/cache /var/cache/jenkins > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF > /var/cache/jenkins/war/META-INF/MANIFEST.MF > drwxr-xr-x 32 root root 4096 Feb 21 07:12 /var > drwxr-xr-x 17 root root 4096 Feb 21 07:12 /var/cache > drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins > drwxr-xr-x 18 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins/war > drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 > /var/cache/jenkins/war/META-INF > -rw-r--r-- 1 jenkins jenkins 129535 Feb 15 18:56 > /var/cache/jenkins/war/META-INF/MANIFEST.MF > ----- > However, maybe it's not that simple: > ----- > > jenkins at 6f513d49f117:~$ exit > logout > root at 6f513d49f117:/var/cache/jenkins# exit > exit > 1000072457 at tlinux:~/work/fuego/release-test-2018-02-19/fuego-release-test$ > ./build_and_run.sh up > [FAIL] Starting Jenkins Continuous Integration Server: jenkins failed! > [ ok ] Starting network benchmark server. > root at 6f513d49f117:/# tail -n 20 /var/log/jenkins/jenkins.log > INFO: Winstone shutdown successfully > Feb 21, 2018 2:38:41 PM winstone.Logger logInternal > SEVERE: Container startup failed > java.io.FileNotFoundException: /var/cache/jenkins/war/META-INF/MANIFEST.MF > (Permission denied) > at java.io.FileOutputStream.open(Native Method) > at java.io.FileOutputStream.(FileOutputStream.java:221) > at java.io.FileOutputStream.(FileOutputStream.java:171) > at winstone.HostConfiguration.getWebRoot(HostConfiguration. > java:280) > at winstone.HostConfiguration.(HostConfiguration.java:83) > at winstone.HostGroup.initHost(HostGroup.java:66) > at winstone.HostGroup.(HostGroup.java:45) > at winstone.Launcher.(Launcher.java:143) > at winstone.Launcher.main(Launcher.java:352) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke( > NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at Main._main(Main.java:264) > at Main.main(Main.java:112) > > root at 6f513d49f117:/# su - jenkins > jenkins at 6f513d49f117:~$ ls -lad /var /var/cache /var/cache/jenkins > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF > /var/cache/jenkins/war/META-INF/MANIFEST.MF > ls: cannot access /var/cache/jenkins/war: Permission denied > ls: cannot access /var/cache/jenkins/war/META-INF: Permission denied > ls: cannot access /var/cache/jenkins/war/META-INF/MANIFEST.MF: Permission > denied > drwxr-xr-x 32 root root 4096 Feb 21 07:12 /var > drwxr-xr-x 17 root root 4096 Feb 21 07:12 /var/cache > drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins > > I'm running this on Ubuntu 14.04, with docker 17.05.0-ce > > ----- > OK - in summary: > > - I think I might be running the wrong branch of fuego-release-test > - I have weird permission problems in my docker container, for the fuego > user and group > that are preventing jenkins from starting > - the jenkins user id and group id don't match my local user's user id and > group id > > Any help would be appreciated. > -- Tim > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Bird at sony.com Thu Feb 22 01:19:18 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 22 Feb 2018 01:19:18 +0000 Subject: [Fuego] release test issues In-Reply-To: References: Message-ID: > -----Original Message----- > From: Guilherme Camargo > > Hello, Tim, thanks for trying it out again and thanks for your time > in debugging this issue and providing logs. > > This problem is happening because we're not using fuego-host-scripts > in the derived fuego-release-test, what ends up resulting in the > jenkins' user not being properly mapped to the host's user. > > That's my fault, I forgot that this would be required in the > derivate image as well. > > I temporarily added that logic to build_and_run.sh (as a fixup commit) > > so that you're able to test it out, please see the patch below: > > diff --git a/build_and_run.sh b/build_and_run.sh > index e448ddf..0134759 100755 > --- a/build_and_run.sh > +++ b/build_and_run.sh > @@ -50,6 +50,25 @@ fi > > if [ "$1" = "up" ]; then > if [ -v clean_start ]; then > + # FIXME: We should provide a simpler way of mapping jenkins uid with > + # hosts uid, that does not require the user (that's extending > + # fuego-base) to have this logic in his docker build. > + # > + # Jenkins' uid/gid should probably be given as a docker-run variable > + # (as http_proxy/https_proxy, and set properly through fuego-base > + # entrypoint.) > + # > + if [ "${UID}" == "0" ]; then > + uid=$(id -u "${SUDO_USER}") > + gid=$(id -g "${SUDO_USER}") > + else > + uid="${UID}" > + gid=$(id -g "${USER}") > + fi > + > + sed -i "s/HOST_UID/${uid}/" ./fuego-ro/conf/fuego.conf > + sed -i "s/HOST_GID/${gid}/" ./fuego-ro/conf/fuego.conf > + > docker build -t "${fuego_rt_image}" . > docker rm -f "${fuego_rt_container}" > docker run -dit --name ${fuego_rt_container} \ > diff --git a/fuego-ro/conf/fuego.conf b/fuego-ro/conf/fuego.conf > index 0c95eae..96cdcc9 100644 > --- a/fuego-ro/conf/fuego.conf > +++ b/fuego-ro/conf/fuego.conf > @@ -1,3 +1,3 @@ > -docker_jenkins_uid=1000 > -docker_jenkins_gid=987 > +docker_jenkins_uid=HOST_UID > +docker_jenkins_gid=HOST_GID > > As I mentioned in my FIXME message, its undesirable to require a derivate > image to contain specific build steps (as the one that's replacing the id into > fuego.conf), > so we might need to come up with a better approach to make this work. > > The patch has already been pushed to > > ? > https://bitbucket.org/profusionmobi/fuego-release-test (master). > Can you please re-sync and test again? The jenkins uid and gid in the container now match those of my host user, but I'm getting the same start failure as before. Even when I explicitly change permissions in the path: /var/cache/jenkins/war/META-INF/MANIFEST.MF, I still get the same (Permission denied) message shown in the log (as below). I'm not sure what to try next. -- Tim > > Thank you > > -- > Guilherme > > > On Wed, Feb 21, 2018 at 11:48 AM, > wrote: > > > > -----Original Message----- > > From: Guilherme Camargo > > ?Tim, please sync the repo again (? > > > ? > https://bitbucket.org/profusionmobi/fuego-release-test > > > ?). > > I've force-pushed some changes. > > > > After that, you can just run `./build_and_run -c up`. > > My container doesn't start Jenkins. I'm not sure if this is > a cascade error from some initial problem, but here is > some information about my situation. > > I removed my repository, and did a new 'git clone' of the > fuego-release-test repository. It doesn't appear to me to > be updated recently: > > $ git branch -v > * master 9d82c80 Initial commit > $ git log > commit 9d82c80d66a4de24ab97b38a16c8536849fea5bc > Author: Guilherme Campos Camargo > > Date: Tue Feb 6 02:13:20 2018 -0200 > > Initial commit > > This repository has been created to store the resources needed for > the > generation of a Docker image, based on fuego-base, that has all > the > tools needed for the automation of the tests that are required for > validating a new Fuego release with Fuego itself. > ... > > I see that there are other branches with more recent commits (the > 'ppa', and the 'fuego-base' branch. Should I be using one of these? > > Here's the error I saw while trying build_and_run.sh: > > ----- > Downloading/unpacking pexpect > Downloading/unpacking ptyprocess>=0.5 (from pexpect) > Downloading ptyprocess-0.5.2-py2.py3-none-any.whl > Installing collected packages: pexpect, ptyprocess > Successfully installed pexpect ptyprocess > Cleaning up... > ---> fd97e25fac02 > Removing intermediate container 5a3a3638cb21 > Step 4/7 : RUN echo "jenkins ALL = (root) NOPASSWD: > /usr/bin/docker, /bin/sh" >> /etc/sudoers > ---> Running in da0a1d824354 > ---> fb6468918ab5 > Removing intermediate container da0a1d824354 > Step 5/7 : COPY fuego-ro /fuego-ro > ---> bbe089e90e5f > Removing intermediate container 6a4b20b92a4e > Step 6/7 : COPY tests /fuego-core/engine/tests > ---> 57c7374dd097 > Removing intermediate container aa6b4c80255c > Step 7/7 : COPY fuego-rt-entrypoint.sh / > ---> 9ef063ab4a5b > Removing intermediate container 32a90a4f3abb > Successfully built 9ef063ab4a5b > Successfully tagged fuego-rt:latest > Error response from daemon: No such container: fuego-rt-container > 6f513d49f117300672e1ba8782f0411448ffdf8e5258dd689797895cd79d > 8068 > Waiting for Jenkins on http://localhost:8090/fuego/... > Creating job fuego-test.default.Functional.fuegotest > fuego-rt-container > [FAIL] Starting Jenkins Continuous Integration Server: jenkins failed! > [ ok ] Starting network benchmark server. > root at 6f513d49f117:/# > > ----- > > And here is some investigation: > ----- > root at 6f513d49f117:/# tail -n 20 /var/log/jenkins/jenkins.log > INFO: Winstone shutdown successfully > Feb 21, 2018 2:13:22 PM winstone.Logger logInternal > SEVERE: Container startup failed > java.io.FileNotFoundException: /var/cache/jenkins/war/META- > INF/MANIFEST.MF (Permission denied) > at java.io.FileOutputStream.open(Native Method) > at java.io.FileOutputStream.(FileOutputStream.java:221) > at java.io.FileOutputStream.(FileOutputStream.java:171) > at > winstone.HostConfiguration.getWebRoot(HostConfiguration.java:280) > at winstone.HostConfiguration.(HostConfiguration.java:83) > at winstone.HostGroup.initHost(HostGroup.java:66) > at winstone.HostGroup.(HostGroup.java:45) > at winstone.Launcher.(Launcher.java:143) > at winstone.Launcher.main(Launcher.java:352) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j > ava:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at Main._main(Main.java:264) > at Main.main(Main.java:112) > > root at 6f513d49f117:/# su - jenkins > jenkins at 6f513d49f117:~$ cat /var/cache/jenkins/war/META- > INF/MANIFEST.MF > cat: /var/cache/jenkins/war/META-INF/MANIFEST.MF: Permission > denied > jenkins at 6f513d49f117:~$ ls -lad /var /var/cache /var/cache/jenkins > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF > /var/cache/jenkins/war/META-INF/MANIFEST.MF > ls: cannot access /var/cache/jenkins/war: Permission denied > ls: cannot access /var/cache/jenkins/war/META-INF: Permission > denied > ls: cannot access /var/cache/jenkins/war/META-INF/MANIFEST.MF: > Permission denied > drwxr-xr-x 32 root root 4096 Feb 21 07:12 /var > drwxr-xr-x 17 root root 4096 Feb 21 07:12 /var/cache > drwxr-x--- 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins > jenkins at 6f513d49f117:~$ exit > logout > root at 6f513d49f117:/# ls -lad /var /var/cache /var/cache/jenkins > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF > /var/cache/jenkins/war/META-INF/MANIFEST.MF > drwxr-xr-x 32 root root 4096 Feb 21 07:12 /var > drwxr-xr-x 17 root root 4096 Feb 21 07:12 /var/cache > drwxr-x--- 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins > drwxr-xr-x 18 jenkins jenkins 4096 Feb 21 07:12 > /var/cache/jenkins/war > drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 > /var/cache/jenkins/war/META-INF > -rw-r--r-- 1 jenkins jenkins 129535 Feb 15 18:56 > /var/cache/jenkins/war/META-INF/MANIFEST.MF > root at 6f513d49f117:/# su - jenkins > jenkins at 6f513d49f117:~$ id > uid=1000(jenkins) gid=987(jenkins) groups=987(jenkins) > jenkins at 6f513d49f117:~$ > ----- > For reasons that escape me, it looks like these permissions are not > allowing jenkins in the container to access the 'war' directory: > drwxr-x--- 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins > > ----- > root at 6f513d49f117:/var/cache/jenkins# chmod o+rx . > root at 6f513d49f117:/var/cache/jenkins# ls -la > total 12 > drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 . > drwxr-xr-x 17 root root 4096 Feb 21 07:12 .. > drwxr-xr-x 18 jenkins jenkins 4096 Feb 21 07:12 war > root at 6f513d49f117:/var/cache/jenkins# su - jenkins > jenkins at 6f513d49f117:~$ ls -lad /var /var/cache /var/cache/jenkins > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF > /var/cache/jenkins/war/META-INF/MANIFEST.MF > drwxr-xr-x 32 root root 4096 Feb 21 07:12 /var > drwxr-xr-x 17 root root 4096 Feb 21 07:12 /var/cache > drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins > drwxr-xr-x 18 jenkins jenkins 4096 Feb 21 07:12 > /var/cache/jenkins/war > drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 > /var/cache/jenkins/war/META-INF > -rw-r--r-- 1 jenkins jenkins 129535 Feb 15 18:56 > /var/cache/jenkins/war/META-INF/MANIFEST.MF > ----- > However, maybe it's not that simple: > ----- > > jenkins at 6f513d49f117:~$ exit > logout > root at 6f513d49f117:/var/cache/jenkins# exit > exit > 1000072457 at tlinux:~/work/fuego/release-test-2018-02-19/fuego- > release-test$ ./build_and_run.sh up > [FAIL] Starting Jenkins Continuous Integration Server: jenkins failed! > [ ok ] Starting network benchmark server. > root at 6f513d49f117:/# tail -n 20 /var/log/jenkins/jenkins.log > INFO: Winstone shutdown successfully > Feb 21, 2018 2:38:41 PM winstone.Logger logInternal > SEVERE: Container startup failed > java.io.FileNotFoundException: /var/cache/jenkins/war/META- > INF/MANIFEST.MF (Permission denied) > at java.io.FileOutputStream.open(Native Method) > at java.io.FileOutputStream.(FileOutputStream.java:221) > at java.io.FileOutputStream.(FileOutputStream.java:171) > at > winstone.HostConfiguration.getWebRoot(HostConfiguration.java:280) > at winstone.HostConfiguration.(HostConfiguration.java:83) > at winstone.HostGroup.initHost(HostGroup.java:66) > at winstone.HostGroup.(HostGroup.java:45) > at winstone.Launcher.(Launcher.java:143) > at winstone.Launcher.main(Launcher.java:352) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j > ava:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at Main._main(Main.java:264) > at Main.main(Main.java:112) > > root at 6f513d49f117:/# su - jenkins > jenkins at 6f513d49f117:~$ ls -lad /var /var/cache /var/cache/jenkins > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF > /var/cache/jenkins/war/META-INF/MANIFEST.MF > ls: cannot access /var/cache/jenkins/war: Permission denied > ls: cannot access /var/cache/jenkins/war/META-INF: Permission > denied > ls: cannot access /var/cache/jenkins/war/META-INF/MANIFEST.MF: > Permission denied > drwxr-xr-x 32 root root 4096 Feb 21 07:12 /var > drwxr-xr-x 17 root root 4096 Feb 21 07:12 /var/cache > drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins > > I'm running this on Ubuntu 14.04, with docker 17.05.0-ce > > ----- > OK - in summary: > > - I think I might be running the wrong branch of fuego-release-test > - I have weird permission problems in my docker container, for the > fuego user and group > that are preventing jenkins from starting > - the jenkins user id and group id don't match my local user's user id > and group id > > Any help would be appreciated. > -- Tim > > > > From guicc at profusion.mobi Thu Feb 22 01:59:53 2018 From: guicc at profusion.mobi (Guilherme Camargo) Date: Wed, 21 Feb 2018 22:59:53 -0300 Subject: [Fuego] release test issues In-Reply-To: References: Message-ID: On Wed, Feb 21, 2018 at 10:19 PM, wrote: > > > > -----Original Message----- > > From: Guilherme Camargo > > > > Hello, Tim, thanks for trying it out again and thanks for your time > > in debugging this issue and providing logs. > > > > This problem is happening because we're not using fuego-host-scripts > > in the derived fuego-release-test, what ends up resulting in the > > jenkins' user not being properly mapped to the host's user. > > > > That's my fault, I forgot that this would be required in the > > derivate image as well. > > > > I temporarily added that logic to build_and_run.sh (as a fixup commit) > > > > so that you're able to test it out, please see the patch below: > > > > diff --git a/build_and_run.sh b/build_and_run.sh > > index e448ddf..0134759 100755 > > --- a/build_and_run.sh > > +++ b/build_and_run.sh > > @@ -50,6 +50,25 @@ fi > > > > if [ "$1" = "up" ]; then > > if [ -v clean_start ]; then > > + # FIXME: We should provide a simpler way of mapping jenkins uid > with > > + # hosts uid, that does not require the user (that's extending > > + # fuego-base) to have this logic in his docker build. > > + # > > + # Jenkins' uid/gid should probably be given as a docker-run > variable > > + # (as http_proxy/https_proxy, and set properly through > fuego-base > > + # entrypoint.) > > + # > > + if [ "${UID}" == "0" ]; then > > + uid=$(id -u "${SUDO_USER}") > > + gid=$(id -g "${SUDO_USER}") > > + else > > + uid="${UID}" > > + gid=$(id -g "${USER}") > > + fi > > + > > + sed -i "s/HOST_UID/${uid}/" ./fuego-ro/conf/fuego.conf > > + sed -i "s/HOST_GID/${gid}/" ./fuego-ro/conf/fuego.conf > > + > > docker build -t "${fuego_rt_image}" . > > docker rm -f "${fuego_rt_container}" > > docker run -dit --name ${fuego_rt_container} \ > > diff --git a/fuego-ro/conf/fuego.conf b/fuego-ro/conf/fuego.conf > > index 0c95eae..96cdcc9 100644 > > --- a/fuego-ro/conf/fuego.conf > > +++ b/fuego-ro/conf/fuego.conf > > @@ -1,3 +1,3 @@ > > -docker_jenkins_uid=1000 > > -docker_jenkins_gid=987 > > +docker_jenkins_uid=HOST_UID > > +docker_jenkins_gid=HOST_GID > > > > As I mentioned in my FIXME message, its undesirable to require a derivate > > image to contain specific build steps (as the one that's replacing the > id into > > fuego.conf), > > so we might need to come up with a better approach to make this work. > > > > The patch has already been pushed to > > > > ? > > https://bitbucket.org/profusionmobi/fuego-release-test (master). > > Can you please re-sync and test again? > > The jenkins uid and gid in the container now match those of my host user, > but I'm getting the same start failure as before. > > Even when I explicitly change permissions in the path: > /var/cache/jenkins/war/META-INF/MANIFEST.MF, I still > get the same (Permission denied) message shown in the log (as below). > > I'm not sure what to try next. > -- Tim > > Thanks for helping, Tim. I'm taking a closer look to understand why this is happening. > > > > > Thank you > > > > -- > > Guilherme > > > > > > On Wed, Feb 21, 2018 at 11:48 AM, > > wrote: > > > > > > > -----Original Message----- > > > From: Guilherme Camargo > > > ?Tim, please sync the repo again (? > > > > > ? > > https://bitbucket.org/profusionmobi/fuego-release-test > > > > > ?). > > > I've force-pushed some changes. > > > > > > After that, you can just run `./build_and_run -c up`. > > > > My container doesn't start Jenkins. I'm not sure if this is > > a cascade error from some initial problem, but here is > > some information about my situation. > > > > I removed my repository, and did a new 'git clone' of the > > fuego-release-test repository. It doesn't appear to me to > > be updated recently: > > > > $ git branch -v > > * master 9d82c80 Initial commit > > $ git log > > commit 9d82c80d66a4de24ab97b38a16c8536849fea5bc > > Author: Guilherme Campos Camargo > > > > Date: Tue Feb 6 02:13:20 2018 -0200 > > > > Initial commit > > > > This repository has been created to store the resources needed > for > > the > > generation of a Docker image, based on fuego-base, that has all > > the > > tools needed for the automation of the tests that are required > for > > validating a new Fuego release with Fuego itself. > > ... > > > > I see that there are other branches with more recent commits (the > > 'ppa', and the 'fuego-base' branch. Should I be using one of > these? > > > > Here's the error I saw while trying build_and_run.sh: > > > > ----- > > Downloading/unpacking pexpect > > Downloading/unpacking ptyprocess>=0.5 (from pexpect) > > Downloading ptyprocess-0.5.2-py2.py3-none-any.whl > > Installing collected packages: pexpect, ptyprocess > > Successfully installed pexpect ptyprocess > > Cleaning up... > > ---> fd97e25fac02 > > Removing intermediate container 5a3a3638cb21 > > Step 4/7 : RUN echo "jenkins ALL = (root) NOPASSWD: > > /usr/bin/docker, /bin/sh" >> /etc/sudoers > > ---> Running in da0a1d824354 > > ---> fb6468918ab5 > > Removing intermediate container da0a1d824354 > > Step 5/7 : COPY fuego-ro /fuego-ro > > ---> bbe089e90e5f > > Removing intermediate container 6a4b20b92a4e > > Step 6/7 : COPY tests /fuego-core/engine/tests > > ---> 57c7374dd097 > > Removing intermediate container aa6b4c80255c > > Step 7/7 : COPY fuego-rt-entrypoint.sh / > > ---> 9ef063ab4a5b > > Removing intermediate container 32a90a4f3abb > > Successfully built 9ef063ab4a5b > > Successfully tagged fuego-rt:latest > > Error response from daemon: No such container: fuego-rt-container > > 6f513d49f117300672e1ba8782f0411448ffdf8e5258dd689797895cd79d > > 8068 > > Waiting for Jenkins on http://localhost:8090/fuego/... > > Creating job fuego-test.default.Functional.fuegotest > > fuego-rt-container > > [FAIL] Starting Jenkins Continuous Integration Server: jenkins > failed! > > [ ok ] Starting network benchmark server. > > root at 6f513d49f117:/# > > > > ----- > > > > And here is some investigation: > > ----- > > root at 6f513d49f117:/# tail -n 20 /var/log/jenkins/jenkins.log > > INFO: Winstone shutdown successfully > > Feb 21, 2018 2:13:22 PM winstone.Logger logInternal > > SEVERE: Container startup failed > > java.io.FileNotFoundException: /var/cache/jenkins/war/META- > > INF/MANIFEST.MF (Permission denied) > > at java.io.FileOutputStream.open(Native Method) > > at java.io.FileOutputStream.(FileOutputStream.java: > 221) > > at java.io.FileOutputStream.(FileOutputStream.java: > 171) > > at > > winstone.HostConfiguration.getWebRoot(HostConfiguration.java:280) > > at winstone.HostConfiguration.< > init>(HostConfiguration.java:83) > > at winstone.HostGroup.initHost(HostGroup.java:66) > > at winstone.HostGroup.(HostGroup.java:45) > > at winstone.Launcher.(Launcher.java:143) > > at winstone.Launcher.main(Launcher.java:352) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > > Method) > > at > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j > > ava:57) > > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > > sorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:606) > > at Main._main(Main.java:264) > > at Main.main(Main.java:112) > > > > root at 6f513d49f117:/# su - jenkins > > jenkins at 6f513d49f117:~$ cat /var/cache/jenkins/war/META- > > INF/MANIFEST.MF > > cat: /var/cache/jenkins/war/META-INF/MANIFEST.MF: Permission > > denied > > jenkins at 6f513d49f117:~$ ls -lad /var /var/cache /var/cache/jenkins > > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF > > /var/cache/jenkins/war/META-INF/MANIFEST.MF > > ls: cannot access /var/cache/jenkins/war: Permission denied > > ls: cannot access /var/cache/jenkins/war/META-INF: Permission > > denied > > ls: cannot access /var/cache/jenkins/war/META-INF/MANIFEST.MF: > > Permission denied > > drwxr-xr-x 32 root root 4096 Feb 21 07:12 /var > > drwxr-xr-x 17 root root 4096 Feb 21 07:12 /var/cache > > drwxr-x--- 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins > > jenkins at 6f513d49f117:~$ exit > > logout > > root at 6f513d49f117:/# ls -lad /var /var/cache /var/cache/jenkins > > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF > > /var/cache/jenkins/war/META-INF/MANIFEST.MF > > drwxr-xr-x 32 root root 4096 Feb 21 07:12 /var > > drwxr-xr-x 17 root root 4096 Feb 21 07:12 /var/cache > > drwxr-x--- 4 jenkins jenkins 4096 Feb 21 07:12 > /var/cache/jenkins > > drwxr-xr-x 18 jenkins jenkins 4096 Feb 21 07:12 > > /var/cache/jenkins/war > > drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 > > /var/cache/jenkins/war/META-INF > > -rw-r--r-- 1 jenkins jenkins 129535 Feb 15 18:56 > > /var/cache/jenkins/war/META-INF/MANIFEST.MF > > root at 6f513d49f117:/# su - jenkins > > jenkins at 6f513d49f117:~$ id > > uid=1000(jenkins) gid=987(jenkins) groups=987(jenkins) > > jenkins at 6f513d49f117:~$ > > ----- > > For reasons that escape me, it looks like these permissions are not > > allowing jenkins in the container to access the 'war' directory: > > drwxr-x--- 4 jenkins jenkins 4096 Feb 21 07:12 > /var/cache/jenkins > > > > ----- > > root at 6f513d49f117:/var/cache/jenkins# chmod o+rx . > > root at 6f513d49f117:/var/cache/jenkins# ls -la > > total 12 > > drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 . > > drwxr-xr-x 17 root root 4096 Feb 21 07:12 .. > > drwxr-xr-x 18 jenkins jenkins 4096 Feb 21 07:12 war > > root at 6f513d49f117:/var/cache/jenkins# su - jenkins > > jenkins at 6f513d49f117:~$ ls -lad /var /var/cache /var/cache/jenkins > > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF > > /var/cache/jenkins/war/META-INF/MANIFEST.MF > > drwxr-xr-x 32 root root 4096 Feb 21 07:12 /var > > drwxr-xr-x 17 root root 4096 Feb 21 07:12 /var/cache > > drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 > /var/cache/jenkins > > drwxr-xr-x 18 jenkins jenkins 4096 Feb 21 07:12 > > /var/cache/jenkins/war > > drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 > > /var/cache/jenkins/war/META-INF > > -rw-r--r-- 1 jenkins jenkins 129535 Feb 15 18:56 > > /var/cache/jenkins/war/META-INF/MANIFEST.MF > > ----- > > However, maybe it's not that simple: > > ----- > > > > jenkins at 6f513d49f117:~$ exit > > logout > > root at 6f513d49f117:/var/cache/jenkins# exit > > exit > > 1000072457 at tlinux:~/work/fuego/release-test-2018-02-19/fuego- > > release-test$ ./build_and_run.sh up > > [FAIL] Starting Jenkins Continuous Integration Server: jenkins > failed! > > [ ok ] Starting network benchmark server. > > root at 6f513d49f117:/# tail -n 20 /var/log/jenkins/jenkins.log > > INFO: Winstone shutdown successfully > > Feb 21, 2018 2:38:41 PM winstone.Logger logInternal > > SEVERE: Container startup failed > > java.io.FileNotFoundException: /var/cache/jenkins/war/META- > > INF/MANIFEST.MF (Permission denied) > > at java.io.FileOutputStream.open(Native Method) > > at java.io.FileOutputStream.(FileOutputStream.java: > 221) > > at java.io.FileOutputStream.(FileOutputStream.java: > 171) > > at > > winstone.HostConfiguration.getWebRoot(HostConfiguration.java:280) > > at winstone.HostConfiguration.< > init>(HostConfiguration.java:83) > > at winstone.HostGroup.initHost(HostGroup.java:66) > > at winstone.HostGroup.(HostGroup.java:45) > > at winstone.Launcher.(Launcher.java:143) > > at winstone.Launcher.main(Launcher.java:352) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > > Method) > > at > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j > > ava:57) > > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > > sorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:606) > > at Main._main(Main.java:264) > > at Main.main(Main.java:112) > > > > root at 6f513d49f117:/# su - jenkins > > jenkins at 6f513d49f117:~$ ls -lad /var /var/cache /var/cache/jenkins > > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF > > /var/cache/jenkins/war/META-INF/MANIFEST.MF > > ls: cannot access /var/cache/jenkins/war: Permission denied > > ls: cannot access /var/cache/jenkins/war/META-INF: Permission > > denied > > ls: cannot access /var/cache/jenkins/war/META-INF/MANIFEST.MF: > > Permission denied > > drwxr-xr-x 32 root root 4096 Feb 21 07:12 /var > > drwxr-xr-x 17 root root 4096 Feb 21 07:12 /var/cache > > drwxr-xr-x 4 jenkins jenkins 4096 Feb 21 07:12 /var/cache/jenkins > > > > I'm running this on Ubuntu 14.04, with docker 17.05.0-ce > > > > ----- > > OK - in summary: > > > > - I think I might be running the wrong branch of fuego-release-test > > - I have weird permission problems in my docker container, for the > > fuego user and group > > that are preventing jenkins from starting > > - the jenkins user id and group id don't match my local user's > user id > > and group id > > > > Any help would be appreciated. > > -- Tim > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyohei.oki at jp.fujitsu.com Thu Feb 22 05:56:28 2018 From: kyohei.oki at jp.fujitsu.com (Oki, Kyohhei) Date: Thu, 22 Feb 2018 05:56:28 +0000 Subject: [Fuego] Report of AGL-AMM2018 Message-ID: Hello, all I had a presentation at AGL-AMM2018 in Japan. I have been advertising Fuego's detailed usage My slide is here. https://schd.ws/hosted_files/aglammjapan2018/14/Introduction%20of%20AGL%27s%20approach%20to%20Fuego.pdf Thanks Oki From tuyen.hoangvan at toshiba-tsdv.com Thu Feb 22 10:50:26 2018 From: tuyen.hoangvan at toshiba-tsdv.com (Hoang Van Tuyen) Date: Thu, 22 Feb 2018 17:50:26 +0700 Subject: [Fuego] [PATCH 1/2] ftc: gen_report: should check run_list is not null, earlier Message-ID: <96aa3fc7-5ae2-3eae-8663-1774d5beee3f@toshiba-tsdv.com> In the future, We will support several other report formats (like html, pdf, ...). We should check the run_list is null or not in do_gen_report function, not in the gen_text_report function. Signed-off-by: Hoang Van Tuyen --- engine/scripts/ftc | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/engine/scripts/ftc b/engine/scripts/ftc index bde3694..44e4da7 100755 --- a/engine/scripts/ftc +++ b/engine/scripts/ftc @@ -1857,11 +1857,6 @@ def gen_text_report(run_list, run_map, header_fields, fields): report += " **** %s ****\n" % title report_date = time.strftime("%Y-%m-%d_%H:%M:%S") - if not run_list: - report += " *** No runs to report, based on requested/filtered runs ***\n" - report += ddash_line - return report - for field in header_fields: if field=="report_date": val_str = time.strftime("%Y-%m-%d_%H:%M:%S") @@ -1969,6 +1964,9 @@ def do_gen_report(conf, options): else: run_list = run_map.keys() + if not run_list: + error_out ('No runs to report, based on requested/filtered runs') + run_list.sort() fmt="txt" -- 2.1.4 -- ================================================================ Hoang Van Tuyen (Mr.) TOSHIBA SOFTWARE DEVELOPMENT (VIETNAM) CO., LTD. 16th Floor, VIT Building, 519 Kim Ma Str., Ba Dinh Dist., Hanoi, Vietnam Tel: 84-4-22208801 (Company) - Ext.251 Fax: 84-4-22208802 (Company) Email: tuyen.hoangvan at toshiba-tsdv.com ================================================================ -------------- next part -------------- From a07e132c66cdf4050860479a9551d53afc377fa7 Mon Sep 17 00:00:00 2001 From: Hoang Van Tuyen Date: Mon, 12 Feb 2018 11:36:53 +0700 Subject: [PATCH 1/2] ftc: gen_report: should check run_list is not null earlier In the future, We will support several other report formats (like html, pdf, ...). We should check the run_list is null or not in do_gen_report function, not in the gen_text_report function. Signed-off-by: Hoang Van Tuyen --- engine/scripts/ftc | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/engine/scripts/ftc b/engine/scripts/ftc index bde3694..44e4da7 100755 --- a/engine/scripts/ftc +++ b/engine/scripts/ftc @@ -1857,11 +1857,6 @@ def gen_text_report(run_list, run_map, header_fields, fields): report += " **** %s ****\n" % title report_date = time.strftime("%Y-%m-%d_%H:%M:%S") - if not run_list: - report += " *** No runs to report, based on requested/filtered runs ***\n" - report += ddash_line - return report - for field in header_fields: if field=="report_date": val_str = time.strftime("%Y-%m-%d_%H:%M:%S") @@ -1969,6 +1964,9 @@ def do_gen_report(conf, options): else: run_list = run_map.keys() + if not run_list: + error_out ('No runs to report, based on requested/filtered runs') + run_list.sort() fmt="txt" -- 2.1.4 -------------- next part -------------- -- This mail was scanned by BitDefender For more information please visit http://www.bitdefender.com From tuyen.hoangvan at toshiba-tsdv.com Thu Feb 22 10:51:06 2018 From: tuyen.hoangvan at toshiba-tsdv.com (Hoang Van Tuyen) Date: Thu, 22 Feb 2018 17:51:06 +0700 Subject: [Fuego] [PATCH 2/2] ftc: gen_report: Add new functions for getting data to, generate the report Message-ID: <48ee9177-bd98-d609-5328-b21a6f110e1e@toshiba-tsdv.com> Hello Tim, I am working on gen-report feature (support several other format like html, pdf, ...). The attached patch defines two new functions used for generating data for the report. Could you please check it? =========================================================================== For reusability, the two functions have been defined with purpose like below: gen_header_for_report: Get value for fields in the header_fields (test, board, report_date, ...). gen_data_for_report: Get value for fields in the fields variable (test_name, spec, timestamp, ...). This commit also modifies gen_text_report function to compatible with defining the two new funtions. Also, correct some grammar mistakes. Signed-off-by: Hoang Van Tuyen --- engine/scripts/ftc | 78 ++++++++++++++++++++++++++++++++---------------------- 1 file changed, 47 insertions(+), 31 deletions(-) diff --git a/engine/scripts/ftc b/engine/scripts/ftc index 44e4da7..a2f5a78 100755 --- a/engine/scripts/ftc +++ b/engine/scripts/ftc @@ -71,7 +71,7 @@ def pvar(name): quiet = 0 verbose = 0 -use_statusouput = 1 +use_statusoutput = 1 server = jenkins.Jenkins('http://localhost:8080/fuego') # keep configuration file in /fuego-ro/conf area @@ -1745,7 +1745,7 @@ class where_class: found = False try: run_value = run.__dict__[self.field_name] - found = true + found = True except: pass @@ -1849,13 +1849,8 @@ def do_list_runs(conf, options): sys.exit(0) -def gen_text_report(run_list, run_map, header_fields, fields): - # generate header - ddash_line="="*70 + "\n" - report = ddash_line - title = "Fuego Test Report" - report += " **** %s ****\n" % title - report_date = time.strftime("%Y-%m-%d_%H:%M:%S") +def gen_header_for_report(run_list, run_map, header_fields, fields): + header_report = "" for field in header_fields: if field=="report_date": @@ -1875,22 +1870,14 @@ def gen_text_report(run_list, run_map, header_fields, fields): else: for value in value_list[1:]: val_str += ", "+value + header_report += " %-20s: %s\n" % (field, val_str) - line = " %-20s: %s\n" % (field, val_str) - report += line - report += ddash_line + return header_report +def gen_data_for_report(run_list, run_map, header_fields, fields): + data_to_report = [] # generate list - # start with a header line - dash_line = "-"*(21*len(fields)+2) + "\n" - report += dash_line - line = " " - for field in fields: - line += "%-20s " % field - report += line + "\n" - report += dash_line - # now loop over the runs, printing the requested report fields # if tguid is a field, we'll print a line for each tguid # otherwise, it's a line per test @@ -1921,10 +1908,6 @@ def gen_text_report(run_list, run_map, header_fields, fields): continue # format each column per row (ie per line) - line = " " - start_sep = " " - mid_sep = " " - end_sep = "" pos = 0 for field in fields: if field=="tguid": @@ -1937,15 +1920,48 @@ def gen_text_report(run_list, run_map, header_fields, fields): tguid_name = "" value = run.get_field(field, tguid_name) if pos==0: - line += "%-20s%s" % (value, start_sep) + data_to_report.append((value,field)) else: - line += "%-20s" % (value) if pos Date: Thu, 22 Feb 2018 17:18:40 +0700 Subject: [PATCH 2/2] ftc: gen_report: Add new functions for getting data to generate the report For reusability, the two functions have been defined with purpose like below: gen_header_for_report: Get value for fields in the header_fields (test, board, report_date, ...). gen_data_for_report: Get value for fields in the fields variable (test_name, spec, timestamp, ...). This commit also modifies gen_text_report function to compatible with defining the two new funtions. Also, correct some grammar mistakes. Signed-off-by: Hoang Van Tuyen --- engine/scripts/ftc | 78 ++++++++++++++++++++++++++++++++---------------------- 1 file changed, 47 insertions(+), 31 deletions(-) diff --git a/engine/scripts/ftc b/engine/scripts/ftc index 44e4da7..a2f5a78 100755 --- a/engine/scripts/ftc +++ b/engine/scripts/ftc @@ -71,7 +71,7 @@ def pvar(name): quiet = 0 verbose = 0 -use_statusouput = 1 +use_statusoutput = 1 server = jenkins.Jenkins('http://localhost:8080/fuego') # keep configuration file in /fuego-ro/conf area @@ -1745,7 +1745,7 @@ class where_class: found = False try: run_value = run.__dict__[self.field_name] - found = true + found = True except: pass @@ -1849,13 +1849,8 @@ def do_list_runs(conf, options): sys.exit(0) -def gen_text_report(run_list, run_map, header_fields, fields): - # generate header - ddash_line="="*70 + "\n" - report = ddash_line - title = "Fuego Test Report" - report += " **** %s ****\n" % title - report_date = time.strftime("%Y-%m-%d_%H:%M:%S") +def gen_header_for_report(run_list, run_map, header_fields, fields): + header_report = "" for field in header_fields: if field=="report_date": @@ -1875,22 +1870,14 @@ def gen_text_report(run_list, run_map, header_fields, fields): else: for value in value_list[1:]: val_str += ", "+value + header_report += " %-20s: %s\n" % (field, val_str) - line = " %-20s: %s\n" % (field, val_str) - report += line - report += ddash_line + return header_report +def gen_data_for_report(run_list, run_map, header_fields, fields): + data_to_report = [] # generate list - # start with a header line - dash_line = "-"*(21*len(fields)+2) + "\n" - report += dash_line - line = " " - for field in fields: - line += "%-20s " % field - report += line + "\n" - report += dash_line - # now loop over the runs, printing the requested report fields # if tguid is a field, we'll print a line for each tguid # otherwise, it's a line per test @@ -1921,10 +1908,6 @@ def gen_text_report(run_list, run_map, header_fields, fields): continue # format each column per row (ie per line) - line = " " - start_sep = " " - mid_sep = " " - end_sep = "" pos = 0 for field in fields: if field=="tguid": @@ -1937,15 +1920,48 @@ def gen_text_report(run_list, run_map, header_fields, fields): tguid_name = "" value = run.get_field(field, tguid_name) if pos==0: - line += "%-20s%s" % (value, start_sep) + data_to_report.append((value,field)) else: - line += "%-20s" % (value) if pos References: <48ee9177-bd98-d609-5328-b21a6f110e1e@toshiba-tsdv.com> Message-ID: On Thu, Feb 22, 2018 at 7:51 AM, Hoang Van Tuyen wrote: > Hello Tim, > > I am working on gen-report feature (support several other format like html, > pdf, ...). do you plan to generate ReStructuredText (RST) and from there use converters, or really generate the same result into multiple formats? using RST allows not only to generate multiple formats, but also to customize output via templates, which is a nice addition. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN, GTalk, FaceTime: barbieri at gmail.com Skype: gsbarbieri Mobile: +55 (16) 99354-9890 From dhinakar.k at samsung.com Thu Feb 22 15:45:57 2018 From: dhinakar.k at samsung.com (Dhinakar Kalyanasundaram) Date: Thu, 22 Feb 2018 21:15:57 +0530 Subject: [Fuego] RFC - new board-control interface In-Reply-To: References: <20180216043812epcms5p6dc01c0ebca9f67aa3d3553e61d923a50@epcms5p6> Message-ID: <20180222154557epcms5p215e4b74d79ddbaefb7dbcf6456dacad3@epcms5p2> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 13402 bytes Desc: not available URL: From Tim.Bird at sony.com Thu Feb 22 20:19:23 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 22 Feb 2018 20:19:23 +0000 Subject: [Fuego] release test issues In-Reply-To: References: Message-ID: > -----Original Message----- > From: Guilherme Camargo > On Wed, Feb 21, 2018 at 10:19 PM, > wrote: > > > > > > -----Original Message----- > > From: Guilherme Camargo > > > > > Hello, Tim, thanks for trying it out again and thanks for your time > > in debugging this issue and providing logs. > > > > This problem is happening because we're not using fuego-host- > scripts > > in the derived fuego-release-test, what ends up resulting in the > > jenkins' user not being properly mapped to the host's user. > > > > That's my fault, I forgot that this would be required in the > > derivate image as well. > > > > I temporarily added that logic to build_and_run.sh (as a fixup > commit) > > > > so that you're able to test it out, please see the patch below: > > > > diff --git a/build_and_run.sh b/build_and_run.sh > > index e448ddf..0134759 100755 > > --- a/build_and_run.sh > > +++ b/build_and_run.sh > > @@ -50,6 +50,25 @@ fi > > > > if [ "$1" = "up" ]; then > > if [ -v clean_start ]; then > > + # FIXME: We should provide a simpler way of mapping jenkins > uid with > > + # hosts uid, that does not require the user (that's extending > > + # fuego-base) to have this logic in his docker build. > > + # > > + # Jenkins' uid/gid should probably be given as a docker-run > variable > > + # (as http_proxy/https_proxy, and set properly through > fuego-base > > + # entrypoint.) > > + # > > + if [ "${UID}" == "0" ]; then > > + uid=$(id -u "${SUDO_USER}") > > + gid=$(id -g "${SUDO_USER}") > > + else > > + uid="${UID}" > > + gid=$(id -g "${USER}") > > + fi > > + > > + sed -i "s/HOST_UID/${uid}/" ./fuego-ro/conf/fuego.conf > > + sed -i "s/HOST_GID/${gid}/" ./fuego-ro/conf/fuego.conf > > + > > docker build -t "${fuego_rt_image}" . > > docker rm -f "${fuego_rt_container}" > > docker run -dit --name ${fuego_rt_container} \ > > diff --git a/fuego-ro/conf/fuego.conf b/fuego-ro/conf/fuego.conf > > index 0c95eae..96cdcc9 100644 > > --- a/fuego-ro/conf/fuego.conf > > +++ b/fuego-ro/conf/fuego.conf > > @@ -1,3 +1,3 @@ > > -docker_jenkins_uid=1000 > > -docker_jenkins_gid=987 > > +docker_jenkins_uid=HOST_UID > > +docker_jenkins_gid=HOST_GID > > > > As I mentioned in my FIXME message, its undesirable to require a > derivate > > image to contain specific build steps (as the one that's replacing the > id into > > fuego.conf), > > so we might need to come up with a better approach to make this > work. > > > > The patch has already been pushed to > > > > > > > https://bitbucket.org/profusionmobi/fuego-release-test > (master). > > Can you please re-sync and test again? > > > The jenkins uid and gid in the container now match those of my host > user, > but I'm getting the same start failure as before. > > Even when I explicitly change permissions in the path: > /var/cache/jenkins/war/META-INF/MANIFEST.MF, I still > get the same (Permission denied) message shown in the log (as > below). > > I'm not sure what to try next. > -- Tim > > > > > Thanks for helping, Tim. > > I'm taking a closer look to understand why this is happening. I'm not sure what is the root cause of this, and fear it might be a docker bug. I have some notes I made when I was first integrating ProFusion's changes to Fuego to start from a base docker container (on Feb 1). In my notes I describe the same permission problem with /var/cache/jenkins/war/META-INF/MANIFEST.MF. In my notes it says: "changed permissions, and it worked" then later "changed permissions back, and it still works (docker fs bug??)" But I may have done something else, unrelated to the permissions, which I didn't take note of at the time. However, I'm pretty sure the current issue has the same root cause as what I was seeing before. Hopefully that's helpful information. -- Tim From guicc at profusion.mobi Thu Feb 22 21:02:49 2018 From: guicc at profusion.mobi (Guilherme Camargo) Date: Thu, 22 Feb 2018 18:02:49 -0300 Subject: [Fuego] release test issues In-Reply-To: References: Message-ID: I made a few more modifications in the way that the uid/gid are set on Fuego ( https://bitbucket.org/profusionmobi/fuego/commits/fe24e93ce191c461f4efa55aaa345a319b1b8fd6 ) and also made the needed changes on fuego-release-test to match those. Hopefully they're more robust now. I plan to send all the new changes by e-mail to the list, but I just wanted to check if you're able to run it locally, so that you can get a feeling about this, before we move on. Can you please try again with: ``` git clone https://bitbucket.org/profusionmobi/fuego-release-test cd fuego-release-test ./build_and_run -c up Then try to access fuego in localhost:8080/fuego/ ``` And check if things go well this time? Can you please also provide info about the distribution you're using along with the docker version? I'll try to find out if there's any similar issue reported by other users. Thanks for your help, Tim. On Thu, Feb 22, 2018 at 5:19 PM, wrote: > > > > -----Original Message----- > > From: Guilherme Camargo > > On Wed, Feb 21, 2018 at 10:19 PM, > > wrote: > > > > > > > > > > > -----Original Message----- > > > From: Guilherme Camargo > > > > > > > > Hello, Tim, thanks for trying it out again and thanks for your > time > > > in debugging this issue and providing logs. > > > > > > This problem is happening because we're not using fuego-host- > > scripts > > > in the derived fuego-release-test, what ends up resulting in the > > > jenkins' user not being properly mapped to the host's user. > > > > > > That's my fault, I forgot that this would be required in the > > > derivate image as well. > > > > > > I temporarily added that logic to build_and_run.sh (as a fixup > > commit) > > > > > > so that you're able to test it out, please see the patch below: > > > > > > diff --git a/build_and_run.sh b/build_and_run.sh > > > index e448ddf..0134759 100755 > > > --- a/build_and_run.sh > > > +++ b/build_and_run.sh > > > @@ -50,6 +50,25 @@ fi > > > > > > if [ "$1" = "up" ]; then > > > if [ -v clean_start ]; then > > > + # FIXME: We should provide a simpler way of mapping > jenkins > > uid with > > > + # hosts uid, that does not require the user (that's > extending > > > + # fuego-base) to have this logic in his docker build. > > > + # > > > + # Jenkins' uid/gid should probably be given as a > docker-run > > variable > > > + # (as http_proxy/https_proxy, and set properly through > > fuego-base > > > + # entrypoint.) > > > + # > > > + if [ "${UID}" == "0" ]; then > > > + uid=$(id -u "${SUDO_USER}") > > > + gid=$(id -g "${SUDO_USER}") > > > + else > > > + uid="${UID}" > > > + gid=$(id -g "${USER}") > > > + fi > > > + > > > + sed -i "s/HOST_UID/${uid}/" ./fuego-ro/conf/fuego.conf > > > + sed -i "s/HOST_GID/${gid}/" ./fuego-ro/conf/fuego.conf > > > + > > > docker build -t "${fuego_rt_image}" . > > > docker rm -f "${fuego_rt_container}" > > > docker run -dit --name ${fuego_rt_container} \ > > > diff --git a/fuego-ro/conf/fuego.conf b/fuego-ro/conf/fuego.conf > > > index 0c95eae..96cdcc9 100644 > > > --- a/fuego-ro/conf/fuego.conf > > > +++ b/fuego-ro/conf/fuego.conf > > > @@ -1,3 +1,3 @@ > > > -docker_jenkins_uid=1000 > > > -docker_jenkins_gid=987 > > > +docker_jenkins_uid=HOST_UID > > > +docker_jenkins_gid=HOST_GID > > > > > > As I mentioned in my FIXME message, its undesirable to require a > > derivate > > > image to contain specific build steps (as the one that's > replacing the > > id into > > > fuego.conf), > > > so we might need to come up with a better approach to make this > > work. > > > > > > The patch has already been pushed to > > > > > > > > > > > https://bitbucket.org/profusionmobi/fuego-release-test > > (master). > > > Can you please re-sync and test again? > > > > > > The jenkins uid and gid in the container now match those of my host > > user, > > but I'm getting the same start failure as before. > > > > Even when I explicitly change permissions in the path: > > /var/cache/jenkins/war/META-INF/MANIFEST.MF, I still > > get the same (Permission denied) message shown in the log (as > > below). > > > > I'm not sure what to try next. > > -- Tim > > > > > > > > > > Thanks for helping, Tim. > > > > I'm taking a closer look to understand why this is happening. > > I'm not sure what is the root cause of this, and fear it might be a docker > bug. > I have some notes I made when I was first integrating ProFusion's > changes to Fuego to start from a base docker container (on Feb 1). > > In my notes I describe the same permission problem with > /var/cache/jenkins/war/META-INF/MANIFEST.MF. > > In my notes it says: > "changed permissions, and it worked" > then later > "changed permissions back, and it still works (docker fs bug??)" > > But I may have done something else, unrelated to the permissions, > which I didn't take note of at the time. > However, I'm pretty sure the current issue has the same root cause > as what I was seeing before. > > Hopefully that's helpful information. > -- Tim > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Bird at sony.com Thu Feb 22 21:05:29 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 22 Feb 2018 21:05:29 +0000 Subject: [Fuego] release test issues In-Reply-To: References: Message-ID: Will do right now. -- Tim > -----Original Message----- > From: fuego-bounces at lists.linuxfoundation.org [mailto:fuego- > bounces at lists.linuxfoundation.org] On Behalf Of Guilherme Camargo > Sent: Thursday, February 22, 2018 1:03 PM > To: Bird, Timothy > Cc: fuego at lists.linuxfoundation.org > Subject: Re: [Fuego] release test issues > > I made a few more modifications in the way that the uid/gid are set on Fuego > (https://bitbucket.org/profusionmobi/fuego/commits/fe24e93ce191c461f4e > fa55aaa345a319b1b8fd6) > and also made the needed changes on fuego-release-test to match those. > Hopefully they're more robust now. I plan to send all the new changes by e- > mail > to the list, but I just wanted to check if you're able to run it locally, so > that you can get a feeling about this, before we move on. > > > Can you please try again with: > > > ``` > git clone https://bitbucket.org/profusionmobi/fuego-release-test > cd fuego-release-test > ./build_and_run -c up > > > Then try to access fuego in localhost:8080/fuego/ > > > ``` > > > And check if things go well this time? > > > Can you please also provide info about the distribution you're using along > with > the docker version? I'll try to find out if there's any similar issue reported > by other users. > > > Thanks for your help, Tim. > > > > On Thu, Feb 22, 2018 at 5:19 PM, > wrote: > > > > > > -----Original Message----- > > From: Guilherme Camargo > > On Wed, Feb 21, 2018 at 10:19 PM, > > > > > wrote: > > > > > > > > > > > -----Original Message----- > > > From: Guilherme Camargo > > > > > > > > > Hello, Tim, thanks for trying it out again and thanks for your > time > > > in debugging this issue and providing logs. > > > > > > This problem is happening because we're not using fuego- > host- > > scripts > > > in the derived fuego-release-test, what ends up resulting in > the > > > jenkins' user not being properly mapped to the host's user. > > > > > > That's my fault, I forgot that this would be required in the > > > derivate image as well. > > > > > > I temporarily added that logic to build_and_run.sh (as a fixup > > commit) > > > > > > so that you're able to test it out, please see the patch below: > > > > > > diff --git a/build_and_run.sh b/build_and_run.sh > > > index e448ddf..0134759 100755 > > > --- a/build_and_run.sh > > > +++ b/build_and_run.sh > > > @@ -50,6 +50,25 @@ fi > > > > > > if [ "$1" = "up" ]; then > > > if [ -v clean_start ]; then > > > + # FIXME: We should provide a simpler way of mapping > jenkins > > uid with > > > + # hosts uid, that does not require the user (that's > extending > > > + # fuego-base) to have this logic in his docker build. > > > + # > > > + # Jenkins' uid/gid should probably be given as a docker- > run > > variable > > > + # (as http_proxy/https_proxy, and set properly through > > fuego-base > > > + # entrypoint.) > > > + # > > > + if [ "${UID}" == "0" ]; then > > > + uid=$(id -u "${SUDO_USER}") > > > + gid=$(id -g "${SUDO_USER}") > > > + else > > > + uid="${UID}" > > > + gid=$(id -g "${USER}") > > > + fi > > > + > > > + sed -i "s/HOST_UID/${uid}/" ./fuego-ro/conf/fuego.conf > > > + sed -i "s/HOST_GID/${gid}/" ./fuego-ro/conf/fuego.conf > > > + > > > docker build -t "${fuego_rt_image}" . > > > docker rm -f "${fuego_rt_container}" > > > docker run -dit --name ${fuego_rt_container} \ > > > diff --git a/fuego-ro/conf/fuego.conf b/fuego- > ro/conf/fuego.conf > > > index 0c95eae..96cdcc9 100644 > > > --- a/fuego-ro/conf/fuego.conf > > > +++ b/fuego-ro/conf/fuego.conf > > > @@ -1,3 +1,3 @@ > > > -docker_jenkins_uid=1000 > > > -docker_jenkins_gid=987 > > > +docker_jenkins_uid=HOST_UID > > > +docker_jenkins_gid=HOST_GID > > > > > > As I mentioned in my FIXME message, its undesirable to > require a > > derivate > > > image to contain specific build steps (as the one that's > replacing the > > id into > > > fuego.conf), > > > so we might need to come up with a better approach to make > this > > work. > > > > > > The patch has already been pushed to > > > > > > > > > > > > > https://bitbucket.org/profusionmobi/fuego-release-test > > > > (master). > > > Can you please re-sync and test again? > > > > > > The jenkins uid and gid in the container now match those of my > host > > user, > > but I'm getting the same start failure as before. > > > > Even when I explicitly change permissions in the path: > > /var/cache/jenkins/war/META-INF/MANIFEST.MF, I still > > get the same (Permission denied) message shown in the log (as > > below). > > > > I'm not sure what to try next. > > -- Tim > > > > > > > > > > Thanks for helping, Tim. > > > > I'm taking a closer look to understand why this is happening. > > > I'm not sure what is the root cause of this, and fear it might be a > docker bug. > I have some notes I made when I was first integrating ProFusion's > changes to Fuego to start from a base docker container (on Feb 1). > > In my notes I describe the same permission problem with > /var/cache/jenkins/war/META-INF/MANIFEST.MF. > > In my notes it says: > "changed permissions, and it worked" > then later > "changed permissions back, and it still works (docker fs bug??)" > > But I may have done something else, unrelated to the permissions, > which I didn't take note of at the time. > However, I'm pretty sure the current issue has the same root cause > as what I was seeing before. > > Hopefully that's helpful information. > -- Tim > > From guicc at profusion.mobi Thu Feb 22 21:06:12 2018 From: guicc at profusion.mobi (Guilherme Camargo) Date: Thu, 22 Feb 2018 18:06:12 -0300 Subject: [Fuego] release test issues In-Reply-To: References: Message-ID: ?Great, thanks? On Thu, Feb 22, 2018 at 6:05 PM, wrote: > Will do right now. > -- Tim > > > > -----Original Message----- > > From: fuego-bounces at lists.linuxfoundation.org [mailto:fuego- > > bounces at lists.linuxfoundation.org] On Behalf Of Guilherme Camargo > > Sent: Thursday, February 22, 2018 1:03 PM > > To: Bird, Timothy > > Cc: fuego at lists.linuxfoundation.org > > Subject: Re: [Fuego] release test issues > > > > I made a few more modifications in the way that the uid/gid are set on > Fuego > > (https://bitbucket.org/profusionmobi/fuego/commits/fe24e93ce191c461f4e > > fa55aaa345a319b1b8fd6) > > and also made the needed changes on fuego-release-test to match those. > > Hopefully they're more robust now. I plan to send all the new changes by > e- > > mail > > to the list, but I just wanted to check if you're able to run it > locally, so > > that you can get a feeling about this, before we move on. > > > > > > Can you please try again with: > > > > > > ``` > > git clone https://bitbucket.org/profusionmobi/fuego-release-test > > cd fuego-release-test > > ./build_and_run -c up > > > > > > Then try to access fuego in localhost:8080/fuego/ > > > > > > ``` > > > > > > And check if things go well this time? > > > > > > Can you please also provide info about the distribution you're using > along > > with > > the docker version? I'll try to find out if there's any similar issue > reported > > by other users. > > > > > > Thanks for your help, Tim. > > > > > > > > On Thu, Feb 22, 2018 at 5:19 PM, > > wrote: > > > > > > > > > > > -----Original Message----- > > > From: Guilherme Camargo > > > On Wed, Feb 21, 2018 at 10:19 PM, > > > > > > > > wrote: > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Guilherme Camargo > > > > > > > > > > > > > Hello, Tim, thanks for trying it out again and thanks > for your > > time > > > > in debugging this issue and providing logs. > > > > > > > > This problem is happening because we're not using fuego- > > host- > > > scripts > > > > in the derived fuego-release-test, what ends up > resulting in > > the > > > > jenkins' user not being properly mapped to the host's > user. > > > > > > > > That's my fault, I forgot that this would be required in > the > > > > derivate image as well. > > > > > > > > I temporarily added that logic to build_and_run.sh (as a > fixup > > > commit) > > > > > > > > so that you're able to test it out, please see the patch > below: > > > > > > > > diff --git a/build_and_run.sh b/build_and_run.sh > > > > index e448ddf..0134759 100755 > > > > --- a/build_and_run.sh > > > > +++ b/build_and_run.sh > > > > @@ -50,6 +50,25 @@ fi > > > > > > > > if [ "$1" = "up" ]; then > > > > if [ -v clean_start ]; then > > > > + # FIXME: We should provide a simpler way of > mapping > > jenkins > > > uid with > > > > + # hosts uid, that does not require the user > (that's > > extending > > > > + # fuego-base) to have this logic in his docker > build. > > > > + # > > > > + # Jenkins' uid/gid should probably be given as > a docker- > > run > > > variable > > > > + # (as http_proxy/https_proxy, and set properly > through > > > fuego-base > > > > + # entrypoint.) > > > > + # > > > > + if [ "${UID}" == "0" ]; then > > > > + uid=$(id -u "${SUDO_USER}") > > > > + gid=$(id -g "${SUDO_USER}") > > > > + else > > > > + uid="${UID}" > > > > + gid=$(id -g "${USER}") > > > > + fi > > > > + > > > > + sed -i "s/HOST_UID/${uid}/" > ./fuego-ro/conf/fuego.conf > > > > + sed -i "s/HOST_GID/${gid}/" > ./fuego-ro/conf/fuego.conf > > > > + > > > > docker build -t "${fuego_rt_image}" . > > > > docker rm -f "${fuego_rt_container}" > > > > docker run -dit --name ${fuego_rt_container} \ > > > > diff --git a/fuego-ro/conf/fuego.conf b/fuego- > > ro/conf/fuego.conf > > > > index 0c95eae..96cdcc9 100644 > > > > --- a/fuego-ro/conf/fuego.conf > > > > +++ b/fuego-ro/conf/fuego.conf > > > > @@ -1,3 +1,3 @@ > > > > -docker_jenkins_uid=1000 > > > > -docker_jenkins_gid=987 > > > > +docker_jenkins_uid=HOST_UID > > > > +docker_jenkins_gid=HOST_GID > > > > > > > > As I mentioned in my FIXME message, its undesirable to > > require a > > > derivate > > > > image to contain specific build steps (as the one that's > > replacing the > > > id into > > > > fuego.conf), > > > > so we might need to come up with a better approach to > make > > this > > > work. > > > > > > > > The patch has already been pushed to > > > > > > > > > > > > > > > > > > > https://bitbucket.org/profusionmobi/fuego-release-test > > > > > > > (master). > > > > Can you please re-sync and test again? > > > > > > > > > The jenkins uid and gid in the container now match those > of my > > host > > > user, > > > but I'm getting the same start failure as before. > > > > > > Even when I explicitly change permissions in the path: > > > /var/cache/jenkins/war/META-INF/MANIFEST.MF, I still > > > get the same (Permission denied) message shown in the log > (as > > > below). > > > > > > I'm not sure what to try next. > > > -- Tim > > > > > > > > > > > > > > > Thanks for helping, Tim. > > > > > > I'm taking a closer look to understand why this is happening. > > > > > > I'm not sure what is the root cause of this, and fear it might be a > > docker bug. > > I have some notes I made when I was first integrating ProFusion's > > changes to Fuego to start from a base docker container (on Feb 1). > > > > In my notes I describe the same permission problem with > > /var/cache/jenkins/war/META-INF/MANIFEST.MF. > > > > In my notes it says: > > "changed permissions, and it worked" > > then later > > "changed permissions back, and it still works (docker fs bug??)" > > > > But I may have done something else, unrelated to the permissions, > > which I didn't take note of at the time. > > However, I'm pretty sure the current issue has the same root cause > > as what I was seeing before. > > > > Hopefully that's helpful information. > > -- Tim > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Bird at sony.com Thu Feb 22 21:27:04 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 22 Feb 2018 21:27:04 +0000 Subject: [Fuego] release test issues In-Reply-To: References: Message-ID: > -----Original Message----- > From: Guilherme Camargo > > I made a few more modifications in the way that the uid/gid are set on Fuego > (https://bitbucket.org/profusionmobi/fuego/commits/fe24e93ce191c461f4e > fa55aaa345a319b1b8fd6) > and also made the needed changes on fuego-release-test to match those. > Hopefully they're more robust now. I plan to send all the new changes by e- > mail > to the list, but I just wanted to check if you're able to run it locally, so > that you can get a feeling about this, before we move on. > > > Can you please try again with: > > > ``` > git clone https://bitbucket.org/profusionmobi/fuego-release-test > cd fuego-release-test > ./build_and_run -c up Still no joy. Step 7/7 : COPY fuego-rt-entrypoint.sh / ---> 4e39b71fb0d5 Removing intermediate container a5e9b9e4244d Successfully built 4e39b71fb0d5 Successfully tagged fuego-rt:latest fuego-rt-container a8750b71dc87bc1ad61ed26954c9484e79376d019fbd563abf86e1fcec86c70b Waiting for Jenkins... Creating job fuego-test.default.Functional.fuegotest fuego-rt-container [FAIL] Starting Jenkins Continuous Integration Server: jenkins failed! [ ok ] Starting network benchmark server. root at a8750b71dc87:/# tail -n 20 /var/log/jenkins/jenkins.log INFO: Winstone shutdown successfully Feb 22, 2018 9:15:14 PM winstone.Logger logInternal SEVERE: Container startup failed java.io.FileNotFoundException: /var/cache/jenkins/war/META-INF/MANIFEST.MF (Permission denied) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.(FileOutputStream.java:221) at java.io.FileOutputStream.(FileOutputStream.java:171) at winstone.HostConfiguration.getWebRoot(HostConfiguration.java:280) at winstone.HostConfiguration.(HostConfiguration.java:83) at winstone.HostGroup.initHost(HostGroup.java:66) at winstone.HostGroup.(HostGroup.java:45) at winstone.Launcher.(Launcher.java:143) at winstone.Launcher.main(Launcher.java:352) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at Main._main(Main.java:264) at Main.main(Main.java:112) ---- But check out this sequence of actions: ----- root at a8750b71dc87:/# id jenkins uid=2060932290(jenkins) gid=2060452353(jenkins) groups=2060452353(jenkins) ... root at a8750b71dc87:/# ls -ld /var /var/cache /var/cache/jenkins /var/cache/jenkins/war /var/cache/jenkins/war/META-INF /var/cache/jenkins/war/META-INF/MANIFEST.MF drwxr-xr-x 32 root root 4096 Feb 22 21:14 /var drwxr-xr-x 17 root root 4096 Feb 22 21:14 /var/cache drwxr-x--- 4 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins drwxr-xr-x 18 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins/war drwxr-xr-x 4 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins/war/META-INF -rw-r--r-- 1 jenkins jenkins 129535 Feb 22 18:17 /var/cache/jenkins/war/META-INF/MANIFEST.MF root at a8750b71dc87:/# su - jenkins jenkins at a8750b71dc87:~$ ls -ld /var /var/cache /var/cache/jenkins /var/cache/jenkins/war /var/cache/jenkins/war/META-INF /var/cache/jenkins/war/META-INF/MANIFEST.MF drwxr-xr-x 32 root root 4096 Feb 22 21:14 /var drwxr-xr-x 17 root root 4096 Feb 22 21:14 /var/cache drwxr-x--- 4 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins drwxr-xr-x 18 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins/war drwxr-xr-x 4 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins/war/META-INF -rw-r--r-- 1 jenkins jenkins 129535 Feb 22 18:17 /var/cache/jenkins/war/META-INF/MANIFEST.MF jenkins at a8750b71dc87:~$ cat /var/cache/jenkins/war/META-INF/MANIFEST.MF Manifest-Version: 1.0 Jenkins-Version: 2.32.1 Implementation-Version: 2.32.1 Hudson-Version: 1.395 Build-Jdk: 1.7.0_21 Built-By: kohsuke Created-By: Apache Maven 3.3.9 Main-Class: Main Archiver-Version: Plexus Archiver Name: images/48x48/red_anime.gif SHA-256-Digest: 2ktTeqkcRPD3cWv0z9xPu6Hf3kMNxoh55qzYKVMdCwk= ... [lots of lines omitted] Name: scripts/yui/assets/skins/sam/button.css SHA-256-Digest: Yp390BkBCcwkhhCQ4Fqj06dTN5qg/zI1QbaR3Gkl6LY= jenkins at a8750b71dc87:~$ exit logout root at a8750b71dc87:/# service jenkins start [ ok ] Starting Jenkins Continuous Integration Server: jenkins. root at a8750b71dc87:/# ----- If the jenkins log message is correct, there's something really weird going on here. The permissions look OK, and the 'jenkins' user can access the MANIFEST.MF file, and a subsequent attempt to start jenkins (as root) works. So I'm not sure what's going on. -- Tim From guicc at profusion.mobi Thu Feb 22 21:29:56 2018 From: guicc at profusion.mobi (Guilherme Camargo) Date: Thu, 22 Feb 2018 18:29:56 -0300 Subject: [Fuego] release test issues In-Reply-To: References: Message-ID: ?I'm not sure either. It's very strange. Maybe something related with selinux? Can you please tell me what linux distribution you're using and the docker version? -- Guilherme On Thu, Feb 22, 2018 at 6:27 PM, wrote: > > > > -----Original Message----- > > From: Guilherme Camargo > > > > I made a few more modifications in the way that the uid/gid are set on > Fuego > > (https://bitbucket.org/profusionmobi/fuego/commits/fe24e93ce191c461f4e > > fa55aaa345a319b1b8fd6) > > and also made the needed changes on fuego-release-test to match those. > > Hopefully they're more robust now. I plan to send all the new changes by > e- > > mail > > to the list, but I just wanted to check if you're able to run it > locally, so > > that you can get a feeling about this, before we move on. > > > > > > Can you please try again with: > > > > > > ``` > > git clone https://bitbucket.org/profusionmobi/fuego-release-test > > cd fuego-release-test > > ./build_and_run -c up > > Still no joy. > > Step 7/7 : COPY fuego-rt-entrypoint.sh / > ---> 4e39b71fb0d5 > Removing intermediate container a5e9b9e4244d > Successfully built 4e39b71fb0d5 > Successfully tagged fuego-rt:latest > fuego-rt-container > a8750b71dc87bc1ad61ed26954c9484e79376d019fbd563abf86e1fcec86c70b > Waiting for Jenkins... > Creating job fuego-test.default.Functional.fuegotest > fuego-rt-container > [FAIL] Starting Jenkins Continuous Integration Server: jenkins failed! > [ ok ] Starting network benchmark server. > root at a8750b71dc87:/# tail -n 20 /var/log/jenkins/jenkins.log > INFO: Winstone shutdown successfully > Feb 22, 2018 9:15:14 PM winstone.Logger logInternal > SEVERE: Container startup failed > java.io.FileNotFoundException: /var/cache/jenkins/war/META-INF/MANIFEST.MF > (Permission denied) > at java.io.FileOutputStream.open(Native Method) > at java.io.FileOutputStream.(FileOutputStream.java:221) > at java.io.FileOutputStream.(FileOutputStream.java:171) > at winstone.HostConfiguration.getWebRoot(HostConfiguration. > java:280) > at winstone.HostConfiguration.(HostConfiguration.java:83) > at winstone.HostGroup.initHost(HostGroup.java:66) > at winstone.HostGroup.(HostGroup.java:45) > at winstone.Launcher.(Launcher.java:143) > at winstone.Launcher.main(Launcher.java:352) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke( > NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at Main._main(Main.java:264) > at Main.main(Main.java:112) > > ---- > But check out this sequence of actions: > > ----- > root at a8750b71dc87:/# id jenkins > uid=2060932290(jenkins) gid=2060452353(jenkins) groups=2060452353(jenkins) > ... > root at a8750b71dc87:/# ls -ld /var /var/cache /var/cache/jenkins > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF > /var/cache/jenkins/war/META-INF/MANIFEST.MF > drwxr-xr-x 32 root root 4096 Feb 22 21:14 /var > drwxr-xr-x 17 root root 4096 Feb 22 21:14 /var/cache > drwxr-x--- 4 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins > drwxr-xr-x 18 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins/war > drwxr-xr-x 4 jenkins jenkins 4096 Feb 22 21:14 > /var/cache/jenkins/war/META-INF > -rw-r--r-- 1 jenkins jenkins 129535 Feb 22 18:17 > /var/cache/jenkins/war/META-INF/MANIFEST.MF > root at a8750b71dc87:/# su - jenkins > jenkins at a8750b71dc87:~$ ls -ld /var /var/cache /var/cache/jenkins > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF > /var/cache/jenkins/war/META-INF/MANIFEST.MF > drwxr-xr-x 32 root root 4096 Feb 22 21:14 /var > drwxr-xr-x 17 root root 4096 Feb 22 21:14 /var/cache > drwxr-x--- 4 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins > drwxr-xr-x 18 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins/war > drwxr-xr-x 4 jenkins jenkins 4096 Feb 22 21:14 > /var/cache/jenkins/war/META-INF > -rw-r--r-- 1 jenkins jenkins 129535 Feb 22 18:17 > /var/cache/jenkins/war/META-INF/MANIFEST.MF > jenkins at a8750b71dc87:~$ cat /var/cache/jenkins/war/META-INF/MANIFEST.MF > Manifest-Version: 1.0 > Jenkins-Version: 2.32.1 > Implementation-Version: 2.32.1 > Hudson-Version: 1.395 > Build-Jdk: 1.7.0_21 > Built-By: kohsuke > Created-By: Apache Maven 3.3.9 > Main-Class: Main > Archiver-Version: Plexus Archiver > > Name: images/48x48/red_anime.gif > SHA-256-Digest: 2ktTeqkcRPD3cWv0z9xPu6Hf3kMNxoh55qzYKVMdCwk= > ... [lots of lines omitted] > > Name: scripts/yui/assets/skins/sam/button.css > SHA-256-Digest: Yp390BkBCcwkhhCQ4Fqj06dTN5qg/zI1QbaR3Gkl6LY= > > jenkins at a8750b71dc87:~$ exit > logout > root at a8750b71dc87:/# service jenkins start > [ ok ] Starting Jenkins Continuous Integration Server: jenkins. > root at a8750b71dc87:/# > ----- > If the jenkins log message is correct, there's something really > weird going on here. The permissions look OK, and the 'jenkins' > user can access the MANIFEST.MF file, and a subsequent > attempt to start jenkins (as root) works. So I'm not sure what's going on. > -- Tim > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Bird at sony.com Thu Feb 22 21:31:54 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Thu, 22 Feb 2018 21:31:54 +0000 Subject: [Fuego] release test issues In-Reply-To: References: Message-ID: But, just because Jenkins started, doesn't mean everything is working. I got a Jenkins "Oops" when trying to build the fuego-test.default.Functional.fuegotest job. Here's the first part of the console log: ----- A problem occurred while processing the request. Please check our bug tracker to see if a similar problem has already been reported. If it is already reported, please vote and put a comment on it to let us gauge the impact of the problem. If you think this is a new issue, please file a new issue. When you file an issue, make sure to add the entire stack trace, along with the version of Jenkins and relevant plugins. The users list might be also useful in understanding what has happened. Stack trace javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-2.32.1.jar!/hudson/model/Run/console.jelly:65:27: Failed to load the key: hudson.console.AnnotatedLargeText.consoleAnnotator at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$10.dispatch(MetaClass.java:362) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$5.doDispatch(MetaClass.java:236) at > -----Original Message----- > From: Tim Bird > > -----Original Message----- > > From: Guilherme Camargo > > > > I made a few more modifications in the way that the uid/gid are set on > Fuego > > > (https://bitbucket.org/profusionmobi/fuego/commits/fe24e93ce191c461f4e > > fa55aaa345a319b1b8fd6) > > and also made the needed changes on fuego-release-test to match those. > > Hopefully they're more robust now. I plan to send all the new changes by > e- > > mail > > to the list, but I just wanted to check if you're able to run it locally, so > > that you can get a feeling about this, before we move on. > > > > > > Can you please try again with: > > > > > > ``` > > git clone https://bitbucket.org/profusionmobi/fuego-release-test > > cd fuego-release-test > > ./build_and_run -c up > > Still no joy. > > Step 7/7 : COPY fuego-rt-entrypoint.sh / > ---> 4e39b71fb0d5 > Removing intermediate container a5e9b9e4244d > Successfully built 4e39b71fb0d5 > Successfully tagged fuego-rt:latest > fuego-rt-container > a8750b71dc87bc1ad61ed26954c9484e79376d019fbd563abf86e1fcec86c70b > Waiting for Jenkins... > Creating job fuego-test.default.Functional.fuegotest > fuego-rt-container > [FAIL] Starting Jenkins Continuous Integration Server: jenkins failed! > [ ok ] Starting network benchmark server. > root at a8750b71dc87:/# tail -n 20 /var/log/jenkins/jenkins.log > INFO: Winstone shutdown successfully > Feb 22, 2018 9:15:14 PM winstone.Logger logInternal > SEVERE: Container startup failed > java.io.FileNotFoundException: /var/cache/jenkins/war/META- > INF/MANIFEST.MF (Permission denied) > at java.io.FileOutputStream.open(Native Method) > at java.io.FileOutputStream.(FileOutputStream.java:221) > at java.io.FileOutputStream.(FileOutputStream.java:171) > at > winstone.HostConfiguration.getWebRoot(HostConfiguration.java:280) > at winstone.HostConfiguration.(HostConfiguration.java:83) > at winstone.HostGroup.initHost(HostGroup.java:66) > at winstone.HostGroup.(HostGroup.java:45) > at winstone.Launcher.(Launcher.java:143) > at winstone.Launcher.main(Launcher.java:352) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j > ava:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at Main._main(Main.java:264) > at Main.main(Main.java:112) > > ---- > But check out this sequence of actions: > > ----- > root at a8750b71dc87:/# id jenkins > uid=2060932290(jenkins) gid=2060452353(jenkins) > groups=2060452353(jenkins) > ... > root at a8750b71dc87:/# ls -ld /var /var/cache /var/cache/jenkins > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF > /var/cache/jenkins/war/META-INF/MANIFEST.MF > drwxr-xr-x 32 root root 4096 Feb 22 21:14 /var > drwxr-xr-x 17 root root 4096 Feb 22 21:14 /var/cache > drwxr-x--- 4 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins > drwxr-xr-x 18 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins/war > drwxr-xr-x 4 jenkins jenkins 4096 Feb 22 21:14 > /var/cache/jenkins/war/META-INF > -rw-r--r-- 1 jenkins jenkins 129535 Feb 22 18:17 > /var/cache/jenkins/war/META-INF/MANIFEST.MF > root at a8750b71dc87:/# su - jenkins > jenkins at a8750b71dc87:~$ ls -ld /var /var/cache /var/cache/jenkins > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF > /var/cache/jenkins/war/META-INF/MANIFEST.MF > drwxr-xr-x 32 root root 4096 Feb 22 21:14 /var > drwxr-xr-x 17 root root 4096 Feb 22 21:14 /var/cache > drwxr-x--- 4 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins > drwxr-xr-x 18 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins/war > drwxr-xr-x 4 jenkins jenkins 4096 Feb 22 21:14 > /var/cache/jenkins/war/META-INF > -rw-r--r-- 1 jenkins jenkins 129535 Feb 22 18:17 > /var/cache/jenkins/war/META-INF/MANIFEST.MF > jenkins at a8750b71dc87:~$ cat /var/cache/jenkins/war/META- > INF/MANIFEST.MF > Manifest-Version: 1.0 > Jenkins-Version: 2.32.1 > Implementation-Version: 2.32.1 > Hudson-Version: 1.395 > Build-Jdk: 1.7.0_21 > Built-By: kohsuke > Created-By: Apache Maven 3.3.9 > Main-Class: Main > Archiver-Version: Plexus Archiver > > Name: images/48x48/red_anime.gif > SHA-256-Digest: 2ktTeqkcRPD3cWv0z9xPu6Hf3kMNxoh55qzYKVMdCwk= > ... [lots of lines omitted] > > Name: scripts/yui/assets/skins/sam/button.css > SHA-256-Digest: Yp390BkBCcwkhhCQ4Fqj06dTN5qg/zI1QbaR3Gkl6LY= > > jenkins at a8750b71dc87:~$ exit > logout > root at a8750b71dc87:/# service jenkins start > [ ok ] Starting Jenkins Continuous Integration Server: jenkins. > root at a8750b71dc87:/# > ----- > If the jenkins log message is correct, there's something really > weird going on here. The permissions look OK, and the 'jenkins' > user can access the MANIFEST.MF file, and a subsequent > attempt to start jenkins (as root) works. So I'm not sure what's going on. > -- Tim > > _______________________________________________ > Fuego mailing list > Fuego at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/fuego From tuyen.hoangvan at toshiba-tsdv.com Fri Feb 23 02:43:01 2018 From: tuyen.hoangvan at toshiba-tsdv.com (Hoang Van Tuyen) Date: Fri, 23 Feb 2018 09:43:01 +0700 Subject: [Fuego] [PATCH 2/2] ftc: gen_report: Add new functions for getting data to, generate the report In-Reply-To: References: <48ee9177-bd98-d609-5328-b21a6f110e1e@toshiba-tsdv.com> Message-ID: <49616ddb-9c5f-8351-9610-a4d54abd1d48@toshiba-tsdv.com> Hi, On 2/22/2018 7:40 PM, Gustavo Sverzut Barbieri wrote: > On Thu, Feb 22, 2018 at 7:51 AM, Hoang Van Tuyen > wrote: >> Hello Tim, >> >> I am working on gen-report feature (support several other format like html, >> pdf, ...). > do you plan to generate ReStructuredText (RST) and from there use > converters, or really generate the same result into multiple formats? > > using RST allows not only to generate multiple formats, but also to > customize output via templates, which is a nice addition. Thank you for your suggestion. I did not think about generating the RST format before. I will consider the method which generates the RST format, then use converters to generate other formats. Thanks Tuyen > > > -- ================================================================ Hoang Van Tuyen (Mr.) TOSHIBA SOFTWARE DEVELOPMENT (VIETNAM) CO., LTD. 16th Floor, VIT Building, 519 Kim Ma Str., Ba Dinh Dist., Hanoi, Vietnam Tel: 84-4-22208801 (Company) - Ext.251 Fax: 84-4-22208802 (Company) Email: tuyen.hoangvan at toshiba-tsdv.com ================================================================ -- This mail was scanned by BitDefender For more information please visit http://www.bitdefender.com From Tim.Bird at sony.com Fri Feb 23 04:49:54 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Fri, 23 Feb 2018 04:49:54 +0000 Subject: [Fuego] [PATCH 2/2] ftc: gen_report: Add new functions for getting data to, generate the report In-Reply-To: <49616ddb-9c5f-8351-9610-a4d54abd1d48@toshiba-tsdv.com> References: <48ee9177-bd98-d609-5328-b21a6f110e1e@toshiba-tsdv.com> <49616ddb-9c5f-8351-9610-a4d54abd1d48@toshiba-tsdv.com> Message-ID: Just a few comments below. > -----Original Message----- > From: Hoang Van Tuyen > Hi, > > On 2/22/2018 7:40 PM, Gustavo Sverzut Barbieri wrote: > > On Thu, Feb 22, 2018 at 7:51 AM, Hoang Van Tuyen > > wrote: > >> Hello Tim, > >> > >> I am working on gen-report feature (support several other format like > html, These patches look good. I skimmed over them, but didn't have time to do a thorough review today. Thanks for the contribution. I hope to review them tomorrow, but I might not get to them until next week due to other commitments tomorrow. > >> pdf, ...). > > do you plan to generate ReStructuredText (RST) and from there use > > converters, or really generate the same result into multiple formats? > > > > using RST allows not only to generate multiple formats, but also to > > customize output via templates, which is a nice addition. > Thank you for your suggestion. I did not think about generating the RST > format before. > I will consider the method which generates the RST format, then use > converters to generate > other formats. I think this might be good, but a lot will depend on the implementation and the context of the report. I'm worried a bit that running it through RST to get to html may take a long time (but I'm in the middle of adding my own RST-based testcase documentation, that will have this same issue.) Also, I haven't looked in detail at the types of reports we plan, but I'm worried that the RST support for tables will require keeping track of column positions for the column borders. With plain ASCII, we haven't worried if something breaks the column boundaries, as it's only intended for human consumption. With RST, I think text exceeding column boundaries might break the parsing required for conversion to other formats. This is something to watch out for. Also, so far, the generator has not dealt with column-spanning (like the chart generator does in the results parser). But long term that will be needed, IMHO. This is going to be pretty complex in RST. (I'm not sure if it's more or less complex than doing column-spanning directly in HTML). I would recommend doing the generator as a python class, with support for different output formats as sub-classes. Just my 2 cents. -- Tim From guicc at profusion.mobi Fri Feb 23 16:23:20 2018 From: guicc at profusion.mobi (Guilherme Camargo) Date: Fri, 23 Feb 2018 13:23:20 -0300 Subject: [Fuego] release test issues In-Reply-To: References: Message-ID: Hello, Tim I think we're getting closer to the root cause. It's still not very clear why, but there seems to be some sort of race condition when, while running the fuego-release-test as a daemon we try to execute fuego-rt-entrypoint.sh. For some reason, we might be trying to run the `ftc` commands while the uid/gid of jenkins have not been mapped yet in the original entrypoint.sh. With my newest change, we're calling `docker run` only once, guaranteeing that: - fuego-base "entrypoint.sh" - fuego-release-test "fuego-rt-entrypoint.sh" - and "/bin/bash" are executed sequentially. Would you please try again with the new commits that have been pushed to master? Steps are: ``` git clone https://bitbucket.org/profusionmobi/fuego-release-test cd fuego-release-test ./build_and_run -c up Then try to access fuego in localhost:8080/fuego/ You can also pass -p PORT to build_and_run and access fuego from that location instead. ``` Thank you very much -- Guilherme On Thu, Feb 22, 2018 at 6:31 PM, wrote: > But, just because Jenkins started, doesn't mean everything is working. > I got a Jenkins "Oops" when trying to build the > fuego-test.default.Functional.fuegotest job. > > Here's the first part of the console log: > ----- > A problem occurred while processing the request. Please check our bug > tracker to see if a similar problem has already been reported. If it is > already reported, please vote and put a comment on it to let us gauge the > impact of the problem. If you think this is a new issue, please file a new > issue. When you file an issue, make sure to add the entire stack trace, > along with the version of Jenkins and relevant plugins. The users list > might be also useful in understanding what has happened. > > Stack trace > > javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: > jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-2.3 > 2.1.jar!/hudson/model/Run/console.jelly:65:27: Failed to > load the key: hudson.console.AnnotatedLargeText.consoleAnnotator > at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.j > ava:103) > at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) > at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) > at org.kohsuke.stapler.MetaClass$10.dispatch(MetaClass.java:362) > at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) > at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) > at org.kohsuke.stapler.MetaClass$5.doDispatch(MetaClass.java:236) > at > > -----Original Message----- > > From: Tim Bird > > > -----Original Message----- > > > From: Guilherme Camargo > > > > > > I made a few more modifications in the way that the uid/gid are set on > > Fuego > > > > > (https://bitbucket.org/profusionmobi/fuego/commits/fe24e93ce191c461f4e > > > fa55aaa345a319b1b8fd6) > > > and also made the needed changes on fuego-release-test to match those. > > > Hopefully they're more robust now. I plan to send all the new changes > by > > e- > > > mail > > > to the list, but I just wanted to check if you're able to run it > locally, so > > > that you can get a feeling about this, before we move on. > > > > > > > > > Can you please try again with: > > > > > > > > > ``` > > > git clone https://bitbucket.org/profusionmobi/fuego-release-test > > > cd fuego-release-test > > > ./build_and_run -c up > > > > Still no joy. > > > > Step 7/7 : COPY fuego-rt-entrypoint.sh / > > ---> 4e39b71fb0d5 > > Removing intermediate container a5e9b9e4244d > > Successfully built 4e39b71fb0d5 > > Successfully tagged fuego-rt:latest > > fuego-rt-container > > a8750b71dc87bc1ad61ed26954c9484e79376d019fbd563abf86e1fcec86c70b > > Waiting for Jenkins... > > Creating job fuego-test.default.Functional.fuegotest > > fuego-rt-container > > [FAIL] Starting Jenkins Continuous Integration Server: jenkins failed! > > [ ok ] Starting network benchmark server. > > root at a8750b71dc87:/# tail -n 20 /var/log/jenkins/jenkins.log > > INFO: Winstone shutdown successfully > > Feb 22, 2018 9:15:14 PM winstone.Logger logInternal > > SEVERE: Container startup failed > > java.io.FileNotFoundException: /var/cache/jenkins/war/META- > > INF/MANIFEST.MF (Permission denied) > > at java.io.FileOutputStream.open(Native Method) > > at java.io.FileOutputStream.(FileOutputStream.java:221) > > at java.io.FileOutputStream.(FileOutputStream.java:171) > > at > > winstone.HostConfiguration.getWebRoot(HostConfiguration.java:280) > > at winstone.HostConfiguration.(HostConfiguration.java:83) > > at winstone.HostGroup.initHost(HostGroup.java:66) > > at winstone.HostGroup.(HostGroup.java:45) > > at winstone.Launcher.(Launcher.java:143) > > at winstone.Launcher.main(Launcher.java:352) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j > > ava:57) > > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > > sorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:606) > > at Main._main(Main.java:264) > > at Main.main(Main.java:112) > > > > ---- > > But check out this sequence of actions: > > > > ----- > > root at a8750b71dc87:/# id jenkins > > uid=2060932290(jenkins) gid=2060452353(jenkins) > > groups=2060452353(jenkins) > > ... > > root at a8750b71dc87:/# ls -ld /var /var/cache /var/cache/jenkins > > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF > > /var/cache/jenkins/war/META-INF/MANIFEST.MF > > drwxr-xr-x 32 root root 4096 Feb 22 21:14 /var > > drwxr-xr-x 17 root root 4096 Feb 22 21:14 /var/cache > > drwxr-x--- 4 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins > > drwxr-xr-x 18 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins/war > > drwxr-xr-x 4 jenkins jenkins 4096 Feb 22 21:14 > > /var/cache/jenkins/war/META-INF > > -rw-r--r-- 1 jenkins jenkins 129535 Feb 22 18:17 > > /var/cache/jenkins/war/META-INF/MANIFEST.MF > > root at a8750b71dc87:/# su - jenkins > > jenkins at a8750b71dc87:~$ ls -ld /var /var/cache /var/cache/jenkins > > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF > > /var/cache/jenkins/war/META-INF/MANIFEST.MF > > drwxr-xr-x 32 root root 4096 Feb 22 21:14 /var > > drwxr-xr-x 17 root root 4096 Feb 22 21:14 /var/cache > > drwxr-x--- 4 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins > > drwxr-xr-x 18 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins/war > > drwxr-xr-x 4 jenkins jenkins 4096 Feb 22 21:14 > > /var/cache/jenkins/war/META-INF > > -rw-r--r-- 1 jenkins jenkins 129535 Feb 22 18:17 > > /var/cache/jenkins/war/META-INF/MANIFEST.MF > > jenkins at a8750b71dc87:~$ cat /var/cache/jenkins/war/META- > > INF/MANIFEST.MF > > Manifest-Version: 1.0 > > Jenkins-Version: 2.32.1 > > Implementation-Version: 2.32.1 > > Hudson-Version: 1.395 > > Build-Jdk: 1.7.0_21 > > Built-By: kohsuke > > Created-By: Apache Maven 3.3.9 > > Main-Class: Main > > Archiver-Version: Plexus Archiver > > > > Name: images/48x48/red_anime.gif > > SHA-256-Digest: 2ktTeqkcRPD3cWv0z9xPu6Hf3kMNxoh55qzYKVMdCwk= > > ... [lots of lines omitted] > > > > Name: scripts/yui/assets/skins/sam/button.css > > SHA-256-Digest: Yp390BkBCcwkhhCQ4Fqj06dTN5qg/zI1QbaR3Gkl6LY= > > > > jenkins at a8750b71dc87:~$ exit > > logout > > root at a8750b71dc87:/# service jenkins start > > [ ok ] Starting Jenkins Continuous Integration Server: jenkins. > > root at a8750b71dc87:/# > > ----- > > If the jenkins log message is correct, there's something really > > weird going on here. The permissions look OK, and the 'jenkins' > > user can access the MANIFEST.MF file, and a subsequent > > attempt to start jenkins (as root) works. So I'm not sure what's going > on. > > -- Tim > > > > _______________________________________________ > > Fuego mailing list > > Fuego at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/fuego > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guicc at profusion.mobi Mon Feb 26 18:30:31 2018 From: guicc at profusion.mobi (Guilherme Camargo) Date: Mon, 26 Feb 2018 15:30:31 -0300 Subject: [Fuego] release test issues In-Reply-To: References: Message-ID: Hello, Tim Hope everything is going well. Did you have the chance to run the test again? Thank you -- Guilherme On Fri, Feb 23, 2018 at 1:23 PM, Guilherme Camargo wrote: > Hello, Tim > > I think we're getting closer to the root cause. > > It's still not very clear why, but there seems to be some sort of race > condition when, while running the fuego-release-test as a daemon we try to > execute fuego-rt-entrypoint.sh. For some reason, we might be trying to run > the > `ftc` commands while the uid/gid of jenkins have not been mapped yet in the > original entrypoint.sh. > > With my newest change, we're calling `docker run` only once, guaranteeing > that: > - fuego-base "entrypoint.sh" > - fuego-release-test "fuego-rt-entrypoint.sh" > - and "/bin/bash" > are executed sequentially. > > Would you please try again with the new commits that have been pushed to > master? > > Steps are: > > ``` > git clone https://bitbucket.org/profusionmobi/fuego-release-test > cd fuego-release-test > ./build_and_run -c up > > Then try to access fuego in localhost:8080/fuego/ > > You can also pass -p PORT to build_and_run and access fuego from that > location instead. > > ``` > > Thank you very much > > -- > Guilherme > > > On Thu, Feb 22, 2018 at 6:31 PM, wrote: > >> But, just because Jenkins started, doesn't mean everything is working. >> I got a Jenkins "Oops" when trying to build the >> fuego-test.default.Functional.fuegotest job. >> >> Here's the first part of the console log: >> ----- >> A problem occurred while processing the request. Please check our bug >> tracker to see if a similar problem has already been reported. If it is >> already reported, please vote and put a comment on it to let us gauge the >> impact of the problem. If you think this is a new issue, please file a new >> issue. When you file an issue, make sure to add the entire stack trace, >> along with the version of Jenkins and relevant plugins. The users list >> might be also useful in understanding what has happened. >> >> Stack trace >> >> javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: >> jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-2.3 >> 2.1.jar!/hudson/model/Run/console.jelly:65:27: Failed to >> load the key: hudson.console.AnnotatedLargeText.consoleAnnotator >> at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.j >> ava:103) >> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) >> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) >> at org.kohsuke.stapler.MetaClass$10.dispatch(MetaClass.java:362) >> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) >> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) >> at org.kohsuke.stapler.MetaClass$5.doDispatch(MetaClass.java:236) >> at >> > -----Original Message----- >> > From: Tim Bird >> > > -----Original Message----- >> > > From: Guilherme Camargo >> > > >> > > I made a few more modifications in the way that the uid/gid are set on >> > Fuego >> > > >> > (https://bitbucket.org/profusionmobi/fuego/commits/fe24e93ce191c461f4e >> > > fa55aaa345a319b1b8fd6) >> > > and also made the needed changes on fuego-release-test to match those. >> > > Hopefully they're more robust now. I plan to send all the new changes >> by >> > e- >> > > mail >> > > to the list, but I just wanted to check if you're able to run it >> locally, so >> > > that you can get a feeling about this, before we move on. >> > > >> > > >> > > Can you please try again with: >> > > >> > > >> > > ``` >> > > git clone https://bitbucket.org/profusionmobi/fuego-release-test >> > > cd fuego-release-test >> > > ./build_and_run -c up >> > >> > Still no joy. >> > >> > Step 7/7 : COPY fuego-rt-entrypoint.sh / >> > ---> 4e39b71fb0d5 >> > Removing intermediate container a5e9b9e4244d >> > Successfully built 4e39b71fb0d5 >> > Successfully tagged fuego-rt:latest >> > fuego-rt-container >> > a8750b71dc87bc1ad61ed26954c9484e79376d019fbd563abf86e1fcec86c70b >> > Waiting for Jenkins... >> > Creating job fuego-test.default.Functional.fuegotest >> > fuego-rt-container >> > [FAIL] Starting Jenkins Continuous Integration Server: jenkins failed! >> > [ ok ] Starting network benchmark server. >> > root at a8750b71dc87:/# tail -n 20 /var/log/jenkins/jenkins.log >> > INFO: Winstone shutdown successfully >> > Feb 22, 2018 9:15:14 PM winstone.Logger logInternal >> > SEVERE: Container startup failed >> > java.io.FileNotFoundException: /var/cache/jenkins/war/META- >> > INF/MANIFEST.MF (Permission denied) >> > at java.io.FileOutputStream.open(Native Method) >> > at java.io.FileOutputStream.(FileOutputStream.java:221) >> > at java.io.FileOutputStream.(FileOutputStream.java:171) >> > at >> > winstone.HostConfiguration.getWebRoot(HostConfiguration.java:280) >> > at winstone.HostConfiguration.(HostConfiguration.java:83) >> > at winstone.HostGroup.initHost(HostGroup.java:66) >> > at winstone.HostGroup.(HostGroup.java:45) >> > at winstone.Launcher.(Launcher.java:143) >> > at winstone.Launcher.main(Launcher.java:352) >> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> > at >> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j >> > ava:57) >> > at >> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces >> > sorImpl.java:43) >> > at java.lang.reflect.Method.invoke(Method.java:606) >> > at Main._main(Main.java:264) >> > at Main.main(Main.java:112) >> > >> > ---- >> > But check out this sequence of actions: >> > >> > ----- >> > root at a8750b71dc87:/# id jenkins >> > uid=2060932290(jenkins) gid=2060452353(jenkins) >> > groups=2060452353(jenkins) >> > ... >> > root at a8750b71dc87:/# ls -ld /var /var/cache /var/cache/jenkins >> > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF >> > /var/cache/jenkins/war/META-INF/MANIFEST.MF >> > drwxr-xr-x 32 root root 4096 Feb 22 21:14 /var >> > drwxr-xr-x 17 root root 4096 Feb 22 21:14 /var/cache >> > drwxr-x--- 4 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins >> > drwxr-xr-x 18 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins/war >> > drwxr-xr-x 4 jenkins jenkins 4096 Feb 22 21:14 >> > /var/cache/jenkins/war/META-INF >> > -rw-r--r-- 1 jenkins jenkins 129535 Feb 22 18:17 >> > /var/cache/jenkins/war/META-INF/MANIFEST.MF >> > root at a8750b71dc87:/# su - jenkins >> > jenkins at a8750b71dc87:~$ ls -ld /var /var/cache /var/cache/jenkins >> > /var/cache/jenkins/war /var/cache/jenkins/war/META-INF >> > /var/cache/jenkins/war/META-INF/MANIFEST.MF >> > drwxr-xr-x 32 root root 4096 Feb 22 21:14 /var >> > drwxr-xr-x 17 root root 4096 Feb 22 21:14 /var/cache >> > drwxr-x--- 4 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins >> > drwxr-xr-x 18 jenkins jenkins 4096 Feb 22 21:14 /var/cache/jenkins/war >> > drwxr-xr-x 4 jenkins jenkins 4096 Feb 22 21:14 >> > /var/cache/jenkins/war/META-INF >> > -rw-r--r-- 1 jenkins jenkins 129535 Feb 22 18:17 >> > /var/cache/jenkins/war/META-INF/MANIFEST.MF >> > jenkins at a8750b71dc87:~$ cat /var/cache/jenkins/war/META- >> > INF/MANIFEST.MF >> > Manifest-Version: 1.0 >> > Jenkins-Version: 2.32.1 >> > Implementation-Version: 2.32.1 >> > Hudson-Version: 1.395 >> > Build-Jdk: 1.7.0_21 >> > Built-By: kohsuke >> > Created-By: Apache Maven 3.3.9 >> > Main-Class: Main >> > Archiver-Version: Plexus Archiver >> > >> > Name: images/48x48/red_anime.gif >> > SHA-256-Digest: 2ktTeqkcRPD3cWv0z9xPu6Hf3kMNxoh55qzYKVMdCwk= >> > ... [lots of lines omitted] >> > >> > Name: scripts/yui/assets/skins/sam/button.css >> > SHA-256-Digest: Yp390BkBCcwkhhCQ4Fqj06dTN5qg/zI1QbaR3Gkl6LY= >> > >> > jenkins at a8750b71dc87:~$ exit >> > logout >> > root at a8750b71dc87:/# service jenkins start >> > [ ok ] Starting Jenkins Continuous Integration Server: jenkins. >> > root at a8750b71dc87:/# >> > ----- >> > If the jenkins log message is correct, there's something really >> > weird going on here. The permissions look OK, and the 'jenkins' >> > user can access the MANIFEST.MF file, and a subsequent >> > attempt to start jenkins (as root) works. So I'm not sure what's going >> on. >> > -- Tim >> > >> > _______________________________________________ >> > Fuego mailing list >> > Fuego at lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/fuego >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Bird at sony.com Mon Feb 26 18:52:30 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Mon, 26 Feb 2018 18:52:30 +0000 Subject: [Fuego] release test issues In-Reply-To: References: Message-ID: > -----Original Message----- > From: Guilherme Camargo [mailto:guicc at profusion.mobi] > Sent: Monday, February 26, 2018 10:31 AM > To: Bird, Timothy > Cc: fuego at lists.linuxfoundation.org > Subject: Re: [Fuego] release test issues > > Hello, Tim > > Hope everything is going well. > > Did you have the chance to run the test again? I ran it just now... Good news!! Jenkins starts in the container, and the fuego-test.default./Functional.fuegotest job is created. When I build that job in Jenkins, it immediately fails, and I get the following error message in the console log (this is a copy paste from the Jenkins interface): A problem occurred while processing the request. Please check our bug tracker to see if a similar problem has already been reported. If it is already reported, please vote and put a comment on it to let us gauge the impact of the problem. If you think this is a new issue, please file a new issue. When you file an issue, make sure to add the entire stack trace, along with the version of Jenkins and relevant plugins. The users list might be also useful in understanding what has happened. Stack trace javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-2.32.1.jar!/hudson/model/Run/console.jelly:65:27: Failed to load the key: hudson.console.AnnotatedLargeText.consoleAnnotator at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$10.dispatch(MetaClass.java:362) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$5.doDispatch(MetaClass.java:236) at ... (lots more traceback). ------------ If I look at /var/lib/jenkins/jobs/fuego-test.default.Functional.fuegotest/builds/3/log, I see the following: Started by user ^[[8mha:AAAAlh+LCAAAAAAAAP9b85aBtbiIQTGjNKU4P08vOT+vOD8nVc83PyU1x6OyILUoJzMv2y+/JJUBAhiZGBgqihhk0NSjKDWzXb3RdlLBUSYGJk8GtpzUvPSSDB8G5tKinBIGIZ+sxLJE/ZzEvHT94JKizLx0a6BxUmjGOUNodHsLgAzOEgYu/dLi1CL9vNKcHACFIKlWvwAAAA==^[[0manonymous Building remotely on ^[[8mha:AAAAoB+LCAAAAAAAAP9b85aBtbiIQTGjNKU4P08vOT+vOD8nVc83PyU1x6OyILUoJzMv2y+/JJUBAhiZGBgqihhk0NSjKDWzXb3RdlLBUSYGJk8GtpzUvPSSDB8G5tKinBIGIZ+sxLJE/ZzEvHT94JKizLx0a6BxUmjGOUNodHsLgAyuEgYR/eT83ILSktQi/bTS1PR83ZLU4hIADoGZQ8kAAAA=^[[0mfuego-testFATAL: Failed to load the key: hudson.model.Job.serverCookie ^[[8mha:AAAAWB+LCAAAAAAAAP9b85aBtbiIQSmjNKU4P08vOT+vOD8nVc8DzHWtSE4tKMnMz/PLL0ldFVf2c+b/lb5MDAwVRQxSaBqcITRIIQMEMIIUFgAAckCEiWAAAAA=^[[0mjava.lang.Error: Failed to load the key: hudson.model.Job.serverCookie at jenkins.security.HexStringConfidentialKey.get(HexStringConfidentialKey.java:62) at hudson.model.Job.getCharacteristicEnvVars(Job.java:367) at hudson.model.Job.getEnvironment(Job.java:395) at hudson.model.AbstractProject.getEnvironment(AbstractProject.java:353) at hudson.model.Run.getEnvironment(Run.java:2264) at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:922) at hudson.model.AbstractBuild$AbstractBuildExecution.decideWorkspace(AbstractBuild.java:478) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:518) at hudson.model.Run.execute(Run.java:1728) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:404) Caused by: java.io.FileNotFoundException: /var/lib/jenkins/secrets/hudson.model.Job.serverCookie (Permission denied) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.(FileOutputStream.java:221) at java.io.FileOutputStream.(FileOutputStream.java:171) at jenkins.security.DefaultConfidentialStore.store(DefaultConfidentialStore.java:79) at jenkins.security.ConfidentialKey.store(ConfidentialKey.java:50) at jenkins.security.HexStringConfidentialKey.get(HexStringConfidentialKey.java:54) ... 11 more FATAL: Failed to load the key: hudson.model.Job.serverCookie ^[[8mha:AAAAWB+LCAAAAAAAAP9b85aBtbiIQSmjNKU4P08vOT+vOD8nVc8DzHWtSE4tKMnMz/PLL0ldFVf2c+b/lb5MDAwVRQxSaBqcITRIIQMEMIIUFgAAckCEiWAAAAA=^[[0mjava.lang.Error: Failed to load the key: hudson.model.Job.serverCookie at jenkins.security.HexStringConfidentialKey.get(HexStringConfidentialKey.java:62) at hudson.model.Job.getCharacteristicEnvVars(Job.java:367) at hudson.model.Job.getEnvironment(Job.java:395) at hudson.model.AbstractProject.getEnvironment(AbstractProject.java:353) at hudson.model.Run.getEnvironment(Run.java:2264) at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:922) at hudson.plugins.descriptionsetter.DescriptionSetterHelper.setDescription(DescriptionSetterHelper.java:53) at hudson.plugins.descriptionsetter.DescriptionSetterPublisher.perform(DescriptionSetterPublisher.java:70) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:720) at hudson.model.Build$BuildExecution.post2(Build.java:185) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:665) at hudson.model.Run.execute(Run.java:1753) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:404) Caused by: java.io.FileNotFoundException: /var/lib/jenkins/secrets/hudson.model.Job.serverCookie (Permission denied) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.(FileOutputStream.java:221) at java.io.FileOutputStream.(FileOutputStream.java:171) at jenkins.security.DefaultConfidentialStore.store(DefaultConfidentialStore.java:79) at jenkins.security.ConfidentialKey.store(ConfidentialKey.java:50) at jenkins.security.HexStringConfidentialKey.get(HexStringConfidentialKey.java:54) ... 16 more Finished: FAILURE ---------- Let me know if there is more information I can provide. BTW - I tried to copy the log file to /fuego-rw/transfer so I could extract it from the container, but I can't find fuego-rw on my host that corresponds to this. Where would this directory be located, in the release test configuration of the containers? -- Tim From guicc at profusion.mobi Mon Feb 26 21:03:40 2018 From: guicc at profusion.mobi (Guilherme Camargo) Date: Mon, 26 Feb 2018 18:03:40 -0300 Subject: [Fuego] release test issues In-Reply-To: References: Message-ID: Hello, Tim, good to know that Jenkins started now. But, still, there seems to be some issue with permissions that for some reason affects your system and does not affect either mine or my peers'. Can you please share the logs that are stored in fuego-rw inside the fuego-rt-container? We're currently not mapping fuego-rw to the host, neither on fuego-release-test (the fuego that is testing), nor in the fuego that's being tested - what means that the user would need to use Jenkin's web interface to read the logs, at least for now. But we could change that to allow mapping if you find it necessary. Thank you a lot -- Guilherme On Mon, Feb 26, 2018 at 3:52 PM, wrote: > > > > -----Original Message----- > > From: Guilherme Camargo [mailto:guicc at profusion.mobi] > > Sent: Monday, February 26, 2018 10:31 AM > > To: Bird, Timothy > > Cc: fuego at lists.linuxfoundation.org > > Subject: Re: [Fuego] release test issues > > > > Hello, Tim > > > > Hope everything is going well. > > > > Did you have the chance to run the test again? > > I ran it just now... > > Good news!! Jenkins starts in the container, and the fuego-test.default./ > Functional.fuegotest > job is created. > > When I build that job in Jenkins, it immediately fails, and I get the > following error message > in the console log (this is a copy paste from the Jenkins interface): > > A problem occurred while processing the request. Please check our bug > tracker to see if a similar problem has already been reported. If it is > already reported, please vote and put a comment on it to let us gauge the > impact of the problem. If you think this is a new issue, please file a new > issue. When you file an issue, make sure to add the entire stack trace, > along with the version of Jenkins and relevant plugins. The users list > might be also useful in understanding what has happened. > > Stack trace > > javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: > jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core- > 2.32.1.jar!/hudson/model/Run/console.jelly:65:27: Failed > to load the key: hudson.console.AnnotatedLargeText.consoleAnnotator > at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch( > JellyFacet.java:103) > at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) > at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) > at org.kohsuke.stapler.MetaClass$10.dispatch(MetaClass.java:362) > at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) > at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) > at org.kohsuke.stapler.MetaClass$5.doDispatch(MetaClass.java:236) > at > ... (lots more traceback). > > ------------ > If I look at /var/lib/jenkins/jobs/fuego-test.default.Functional.fuegotest/builds/3/log, > I see the following: > > Started by user ^[[8mha:AAAAlh+LCAAAAAAAAP9b85aBtbiIQTGjNKU4P08vOT+ > vOD8nVc83PyU1x6OyILUoJzMv2y+/JJUBAhiZGBgqihhk0NSjKDWzXb3Rdl > LBUSYGJk8GtpzUvPSSDB8G5tKinBIGIZ+sxLJE/ZzEvHT94JKizLx0a6BxUmjGOUNodHs > LgAzOEgYu/dLi1CL9vNKcHACFIKlWvwAAAA==^[[0manonymous > Building remotely on ^[[8mha:AAAAoB+LCAAAAAAAAP9b85aBtbiIQTGjNKU4P08vOT+ > vOD8nVc83PyU1x6OyILUoJzMv2y+/JJUBAhiZGBgqihhk0NSjKDWzXb3Rdl > LBUSYGJk8GtpzUvPSSDB8G5tKinBIGIZ+sxLJE/ZzEvHT94JKizLx0a6BxUmjGOUNodHs > LgAyuEgYR/eT83ILSktQi/bTS1PR83ZLU4hIADoGZQ8kAAAA=^[[0mfuego-testFATAL: > Failed to load the key: hudson.model.Job.serverCookie > ^[[8mha:AAAAWB+LCAAAAAAAAP9b85aBtbiIQSmjNKU4P08vOT+vOD8nVc8DzHWtSE4tKMnMz/ > PLL0ldFVf2c+b/lb5MDAwVRQxSaBqcITRIIQMEMIIUFgAAckCEiWAAAAA=^[[0mjava.lang.Error: > Failed to load the key: hudson.model.Job.serverCookie > at jenkins.security.HexStringConfidentialKey.get( > HexStringConfidentialKey.java:62) > at hudson.model.Job.getCharacteristicEnvVars(Job.java:367) > at hudson.model.Job.getEnvironment(Job.java:395) > at hudson.model.AbstractProject.getEnvironment( > AbstractProject.java:353) > at hudson.model.Run.getEnvironment(Run.java:2264) > at hudson.model.AbstractBuild.getEnvironment(AbstractBuild. > java:922) > at hudson.model.AbstractBuild$AbstractBuildExecution. > decideWorkspace(AbstractBuild.java:478) > at hudson.model.AbstractBuild$AbstractBuildExecution.run( > AbstractBuild.java:518) > at hudson.model.Run.execute(Run.java:1728) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) > at hudson.model.ResourceController.execute( > ResourceController.java:98) > at hudson.model.Executor.run(Executor.java:404) > Caused by: java.io.FileNotFoundException: /var/lib/jenkins/secrets/hudson.model.Job.serverCookie > (Permission denied) > at java.io.FileOutputStream.open(Native Method) > at java.io.FileOutputStream.(FileOutputStream.java:221) > at java.io.FileOutputStream.(FileOutputStream.java:171) > at jenkins.security.DefaultConfidentialStore.store( > DefaultConfidentialStore.java:79) > at jenkins.security.ConfidentialKey.store(ConfidentialKey.java:50) > at jenkins.security.HexStringConfidentialKey.get( > HexStringConfidentialKey.java:54) > ... 11 more > FATAL: Failed to load the key: hudson.model.Job.serverCookie > ^[[8mha:AAAAWB+LCAAAAAAAAP9b85aBtbiIQSmjNKU4P08vOT+vOD8nVc8DzHWtSE4tKMnMz/ > PLL0ldFVf2c+b/lb5MDAwVRQxSaBqcITRIIQMEMIIUFgAAckCEiWAAAAA=^[[0mjava.lang.Error: > Failed to load the key: hudson.model.Job.serverCookie > at jenkins.security.HexStringConfidentialKey.get( > HexStringConfidentialKey.java:62) > at hudson.model.Job.getCharacteristicEnvVars(Job.java:367) > at hudson.model.Job.getEnvironment(Job.java:395) > at hudson.model.AbstractProject.getEnvironment( > AbstractProject.java:353) > at hudson.model.Run.getEnvironment(Run.java:2264) > at hudson.model.AbstractBuild.getEnvironment(AbstractBuild. > java:922) > at hudson.plugins.descriptionsetter.DescriptionSetterHelper. > setDescription(DescriptionSetterHelper.java:53) > at hudson.plugins.descriptionsetter.DescriptionSetterPublisher. > perform(DescriptionSetterPublisher.java:70) > at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor. > java:20) > at hudson.model.AbstractBuild$AbstractBuildExecution. > perform(AbstractBuild.java:779) > at hudson.model.AbstractBuild$AbstractBuildExecution. > performAllBuildSteps(AbstractBuild.java:720) > at hudson.model.Build$BuildExecution.post2(Build.java:185) > at hudson.model.AbstractBuild$AbstractBuildExecution.post( > AbstractBuild.java:665) > at hudson.model.Run.execute(Run.java:1753) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) > at hudson.model.ResourceController.execute( > ResourceController.java:98) > at hudson.model.Executor.run(Executor.java:404) > Caused by: java.io.FileNotFoundException: /var/lib/jenkins/secrets/hudson.model.Job.serverCookie > (Permission denied) > at java.io.FileOutputStream.open(Native Method) > at java.io.FileOutputStream.(FileOutputStream.java:221) > at java.io.FileOutputStream.(FileOutputStream.java:171) > at jenkins.security.DefaultConfidentialStore.store( > DefaultConfidentialStore.java:79) > at jenkins.security.ConfidentialKey.store(ConfidentialKey.java:50) > at jenkins.security.HexStringConfidentialKey.get( > HexStringConfidentialKey.java:54) > ... 16 more > Finished: FAILURE > > ---------- > Let me know if there is more information I can provide. > > BTW - I tried to copy the log file to /fuego-rw/transfer so I could > extract it from the container, > but I can't find fuego-rw on my host that corresponds to this. Where > would this directory > be located, in the release test configuration of the containers? > -- Tim > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.sangorrin at toshiba.co.jp Mon Feb 26 23:35:13 2018 From: daniel.sangorrin at toshiba.co.jp (Daniel Sangorrin) Date: Tue, 27 Feb 2018 08:35:13 +0900 Subject: [Fuego] Report of AGL-AMM2018 In-Reply-To: References: Message-ID: <004a01d3af5a$733580c0$59a08240$@toshiba.co.jp> Hi Oki, > -----Original Message----- > From: fuego-bounces at lists.linuxfoundation.org [mailto:fuego-bounces at lists.linuxfoundation.org] On Behalf Of Oki, Kyohhei > I had a presentation at AGL-AMM2018 in Japan. > I have been advertising Fuego's detailed usage > > My slide is here. > https://schd.ws/hosted_files/aglammjapan2018/14/Introduction%20of%20AGL%27s%20approach%20to%20Fuego.pdf Thanks for the slides! I think it is a nice introduction to Fuego. I liked the idea of clicking on the PASS/FAIL result to see the corresponding log. Is this related to the patches that Liu sent? About the LTP network support, did you need to change anything else than the spec shown on the slides? Thanks, Daniel From Tim.Bird at sony.com Tue Feb 27 18:49:04 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Tue, 27 Feb 2018 18:49:04 +0000 Subject: [Fuego] [PATCH 1/2] ftc: gen_report: should check run_list is not null, earlier In-Reply-To: <96aa3fc7-5ae2-3eae-8663-1774d5beee3f@toshiba-tsdv.com> References: <96aa3fc7-5ae2-3eae-8663-1774d5beee3f@toshiba-tsdv.com> Message-ID: Sorry this took so long to get to. See comments inline below. > -----Original Message----- > From: Hoang Van Tuyen > In the future, We will support several other report formats (like html, > pdf, ...). > We should check the run_list is null or not in do_gen_report function, > not in the > gen_text_report function. > > Signed-off-by: Hoang Van Tuyen > --- > engine/scripts/ftc | 8 +++----- > 1 file changed, 3 insertions(+), 5 deletions(-) > > diff --git a/engine/scripts/ftc b/engine/scripts/ftc > index bde3694..44e4da7 100755 > --- a/engine/scripts/ftc > +++ b/engine/scripts/ftc > @@ -1857,11 +1857,6 @@ def gen_text_report(run_list, run_map, > header_fields, fields): > report += " **** %s ****\n" % title > report_date = time.strftime("%Y-%m-%d_%H:%M:%S") > > - if not run_list: > - report += " *** No runs to report, based on requested/filtered > runs ***\n" > - report += ddash_line > - return report > - > for field in header_fields: > if field=="report_date": > val_str = time.strftime("%Y-%m-%d_%H:%M:%S") > @@ -1969,6 +1964,9 @@ def do_gen_report(conf, options): > else: > run_list = run_map.keys() > > + if not run_list: > + error_out ('No runs to report, based on requested/filtered runs') > + This ends up changing the look of report in the "No runs" case. Also, the call to error_out() ends up putting the message on stderr instead of stdout, and causing ftc to return a non-zero exit code. Both of those are bigger changes than I think I'd like. At some point we'll add support for specifying an output file, and viewing the report in the Jenkins interface. We might create jenkins jobs that produce reports automatically after a run. I'm not sure what is better in this case: 1) producing a report that has no data 2) returning an error, and producing no report Let's try it with the error_out() for now, but I reserve the right to switch back to the other method, if it looks like it will suit our intended usage of ftc gen-report better in the future. If we do that, we should have the wording be the same for this "empty report" condition, between different output format types. So the string should probably be shared. But we can make that so if we ever decide to switch back. > run_list.sort() > > fmt="txt" > -- > 2.1.4 This patch is accepted. -- Tim From Tim.Bird at sony.com Tue Feb 27 19:47:27 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Tue, 27 Feb 2018 19:47:27 +0000 Subject: [Fuego] [PATCH 2/2] ftc: gen_report: Add new functions for getting data to, generate the report In-Reply-To: <48ee9177-bd98-d609-5328-b21a6f110e1e@toshiba-tsdv.com> References: <48ee9177-bd98-d609-5328-b21a6f110e1e@toshiba-tsdv.com> Message-ID: comments inline below. > -----Original Message----- > From: Hoang Van Tuyen > > Hello Tim, > > I am working on gen-report feature (support several other format like > html, pdf, ...). > > The attached patch defines two new functions used for generating data > for the report. > > Could you please check it? > > ========================================================== > ================= > > For reusability, the two functions have been defined with purpose like > below: > gen_header_for_report: Get value for fields in the header_fields > (test, board, > report_date, ...). > gen_data_for_report: Get value for fields in the fields variable > (test_name, > spec, timestamp, ...). > > This commit also modifies gen_text_report function to compatible with > defining the two new funtions. > Also, correct some grammar mistakes. > > Signed-off-by: Hoang Van Tuyen > --- > engine/scripts/ftc | 78 > ++++++++++++++++++++++++++++++++---------------------- > 1 file changed, 47 insertions(+), 31 deletions(-) > > diff --git a/engine/scripts/ftc b/engine/scripts/ftc > index 44e4da7..a2f5a78 100755 > --- a/engine/scripts/ftc > +++ b/engine/scripts/ftc > @@ -71,7 +71,7 @@ def pvar(name): > > quiet = 0 > verbose = 0 > -use_statusouput = 1 > +use_statusoutput = 1 Hmmm. This variable assignment was never used by ftc due to this mis-spelling. Note that the global variable is always set to 0 in main() anyway. That also makes this definition superfluous. I'm just going to remove this bogus assignment completely. I could give a long story about why this variable was even introduced, but the logic of its current usage in 'ftc' is a mess. Thanks for bringing this to my attention. > server = jenkins.Jenkins('http://localhost:8080/fuego') > > # keep configuration file in /fuego-ro/conf area > @@ -1745,7 +1745,7 @@ class where_class: > found = False > try: > run_value = run.__dict__[self.field_name] > - found = true > + found = True Wow. This is a pernicious bug that resulted in this try statement ALWAYS raising an exception, resulting in found always being False, and the code ALWAYS, therefore, reading the run.json file, even when the field could have been read from the run object. The logic would all still have worked, but this would have resulted in big slowdowns processing data. Great find! Thanks. It would have been better if the above 2 bugfixes were provided in separate commits. I'm not real strict about this, because so far we haven't done a lot of git bisecting of Fuego bugs. But in the future, please isolate unrelated changes into separate commits (/patches). Thanks. > except: > pass > > @@ -1849,13 +1849,8 @@ def do_list_runs(conf, options): > > sys.exit(0) > > -def gen_text_report(run_list, run_map, header_fields, fields): > - # generate header > - ddash_line="="*70 + "\n" > - report = ddash_line > - title = "Fuego Test Report" > - report += " **** %s ****\n" % title > - report_date = time.strftime("%Y-%m-%d_%H:%M:%S") > +def gen_header_for_report(run_list, run_map, header_fields, fields): > + header_report = "" > > for field in header_fields: > if field=="report_date": > @@ -1875,22 +1870,14 @@ def gen_text_report(run_list, run_map, > header_fields, fields): > else: > for value in value_list[1:]: > val_str += ", "+value > + header_report += " %-20s: %s\n" % (field, val_str) This doesn't quite go far enough isolating the field value gathering from the formatting. This string formatting should be left as an exercise for gen_text_report. I'll fix that in a subsequent commit. > > - line = " %-20s: %s\n" % (field, val_str) > - report += line > - report += ddash_line > + return header_report gen_header_for_report should return a list of tuples (field_name, value_str) for the header. This needs to be refactored a bit, including a name change, IMHO. I'll do that. > > +def gen_data_for_report(run_list, run_map, header_fields, fields): > + data_to_report = [] > # generate list > > - # start with a header line > - dash_line = "-"*(21*len(fields)+2) + "\n" > - report += dash_line > - line = " " > - for field in fields: > - line += "%-20s " % field > - report += line + "\n" > - report += dash_line > - > # now loop over the runs, printing the requested report fields > # if tguid is a field, we'll print a line for each tguid > # otherwise, it's a line per test > @@ -1921,10 +1908,6 @@ def gen_text_report(run_list, run_map, > header_fields, fields): > continue > > # format each column per row (ie per line) > - line = " " > - start_sep = " " > - mid_sep = " " > - end_sep = "" > pos = 0 > for field in fields: > if field=="tguid": > @@ -1937,15 +1920,48 @@ def gen_text_report(run_list, run_map, > header_fields, fields): > tguid_name = "" > value = run.get_field(field, tguid_name) > if pos==0: > - line += "%-20s%s" % (value, start_sep) > + data_to_report.append((value,field)) > else: > - line += "%-20s" % (value) > if pos - line += mid_sep > - else: > - line += end_sep > + data_to_report.append((value,field)) > pos += 1 > - report += line + "\n" > + return data_to_report > + > +def gen_text_report(run_list, run_map, header_fields, fields): > + #get data for report > + header_report = gen_header_for_report(run_list, run_map, > header_fields, fields) > + data_to_report = gen_data_for_report(run_list, run_map, > header_fields, fields) > + > + # generate header > + ddash_line="="*70 + "\n" > + report = ddash_line > + title = "Fuego Test Report" > + report += " **** %s ****\n" % title > + report_date = time.strftime("%Y-%m-%d_%H:%M:%S") > + > + report += header_report > + report += ddash_line > + > + # generate list > + > + # start with a header line > + dash_line = "-"*(21*len(fields)+2) + "\n" > + report += dash_line > + report += " " > + for field in fields: > + report += "%-20s " % field > + report += "\n" + dash_line > + > + # now loop over the runs, printing the requested report fields > + # format each column per row (ie per line) > + for i in range(0,len(data_to_report)): > + if (data_to_report[i][1] == "test_name"): > + report += " %-20s" % (data_to_report[i][0]) > + else: > + if (data_to_report[i][1] == "result"): > + report += " %-20s\n" % (data_to_report[i][0]) > + else: > + report += " %-20s" % (data_to_report[i][0]) > > report += dash_line > > -- > 2.1.4 OK - I don't think this is the final layout of code to implement this feature, but it's a start. I've applied this patch, and will apply a few fixups on top of it to address the issues I raised. Thanks, -- Tim From Tim.Bird at sony.com Wed Feb 28 02:37:44 2018 From: Tim.Bird at sony.com (Tim.Bird at sony.com) Date: Wed, 28 Feb 2018 02:37:44 +0000 Subject: [Fuego] [Bitbucket] Pull request #9: Chart improve (tbird20d/fuego-core) In-Reply-To: References: Message-ID: OK ? it's hard to do list-based patch review, with pull requests like this. I found a couple of things in the pull request I didn't like, but it was easier to apply the whole series, and go back and fix a few minor issues, than to cherry-pick my way through each commit. So that's what I did. Some issues: 1) I didn?t like the conversion of: if value=="PASS": to: if "PASS" in value: I recognize that 'value' has from the result_map has been augmented with an http link, so you can't test for equality any more. However, this is potentially fragile. For example, if a test were named Functional.TEST_PASS or something that included the word "PASS", you would get a false hit here. It's not the end of the world because it's just the cell color, but it's not as robust as the original code. However, I don't have an easy solution for this (except maybe stripping off the '' at the end of the value, and using value.endswith("PASS") instead. Let me know what you think. 2) split_output_per_testcase assumes that test information precedes the line indicating the testcase. I would like the routine to also be able to handle test information that follows the testcase result line. Can you possibly support an optional flag passed into split_output_per_testcase, to allow parsing the results in that manner? e.g. add a new variable 'info_folows_regex', for this case, like so: def split_output_per_testcase (regex_string, measurements, info_follows_regex=0) ? ? Then a call could be made like so: plib.split_output_per_testcase(regex_string, measurements, 1) Overall, my preference is for tests to put informational lines following the test result lines, in their output. But it would be nice for the code to handle either pattern. Let me know what you think. Applied and pushed. -- Tim From: Liu Wenlong [mailto:pullrequests-reply at bitbucket.org] Sent: Monday, February 26, 2018 9:13 PM To: Bird, Timothy Subject: [Bitbucket] Pull request #9: Chart improve (tbird20d/fuego-core) [liuwlfnst] Liu Wenlong created pull request #9: Chart improve ? chart: add log links for each testcase Add log links for the tests which have separated log file, Such as, Functional.LTP in the current Fuego. The separated log link can help us to find the error log easily and help us to compare the test results of different builds. I also added link to "testlog.txt" for those tests who don't have the separated log. Signed-off-by: Liu Wenlong liuwl.fnst at cn.fujitsu.com ? common: add a generic function to split test outputs Functional.LTP can split the test outputs to separated log file for each case. Now, I add some links to those separated log files, which can help user to check the error log for each case quickly, especially for those tests who had heavy logs. Signed-off-by: Liu Wenlong liuwl.fnst at cn.fujitsu.com ? bzip2: add support that we can split the output for each testcase We can use those separated logs as the log link, which can help user to check the log of those failures easily. Signed-off-by: Liu Wenlong liuwl.fnst at cn.fujitsu.com ? curl: add support that we can split the output for each testcase We can use those separated logs as the log link, which can help user to check the log of those failures easily. Signed-off-by: Liu Wenlong liuwl.fnst at cn.fujitsu.com ? jpeg: add support that we can split the output for each testcase We can use those separated logs as the log link, which can help user to check the log of those failures easily. Signed-off-by: Liu Wenlong liuwl.fnst at cn.fujitsu.com ? fuego_check tguid&tables: add support that we can split the output for each testcase This test has multi-testsets and multi-testcases, it also can use the generic function that we added before. We can use those separated logs as the log link, which can help user to check the log of those failures easily. Signed-off-by: Liu Wenlong liuwl.fnst at cn.fujitsu.com ? glibc: add support that we can split the output for each testcase We can use those separated logs as the log link, which can help user to check the log of those failures easily. Signed-off-by: Liu Wenlong liuwl.fnst at cn.fujitsu.com ? tiff: add support that we can split the output for each testcase This test has not been tested yet. The untest reason is that my sdk cannot build Functional.tiff successfully. However, the same code works well for other tests and the Functional.tiff seems to be not special with other jobs, so I just leave it here. Signed-off-by: Liu Wenlong liuwl.fnst at cn.fujitsu.com ? croco: add parser.py and split the output for each testcase Add a parser.py for this test. Signed-off-by: Liu Wenlong liuwl.fnst at cn.fujitsu.com Author Commit Message Date [liuwlfnst]Liu Wenlong bde5fd3 croco: add parser.py and split the output for each testcase 26 Feb 2018 [liuwlfnst]Liu Wenlong e0b370d tiff: add support that we can split the output for each testcase 26 Feb 2018 [liuwlfnst]Liu Wenlong 1e44142 glibc: add support that we can split the output for each testcase 26 Feb 2018 [liuwlfnst]Liu Wenlong 01fb98d fuego_check tguid&tables: add support that we can split the output for each testcase 26 Feb 2018 [liuwlfnst]Liu Wenlong e3659f7 jpeg: add support that we can split the output for each testcase 26 Feb 2018 4 more commits. View this pull request or add a comment by replying to this email. Unsubscribe from pull request emails for this repository. [Bitbucket] -------------- next part -------------- An HTML attachment was scrubbed... URL: