Boot from image (creates a new volume) starts an instance with no image

[Everett Toews]

1. Fire up a DevStack instance from the stable/havana, stable/icehouse, or master branches.
2. Go into Horizon
3. Launch an instance
3.1 Instance Boot Source: Boot from image (creates a new volume)
3.2 Image Name: cirros
3.3 Device size (GB): 1

When the instance finishes booting you’ll see that the instance only has a ‘-‘ in the Image Name column. If you click on the instance you’ll see in the Overview Meta section “Image Name (not found)”.

My understanding of Boot from image (creates a new volume) is that it simply creates a instance and attaches a volume automatically. It’s basically a convenience for the user. Is that right?

Seems the bug is in Nova as the instance was created with the cirros image and Nova isn’t reporting that fact back. The different responses from various clients.

API
    curl .../v2/tenant_id/servers/server_id
    "image": “”
python-novaclient
    nova show server_id
    "Attempt to boot from volume - no image supplied”
Horizon
    "Image Name (not found)"

I suspect Horizon is making some bad calls but Nova shouldn’t be allowing an instance to get into this state.

[Tiago Mello (timello)]

My guess this is a problem in the api.

[Andrew Ruef (awruef)]

This bug prevents jclouds from working with openstack: https://issues.apache.org/jira/browse/JCLOUDS-558

It is preventing me from making any progress in implementing an application using jclouds...

[wingwj (wingwj)]

When an instance boots from a image, its 'image' param seems be equal to '', like boots from a volume/snapshot.

IMO if you don't createVM using original '--image-id' method, Nova will always treat it as a volume-backend instance. So the 'image' will always be '' in the situation.

Is the issue caused by the horizon or other portals use '' to query the image from Glance?

I checked the codes in novaclient, the process is like this:
# if image:
# ...
# else: # Booted from volume
# info['image'] = _("Attempt to boot from volume - no image supplied")

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/98356

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/98356
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=c3191cf0ba5ad3dc2df8da2a2bf5c9d270fde9d9
Submitter: Jenkins
Branch: master

commit c3191cf0ba5ad3dc2df8da2a2bf5c9d270fde9d9
Author: liyingjun <email address hidden>
Date: Tue Jun 24 19:20:50 2014 +0800

    Add missing image to instance booted from volume

    When booting an instance from a volume, the image_ref for
    the instance will be None. And the API do not get the image
    information for the instance also. So when we calling the
    related API, we get "" for instance.image.

    Change-Id: I3c35ab1d7c8bcec551fb5d67d0b44418266b32a4
    Closes-bug: 1317880

[Nikola Đipanov (ndipanov)]

All of this is by design - image field on the instance means that the instance was started with the particular image. If the volume was created from an image at any point, and instance was booted from that volume at a later stage - it may or may not have anything to do with the image, so setting it is wrong and probably breaks a bunch of assumptions Nova code makes about the empty image field for instances booted from volume.

Luckily there is a revert for this commit that was merged by mistake here: https://review.openstack.org/#/c/107875/

[James Lewis (james-fsck)]

Nikola Đipanov,

In #6 you say the issue raised above it by design, however I can't see how this can be... say for example someone wished to install a long running OS on a volume.

They would go to Instances, and attempt to launch an instance selecting "Boot from image (creates new volume)". Select an ISO image and define the volume to attach.

The instance would then fail to boot with the error that the /image/ is not found.

When booting from an image, vs booting from an image and attaching a volume there should be no difference to the handling of the image.... surely the only difference should be creating and attaching a volume in addition to booting from the image.

[James Lewis (james-fsck)]

There seems to be a disconnect between Nova and Horizon here, because what Nikola Đipanov observed to be "by design" in Nova below in comment #6 appears to break functionality in Horizon.

[Julie Pichon (jpichon)]

Unless I'm missing something, this isn't breaking Horizon functionality (the instance launches and works) although it does mean we're showing less information to the user than we'd like. Looking at the JSON reply when calling to the server details though, at this point there doesn't seem to be anything that can be done in Horizon to improve this. The revert mentions an image_ref attribute but it doesn't look like this is returned.

[QuentinHartman (qhartman)]

This seems to also make it impossible to resize instances that are created this way as well. When I try to do that through Horizon, it seems to succeed, but the instance size never changes, and I have the following pair of messages in my nova-conductor.log:

2014-08-05 11:31:32.530 25190 ERROR glanceclient.common.http [-] Request returned failure status.
2014-08-05 11:31:32.530 25190 WARNING nova.compute.utils [req-8c7cdf64-495d-43f6-9b90-778fb5f39ddb eaa8a6534774472791a79d3b02ea3a18 4986c16a1f1b4de598a2e77f21685235] [instance: 48361913-f57f-41c7-b83b-84a779a9cda9] Can't access image : Image could not be found.

Similarly, when trying to resize from the cli:

root@dwd-maas-1:/var/log/nova# nova flavor-list
+--------------------------------------+--------------+-----------+------+-----------+------+-------+-------------+-----------+
| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |
+--------------------------------------+--------------+-----------+------+-----------+------+-------+-------------+-----------+
| 02ed8cd0-84c3-4731-8769-3bf77d752720 | m3.medium | 4096 | 8 | 0 | | 1 | 1.0 | True |
| 17ab5b0c-1839-482b-9998-024163413cb6 | m2.xlarge | 20480 | 16 | 0 | | 2 | 1.0 | True |
| 3df44567-ba32-45e4-b6ca-843b368cb86c | c3.xlarge | 8192 | 16 | 0 | | 4 | 1.0 | True |
| 51fb187f-5ef0-4a2b-bf31-e4fe1a0e971f | m3.large | 8192 | 32 | 0 | | 2 | 1.0 | True |
| 773e7b71-9fb9-4d30-aaa7-3609b14994fa | c3.large | 4096 | 5 | 0 | | 2 | 1.0 | True |
| 7b9b9d29-c724-46af-8d48-b3d9aeb65271 | r3.large | 16384 | 16 | 0 | | 2 | 1.0 | True |
| a200f0e0-ccc7-42d8-8119-84f304e9be61 | c1.medium | 2048 | 8 | 0 | | 2 | 1.0 | True |
| a4cd4480-c19f-4cdc-b2dd-b6cfc32e5bcd | c1.xlarge | 8192 | 16 | 0 | | 8 | 1.0 | True |
| af36a6ff-2215-41ae-9fad-a9871ea788ff | m1.small | 2048 | 5 | 0 | | 1 | 1.0 | True |
| d403462f-786f-40c3-b366-23d49c5827af | m1.xlarge | 16384 | 16 | 0 | | 4 | 1.0 | True |
| d54455f8-e6a7-4b45-9b9d-f149a464e7b4 | m3.2xlarge | 30720 | 100 | 0 | | 8 | 1.0 | True |
| f7844bd1-ad00-4969-9c1e-f0b5f7264090 | m1.tiny | 512 | 5 | 0 | | 1 | 1.0 | True |
+--------------------------------------+--------------+-----------+------+-----------+------+-------+-------------+-----------+
root@dwd-maas-1:/var/log/nova# nova show 48361913-f57f-41c7-b83b-84a779a9cda9 | grep flavor
| flavor | m3.large (51fb187f-5ef0-4a2b-bf31-e4fe1a0e971f) |
root@dwd-maas-1:/var/log/nova# nova resize --poll 48361913-f57f-41c7-b83b-84a779a9cda9 3df44567-ba32-45e4-b6ca-843b368cb86c
Server resizing... 100% complete
Finished
root@dwd-maas-1:/var/log/nova# nova show 48361913-f57f-41c7-b83b-84a779a9cda...

[James Lewis (james-fsck)]

I've attached a short video showing the issue I see in Horizon due to this...

First, Boot from image (creates a new volume) (fails)...

Then, Boot from image (works fine).

Hope this makes it clearer.

[Rob Cresswell (robcresswell-deactivatedaccount)]

This is an interesting one. So because of how Nova handles the response, Horizon doesn't know which image was used, or at least didn't when this code was originally implemented. If you boot from volume and create a new image, Horizon still shows '-' for the image. This isn't "broken" precisely, but it's a slightly poor UX. The Instance Details page also specifically says "Image: None", which doesn't help either.