All of lore.kernel.org
 help / color / mirror / Atom feed
* [XTF PATCH v2] xtf-runner: support two modes for getting output
@ 2016-08-11 14:14 Wei Liu
  2016-08-11 16:27 ` Ian Jackson
  0 siblings, 1 reply; 13+ messages in thread
From: Wei Liu @ 2016-08-11 14:14 UTC (permalink / raw)
  To: Xen-devel; +Cc: Wei Liu, Ian Jackson, andrew.cooper3

We need two modes for getting output:

1. Use console directly with newer (>=4.8) Xen
2. Use log files for older Xen

This patch implements both. The default behaviour is to use the console
mode.

Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
v2: delete auto selection mode, squash all patches into one.
---
 xtf-runner | 110 +++++++++++++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 89 insertions(+), 21 deletions(-)

diff --git a/xtf-runner b/xtf-runner
index c063699..1150621 100755
--- a/xtf-runner
+++ b/xtf-runner
@@ -425,30 +425,19 @@ def list_tests(opts):
     for sel in opts.selection:
         print sel
 
+def run_test_console(opts, test):
+    """ Run a specific test via xenconsole"""
 
-def run_test(test):
-    """ Run a specific test """
-
-    cmd = ['xl', 'create', '-p', test.cfg_path()]
-    print "Executing '%s'" % (" ".join(cmd), )
-    rc = subproc_call(cmd)
-    if rc:
-        raise RunnerError("Failed to create VM")
-
-    cmd = ['xl', 'console', test.vm_name()]
+    cmd = ['xl', 'create', '-Fc', test.cfg_path()]
     print "Executing '%s'" % (" ".join(cmd), )
-    console = Popen(cmd, stdout = PIPE)
+    guest = Popen(cmd, stdout = PIPE, stderr = PIPE)
 
-    cmd = ['xl', 'unpause', test.vm_name()]
-    print "Executing '%s'" % (" ".join(cmd), )
-    rc = subproc_call(cmd)
-    if rc:
-        raise RunnerError("Failed to unpause VM")
+    # stdout is console output, stderr is xl output
+    stdout, stderr = guest.communicate()
 
-    stdout, _ = console.communicate()
-
-    if console.returncode:
-        raise RunnerError("Failed to obtain VM console")
+    if guest.returncode:
+        print stderr
+        raise RunnerError("Failed to communicate with guest")
 
     lines = stdout.splitlines()
 
@@ -470,6 +459,52 @@ def run_test(test):
     return "ERROR"
 
 
+def run_test_logfile(opts, test):
+    """ Run a specific test via grepping log file"""
+
+    fn = opts.logfile_dir + (opts.logfile_pattern % test)
+
+    print "Using %s" % fn
+
+    try:
+        logfile = open(fn, "rb")
+    except IOError as e:
+        # Create file if it doesn't exist
+        if e.errno == 2:
+            logfile = open(fn, "ab")
+            logfile.close()
+            logfile = open(fn, "rb")
+        else:
+            raise e
+
+    logfile.seek(0, 2) # Go to end of file
+
+    cmd = ['xl', 'create', '-F', test.cfg_path()]
+    print "Executing '%s'" % (" ".join(cmd), )
+    rc = subproc_call(cmd)
+    if rc:
+        raise RunnerError("Failed to run test")
+
+    lines = logfile.readlines()
+    logfile.close()
+
+    if len(lines) == 0:
+        raise RunnerError("Test output empty")
+
+    print "".join(lines)
+
+    test_result = lines[-1]
+    if not "Test result:" in test_result:
+        return "ERROR"
+
+    for res in all_results:
+
+        if res in test_result:
+            return res
+
+    return "ERROR"
+
+
 def run_tests(opts):
     """ Run tests """
 
@@ -477,12 +512,21 @@ def run_tests(opts):
     if not len(tests):
         raise RunnerError("No tests to run")
 
+    if opts.mode == "console":
+        run_test = run_test_console
+    elif opts.mode == "logfile":
+        print "Using logfile mode, please make sure the log \
+files are not rotated!"
+        run_test = run_test_logfile
+    else:
+        raise RunnerError("Unrecognised mode")
+
     rc = all_results.index('SUCCESS')
     results = []
 
     for test in tests:
 
-        res = run_test(test)
+        res = run_test(opts, test)
         res_idx = all_results.index(res)
         if res_idx > rc:
             rc = res_idx
@@ -519,6 +563,17 @@ def main():
                   "  all tests in the selection, printing a summary of their\n"
                   "  results at the end.\n"
                   "\n"
+                  "  To determine how runner should get output from Xen, use\n"
+                  "  --mode option. The default value is \"console\", which\n"
+                  "  means using xenconsole program to extract output.\n"
+                  "  The other supported value is \"logfile\", which\n"
+                  "  means to get output from log file.\n"
+                  "\n"
+                  "  The \"logfile\" mode requires users to configure\n"
+                  "  xenconsoled to log guest console output. This mode\n"
+                  "  is useful for Xen version < 4.8. Also see --logfile-dir\n"
+                  "  and --logfile-pattern options.\n"
+                  "\n"
                   "Selections:\n"
                   "  A selection is zero or more of any of the following\n"
                   "  parameters: Categories, Environments and Tests.\n"
@@ -596,6 +651,19 @@ def main():
                       dest = "host", help = "Restrict selection to applicable"
                       " tests for the current host",
                       )
+    parser.add_option("-m", "--mode", action = "store",
+                      dest = "mode", default = "console", type = "string",
+                      help = "Instruct how runner gets its output (see below)")
+    parser.add_option("--logfile-dir", action = "store",
+                      dest = "logfile_dir", default = "/var/log/xen/console/",
+                      type = "string",
+                      help = 'Specify the directory to look for console logs, \
+defaults to "/var/log/xen/console/"')
+    parser.add_option("--logfile-pattern", action = "store",
+                      dest = "logfile_pattern", default = "guest-%s.log",
+                      type = "string",
+                      help = 'Specify the log file name pattern, \
+defaults to "guest-%s.log"')
 
     opts, args = parser.parse_args()
     opts.args = args
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

* Re: [XTF PATCH v2] xtf-runner: support two modes for getting output
  2016-08-11 14:14 [XTF PATCH v2] xtf-runner: support two modes for getting output Wei Liu
@ 2016-08-11 16:27 ` Ian Jackson
  2016-08-11 16:50   ` Wei Liu
  0 siblings, 1 reply; 13+ messages in thread
From: Ian Jackson @ 2016-08-11 16:27 UTC (permalink / raw)
  To: Wei Liu; +Cc: Xen-devel, andrew.cooper3

Wei Liu writes ("[XTF PATCH v2] xtf-runner: support two modes for getting output"):
> We need two modes for getting output:
...
> +        logfile = open(fn, "rb")
> +    except IOError as e:
> +        # Create file if it doesn't exist
> +        if e.errno == 2:
> +            logfile = open(fn, "ab")
> +            logfile.close()
> +            logfile = open(fn, "rb")
> +        else:
> +            raise e

This is perverse.  Why not just open it O_CREAT|O_RDONLY ?  If Python
can't do that then unconditionally opening it O_CREAT|O_RDWR would do.

> +    logfile.seek(0, 2) # Go to end of file

Does Python not have SEEK_END somewhere ?

> +    lines = logfile.readlines()
> +    logfile.close()
> +
> +    if len(lines) == 0:
> +        raise RunnerError("Test output empty")

I think you are racing with xenconsoled here.  How do you know that
all the output has arrived ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

* Re: [XTF PATCH v2] xtf-runner: support two modes for getting output
  2016-08-11 16:27 ` Ian Jackson
@ 2016-08-11 16:50   ` Wei Liu
  2016-08-11 17:17     ` Ian Jackson
  0 siblings, 1 reply; 13+ messages in thread
From: Wei Liu @ 2016-08-11 16:50 UTC (permalink / raw)
  To: Ian Jackson; +Cc: Xen-devel, Wei Liu, andrew.cooper3

On Thu, Aug 11, 2016 at 05:27:56PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[XTF PATCH v2] xtf-runner: support two modes for getting output"):
> > We need two modes for getting output:
> ...
> > +        logfile = open(fn, "rb")
> > +    except IOError as e:
> > +        # Create file if it doesn't exist
> > +        if e.errno == 2:
> > +            logfile = open(fn, "ab")
> > +            logfile.close()
> > +            logfile = open(fn, "rb")
> > +        else:
> > +            raise e
> 
> This is perverse.  Why not just open it O_CREAT|O_RDONLY ?  If Python
> can't do that then unconditionally opening it O_CREAT|O_RDWR would do.
> 

The open call doesn't accept O_CREAT|O_RDONLY.

Andy my experiment showed that "rb" doesn't create the file.

> > +    logfile.seek(0, 2) # Go to end of file
> 
> Does Python not have SEEK_END somewhere ?

There is one, but that's in os module.

Python official document is using numeric values directly.

> 
> > +    lines = logfile.readlines()
> > +    logfile.close()
> > +
> > +    if len(lines) == 0:
> > +        raise RunnerError("Test output empty")
> 
> I think you are racing with xenconsoled here.  How do you know that
> all the output has arrived ?
> 

Unfortunately there doesn't seem to be a direct way to synchronise
between the two.

Maybe the best bet is to watch the tty node for it to go away?

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

* Re: [XTF PATCH v2] xtf-runner: support two modes for getting output
  2016-08-11 16:50   ` Wei Liu
@ 2016-08-11 17:17     ` Ian Jackson
  2016-08-11 17:21       ` Andrew Cooper
  2016-08-11 17:51       ` Wei Liu
  0 siblings, 2 replies; 13+ messages in thread
From: Ian Jackson @ 2016-08-11 17:17 UTC (permalink / raw)
  To: Wei Liu; +Cc: Xen-devel, andrew.cooper3

Wei Liu writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting output"):
> On Thu, Aug 11, 2016 at 05:27:56PM +0100, Ian Jackson wrote:
> > This is perverse.  Why not just open it O_CREAT|O_RDONLY ?  If Python
> > can't do that then unconditionally opening it O_CREAT|O_RDWR would do.
> 
> The open call doesn't accept O_CREAT|O_RDONLY.

open("t", O_RDONLY|O_CREAT, 0666)       = 3

But maybe you mean Python's open doesn't.

> Andy my experiment showed that "rb" doesn't create the file.

Yes, it wouldn't.  If you want a fopen mode, "a+" may be of some use.

> > > +    logfile.seek(0, 2) # Go to end of file
> > 
> > Does Python not have SEEK_END somewhere ?
> 
> There is one, but that's in os module.
> Python official document is using numeric values directly.

Seriously?  Fine, whatever.

> > > +    lines = logfile.readlines()
> > > +    logfile.close()
> > > +
> > > +    if len(lines) == 0:
> > > +        raise RunnerError("Test output empty")
> > 
> > I think you are racing with xenconsoled here.  How do you know that
> > all the output has arrived ?
> 
> Unfortunately there doesn't seem to be a direct way to synchronise
> between the two.
> 
> Maybe the best bet is to watch the tty node for it to go away?

Does xenconsole write the remaining output to the logfile before
deleting the tty node from xenstore ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

* Re: [XTF PATCH v2] xtf-runner: support two modes for getting output
  2016-08-11 17:17     ` Ian Jackson
@ 2016-08-11 17:21       ` Andrew Cooper
  2016-08-11 17:23         ` Wei Liu
  2016-08-11 17:51       ` Wei Liu
  1 sibling, 1 reply; 13+ messages in thread
From: Andrew Cooper @ 2016-08-11 17:21 UTC (permalink / raw)
  To: Ian Jackson, Wei Liu; +Cc: Xen-devel

On 11/08/16 18:17, Ian Jackson wrote:
> Wei Liu writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting output"):
>> On Thu, Aug 11, 2016 at 05:27:56PM +0100, Ian Jackson wrote:
>>> This is perverse.  Why not just open it O_CREAT|O_RDONLY ?  If Python
>>> can't do that then unconditionally opening it O_CREAT|O_RDWR would do.
>> The open call doesn't accept O_CREAT|O_RDONLY.
> open("t", O_RDONLY|O_CREAT, 0666)       = 3
>
> But maybe you mean Python's open doesn't.

Use os.open() to get a Posix open, the os.fdopen(fd) to get a Python
file object for the fd.

>
>> Andy my experiment showed that "rb" doesn't create the file.
> Yes, it wouldn't.  If you want a fopen mode, "a+" may be of some use.
>
>>>> +    logfile.seek(0, 2) # Go to end of file
>>> Does Python not have SEEK_END somewhere ?
>> There is one, but that's in os module.
>> Python official document is using numeric values directly.
> Seriously?  Fine, whatever.

os.SEEK_END is the proper way of doing this.  The documentation is
presumably just being lazy.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

* Re: [XTF PATCH v2] xtf-runner: support two modes for getting output
  2016-08-11 17:21       ` Andrew Cooper
@ 2016-08-11 17:23         ` Wei Liu
  0 siblings, 0 replies; 13+ messages in thread
From: Wei Liu @ 2016-08-11 17:23 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: Wei Liu, Ian Jackson, Xen-devel

On Thu, Aug 11, 2016 at 06:21:55PM +0100, Andrew Cooper wrote:
> On 11/08/16 18:17, Ian Jackson wrote:
> > Wei Liu writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting output"):
> >> On Thu, Aug 11, 2016 at 05:27:56PM +0100, Ian Jackson wrote:
> >>> This is perverse.  Why not just open it O_CREAT|O_RDONLY ?  If Python
> >>> can't do that then unconditionally opening it O_CREAT|O_RDWR would do.
> >> The open call doesn't accept O_CREAT|O_RDONLY.
> > open("t", O_RDONLY|O_CREAT, 0666)       = 3
> >
> > But maybe you mean Python's open doesn't.
> 
> Use os.open() to get a Posix open, the os.fdopen(fd) to get a Python
> file object for the fd.
> 
> >
> >> Andy my experiment showed that "rb" doesn't create the file.
> > Yes, it wouldn't.  If you want a fopen mode, "a+" may be of some use.
> >
> >>>> +    logfile.seek(0, 2) # Go to end of file
> >>> Does Python not have SEEK_END somewhere ?
> >> There is one, but that's in os module.
> >> Python official document is using numeric values directly.
> > Seriously?  Fine, whatever.
> 
> os.SEEK_END is the proper way of doing this.  The documentation is
> presumably just being lazy.

Looks like switching to use os module should work better.

Wei.

> 
> ~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

* Re: [XTF PATCH v2] xtf-runner: support two modes for getting output
  2016-08-11 17:17     ` Ian Jackson
  2016-08-11 17:21       ` Andrew Cooper
@ 2016-08-11 17:51       ` Wei Liu
  2016-08-11 17:54         ` Andrew Cooper
  1 sibling, 1 reply; 13+ messages in thread
From: Wei Liu @ 2016-08-11 17:51 UTC (permalink / raw)
  To: Ian Jackson; +Cc: Xen-devel, Wei Liu, andrew.cooper3

On Thu, Aug 11, 2016 at 06:17:31PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting output"):
> > On Thu, Aug 11, 2016 at 05:27:56PM +0100, Ian Jackson wrote:
> > > This is perverse.  Why not just open it O_CREAT|O_RDONLY ?  If Python
> > > can't do that then unconditionally opening it O_CREAT|O_RDWR would do.
> > 
> > The open call doesn't accept O_CREAT|O_RDONLY.
> 
> open("t", O_RDONLY|O_CREAT, 0666)       = 3
> 
> But maybe you mean Python's open doesn't.
> 
> > Andy my experiment showed that "rb" doesn't create the file.
> 
> Yes, it wouldn't.  If you want a fopen mode, "a+" may be of some use.
> 
> > > > +    logfile.seek(0, 2) # Go to end of file
> > > 
> > > Does Python not have SEEK_END somewhere ?
> > 
> > There is one, but that's in os module.
> > Python official document is using numeric values directly.
> 
> Seriously?  Fine, whatever.
> 
> > > > +    lines = logfile.readlines()
> > > > +    logfile.close()
> > > > +
> > > > +    if len(lines) == 0:
> > > > +        raise RunnerError("Test output empty")
> > > 
> > > I think you are racing with xenconsoled here.  How do you know that
> > > all the output has arrived ?
> > 
> > Unfortunately there doesn't seem to be a direct way to synchronise
> > between the two.
> > 
> > Maybe the best bet is to watch the tty node for it to go away?
> 
> Does xenconsole write the remaining output to the logfile before
> deleting the tty node from xenstore ?
> 

Unfortunately no, watching tty node in xenstore won't work.  In fact,
xenconsoled doesn't delete the tty node at all. It's libxl that deletes
it AFAICT.

It is sure that xenconsoled will close the tty before closing the file,
so stat'ing the actual device node won't work either.

I'm pretty out of idea here.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

* Re: [XTF PATCH v2] xtf-runner: support two modes for getting output
  2016-08-11 17:51       ` Wei Liu
@ 2016-08-11 17:54         ` Andrew Cooper
  2016-08-11 18:29           ` Ian Jackson
  0 siblings, 1 reply; 13+ messages in thread
From: Andrew Cooper @ 2016-08-11 17:54 UTC (permalink / raw)
  To: Wei Liu, Ian Jackson; +Cc: Xen-devel

On 11/08/16 18:51, Wei Liu wrote:
> On Thu, Aug 11, 2016 at 06:17:31PM +0100, Ian Jackson wrote:
>> Wei Liu writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting output"):
>>> On Thu, Aug 11, 2016 at 05:27:56PM +0100, Ian Jackson wrote:
>>>> This is perverse.  Why not just open it O_CREAT|O_RDONLY ?  If Python
>>>> can't do that then unconditionally opening it O_CREAT|O_RDWR would do.
>>> The open call doesn't accept O_CREAT|O_RDONLY.
>> open("t", O_RDONLY|O_CREAT, 0666)       = 3
>>
>> But maybe you mean Python's open doesn't.
>>
>>> Andy my experiment showed that "rb" doesn't create the file.
>> Yes, it wouldn't.  If you want a fopen mode, "a+" may be of some use.
>>
>>>>> +    logfile.seek(0, 2) # Go to end of file
>>>> Does Python not have SEEK_END somewhere ?
>>> There is one, but that's in os module.
>>> Python official document is using numeric values directly.
>> Seriously?  Fine, whatever.
>>
>>>>> +    lines = logfile.readlines()
>>>>> +    logfile.close()
>>>>> +
>>>>> +    if len(lines) == 0:
>>>>> +        raise RunnerError("Test output empty")
>>>> I think you are racing with xenconsoled here.  How do you know that
>>>> all the output has arrived ?
>>> Unfortunately there doesn't seem to be a direct way to synchronise
>>> between the two.
>>>
>>> Maybe the best bet is to watch the tty node for it to go away?
>> Does xenconsole write the remaining output to the logfile before
>> deleting the tty node from xenstore ?
>>
> Unfortunately no, watching tty node in xenstore won't work.  In fact,
> xenconsoled doesn't delete the tty node at all. It's libxl that deletes
> it AFAICT.
>
> It is sure that xenconsoled will close the tty before closing the file,
> so stat'ing the actual device node won't work either.
>
> I'm pretty out of idea here.

Because of XTF's behaviour (waiting for xenconsoled to catch up), you
know for certain that once `xl create` has finished, nothing more will
write into the log.

This is a catch 22 situation though, as I specifically want to avoid
that behaviour.  Perhaps it is acceptable in logfile mode, if we can get
`xl console` mode working without the synchronous delay.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

* Re: [XTF PATCH v2] xtf-runner: support two modes for getting output
  2016-08-11 17:54         ` Andrew Cooper
@ 2016-08-11 18:29           ` Ian Jackson
  2016-08-12  9:23             ` Wei Liu
  0 siblings, 1 reply; 13+ messages in thread
From: Ian Jackson @ 2016-08-11 18:29 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: Xen-devel, Wei Liu

Andrew Cooper writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting output"):
> On 11/08/16 18:51, Wei Liu wrote:
> > I'm pretty out of idea here.
> 
> Because of XTF's behaviour (waiting for xenconsoled to catch up), you
> know for certain that once `xl create` has finished, nothing more will
> write into the log.

You're missing the problem, I think.  It's this possible race:

   VM prints last output to ring
                                        xenconsoled wakes up from poll
   VM calls shutdown
             xenstored sends domain death event
             xl receives domain death event
             xl tears down guest, destroying
                 all relevant xenstore nodes
             xl exits
                     xtf-runner opens logfile
                     xtf-runner reads logfile
                     xtf-runner gets eof on logfile

                                       xenconsoled reads data from
                                       ring (which page is now only
                                       owned by xenconsoled)

                                       xenconsoled writes final data
                                       to logfile

Wei: Maybe you could rely on `xl console' not exiting until xenconsole
has written the last data to the logfile ?  You say:

> It is sure that xenconsoled will close the tty before closing the file,
> so stat'ing the actual device node won't work either.

We don't care when xenconsoled closes the logfile.  We care about when
it last calls write() (with a nonempty buffer).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

* Re: [XTF PATCH v2] xtf-runner: support two modes for getting output
  2016-08-11 18:29           ` Ian Jackson
@ 2016-08-12  9:23             ` Wei Liu
  2016-08-12  9:51               ` Ian Jackson
  0 siblings, 1 reply; 13+ messages in thread
From: Wei Liu @ 2016-08-12  9:23 UTC (permalink / raw)
  To: Ian Jackson; +Cc: Andrew Cooper, Wei Liu, Xen-devel

On Thu, Aug 11, 2016 at 07:29:00PM +0100, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting output"):
> > On 11/08/16 18:51, Wei Liu wrote:
> > > I'm pretty out of idea here.
> > 
> > Because of XTF's behaviour (waiting for xenconsoled to catch up), you
> > know for certain that once `xl create` has finished, nothing more will
> > write into the log.
> 
> You're missing the problem, I think.  It's this possible race:
> 
>    VM prints last output to ring
>                                         xenconsoled wakes up from poll
>    VM calls shutdown
>              xenstored sends domain death event
>              xl receives domain death event
>              xl tears down guest, destroying
>                  all relevant xenstore nodes
>              xl exits
>                      xtf-runner opens logfile
>                      xtf-runner reads logfile
>                      xtf-runner gets eof on logfile
> 
>                                        xenconsoled reads data from
>                                        ring (which page is now only
>                                        owned by xenconsoled)
> 
>                                        xenconsoled writes final data
>                                        to logfile
> 
> Wei: Maybe you could rely on `xl console' not exiting until xenconsole
> has written the last data to the logfile ?  You say:
> 
> > It is sure that xenconsoled will close the tty before closing the file,
> > so stat'ing the actual device node won't work either.
> 
> We don't care when xenconsoled closes the logfile.  We care about when
> it last calls write() (with a nonempty buffer).
> 

In logfile mode, no console client is spawned, because it is not
reliable -- that's why we use logfile mode in the first place.

And I would rather just add a bodge (wait 1 or 2 seconds) than to rely
on sophisticated hack.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

* Re: [XTF PATCH v2] xtf-runner: support two modes for getting output
  2016-08-12  9:23             ` Wei Liu
@ 2016-08-12  9:51               ` Ian Jackson
  2016-08-12 13:28                 ` Wei Liu
  2016-08-15 10:58                 ` Wei Liu
  0 siblings, 2 replies; 13+ messages in thread
From: Ian Jackson @ 2016-08-12  9:51 UTC (permalink / raw)
  To: Wei Liu; +Cc: Andrew Cooper, Xen-devel

Wei Liu writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting output"):
> On Thu, Aug 11, 2016 at 07:29:00PM +0100, Ian Jackson wrote:
> > We don't care when xenconsoled closes the logfile.  We care about when
> > it last calls write() (with a nonempty buffer).
> 
> In logfile mode, no console client is spawned, because it is not
> reliable -- that's why we use logfile mode in the first place.
> 
> And I would rather just add a bodge (wait 1 or 2 seconds)

That would increase the duration of each test by that 1 or 2 seconds.
I suppose you could conclude the logfile is complete if it contains
the expected end-of-run message from the vm, and only poll if not.

But, it's worse:

I went to read the xenconsoled source code, and it can handle a domain
death event before finishing reading all of the data out of a domain's
ring.

Maybe this will be mitigated by XTF's printf waiting for the
xenconsoled ring pointer to catch up ?

xenconsoled advances the ring pointer before writing to the logfile,
but (assuming there's no overflow), the write will happen before it
goes back into the event loop, so it won't be lost.

> than to rely on sophisticated hack.

To my mind polling the logfile looking for the final message from the
vm is something of a hack.

But indeed I can't see another way to wait for xenconsoled, than
going behind libxl's back with something like
 * spawn xl create -p -F
 * look for the console tty in xenstore
 * open the console tty
 * unpause
 * wait for the console tty to get eof

This is not a logfile mode at all, of course.  It probably wouldn't be
easily adaptable to other toolstacks (eg XenServer).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

* Re: [XTF PATCH v2] xtf-runner: support two modes for getting output
  2016-08-12  9:51               ` Ian Jackson
@ 2016-08-12 13:28                 ` Wei Liu
  2016-08-15 10:58                 ` Wei Liu
  1 sibling, 0 replies; 13+ messages in thread
From: Wei Liu @ 2016-08-12 13:28 UTC (permalink / raw)
  To: Ian Jackson; +Cc: Andrew Cooper, Wei Liu, Xen-devel

On Fri, Aug 12, 2016 at 10:51:37AM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting output"):
> > On Thu, Aug 11, 2016 at 07:29:00PM +0100, Ian Jackson wrote:
> > > We don't care when xenconsoled closes the logfile.  We care about when
> > > it last calls write() (with a nonempty buffer).
> > 
> > In logfile mode, no console client is spawned, because it is not
> > reliable -- that's why we use logfile mode in the first place.
> > 
> > And I would rather just add a bodge (wait 1 or 2 seconds)
> 
> That would increase the duration of each test by that 1 or 2 seconds.
> I suppose you could conclude the logfile is complete if it contains
> the expected end-of-run message from the vm, and only poll if not.
> 
> But, it's worse:
> 
> I went to read the xenconsoled source code, and it can handle a domain
> death event before finishing reading all of the data out of a domain's
> ring.
> 
> Maybe this will be mitigated by XTF's printf waiting for the
> xenconsoled ring pointer to catch up ?
> 

I think so.

Under normal circumstance (micro VM doesn't crash), we're sure that all
output is consumed by xenconsoled before the VM shuts down itself.

> xenconsoled advances the ring pointer before writing to the logfile,
> but (assuming there's no overflow), the write will happen before it
> goes back into the event loop, so it won't be lost.
> 

Correct.

> > than to rely on sophisticated hack.
> 
> To my mind polling the logfile looking for the final message from the
> vm is something of a hack.
> 
> But indeed I can't see another way to wait for xenconsoled, than
> going behind libxl's back with something like
>  * spawn xl create -p -F
>  * look for the console tty in xenstore
>  * open the console tty
>  * unpause
>  * wait for the console tty to get eof
> 
> This is not a logfile mode at all, of course.  It probably wouldn't be
> easily adaptable to other toolstacks (eg XenServer).
> 

Andrew, what is your opinion?

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

* Re: [XTF PATCH v2] xtf-runner: support two modes for getting output
  2016-08-12  9:51               ` Ian Jackson
  2016-08-12 13:28                 ` Wei Liu
@ 2016-08-15 10:58                 ` Wei Liu
  1 sibling, 0 replies; 13+ messages in thread
From: Wei Liu @ 2016-08-15 10:58 UTC (permalink / raw)
  To: Ian Jackson; +Cc: Andrew Cooper, Wei Liu, Xen-devel

On Fri, Aug 12, 2016 at 10:51:37AM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting output"):
> > On Thu, Aug 11, 2016 at 07:29:00PM +0100, Ian Jackson wrote:
> > > We don't care when xenconsoled closes the logfile.  We care about when
> > > it last calls write() (with a nonempty buffer).
> > 
> > In logfile mode, no console client is spawned, because it is not
> > reliable -- that's why we use logfile mode in the first place.
> > 
> > And I would rather just add a bodge (wait 1 or 2 seconds)
> 
> That would increase the duration of each test by that 1 or 2 seconds.
> I suppose you could conclude the logfile is complete if it contains
> the expected end-of-run message from the vm, and only poll if not.
> 
> But, it's worse:
> 
> I went to read the xenconsoled source code, and it can handle a domain
> death event before finishing reading all of the data out of a domain's
> ring.
> 
> Maybe this will be mitigated by XTF's printf waiting for the
> xenconsoled ring pointer to catch up ?
> 
> xenconsoled advances the ring pointer before writing to the logfile,
> but (assuming there's no overflow), the write will happen before it
> goes back into the event loop, so it won't be lost.
> 
> > than to rely on sophisticated hack.
> 
> To my mind polling the logfile looking for the final message from the
> vm is something of a hack.
> 
> But indeed I can't see another way to wait for xenconsoled, than
> going behind libxl's back with something like
>  * spawn xl create -p -F
>  * look for the console tty in xenstore
>  * open the console tty
>  * unpause
>  * wait for the console tty to get eof
> 
> This is not a logfile mode at all, of course.  It probably wouldn't be
> easily adaptable to other toolstacks (eg XenServer).
> 

It's only empirical, but my experience of running this patch in logfile
mode (a few dozen times) hasn't seen a single error due to missing output.

I can go for the polling mode but with a timeout of 1 second. A bit
hacky, but hopefully should work good enough.

I want to get something working which I can run in osstest. We can go
with something more sophisticated if the above scheme is deemed not
suitable for osstest.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

end of thread, other threads:[~2016-08-15 10:58 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-11 14:14 [XTF PATCH v2] xtf-runner: support two modes for getting output Wei Liu
2016-08-11 16:27 ` Ian Jackson
2016-08-11 16:50   ` Wei Liu
2016-08-11 17:17     ` Ian Jackson
2016-08-11 17:21       ` Andrew Cooper
2016-08-11 17:23         ` Wei Liu
2016-08-11 17:51       ` Wei Liu
2016-08-11 17:54         ` Andrew Cooper
2016-08-11 18:29           ` Ian Jackson
2016-08-12  9:23             ` Wei Liu
2016-08-12  9:51               ` Ian Jackson
2016-08-12 13:28                 ` Wei Liu
2016-08-15 10:58                 ` Wei Liu

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.