If user 'A' creates an image using the *v1* api, and provides a kernel_id or ramdisk_id which does not match the *v2* schema, eg:
$ glance image-create --disk-format raw --container-format bare --name img1 --property kernel_id=1234 --property ramdisk_id=5678 --file /etc/fstab
+-----------------------+--------------------------------------+
| Property | Value |
+-----------------------+--------------------------------------+
| Property 'kernel_id' | 1234 |
| Property 'ramdisk_id' | 5678 |
| checksum | 9cb02fe7fcac26f8a25d6db3109063ae |
| container_format | bare |
| created_at | 2015-07-24T09:28:58.000000 |
| deleted | False |
| deleted_at | None |
| disk_format | raw |
| id | 2c1e856d-ec2a-4080-a25c-9c5ee65f853e |
| is_public | False |
| min_disk | 0 |
| min_ram | 0 |
| name | img1 |
| owner | 411423405e10431fb9c47ac5b2446557 |
| protected | False |
| size | 145 |
| status | active |
| updated_at | 2015-07-24T09:28:58.000000 |
| virtual_size | None |
+-----------------------+--------------------------------------+
Then an admin user who tries to list images can see the following:
$ glance --os-image-api-version 2 image-list
u'5678' does not match u'^([0-9a-fA-F]){8}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){12}$'
Failed validating u'pattern' in schema[u'properties'][u'ramdisk_id']:
{u'description': u'ID of image stored in Glance that should be used as the ramdisk when booting an AMI-style image.',
u'is_base': False,
u'pattern': u'^([0-9a-fA-F]){8}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){12}$',
u'type': [u'null', u'string']}
On instance[u'ramdisk_id']:
u'5678'
If the user deletes the image the admin listing starts to work again.
Note: to reproduce this it may be necessary for user 'A' to upload several images to ensure that an image which breaks the schema is returned first in a batch from the server.
This will effect a regular admin user, or anything which automatically polls glance using v2 in admin context (eg monitoring, metering, billing etc).
This can also affect some non-admin user cases:
* Public images
if someone has the ability to mark an image as public, then they can potentially break image listing via v2 for all users.
* Shared images
if user A has shared image X with user B, then they can potentially break image listing for user B via v2.
For a user to be able to do this v1 and v2 need to be enabled. This is the default glance configuration.
If v1 is currently disabled, but was enabled at some point there may be already existing private images which could be made public/shared.
When listing images, images are returned from the server in batches of, eg, 25.
Currently the v2 client validates the returned image metadata against the image schema for the first image in each batch.
(Originally all images were checked against the schema, but that was found to give poor performance.)
I'm not sure anymore if validating the schema for a subset of images when listing is a good idea.
It can give behaviour such as adding a 'good' image can break image listing if it means that a 'bad' image is now the first in a batch. Basically it can lead to unpredictable behaviour and bugs like this one.
I think removing all schema validation (at least by default) when doing v2 listing may make sense.