All of lore.kernel.org
 help / color / mirror / Atom feed
* [Fuego] Patch for Functional.check_mounts
@ 2019-11-19  9:54 Kumar T
  2019-11-19 19:39 ` Tim.Bird
  0 siblings, 1 reply; 10+ messages in thread
From: Kumar T @ 2019-11-19  9:54 UTC (permalink / raw)
  To: fuego


[-- Attachment #1.1: Type: text/plain, Size: 271 bytes --]

Hi Tim,

      I am Kumar from HCL Technologies. I am developing test cases for
"Functional.check_mounts" as discussed earlier. Updated the code as per
your review comments.

Please find the attached PATCH and other source files. Please review.

Thanks & Regards,
Kumar.

[-- Attachment #1.2: Type: text/html, Size: 480 bytes --]

[-- Attachment #2: 0001-check_mounts-PATCH-1-1.patch --]
[-- Type: text/x-patch, Size: 3079 bytes --]

From 1ce54041f21a7185e060714d79b595016a6f39e2 Mon Sep 17 00:00:00 2001
From: HCL-BMC <thangavel.k@hcl.com>
Date: Tue, 19 Nov 2019 13:12:36 +0530
Subject: [PATCH] <check_mounts>:[PATCH 1/1]

This PATCH added test cases to check the expected mounts
with system mount points. If any mount point is not matched
test would fail. It has save_baseline spec to save the
system mount points as expected mount points.
---
 tests/Functional.check_mounts/fuego_test.sh | 28 ++++++++++++++++++---
 tests/Functional.check_mounts/spec.json     |  6 ++++-
 tests/Functional.check_mounts/test.yaml     |  4 +--
 3 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/tests/Functional.check_mounts/fuego_test.sh b/tests/Functional.check_mounts/fuego_test.sh
index 7e93f6f..609999b 100755
--- a/tests/Functional.check_mounts/fuego_test.sh
+++ b/tests/Functional.check_mounts/fuego_test.sh
@@ -5,13 +5,35 @@ function test_build {
 }
 
 function test_deploy {
-    put fs_test $BOARD_TESTDIR/fuego.$TESTDIR/
-    put /fuego-rw/boards/rpi3/expected_mounts.txt $BOARD_TESTDIR/fuego.$TESTDIR/
+
+    EXPECTED_FILE=/fuego-rw/boards/$NODE_NAME/expected_mounts.txt
+
+    if [ "$TESTSPEC" = "default" ] ; then
+
+    	if [ -f "${EXPECTED_FILE}" ] ; then
+      	    put "${EXPECTED_FILE}" $BOARD_TESTDIR/fuego.$TESTDIR/ 
+	else
+            abort_job "Please create file ${EXPECTED_FILE} with the list of expected mounts"
+        fi
+
+        put fs_test $BOARD_TESTDIR/fuego.$TESTDIR/
+    fi
+
 }
  
 function test_run {
-    report "cd $BOARD_TESTDIR/fuego.$TESTDIR; \
+
+    DATA_FILE=$LOGDIR/expected_mount_data.txt
+
+    if [ "$TESTSPEC" = "save_baseline" ] ; then
+        mount | awk '{print substr($1, 1, length($1))}'>$DATA_FILE
+	cp $DATA_FILE ${EXPECTED_FILE}
+        log_this "echo \"baseline file: ${EXPECTED_FILE} saved\""
+        return 0
+    else
+        report "cd $BOARD_TESTDIR/fuego.$TESTDIR; \
         ./fs_test"
+    fi
 }
 
 function test_processing {
diff --git a/tests/Functional.check_mounts/spec.json b/tests/Functional.check_mounts/spec.json
index 65eab4d..e3e383f 100644
--- a/tests/Functional.check_mounts/spec.json
+++ b/tests/Functional.check_mounts/spec.json
@@ -1,7 +1,11 @@
 {
     "testName": "Functional.check_mounts",
     "specs": {
-        "default": {}
+        "default": {
+	},
+	"save_baseline": {
+            "save_baseline": "true"
+	}
     }
 }
 
diff --git a/tests/Functional.check_mounts/test.yaml b/tests/Functional.check_mounts/test.yaml
index 57942b5..beaa67c 100644
--- a/tests/Functional.check_mounts/test.yaml
+++ b/tests/Functional.check_mounts/test.yaml
@@ -1,8 +1,8 @@
 fuego_package_version: 1
 name: Functional.check_mounts
 description: |
-    Sample test that runs fs_test. This test
-    comes with specs to check the expected mounts with system's mount.
+    Run fs_test, using an 'expected_mounts.txt' file, in order to verify
+    that the mouned filesystems on the target board are as expected.
 license: MIT
 author: Kumar Thangavel <thangavel.k@hcl.com>
 maintainer: Kumar Thangavel <thangavel.k@hcl.com>
-- 
2.17.1


[-- Attachment #3: fs-test-1.1.tgz --]
[-- Type: application/x-compressed-tar, Size: 2209 bytes --]

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [Fuego] Patch for Functional.check_mounts
  2019-11-19  9:54 [Fuego] Patch for Functional.check_mounts Kumar T
@ 2019-11-19 19:39 ` Tim.Bird
  2019-11-21  9:05   ` Kumar T
  0 siblings, 1 reply; 10+ messages in thread
From: Tim.Bird @ 2019-11-19 19:39 UTC (permalink / raw)
  To: kumar.hcl.ers.epl, fuego



> -----Original Message-----
> From: Kumar T
> 
> Hi Tim,
> 
>       I am Kumar from HCL Technologies. I am developing test cases for
> "Functional.check_mounts" as discussed earlier. Updated the code as per
> your review comments.
> 
> 
> Please find the attached PATCH and other source files. Please review.

The patch you sent consists of edits on top of material that is not upstream
yet.

You need to combine this work with the previous work and submit it
as one patch.  If the previous patch had been accepted upstream,
this patch consisting of changes would be appropriate.  However,
I need to see the entire test as a single patch in order to review it.

Please use an interactive rebase to combine the commits into a single
commit, and then send that patch.  You can see this blog entry:
https://thoughtbot.com/blog/git-interactive-rebase-squash-amend-rewriting-history
for some instructions on how to do a rebase.  See especially the section
"Squash commits together".

Thanks,
 -- Tim






^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Fuego] Patch for Functional.check_mounts
  2019-11-19 19:39 ` Tim.Bird
@ 2019-11-21  9:05   ` Kumar T
  2019-12-02 13:03     ` Tim.Bird
  0 siblings, 1 reply; 10+ messages in thread
From: Kumar T @ 2019-11-21  9:05 UTC (permalink / raw)
  To: Tim.Bird; +Cc: fuego


[-- Attachment #1.1: Type: text/plain, Size: 1269 bytes --]

Hi Tim,

Thanks for your comments.

I have combined the patches as single patch. Please find the attached PATCH
and source files.

Thanks,
Kumar.

On Wed, 20 Nov 2019 at 01:10, <Tim.Bird@sony.com> wrote:

>
>
> > -----Original Message-----
> > From: Kumar T
> >
> > Hi Tim,
> >
> >       I am Kumar from HCL Technologies. I am developing test cases for
> > "Functional.check_mounts" as discussed earlier. Updated the code as per
> > your review comments.
> >
> >
> > Please find the attached PATCH and other source files. Please review.
>
> The patch you sent consists of edits on top of material that is not
> upstream
> yet.
>
> You need to combine this work with the previous work and submit it
> as one patch.  If the previous patch had been accepted upstream,
> this patch consisting of changes would be appropriate.  However,
> I need to see the entire test as a single patch in order to review it.
>
> Please use an interactive rebase to combine the commits into a single
> commit, and then send that patch.  You can see this blog entry:
>
> https://thoughtbot.com/blog/git-interactive-rebase-squash-amend-rewriting-history
> for some instructions on how to do a rebase.  See especially the section
> "Squash commits together".
>
> Thanks,
>  -- Tim
>
>
>
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 1948 bytes --]

[-- Attachment #2: 0001-check_mounts-PATCH-1-1.patch --]
[-- Type: text/x-patch, Size: 6398 bytes --]

From e743b49fe70950a8bd3e799808f531b72d4b9ff0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E2=80=8B?= <​>
Date: Wed, 23 Oct 2019 16:14:17 +0530
Subject: [PATCH] <check_mounts>:[PATCH 1/1]

This PATCH added test cases to check the expected mounts
with system mount points. If any mount point is not matched
test would fail. It has save_baseline spec to save the
system mount points as expected mount points.

Signed-off-by: Kumar Thangavel <thangavel.k@hcl.com>
---
 tests/Functional.check_mounts/fs-test-1.1.tgz | Bin 0 -> 2209 bytes
 tests/Functional.check_mounts/fuego_test.sh   |  41 ++++++++++++++++++
 tests/Functional.check_mounts/spec.json       |  11 +++++
 tests/Functional.check_mounts/test.yaml       |  15 +++++++
 4 files changed, 67 insertions(+)
 create mode 100644 tests/Functional.check_mounts/fs-test-1.1.tgz
 create mode 100755 tests/Functional.check_mounts/fuego_test.sh
 create mode 100644 tests/Functional.check_mounts/spec.json
 create mode 100644 tests/Functional.check_mounts/test.yaml

diff --git a/tests/Functional.check_mounts/fs-test-1.1.tgz b/tests/Functional.check_mounts/fs-test-1.1.tgz
new file mode 100644
index 0000000000000000000000000000000000000000..1f832d3c62f4b21b36c1148313c20841fae9ecdb
GIT binary patch
literal 2209
zcmV;S2wwLeiwFQZDX?7t1MOLRbJ|D}_rK^<bP?YgdwKemDmzX^1`(^4hf9cLbB>D=
zVg%X<jY^N$j?dqHyGIfd7$?~~@1|16RASJ~^snFDqrnO)Aq&DvquQu#{Y|5e<K@v2
zeKuYm)$^a}*lHXc9Ua#94-XD;zR{>3?{C4;-z89fL_uiy09(v+zPj&Q>p$tRa{jl1
z5q+<k&&=cN{%`Czj*nOTzyGp+yan}VmSgSsKlgua@B4-Xd$5QPsDR1mp5fc>6v7#U
z;4TQ+94y;OzXxz*hck!*<^#L+m>IIk(mDbXW|Mn&zCE3VuwQQ+!+^VYIOluZH$t1c
zv_+1>8TU`%w`h)@(r1P{H9j*3UWMt`>Zdm|)2X6NuZf^zo6HT^33OFGVROm+xg7+E
z2zCH7=Ckn~Ont*evC3fii~+a6oEiR<l_BI{pd23a10>+%(6C)pm4FP?+`FUA;S7-i
zZiP37&v5?)j3D5qZIGrDZbozFhC&IUcK{`{6hRaR2~lxZu$nN#0oxUZOqYc9coc$<
z2KQ}~V9L13bfQTjNxH+a=XSz}5QH%U!bRJcg|uau^NDTIClmU4(b%zrS(#uaHZd4S
zA<hRhFKkyPg=*Y~fH@9<*r<R|I+IcCK}Lk)k$uC&VuJh4jL(-<LUUP>?;>M15qfhp
zpJ4h2hDQQK6c%?JenYWka(7~rYQah3NFCRWG5^ejW^v@WJVdEuX~-#F=ImrCm>H<X
zSeQRHB8q?}H*(7PBncJ+H?+|o7=VKBs?ya|jtd0_{kHyI))Y_&aH;j*sV$`iMR|bF
z#WK8C^^5*c2i&2_J^cgp+aUKoz;9}=B`mM}eyJ&g0rWLcyO$kRX_Z0kH9NzW+ItJ<
zNZRY`&`~jp5m)aEo(Y<&AYGeKx{B7kz!~{m?Wp>PGPG5_N3d<gmEls>bhSC`$QoP@
zwaflMK_Oa1*z5PyURy(6N>}OWRpgCxpuEEe7+lDmj$kMcQ4LK<+3a6_(A2jVI$ZQS
zEkzp;%(;Rh%I6&=W{3(lJF?m>Lrd<;Zxun<M<7jXOJsb1p@=DDDfdK<H+8k&BNH|I
zJzc}cGHR^p3+ngkKq-T)sRJ@jTk9hSvMy4P{R9Y-_LLZijKAz7+(pmBfs#qoQsfT8
z4M+~0AdGZB`T6@sO_E+DF$J%JaANc7?Df(VmC4n)iDQqK=R$kVXhy1Gbg?;AK>sc-
znV2j=$o;f-?gW_7k&EfZZ5MMLMR+k`mhCchen;uaT?LA@aPHNJx+oCaOE`;){1gtx
zCR$Qyjk^6|PahF16jQ2^pbDztZ5V?qOK<@gzHi(?V1Hq2F)@Tk1NGkumi)g!E+olQ
zAH~$?k!4|%S?DG}5UibVMu<bjJzcbdt5vw`t4H!(p9%)=u+JG|1jB+V3YRI2MpYr@
zm1}Io3atqlt5LlF4C;s{ygL)6&=pl3>o^u6pBa-!h-p{#dD2=D`ZKpDVt4F>i4hv5
zUFlvb2=(?HwA5%ESrCsi=nXraQ>j4498s@`mq)_5LZU*DUla3!kd{afJ4EB=N32Id
zgv6fZ(Rb9T@3FZ52(x2p6&hjR5mFZ{59ut9n@VYjmZ9hucN22u7Q2TyF<6G}L=@`S
z(;_@Y%n%o;(PE^E0JE(U;l;}BN~vJ?Qcg<j0Y3LjMTI^Pg`^_(>4_x{d@`RfZS|u|
zvg805N>oyQS26fywKLQdTrNDs(!OP}`z_lKV#B3vLST`QDNJV7GnlfF9!tNZZYaYq
zOCG_Kh({JliIG)@a}SYy9!>Eyg}upv8*FuGpb2;5W5RmIvC5^4|7&#I8e<hQUaD*Q
zj7}}UBR^Iv4qY;OvTY@*fBlslnAa6`xmqx-G_KEfKGt_~n`-fyZ^;kK@s3f)VH{_5
zjx*L#)4MBW8BCFRU0!e{|0G*!MM#$CnmWy8w~5bk;Qx)A(r9SY>5-7}G{H@A{1fn*
z3aQcQoLS1ryA&jpwQ0Tz+@`|=mgUrh1*UI%SmTx;P1;ow0zG`Yyeu8XAJrE;K~WEk
z&-S_CdZNr_wJ4z&rSLzrHl+`=!*Y!2;~oD)^;**ye{3OJY2}-W_M8<>gijJOE4jM1
z$ieccWx4by`O-WR`aY3h3o$SNDAv#Fry}NGt;l?uRJ`2<#r@)&$ONlI)pPEZGC!@<
z(On9|oHcU;u@+z+o@GM|qjBjdD1z<`uKpEVLw9AOm{sV<Ofdipg%tB+s4D{<@SSMb
z(UJO69t`3j#!ZPQ8d*da3S-RDPp7eT4-17K*119O5Kf5Pxe=PPr;SZXDVVLZM{J8#
zE5IWwV3y;nCps>2#fxUP0bjhs;&Ru@A+FkhGBvTmLcJA{e%c<FbC0=bb=G&cI&$dT
zu-&-Dh|<f<C`^xbn0Rw>DTDtp0~7eA_Z?ai?+lal`XxPOrz}O|N|3IuQS@RA@E<U4
zKEcj?99H7qz%Ok#%7FhI=1#*IKJD&4?7(ZtUc_RZbD{=<X)0+VLolN&7xG&io26tu
z?J(N9R|UxT^1LR6)pv!{!V1jVs<ezl(k&ed7OaDe$5+k(f~U{I$akrhK1e_M)^jt`
zk-z`%8lM>X`?-01>-V3d<oBP0`oZzx@k_e@KRP(v-2eX*1MB%oda*A_?-XsI_Iqa-
z4U#Tvbh<rDBV_wNS$(L6(=U=lWs09<KMF{N?fYi)0k&U3g~Rq6NirQ~xF?wTbEsGu
z6Z(s@Z>s4JPEheBiSD6e0uUc5S+!c*zE5O%pr^<3#Ka3a$AwBj{KUQ|NDAcj$_y&z
zm(QzADovb#N`>8utGTniT6JoNd+->h_S09geEw^S-0CXT`Q({-eDn9;Mq@Sq4{&*t
j|Np>vkp#d`AIO`r8Jn>go3R<2@!jK3Lgh0d04M+e6E#B`

literal 0
HcmV?d00001

diff --git a/tests/Functional.check_mounts/fuego_test.sh b/tests/Functional.check_mounts/fuego_test.sh
new file mode 100755
index 0000000..609999b
--- /dev/null
+++ b/tests/Functional.check_mounts/fuego_test.sh
@@ -0,0 +1,41 @@
+tarball=fs-test-1.1.tgz
+
+function test_build {
+    make
+}
+
+function test_deploy {
+
+    EXPECTED_FILE=/fuego-rw/boards/$NODE_NAME/expected_mounts.txt
+
+    if [ "$TESTSPEC" = "default" ] ; then
+
+    	if [ -f "${EXPECTED_FILE}" ] ; then
+      	    put "${EXPECTED_FILE}" $BOARD_TESTDIR/fuego.$TESTDIR/ 
+	else
+            abort_job "Please create file ${EXPECTED_FILE} with the list of expected mounts"
+        fi
+
+        put fs_test $BOARD_TESTDIR/fuego.$TESTDIR/
+    fi
+
+}
+ 
+function test_run {
+
+    DATA_FILE=$LOGDIR/expected_mount_data.txt
+
+    if [ "$TESTSPEC" = "save_baseline" ] ; then
+        mount | awk '{print substr($1, 1, length($1))}'>$DATA_FILE
+	cp $DATA_FILE ${EXPECTED_FILE}
+        log_this "echo \"baseline file: ${EXPECTED_FILE} saved\""
+        return 0
+    else
+        report "cd $BOARD_TESTDIR/fuego.$TESTDIR; \
+        ./fs_test"
+    fi
+}
+
+function test_processing {
+    log_compare "$TESTDIR" "0" "FAIL" "n"
+}
diff --git a/tests/Functional.check_mounts/spec.json b/tests/Functional.check_mounts/spec.json
new file mode 100644
index 0000000..e3e383f
--- /dev/null
+++ b/tests/Functional.check_mounts/spec.json
@@ -0,0 +1,11 @@
+{
+    "testName": "Functional.check_mounts",
+    "specs": {
+        "default": {
+	},
+	"save_baseline": {
+            "save_baseline": "true"
+	}
+    }
+}
+
diff --git a/tests/Functional.check_mounts/test.yaml b/tests/Functional.check_mounts/test.yaml
new file mode 100644
index 0000000..beaa67c
--- /dev/null
+++ b/tests/Functional.check_mounts/test.yaml
@@ -0,0 +1,15 @@
+fuego_package_version: 1
+name: Functional.check_mounts
+description: |
+    Run fs_test, using an 'expected_mounts.txt' file, in order to verify
+    that the mouned filesystems on the target board are as expected.
+license: MIT
+author: Kumar Thangavel <thangavel.k@hcl.com>
+maintainer: Kumar Thangavel <thangavel.k@hcl.com>
+version: 1.1
+fuego_release: 1
+type: Functional
+tags: ['example']
+data_files:
+ - fs-test-1.1.tgz
+ - spec.json
-- 
2.17.1


[-- Attachment #3: fs-test-1.1.tgz --]
[-- Type: application/x-compressed-tar, Size: 2209 bytes --]

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [Fuego] Patch for Functional.check_mounts
  2019-11-21  9:05   ` Kumar T
@ 2019-12-02 13:03     ` Tim.Bird
  2019-12-02 13:49       ` Tim.Bird
  0 siblings, 1 reply; 10+ messages in thread
From: Tim.Bird @ 2019-12-02 13:03 UTC (permalink / raw)
  To: kumar.hcl.ers.epl; +Cc: fuego



> -----Original Message-----
> From: Kumar T [mailto:kumar.hcl.ers.epl@gmail.com]
> 
> Hi Tim,
> 
> Thanks for your comments.
> 
> I have combined the patches as single patch. Please find the attached PATCH
> and source files.
> 
> Thanks,
> Kumar.
>

This code has serious problems.

There was no signed-off-by line in the commit message body.  This is required.

The commit still consists of a patch against previously-submitted code.
I don't have the baseline code to apply this against.

In test_run, when generating a baseline expected_mount file, the
commands used are "mount | awk ...", but this is run on the host,
not on the board.  This should be "cmd mount | awk ..."
And the file should be placed in /fuego-rw/boards/$NODE_NAME/expected_mounts.txt

It has the wrong filename ("expected_mounts_data.txt"), and it's placed
in the log directory.

The Makefile in the fs-test tarball has a target of 'hello'.  This is a
copy-paste bug from the hello_world Makefile.  The target should named
'fs_test'.

The README.md file is empty, except for a comment with no value.

The file fs_test.c has a copyright of "2016 Sony Corporation". This
is clearly a copy-paste bug, and is the wrong copyright.

The routine "read_mountdata()" reads lines from /tmp/file.  I don't
understand how this file would have any mount data.

Can you explain why this approach of using the 'mount' command
is preferred over just reading from /proc/mounts?

You use the 'system' command, which requires a shell, and you call
the 'mount and awk' commands.  It would be much preferable to avoid
using awk on the target.  If you must use 'awk', you should
put an "assert_has_program awk" in function test_precheck().

The routine read_compare_expectedmountdata() generates a PASS result
for every mounted filesystem that was found in the expected data file.
And it generates a FAIL for every mounted filesystem that was not
found in the expected data file.  However, (and this is important), it should
also report FAIL for every expected mount that was not found on mounted
on the machine.

This code needs a lot more work.

The variables EXPECTED_ARR_SIZE and MOUNTED_ARR_SIZE
are not used correctly (or are not named correctly).  You use them to make
a 2-dimensional array.

EXPECTED_ARR_SIZE is only 20 bytes.  The line read from mount data may
b much longer than this.  This should probably be converted to use an
an array of allocated strings.

While is line 74 (starting with line_size =') indented to the same level
as the while loop that follows it.

fs_test.c sometimes uses tabs and sometimes uses spaces.  It should one
or the other, consistently.

Some of these mistakes are basic mistakes in C coding.  I'm afraid that
I cannot debug through basic C issues and fix code that is not suitable
for production use.

After considering the issue, I think it would be better to structure the fs_test.c
code as a tool that takes two files and compares them
(kind of like diff, but allowing out-of-order lines).

Instead of hard-coding the filenames, please use 2 filenames that are passed
on the command line.

If 2 lines are substantially similar (e.g. use the same mount point, or mount device
then they should be shown as referencing the same intended mount, but with different options)

I would also like to structure this code so that it does not use a tarball.  It's very difficult to do code
reviews on the C code when they come in a tarfile.  The usual case with Fuego where a tarball is
used is that the upstream code is not under development, but is assumed to be a finished
product that only requires at most a few patches.  This is not the case here, where the C code
is in development.

I plan to add a feature to Fuego to support an unpack operation for "local" files (source files
that are in the test directory - where the fuego_test.sh file resides).  I'd like to use this test
as a test case for that new feature.  I'll let you know the details of when this feature is completed.

This patch has not been applied.
 -- Tim

> 
> On Wed, 20 Nov 2019 at 01:10, <Tim.Bird@sony.com
> <mailto:Tim.Bird@sony.com> > wrote:
> 
> 
> 
> 
> 	> -----Original Message-----
> 	> From: Kumar T
> 	>
> 	> Hi Tim,
> 	>
> 	>       I am Kumar from HCL Technologies. I am developing test cases
> for
> 	> "Functional.check_mounts" as discussed earlier. Updated the code
> as per
> 	> your review comments.
> 	>
> 	>
> 	> Please find the attached PATCH and other source files. Please
> review.
> 
> 	The patch you sent consists of edits on top of material that is not
> upstream
> 	yet.
> 
> 	You need to combine this work with the previous work and submit it
> 	as one patch.  If the previous patch had been accepted upstream,
> 	this patch consisting of changes would be appropriate.  However,
> 	I need to see the entire test as a single patch in order to review it.
> 
> 	Please use an interactive rebase to combine the commits into a single
> 	commit, and then send that patch.  You can see this blog entry:
> 	https://thoughtbot.com/blog/git-interactive-rebase-squash-amend-
> rewriting-history
> 	for some instructions on how to do a rebase.  See especially the
> section
> 	"Squash commits together".
> 
> 	Thanks,
> 	 -- Tim
> 
> 
> 
> 
> 
> 


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Fuego] Patch for Functional.check_mounts
  2019-12-02 13:03     ` Tim.Bird
@ 2019-12-02 13:49       ` Tim.Bird
  2019-12-03 12:43         ` Kumar T
  0 siblings, 1 reply; 10+ messages in thread
From: Tim.Bird @ 2019-12-02 13:49 UTC (permalink / raw)
  To: kumar.hcl.ers.epl; +Cc: fuego



> -----Original Message-----
> From: Tim.Bird@sony.com
> 
> > -----Original Message-----
> > From: Kumar T [mailto:kumar.hcl.ers.epl@gmail.com]
> I plan to add a feature to Fuego to support an unpack operation for "local"
> files (source files
> that are in the test directory - where the fuego_test.sh file resides).  I'd like
> to use this test
> as a test case for that new feature.  I'll let you know the details of when this
> feature is completed.


OK - I have added the feature to Fuego, and checked it into the master branch.

Now, instead of using the 'tarball' variable to specify the compiled code for a test,
you can place the materials to be compiled directly into the test's home directory
(e.g. you can put fs_test.c, the Makefile, and the README.md into
fuego-core/tests/Functional.check_mounts). 

Inside the fuego_test.sh, instead of using a 'tarball=' line, put a line like the
following at the top of the file:
local_source=1

This will cause the internal code in Fuego that unpacks the source into the
build directory to copy the contents of the test's home directory there.
The build will then proceed as usual.

This will allow me to code review the source code for compiled portions
of the test, along with the fuego_test.sh, spec.json, and other Fuego-specific
test materials.

Please try this out, and let me know if you see any problems.
 -- Tim


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Fuego] Patch for Functional.check_mounts
  2019-12-02 13:49       ` Tim.Bird
@ 2019-12-03 12:43         ` Kumar T
  2020-01-09 11:47           ` Kumar T
  0 siblings, 1 reply; 10+ messages in thread
From: Kumar T @ 2019-12-03 12:43 UTC (permalink / raw)
  To: Tim.Bird; +Cc: fuego

[-- Attachment #1: Type: text/plain, Size: 2629 bytes --]

Hi Tim,

Thanks a lot for your time and review comments.

Apologies for the basic mistakes which I have done. I will correct these
kinds of mistakes from upcoming patches.

> After considering the issue, I think it would be better to structure the
fs_test.c
> code as a tool that takes two files and compares them
> (kind of like diff, but allowing out-of-order lines).

> Instead of hard-coding the filenames, please use 2 filenames that are
passed
> on the command line.

   I will structure the fs_test.c code as tool that takes two files as
command line arguments and compares them.
   Will work on those review comments.

> This will cause the internal code in Fuego that unpacks the source into
the
> build directory to copy the contents of the test's home directory there.
> The build will then proceed as usual.

> This will allow me to code review the source code for compiled portions
> of the test, along with the fuego_test.sh, spec.json, and other
Fuego-specific
> test materials.

> Please try this out, and let me know if you see any problems.

  I will check and update you on this.

Thanks,
Kumar.

On Mon, 2 Dec 2019 at 19:19, <Tim.Bird@sony.com> wrote:

>
>
> > -----Original Message-----
> > From: Tim.Bird@sony.com
> >
> > > -----Original Message-----
> > > From: Kumar T [mailto:kumar.hcl.ers.epl@gmail.com]
> > I plan to add a feature to Fuego to support an unpack operation for
> "local"
> > files (source files
> > that are in the test directory - where the fuego_test.sh file resides).
> I'd like
> > to use this test
> > as a test case for that new feature.  I'll let you know the details of
> when this
> > feature is completed.
>
>
> OK - I have added the feature to Fuego, and checked it into the master
> branch.
>
> Now, instead of using the 'tarball' variable to specify the compiled code
> for a test,
> you can place the materials to be compiled directly into the test's home
> directory
> (e.g. you can put fs_test.c, the Makefile, and the README.md into
> fuego-core/tests/Functional.check_mounts).
>
> Inside the fuego_test.sh, instead of using a 'tarball=' line, put a line
> like the
> following at the top of the file:
> local_source=1
>
> This will cause the internal code in Fuego that unpacks the source into the
> build directory to copy the contents of the test's home directory there.
> The build will then proceed as usual.
>
> This will allow me to code review the source code for compiled portions
> of the test, along with the fuego_test.sh, spec.json, and other
> Fuego-specific
> test materials.
>
> Please try this out, and let me know if you see any problems.
>  -- Tim
>
>

[-- Attachment #2: Type: text/html, Size: 3529 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Fuego] Patch for Functional.check_mounts
  2019-12-03 12:43         ` Kumar T
@ 2020-01-09 11:47           ` Kumar T
  2020-01-14  2:29             ` Tim.Bird
  0 siblings, 1 reply; 10+ messages in thread
From: Kumar T @ 2020-01-09 11:47 UTC (permalink / raw)
  To: Tim.Bird; +Cc: fuego


[-- Attachment #1.1: Type: text/plain, Size: 3160 bytes --]

Hi Tim,

         I have restructured the code as per your suggestions. I have taken
one of your patch as reference as created this "check_mounts" test cases
without using C code.  Fixed all the review comments.

        Please find the attached PATCH and other source files.
        Could you please review this patch.

Thanks,
Kumar.




On Tue, 3 Dec 2019 at 18:13, Kumar T <kumar.hcl.ers.epl@gmail.com> wrote:

> Hi Tim,
>
> Thanks a lot for your time and review comments.
>
> Apologies for the basic mistakes which I have done. I will correct these
> kinds of mistakes from upcoming patches.
>
> > After considering the issue, I think it would be better to structure the
> fs_test.c
> > code as a tool that takes two files and compares them
> > (kind of like diff, but allowing out-of-order lines).
>
> > Instead of hard-coding the filenames, please use 2 filenames that are
> passed
> > on the command line.
>
>    I will structure the fs_test.c code as tool that takes two files as
> command line arguments and compares them.
>    Will work on those review comments.
>
> > This will cause the internal code in Fuego that unpacks the source into
> the
> > build directory to copy the contents of the test's home directory there.
> > The build will then proceed as usual.
>
> > This will allow me to code review the source code for compiled portions
> > of the test, along with the fuego_test.sh, spec.json, and other
> Fuego-specific
> > test materials.
>
> > Please try this out, and let me know if you see any problems.
>
>   I will check and update you on this.
>
> Thanks,
> Kumar.
>
> On Mon, 2 Dec 2019 at 19:19, <Tim.Bird@sony.com> wrote:
>
>>
>>
>> > -----Original Message-----
>> > From: Tim.Bird@sony.com
>> >
>> > > -----Original Message-----
>> > > From: Kumar T [mailto:kumar.hcl.ers.epl@gmail.com]
>> > I plan to add a feature to Fuego to support an unpack operation for
>> "local"
>> > files (source files
>> > that are in the test directory - where the fuego_test.sh file
>> resides).  I'd like
>> > to use this test
>> > as a test case for that new feature.  I'll let you know the details of
>> when this
>> > feature is completed.
>>
>>
>> OK - I have added the feature to Fuego, and checked it into the master
>> branch.
>>
>> Now, instead of using the 'tarball' variable to specify the compiled code
>> for a test,
>> you can place the materials to be compiled directly into the test's home
>> directory
>> (e.g. you can put fs_test.c, the Makefile, and the README.md into
>> fuego-core/tests/Functional.check_mounts).
>>
>> Inside the fuego_test.sh, instead of using a 'tarball=' line, put a line
>> like the
>> following at the top of the file:
>> local_source=1
>>
>> This will cause the internal code in Fuego that unpacks the source into
>> the
>> build directory to copy the contents of the test's home directory there.
>> The build will then proceed as usual.
>>
>> This will allow me to code review the source code for compiled portions
>> of the test, along with the fuego_test.sh, spec.json, and other
>> Fuego-specific
>> test materials.
>>
>> Please try this out, and let me know if you see any problems.
>>  -- Tim
>>
>>

[-- Attachment #1.2: Type: text/html, Size: 4477 bytes --]

[-- Attachment #2: 0001-check_mounts-PATCH-1-1.patch --]
[-- Type: text/x-patch, Size: 5501 bytes --]

From dd8285cac45305f80a8d4d24c41e8debaa92c3f0 Mon Sep 17 00:00:00 2001
From: Kumar Thangavel <thangavel.k@hcl.com>
Date: Thu, 9 Jan 2020 16:57:19 +0530
Subject: [PATCH] <check_mounts>:[PATCH 1/1]

This PATCH added test cases to check the expected mounts
with system mount points. If any mount point is not matched
test would fail. It has save_baseline spec to save the
system mount points as expected mount points.

Signed-off-by: Kumar Thangavel <thangavel.k@hcl.com>
---
 tests/Functional.check_mounts/fuego_test.sh | 91 +++++++++++++++------
 tests/Functional.check_mounts/test.yaml     |  5 +-
 2 files changed, 70 insertions(+), 26 deletions(-)

diff --git a/tests/Functional.check_mounts/fuego_test.sh b/tests/Functional.check_mounts/fuego_test.sh
index 609999b..cd6fa62 100755
--- a/tests/Functional.check_mounts/fuego_test.sh
+++ b/tests/Functional.check_mounts/fuego_test.sh
@@ -1,41 +1,86 @@
-tarball=fs-test-1.1.tgz
+# Functional.check_mounts
+#  This test checks to see if the mount points is different from a 
+#  a baseline snapshot taken some time in the past.
+#
+#  The purpose of this test is to do a high-level comparison of the 
+#  mount points of filesystem, to see if anything has changed since
+#  the last baseline snapshot was made.
+#
+# Usage:
+#  preparation:
+#    Create 2 jobs:
+#     $ ftc add-job -b <brd> -t Functional.check_mounts -s default
+#     $ ftc add-job -b <brd> -t Functional.check_mounts -s save_baseline
+#    Save baseline reports
+#      If the filesystem mount points is in a known-good state that reflects "normal"
+#      status for a board,
+#      save the baseline data into a file by running run
+#      the 'save_baseline' job:
+#     $ ftc build-job <brd>.save_baseline.Functional.check_mounts
+#      This will create baseline report files in /fuego-rw/boards/<brd>
+# periodic usage:
+#     Check that the overall reports still match, by running the default job:
+#     $ ftc build-job <board>.default.Functional.check_mounts
+#
 
-function test_build {
-    make
-}
-
-function test_deploy {
+function test_pre_check {
+    # check_mounts dependencies
+    assert_has_program awk
 
-    EXPECTED_FILE=/fuego-rw/boards/$NODE_NAME/expected_mounts.txt
+    export board_rw_dir=$FUEGO_RW/boards/$NODE_NAME
+    export baseline_file=$board_rw_dir/$TESTDIR-baseline-data.txt
 
-    if [ "$TESTSPEC" = "default" ] ; then
+    mkdir -p $board_rw_dir
 
-    	if [ -f "${EXPECTED_FILE}" ] ; then
-      	    put "${EXPECTED_FILE}" $BOARD_TESTDIR/fuego.$TESTDIR/ 
-	else
-            abort_job "Please create file ${EXPECTED_FILE} with the list of expected mounts"
-        fi
+    # check for existence of baseline file
 
-        put fs_test $BOARD_TESTDIR/fuego.$TESTDIR/
+    # but don't check if we're doing the save operation
+    if [ "$TESTSPEC" = "save_baseline" ] ; then
+        return 0
     fi
 
+    if [ ! -f $baseline_file ] ; then
+        echo "Missing baseline results file: $baseline_file1"
+        echo "Maybe try running test with the 'save_baseline' spec?"
+        abort_job "Missing baseline results file"
+    fi
 }
- 
+
 function test_run {
+    echo "Getting mount points"
 
-    DATA_FILE=$LOGDIR/expected_mount_data.txt
+    DATA_FILE=$LOGDIR/mount_points.txt
 
+    # get the mounted points from system
+    cmd "cat /proc/mounts | awk '{print substr($1, 1, length($1))}'" >$DATA_FILE
+    #cat /proc/mounts | awk '{print substr($1, 1, length($1))}' >$DATA_FILE
+    log_this "echo \"Here is the current mounted points :\""
+    log_this "cat $DATA_FILE"
+    echo "--------"
+
+    # if we're doing the "save_baseline" spec, save the data
     if [ "$TESTSPEC" = "save_baseline" ] ; then
-        mount | awk '{print substr($1, 1, length($1))}'>$DATA_FILE
-	cp $DATA_FILE ${EXPECTED_FILE}
-        log_this "echo \"baseline file: ${EXPECTED_FILE} saved\""
+        cp $DATA_FILE $baseline_file
+        log_this "echo \"baseline file: $baseline_file saved\""
+        log_this "echo \"ok 1 compare system mounted points with baseline saved\""
         return 0
-    else
-        report "cd $BOARD_TESTDIR/fuego.$TESTDIR; \
-        ./fs_test"
+    fi
+
+    # check for differences from baseline
+    set +e
+    log_this "echo \"Checking for differences in mount points\""
+    log_this "diff -u $baseline_file $LOGDIR/mount_points.txt"
+    diff_rcode="$?"
+    log_this "echo ------------------------"
+    set -e
+
+    if [ $diff_rcode == "0" ] ; then
+        log_this "echo \"no changes found between current mount points and baseline\""
+	log_this "echo \"ok \""
     fi
 }
 
 function test_processing {
-    log_compare "$TESTDIR" "0" "FAIL" "n"
+    log_compare $TESTDIR 1 "^ok " "p"
 }
+
diff --git a/tests/Functional.check_mounts/test.yaml b/tests/Functional.check_mounts/test.yaml
index beaa67c..b1fc55a 100644
--- a/tests/Functional.check_mounts/test.yaml
+++ b/tests/Functional.check_mounts/test.yaml
@@ -1,8 +1,8 @@
 fuego_package_version: 1
 name: Functional.check_mounts
 description: |
-    Run fs_test, using an 'expected_mounts.txt' file, in order to verify
-    that the mouned filesystems on the target board are as expected.
+    This test checks to see if the mount points is different from a 
+    a baseline snapshot taken some time in the past.
 license: MIT
 author: Kumar Thangavel <thangavel.k@hcl.com>
 maintainer: Kumar Thangavel <thangavel.k@hcl.com>
@@ -11,5 +11,4 @@ fuego_release: 1
 type: Functional
 tags: ['example']
 data_files:
- - fs-test-1.1.tgz
  - spec.json
-- 
2.17.1


[-- Attachment #3: fuego_test.sh --]
[-- Type: application/x-shellscript, Size: 2881 bytes --]

[-- Attachment #4: test.yaml --]
[-- Type: application/x-yaml, Size: 391 bytes --]

[-- Attachment #5: spec.json --]
[-- Type: application/json, Size: 153 bytes --]

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [Fuego] Patch for Functional.check_mounts
  2020-01-09 11:47           ` Kumar T
@ 2020-01-14  2:29             ` Tim.Bird
  2020-01-18  0:12               ` Tim.Bird
  0 siblings, 1 reply; 10+ messages in thread
From: Tim.Bird @ 2020-01-14  2:29 UTC (permalink / raw)
  To: kumar.hcl.ers.epl; +Cc: fuego



> From: Kumar T <kumar.hcl.ers.epl@gmail.com> 
> Subject: Re: [Fuego] Patch for Functional.check_mounts
> 
> Hi Tim,
> 
>        I have restructured the code as per your suggestions. I have taken one of your patch as reference as created this "check_mounts" test cases without using C code.  Fixed all the review comments.
>  
>        Please find the attached PATCH and other source files. 
>        Could you please review this patch. 

I took a look.  I modified a few minor things, but overall the code looks good.
The submission is a bit weird.  You've got a patch against previous materials,
along with all the raw files that comprise the test.  I was able to figure out
where stuff goes and install it myself, but I couldn't use my normal patch
application and review steps.  In the future, patches should be submitted
as patches against pristine upstream code (either from the master branch
or next branch, whichever makes sense).  I think you have part of this 
test already committed in your git tree.  You should move the code to a
pristine upstream source tree, commit it, format the patch from
that commit, and then send that for review.

Because the code is not inline in the email message body, it's hard to review
by quoting specific lines, but I'll put some general notes below.


Here are a few items I saw and just fixed myself:
I modified the code so that the 'awk' command is only run on the host, not on the
target.  Then I removed the assert_has_program awk.

I modified the wording in a few places to refer to 'mounted filesystems'
rather than 'mount points'.  And I changed 'is' to 'are' in a few places.

I had an idea to simplify usage of the test, which is to save a baseline file
instead of abort, if no baseline file is found.  The saved baseline file
would have a warning saying it was autogenerated and should be reviewed
by a human for correctness before being used for testing for regressions.

This would mean that the flow of usage of the test would change:

Currently, the flow is:
 - user creates a save_baseline job and a default job for check_mounts
 - user verifies that filesystem mounts are correct on their system
 - user executes the save_baseline spec of Functional.check_mounts
   - this creates a baseline file
- user periodically executes the default spec of Functional.check_mounts
   - the test succeeds if the mounts are the same as the baseline, and fails otherwise

The new flow would be:
 - user create a default job for check_mounts
 - user executes Functional.check_mounts
   - since no baseline file exists, it creates one with a warning message
   that the data needs to be verified
 - user reviews the baseline data to verify that the mounts are correct
   and removes the warning message from the baseline data
 - user periodically executes Functional.check_mounts
   - test succeeds if the mounts are the same as the baseline, and fails otherwise
   - Note that the test fails with a warning that the baseline data has not
   been verified, if the warning message has not been removed from the baseline data.

This avoid the need for a separate spec (the 'save-baseline' spec) for the test,
but still requires manual intervention in order to make the test succeed.
At some point the user needs to review that the baseline data is correct, before
it can be used to test for regressions.  But now the test (and Fuego) automatically
generate the first draft of the baseline data, when the test is executed the first
time.

Let me know what you think.  

Finally I wanted to test it before committing it, but I'm having problems with
access to my lab today.  I inadvertently wiped out some of my containers and
I'm having to rebuild some things, AND I'm accessing my lab remotely, so things
are a bit complicated today.

I may not finish my testing today, and I'm traveling tomorrow, so unfortunately
I may not be able to commit the code until later this week.  Ping me if you don't
hear back from me in a few days.

Thanks for the submission.
 -- Tim



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Fuego] Patch for Functional.check_mounts
  2020-01-14  2:29             ` Tim.Bird
@ 2020-01-18  0:12               ` Tim.Bird
  2020-01-22  9:04                 ` Kumar T
  0 siblings, 1 reply; 10+ messages in thread
From: Tim.Bird @ 2020-01-18  0:12 UTC (permalink / raw)
  To: kumar.hcl.ers.epl; +Cc: fuego

Kumar,

OK - I accepted your test, and have committed it to the master branch.

I made several additions to the test in subsequent commits, that you
can review in the master branch.

Here are some features I added:
 - Using the 'save_baseline' spec is no longer required.  If the
 baseline data for the mounted filesystems is missing, it will
 automatically be created on the first run of the test.  A user
 can still create a "save_baseline" job, if they want to be able
 to automatically update the baseline data from the Jenkins
 interface (e.g. after some change is made which alters the
 mount points or options, and the user wants to update the
 baseline data
 - I don't filter the mount data down to just the first field
  For things like cgroups, tmpfs, or snaps, this would eliminate
 a lot of data about the mounted filesystem that a user might
 want to verify has not changed.
 - I added the ability to filter the mount data with a regular expression.
 You can now specify a spec which will filter the data to only a specific
  set of filesystems or mount devices, or attributes (anything which shows
 up in the 'mount' line.
 - I use the output from 'mount' rather than /proc/mounts.

Please run the test, and let me know if it works for you as you would like.
Let me know if you see any problems with the test.

I think this is a nice addition to Fuego's test suite.

Thanks and regards,
 -- Tim


> -----Original Message-----
> From: Bird, Tim
> 
> > From: Kumar T <kumar.hcl.ers.epl@gmail.com>
> > Subject: Re: [Fuego] Patch for Functional.check_mounts
> >
> > Hi Tim,
> >
> >        I have restructured the code as per your suggestions. I have taken one of your patch as reference as created this "check_mounts" test
> cases without using C code.  Fixed all the review comments.
> >
> >        Please find the attached PATCH and other source files.
> >        Could you please review this patch.
> 
> I took a look.  I modified a few minor things, but overall the code looks good.
> The submission is a bit weird.  You've got a patch against previous materials,
> along with all the raw files that comprise the test.  I was able to figure out
> where stuff goes and install it myself, but I couldn't use my normal patch
> application and review steps.  In the future, patches should be submitted
> as patches against pristine upstream code (either from the master branch
> or next branch, whichever makes sense).  I think you have part of this
> test already committed in your git tree.  You should move the code to a
> pristine upstream source tree, commit it, format the patch from
> that commit, and then send that for review.
> 
> Because the code is not inline in the email message body, it's hard to review
> by quoting specific lines, but I'll put some general notes below.
> 
> 
> Here are a few items I saw and just fixed myself:
> I modified the code so that the 'awk' command is only run on the host, not on the
> target.  Then I removed the assert_has_program awk.
> 
> I modified the wording in a few places to refer to 'mounted filesystems'
> rather than 'mount points'.  And I changed 'is' to 'are' in a few places.
> 
> I had an idea to simplify usage of the test, which is to save a baseline file
> instead of abort, if no baseline file is found.  The saved baseline file
> would have a warning saying it was autogenerated and should be reviewed
> by a human for correctness before being used for testing for regressions.
> 
> This would mean that the flow of usage of the test would change:
> 
> Currently, the flow is:
>  - user creates a save_baseline job and a default job for check_mounts
>  - user verifies that filesystem mounts are correct on their system
>  - user executes the save_baseline spec of Functional.check_mounts
>    - this creates a baseline file
> - user periodically executes the default spec of Functional.check_mounts
>    - the test succeeds if the mounts are the same as the baseline, and fails otherwise
> 
> The new flow would be:
>  - user create a default job for check_mounts
>  - user executes Functional.check_mounts
>    - since no baseline file exists, it creates one with a warning message
>    that the data needs to be verified
>  - user reviews the baseline data to verify that the mounts are correct
>    and removes the warning message from the baseline data
>  - user periodically executes Functional.check_mounts
>    - test succeeds if the mounts are the same as the baseline, and fails otherwise
>    - Note that the test fails with a warning that the baseline data has not
>    been verified, if the warning message has not been removed from the baseline data.
> 
> This avoid the need for a separate spec (the 'save-baseline' spec) for the test,
> but still requires manual intervention in order to make the test succeed.
> At some point the user needs to review that the baseline data is correct, before
> it can be used to test for regressions.  But now the test (and Fuego) automatically
> generate the first draft of the baseline data, when the test is executed the first
> time.
> 
> Let me know what you think.
> 
> Finally I wanted to test it before committing it, but I'm having problems with
> access to my lab today.  I inadvertently wiped out some of my containers and
> I'm having to rebuild some things, AND I'm accessing my lab remotely, so things
> are a bit complicated today.
> 
> I may not finish my testing today, and I'm traveling tomorrow, so unfortunately
> I may not be able to commit the code until later this week.  Ping me if you don't
> hear back from me in a few days.
> 
> Thanks for the submission.
>  -- Tim
> 


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Fuego] Patch for Functional.check_mounts
  2020-01-18  0:12               ` Tim.Bird
@ 2020-01-22  9:04                 ` Kumar T
  0 siblings, 0 replies; 10+ messages in thread
From: Kumar T @ 2020-01-22  9:04 UTC (permalink / raw)
  To: Tim.Bird; +Cc: fuego

[-- Attachment #1: Type: text/plain, Size: 6078 bytes --]

Thanks a lot Tim.

I have run the test, it is working as expected.
Apologies for the delay due to personal reasons.

Thanks,
Kumar.




On Sat, 18 Jan 2020 at 05:42, <Tim.Bird@sony.com> wrote:

> Kumar,
>
> OK - I accepted your test, and have committed it to the master branch.
>
> I made several additions to the test in subsequent commits, that you
> can review in the master branch.
>
> Here are some features I added:
>  - Using the 'save_baseline' spec is no longer required.  If the
>  baseline data for the mounted filesystems is missing, it will
>  automatically be created on the first run of the test.  A user
>  can still create a "save_baseline" job, if they want to be able
>  to automatically update the baseline data from the Jenkins
>  interface (e.g. after some change is made which alters the
>  mount points or options, and the user wants to update the
>  baseline data
>  - I don't filter the mount data down to just the first field
>   For things like cgroups, tmpfs, or snaps, this would eliminate
>  a lot of data about the mounted filesystem that a user might
>  want to verify has not changed.
>  - I added the ability to filter the mount data with a regular expression.
>  You can now specify a spec which will filter the data to only a specific
>   set of filesystems or mount devices, or attributes (anything which shows
>  up in the 'mount' line.
>  - I use the output from 'mount' rather than /proc/mounts.
>
> Please run the test, and let me know if it works for you as you would like.
> Let me know if you see any problems with the test.
>
> I think this is a nice addition to Fuego's test suite.
>
> Thanks and regards,
>  -- Tim
>
>
> > -----Original Message-----
> > From: Bird, Tim
> >
> > > From: Kumar T <kumar.hcl.ers.epl@gmail.com>
> > > Subject: Re: [Fuego] Patch for Functional.check_mounts
> > >
> > > Hi Tim,
> > >
> > >        I have restructured the code as per your suggestions. I have
> taken one of your patch as reference as created this "check_mounts" test
> > cases without using C code.  Fixed all the review comments.
> > >
> > >        Please find the attached PATCH and other source files.
> > >        Could you please review this patch.
> >
> > I took a look.  I modified a few minor things, but overall the code
> looks good.
> > The submission is a bit weird.  You've got a patch against previous
> materials,
> > along with all the raw files that comprise the test.  I was able to
> figure out
> > where stuff goes and install it myself, but I couldn't use my normal
> patch
> > application and review steps.  In the future, patches should be submitted
> > as patches against pristine upstream code (either from the master branch
> > or next branch, whichever makes sense).  I think you have part of this
> > test already committed in your git tree.  You should move the code to a
> > pristine upstream source tree, commit it, format the patch from
> > that commit, and then send that for review.
> >
> > Because the code is not inline in the email message body, it's hard to
> review
> > by quoting specific lines, but I'll put some general notes below.
> >
> >
> > Here are a few items I saw and just fixed myself:
> > I modified the code so that the 'awk' command is only run on the host,
> not on the
> > target.  Then I removed the assert_has_program awk.
> >
> > I modified the wording in a few places to refer to 'mounted filesystems'
> > rather than 'mount points'.  And I changed 'is' to 'are' in a few places.
> >
> > I had an idea to simplify usage of the test, which is to save a baseline
> file
> > instead of abort, if no baseline file is found.  The saved baseline file
> > would have a warning saying it was autogenerated and should be reviewed
> > by a human for correctness before being used for testing for regressions.
> >
> > This would mean that the flow of usage of the test would change:
> >
> > Currently, the flow is:
> >  - user creates a save_baseline job and a default job for check_mounts
> >  - user verifies that filesystem mounts are correct on their system
> >  - user executes the save_baseline spec of Functional.check_mounts
> >    - this creates a baseline file
> > - user periodically executes the default spec of Functional.check_mounts
> >    - the test succeeds if the mounts are the same as the baseline, and
> fails otherwise
> >
> > The new flow would be:
> >  - user create a default job for check_mounts
> >  - user executes Functional.check_mounts
> >    - since no baseline file exists, it creates one with a warning message
> >    that the data needs to be verified
> >  - user reviews the baseline data to verify that the mounts are correct
> >    and removes the warning message from the baseline data
> >  - user periodically executes Functional.check_mounts
> >    - test succeeds if the mounts are the same as the baseline, and fails
> otherwise
> >    - Note that the test fails with a warning that the baseline data has
> not
> >    been verified, if the warning message has not been removed from the
> baseline data.
> >
> > This avoid the need for a separate spec (the 'save-baseline' spec) for
> the test,
> > but still requires manual intervention in order to make the test succeed.
> > At some point the user needs to review that the baseline data is
> correct, before
> > it can be used to test for regressions.  But now the test (and Fuego)
> automatically
> > generate the first draft of the baseline data, when the test is executed
> the first
> > time.
> >
> > Let me know what you think.
> >
> > Finally I wanted to test it before committing it, but I'm having
> problems with
> > access to my lab today.  I inadvertently wiped out some of my containers
> and
> > I'm having to rebuild some things, AND I'm accessing my lab remotely, so
> things
> > are a bit complicated today.
> >
> > I may not finish my testing today, and I'm traveling tomorrow, so
> unfortunately
> > I may not be able to commit the code until later this week.  Ping me if
> you don't
> > hear back from me in a few days.
> >
> > Thanks for the submission.
> >  -- Tim
> >
>
>

[-- Attachment #2: Type: text/html, Size: 7384 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2020-01-22  9:04 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-19  9:54 [Fuego] Patch for Functional.check_mounts Kumar T
2019-11-19 19:39 ` Tim.Bird
2019-11-21  9:05   ` Kumar T
2019-12-02 13:03     ` Tim.Bird
2019-12-02 13:49       ` Tim.Bird
2019-12-03 12:43         ` Kumar T
2020-01-09 11:47           ` Kumar T
2020-01-14  2:29             ` Tim.Bird
2020-01-18  0:12               ` Tim.Bird
2020-01-22  9:04                 ` Kumar T

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.