yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #96410
[Bug 2122630] [NEW] container_format and disk_format are nullable in the API
Public bug reported:
As of
https://review.opendev.org/c/openstack/glance/+/138183, the container_format and disk_format fields are able to be set to null when creating/updating an image.
Example:
$ curl -s -X POST -H "Content-Type: application/json" -H "X-Auth-Token: $(openstack token issue -c id -f value)" -d '{"name": "test-image", "container_format": null, "disk_format": null}' https://api.example.com:9292/v2/images | jq
{
"name": "test-image",
"disk_format": null,
"container_format": null,
"visibility": "shared",
"size": null,
"virtual_size": null,
"status": "queued",
"checksum": null,
"protected": false,
"min_ram": 0,
"min_disk": 0,
"owner": "b5a3b140bf504334a01e2059fa1076e2",
"os_hidden": false,
"os_hash_algo": null,
"os_hash_value": null,
"id": "8df6b28a-50af-455a-b4b9-4856a7661123",
"created_at": "2025-09-11T09:57:08Z",
"updated_at": "2025-09-11T09:57:08Z",
"tags": [],
"self": "/v2/images/8df6b28a-50af-455a-b4b9-4856a7661123",
"file": "/v2/images/8df6b28a-50af-455a-b4b9-4856a7661123/file",
"schema": "/v2/schemas/image"
}
Thankfully Glance won't allow an image to be uploaded unless those
fields are set correctly, but this demonstrates that in practice these
fields should be treated as *required*. I can't think of any practical
reason why they should be nullable/optional (the client should *always*
specify the format of the image being uploaded), and the change or bug
that made them nullable (https://bugs.launchpad.net/glance/+bug/1398313)
don't provide any justification except for "these fields are optional"
(which I don't believe they should be).
The effects of these attributes being nullable are usually mitigated by
the fact that clients usually explicitly them to 'bare' and 'raw' by
default if they are not specified by the user/caller, but there are
cases where you can run into images in this state without explicitly
creating them.
When creating images from an image-backed instance via Nova's API
(openstack server image create), container_format and disk_format are
not set until the the image upload process starts (the image goes into
'saving' state):
$ openstack server image create --name test-instance-image test-instance-image
+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| checksum | None |
| container_format | None |
| created_at | 2025-09-12T02:51:04Z |
| disk_format | None |
| file | /v2/images/c0804ba2-daa3-4e87-94d6-e7941bfd6f39/file |
| id | c0804ba2-daa3-4e87-94d6-e7941bfd6f39 |
| min_disk | 10 |
| min_ram | 0 |
| name | test-instance-image |
| owner | 4e00c8b237dd4805b2b9e76643f1b2d8 |
| properties | base_image_ref='00000000-0000-0000-0000-000000000000', boot_roles='reader,member,admin', image_type='snapshot', instance_uuid='79e52fe9-4645-4557-aedd-821980f1f2e9', os_hash_algo=, os_hash_value=, os_hidden='False', owner_project_name='openstack', owner_specified.openstack.md5='56730d3091a764d5f8b38feeef0bfcef', owner_specified.openstack.object='images/tempest_cirros-0.3.4-x86_64', owner_specified.openstack.sha256='63c6e014a024dcc20ec66d11ecbd6c36dd609ff3b6dfaa05cf7d4502614a6923', owner_user_name='admin', user_id='9000ad6cd4bc447dbaea17cdc8c6988d' |
| protected | False |
| schema | /v2/schemas/image |
| size | None |
| status | queued |
| tags | |
| updated_at | 2025-09-12T02:51:04Z |
| virtual_size | None |
| visibility | private |
+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
I'm not sure if Nova is explicitly setting these to null or if it just
doesn't explicitly set the values when creating the image, but if we
want to make these attribute non-nullable we'd need to check
compatibility against current and older supported versions of Nova (and
Cinder, since you can also create an image from a volume using its
APIs).
We've also come across cases where images created from processes such as
the above did not complete successfully, leaving invalid images in a
state where they are in 'active' state without container_format or
disk_format specified, or an actual image uploaded to it.
** Affects: glance
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/2122630
Title:
container_format and disk_format are nullable in the API
Status in Glance:
New
Bug description:
As of
https://review.opendev.org/c/openstack/glance/+/138183, the container_format and disk_format fields are able to be set to null when creating/updating an image.
Example:
$ curl -s -X POST -H "Content-Type: application/json" -H "X-Auth-Token: $(openstack token issue -c id -f value)" -d '{"name": "test-image", "container_format": null, "disk_format": null}' https://api.example.com:9292/v2/images | jq
{
"name": "test-image",
"disk_format": null,
"container_format": null,
"visibility": "shared",
"size": null,
"virtual_size": null,
"status": "queued",
"checksum": null,
"protected": false,
"min_ram": 0,
"min_disk": 0,
"owner": "b5a3b140bf504334a01e2059fa1076e2",
"os_hidden": false,
"os_hash_algo": null,
"os_hash_value": null,
"id": "8df6b28a-50af-455a-b4b9-4856a7661123",
"created_at": "2025-09-11T09:57:08Z",
"updated_at": "2025-09-11T09:57:08Z",
"tags": [],
"self": "/v2/images/8df6b28a-50af-455a-b4b9-4856a7661123",
"file": "/v2/images/8df6b28a-50af-455a-b4b9-4856a7661123/file",
"schema": "/v2/schemas/image"
}
Thankfully Glance won't allow an image to be uploaded unless those
fields are set correctly, but this demonstrates that in practice these
fields should be treated as *required*. I can't think of any practical
reason why they should be nullable/optional (the client should
*always* specify the format of the image being uploaded), and the
change or bug that made them nullable
(https://bugs.launchpad.net/glance/+bug/1398313) don't provide any
justification except for "these fields are optional" (which I don't
believe they should be).
The effects of these attributes being nullable are usually mitigated
by the fact that clients usually explicitly them to 'bare' and 'raw'
by default if they are not specified by the user/caller, but there are
cases where you can run into images in this state without explicitly
creating them.
When creating images from an image-backed instance via Nova's API
(openstack server image create), container_format and disk_format are
not set until the the image upload process starts (the image goes into
'saving' state):
$ openstack server image create --name test-instance-image test-instance-image
+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| checksum | None |
| container_format | None |
| created_at | 2025-09-12T02:51:04Z |
| disk_format | None |
| file | /v2/images/c0804ba2-daa3-4e87-94d6-e7941bfd6f39/file |
| id | c0804ba2-daa3-4e87-94d6-e7941bfd6f39 |
| min_disk | 10 |
| min_ram | 0 |
| name | test-instance-image |
| owner | 4e00c8b237dd4805b2b9e76643f1b2d8 |
| properties | base_image_ref='00000000-0000-0000-0000-000000000000', boot_roles='reader,member,admin', image_type='snapshot', instance_uuid='79e52fe9-4645-4557-aedd-821980f1f2e9', os_hash_algo=, os_hash_value=, os_hidden='False', owner_project_name='openstack', owner_specified.openstack.md5='56730d3091a764d5f8b38feeef0bfcef', owner_specified.openstack.object='images/tempest_cirros-0.3.4-x86_64', owner_specified.openstack.sha256='63c6e014a024dcc20ec66d11ecbd6c36dd609ff3b6dfaa05cf7d4502614a6923', owner_user_name='admin', user_id='9000ad6cd4bc447dbaea17cdc8c6988d' |
| protected | False |
| schema | /v2/schemas/image |
| size | None |
| status | queued |
| tags | |
| updated_at | 2025-09-12T02:51:04Z |
| virtual_size | None |
| visibility | private |
+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
I'm not sure if Nova is explicitly setting these to null or if it just
doesn't explicitly set the values when creating the image, but if we
want to make these attribute non-nullable we'd need to check
compatibility against current and older supported versions of Nova
(and Cinder, since you can also create an image from a volume using
its APIs).
We've also come across cases where images created from processes such
as the above did not complete successfully, leaving invalid images in
a state where they are in 'active' state without container_format or
disk_format specified, or an actual image uploaded to it.
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/2122630/+subscriptions