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
- VCL-122: failed experimental/test reservations Andy Kurth
-
