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 conditions.
> Thoughts?
> Regards,
> Andy

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


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


Reply via email to