failedtest sounds good

--On March 31, 2009 11:09:15 AM -0400 Josh Thompson <> wrote:

Hash: SHA1

Sounds good to me.  I can't think of a better term than "failedtest".
So, I'd  say just go with that.


On Tuesday March 31, 2009, Andy Kurth wrote:
This relates to Aaron's work on VCL-122 where he updated the code to not
modify the log table for reload reservations.

There are cases where log.ending may get set to failed even though the
reservation didn't really fail for an end user using a production image.
If a reservation fails and the image revision is not set to production, I
propose not setting log.ending to failed.

I'm guessing a fair amount of failures result from someone saving an
image which has been broken by the changes he/she made.  This may occur
if the image admin is experimenting or testing a new image.  That same
image admin then makes multiple reservations for the broken revision,
increasing the failure count, thus making VCL's reliability % lower than
it is in reality.

I don't think we should simply bypass updating the log table for such
reservations.  It's useful to retain this data.  How about adding a new
value to log.ending for failed experimental reservations.  I can't really
think of a good, short value.  Maybe something like "failedtest"?

Another case where log.ending may get set to failed even though it's
known to be an experimental/test reservation is when an image admin
creates a new image (revision 0) and the image hasn't been assigned to
any groups yet.  We can detect this if an image only belongs to the
newimages-<username>-<userid> group. I'd propose also setting log.ending
to something like "failedtest" if a reservation fails under these



- --
- -------------------------------
Josh Thompson
Systems Programmer
Virtual Computing Lab (VCL)
North Carolina State University

my GPG/PGP key can be found at
Version: GnuPG v1.4.6 (GNU/Linux)


Aaron Peeler
OIT Advanced Computing
College of Engineering-NCSU

Reply via email to