Data immutability

An important aspect of how Cloud Images treats images is that image data is immutable. After the image data has been uploaded and the checksum and location are set, the image data cannot be modified. Thus you are guaranteed that whenever you boot a server from the image with ID da455637-9ff1-43e9-bb81-0f9e5498a913, you will always receive the exact same set of bits (and hence, the exact same operating system kernal and configuration) every time.

Consider this immutablity if you plan to create your own set of custom images. If you create an image and then discover, for example, that it’s missing a security update so important that you don’t want anyone to use the original image, you can’t simply swap out the image data. Instead, you must delete the original image and create a new one.

The new image will be assigned a different UUID. Thus, if you are writing scripts to use an image that contains the SuperOS operating system, it’s a good idea not to use the image UUID in your script. Instead, you should use some custom image property to identify an image as containing the SuperOS operating system, and then program your script to use the filtering abilities of the Cloud Images API to locate the image that you want.

See also

Image properties Data immutability On-demand images Importing and exporting images Scheduled images Creating custom images from servers Creating cloud servers from base images: Default base image configurations Base images life cycle Patching base images

Sharing images: Managing shared images Models of sharing images Planning to share or use shared images Preparing to share images Image-sharing roles Getting support for shared images

Understanding Cloud Images introduces key ideas. To learn how to put these ideas to work, start at Actions for Cloud Images.