All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas Meneghel Rodrigues <lmr@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: Lucas Meneghel Rodrigues <mrodrigu@redhat.com>, kvm@vger.kernel.org
Subject: Re: [PATCH KVM-AUTOTEST 2/2] Convert images to JPEG using PIL instead of an external program
Date: Wed, 12 Aug 2009 10:26:19 -0300	[thread overview]
Message-ID: <1250083579.2921.36.camel@localhost.localdomain> (raw)
In-Reply-To: <4A82BCE6.9050703@redhat.com>

On Wed, 2009-08-12 at 16:00 +0300, Avi Kivity wrote:
> On 08/12/2009 03:44 PM, Lucas Meneghel Rodrigues wrote:
> >> @@ -110,9 +111,8 @@ def barrier_2(vm, words, params, debug_dir, data_scrdump_filename,
> >>               history_scrdump_filename = os.path.join(history_dir,
> >>                       "scrdump-step_%s-%s.jpg" % (current_step_num,
> >>                                                   time.strftime("%Y%m%d-%H%M%S")))
> >> -            kvm_subprocess.run_fg("convert -quality 30 %s %s" %
> >> -                                  (scrdump_filename, history_scrdump_filename),
> >> -                                  logging.debug, "(convert) ", timeout=30)
> >> +            image = PIL.Image.open(scrdump_filename)
> >> +            image.save(history_scrdump_filename, format = 'JPEG', quality = 30)
> >>      
> > Utilities to perform automatic guest installation using step files.
> >
> > Looks great, but since the python imaging library is an external
> > library, we need to handle import failures. We can't guarantee that it
> > will allways be installed, so we just degrade functionality gracefully
> > in the case is not present.

> Why not require it unconditionally?  It's not new and installing it is 
> trivial.

Just general autotest policy I try to follow. For client side testing,
we try to make as few assumptions as possible about the machine where we
are going to run the client, except to have a python install > 2.4 and a
working toolchain (to build C/C++ programs). We try to not rely on
anything but those 2 items. For the autotest server machine it's OK to
depend on external libraries.

I also agree that this is a special case:
 * PIL is almost ubiquitous across linux distributions
 * It comes installed by default in most setups
 * It's not like we are going to test kvm on dramatically old linux
systems

But I prefer to follow the project policy when possible. The reason why
I accepted the original code that Michael wrote to perform the
conversion was graceful degradation of functionality (if you don't have
ImageMagick installed, the test will not abort).

We could handle import failures in a way that supports graceful
degradation and prints a warning message saying that the user don't have
PIL installed, and that the conversion functionality only works when
having PIL installed. What do you think? If you still think it's not
worth the effort of doing this import handling I am going to think a
little bit more, and eventually apply this.




  reply	other threads:[~2009-08-12 13:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-12  9:34 [PATCH KVM-AUTOTEST 0/2] Remove some external command callouts Avi Kivity
2009-08-12  9:34 ` [PATCH KVM-AUTOTEST 1/2] Replace subprocess 'rm *.ppm' by equivalent Python code Avi Kivity
2009-08-12  9:34 ` [PATCH KVM-AUTOTEST 2/2] Convert images to JPEG using PIL instead of an external program Avi Kivity
2009-08-12 12:44   ` Lucas Meneghel Rodrigues
2009-08-12 13:00     ` Avi Kivity
2009-08-12 13:26       ` Lucas Meneghel Rodrigues [this message]
2009-08-12 13:33         ` Avi Kivity
2009-08-12 15:01           ` Lucas Meneghel Rodrigues
2009-08-12 15:05             ` Avi Kivity
     [not found] <1587932675.1809681250071942865.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com>
2009-08-12 10:13 ` Michael Goldish

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1250083579.2921.36.camel@localhost.localdomain \
    --to=lmr@redhat.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mrodrigu@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.