Re: VCL-122: failed experimental/test reservations
failedtest sounds good A --On March 31, 2009 11:09:15 AM -0400 Josh Thompson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sounds good to me. I can't think of a better term than "failedtest". So, I'd say just go with that. Josh 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-- 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 josh_thomp...@ncsu.edu 919-515-5323 my GPG/PGP key can be found at pgp.mit.edu -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJ0jIcV/LQcNdtPQMRAsZAAJwMsRFtXaEHGw1hL3Hiq4KA9PRinQCeOeRe /0n6iEhDeSqg6oMD1yTizvU= =LsYA -END PGP SIGNATURE- Aaron Peeler OIT Advanced Computing College of Engineering-NCSU 919.513.4571 http://vcl.ncsu.edu
Re: VCL-122: failed experimental/test reservations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sounds good to me. I can't think of a better term than "failedtest". So, I'd say just go with that. Josh 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-- 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 josh_thomp...@ncsu.edu 919-515-5323 my GPG/PGP key can be found at pgp.mit.edu -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJ0jIcV/LQcNdtPQMRAsZAAJwMsRFtXaEHGw1hL3Hiq4KA9PRinQCeOeRe /0n6iEhDeSqg6oMD1yTizvU= =LsYA -END PGP SIGNATURE-
VCL-122: failed experimental/test reservations
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-- group. I'd propose also setting log.ending to something like "failedtest" if a reservation fails under these conditions. Thoughts? Regards, Andy
