[VCL-862] Tag loaded image when request is reserved, inuse, or modified in any way other than a normal reload

• Type: Improvement
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 2.5
• Component/s: vcld (backend)
• Assignee: Andrew Kurth
• Reporter: Andrew Kurth
• Created: 14/Apr/15 14:50
• Updated: 26/Oct/16 20:35
• Resolved: 14/Jul/16 18:33

Description

It would be beneficial to tag the OS of a loaded computer once a request enters the reserved or inuse states. It would also be beneficial to tag a computer if anything is done to the computer which would not be done for a normal, non-cluster reservation. By tagging, I mean add something withing the computer's OS indicating the state. The easiest way to do this would be to add text to the currentimage.txt file. We currently do this after the OS module's post_load subroutine has run.

The benefits would pertain to security and a consistent user experience. If for some reason, a computer gets put back into the available state that had previously been reserved for a user but not fully sanitized or if the user logged in, the computer should be reloaded before being reserved for another user. This ordinarily wouldn't happen but is possible if one of the vcld processes abruptly dies or if the database is manipulated.

Once a computer is reserved for a user, a line should be added to currentimage.txt. It could simply be a timestamp and the word reserved. If the computer is sanitized due to the user not acknowledging or connecting, the user accounts should be removed. Once completely sanitized, the line should be removed. If for any reason the computer isn't completely sanitized, the line would remain. Future reservation processes would see this and reload the computer.

The same would be true if the user connects. An inuse line would be added to currentimage.txt.

The code should also check if anything alters the computer which would not ordinarily happen for a single-computer reservation such as cluster scripts being run. For example, an image could be a child image for a cluster. A user could make a reservation for the cluster image and something could be applied to the to the child computer. If the user never acknowledges, the child computer wouldn't be reloaded. It could be assigned to another cluster request with different computers for a different user. Inconsistent results could happen if the cluster scripts are run again.