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.



Reply via email to