-----BEGIN PGP SIGNED MESSAGE-----
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 conditions.
Virtual Computing Lab (VCL)
North Carolina State University
my GPG/PGP key can be found at pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----