Remove validation on image_type

[Rick Harris]

Nova's xs-unified-images branch adds a new image_type called 'vhd' (slightly different than 'raw').

While, we could add 'vhd' to the validation, I think it makes more sense to remove the validation entirely. Unlike statuses, which need to be controlled by Glance to remain consistent across installations, image_type is *only* used by the IAAS modules (Nova). Since Nova, et. al. may support different image_types, it makes sense to just blindly store whatever they tell us.

This change would be a stop-gap. Eventually, we'll have container_format and disk_format attributes instead of image type.

[Jay Pipes (jaypipes)]

"Unlike statuses, which need to be controlled by Glance to remain consistent across installations, image_type is *only* used by the IAAS modules (Nova)."

This is not correct. Glance can run entirely without Nova. When run as a stand-alone image registry and delivery service, wouldn't it be a good idea to validate the data going into the registry database?

Removing this constraint just means Glance lets whatever garbage is in the request into the database.

IMHO, a better idea would be to complete the api-image-format blueprint *before* trying to do Nova's xs-unified-images blueprint because the latter is facilitated by the former.

-jay

[Rick Harris (rconradharris)]

> Glance can run entirely without Nova

Agreed, Glance can run entirely without any IAAS service. I guess my point is that `type` is not a field that Glance should enforce since it has no idea what `types` will be supported by any given IAAS service.

Nova started out just supporting kernel, ramdisk and machine. Then we added raw. Now we're adding VHD. Do we need to adjust this validation for every image `type` added, for every IAAS service, for all time?

> Removing this constraint just means Glance lets whatever garbage is in the request into the database.

This is true, but Glance isn't in a position to make this call. It has no idea what `types` the IAAS can support. If Nova2 adds 'vhd2', Glance should happily store that so Nova2 can handle it appropriately.

I think some of the reservations here probably stem from the fact that `type` is a first class attribute. I think there was a tacit assumption that Glance would 'manage` (enforce validation, index, provide queries for) first class attributes and blindly pass-through image-properties. For this reason, perhaps it would be better, when we do get around to implementing container_format and disk_format that we add them as image-properties.

> IMHO, a better idea would be to complete the api-image-format blueprint *before* trying to do Nova's xs-unified-images

I think in an ideal world you're right; however, I committed to xs-unified-images, so in the interest of making good on that promise, I needed to start on xs-unified-images right away.

I suspect there is going to be more discussion on container formats and disk_format (in addition to what we already have said); I didn't what this discussion holding up something xs-unified-images.

The idea with this patch is to propose this as a stop-gap; keep Nova trunk working with Glance trunk, then when we have time allocated to do "container_format/disk_format" TheRightWay, we do so.

[Rick Harris (rconradharris)]

After discussing this with Jay, decided to add 'vhd' to the list of approved image types. We'll leave validation in for now until the image_format bp reworks all of this.