Description of problem: `openstack server list` returns empty flavor and image when creating a boot from volume instance (overcloud) [stack@undercloud-0-rhosp16 ~]$ openstack server list +--------------------------------------+---------+--------+------------------+-------+--------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+---------+--------+------------------+-------+--------+ | 579b45a9-25b0-4bb7-baa4-8b62a1f76b3b | test-vm | ACTIVE | test=10.254.2.28 | | | +--------------------------------------+---------+--------+------------------+-------+--------+ Version-Release number of selected component (if applicable): [heat-admin@overcloud-controller-0 ~]$ sudo podman ps | grep nova f992b3fd77f0 undercloud-0-rhosp16.ctlplane.localdomain:8787/rhosp-rhel8/openstack-nova-api:16.0-100 kolla_start 3 days ago Up 13 minutes ago nova_api_cron 9bfa064e9e55 undercloud-0-rhosp16.ctlplane.localdomain:8787/rhosp-rhel8/openstack-nova-api:16.0-100 kolla_start 3 days ago Up 13 minutes ago nova_metadata 8235b4b199be undercloud-0-rhosp16.ctlplane.localdomain:8787/rhosp-rhel8/openstack-nova-api:16.0-100 kolla_start 3 days ago Up 13 minutes ago nova_api 0614ca69d3a1 undercloud-0-rhosp16.ctlplane.localdomain:8787/rhosp-rhel8/openstack-nova-novncproxy:16.0-98 kolla_start 3 days ago Up 13 minutes ago nova_vnc_proxy 650ee53235d4 undercloud-0-rhosp16.ctlplane.localdomain:8787/rhosp-rhel8/openstack-nova-scheduler:16.0-98 kolla_start 3 days ago Up 12 minutes ago nova_scheduler 3aaed1b6557c undercloud-0-rhosp16.ctlplane.localdomain:8787/rhosp-rhel8/openstack-nova-conductor:16.0-98 kolla_start 3 days ago Up 11 minutes ago nova_conductor How reproducible: Always Steps to Reproduce: 1. Create a volume from image 2. Create a boot from volume image using the previously created volume 3. Actual results: 2 columns are empty in `openstack server list` Expected results: 2 columns shouldn't be empty. Additional info:
If we create a boot from image instance, the image shows up but not the flavor: ~~~ (overcloud) [stack@undercloud-0-rhosp16 ~]$ openstack server list +--------------------------------------+---------+--------+------------------+------------------------------+--------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+---------+--------+------------------+------------------------------+--------+ | ed55fb47-283a-4392-a9db-5fc42ceca04e | test-vm | ACTIVE | test=10.254.1.11 | cirros-0.4.0-x86_64-disk.img | | +--------------------------------------+---------+--------+------------------+------------------------------+--------+ ~~~ but if we do `openstack server show` , we see both: ~~~ (overcloud) [stack@undercloud-0-rhosp16 ~]$ openstack server show test-vm | egrep "flavor|image" | flavor | disk='1', ephemeral='0', , original_name='m1.micro', ram='256', swap='0', vcpus='1' | | image | cirros-0.4.0-x86_64-disk.img (12471524-1f7e-4fd7-b5ef-fb4dd6f72b8a) | | trusted_image_certificates | None | ~~~
And boot from volume gives that: ~~~ (overcloud) [stack@undercloud-0-rhosp16 cloud]$ openstack server list +--------------------------------------+---------+--------+-------------------+-------+--------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+---------+--------+-------------------+-------+--------+ | 0abad1b9-6e3e-4afd-a82c-062a66db258d | test-vm | ACTIVE | test=10.254.2.165 | | | +--------------------------------------+---------+--------+-------------------+-------+--------+ ~~~ and the server show : ~~~ | (overcloud) [stack@undercloud-0-rhosp16 cloud]$ openstack server show test-vm | egrep "image|flavor|volume" | flavor | disk='1', ephemeral='0', , original_name='m1.micro', ram='256', swap='0', vcpus='1' | | image | | | trusted_image_certificates | None | | volumes_attached | delete_on_termination='True', id='0a3b6003-9cc2-43c4-a283-928a1ad5e9e7' | ~~~
This is not a nova issue, but rather a python-openstackclient issue, so I'm changing the component to python-openstackclient. The issue of the flavor not being shown looks to be a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1801937 and not related to booting from a volume. I have commented on the other rhbz for that. Regarding the empty image field, this is expected and not a bug for an instance booted from a volume. Nova does not store an image_id for instances that are not booted from an image. In the python-openstackclient, this is shown as empty. In the python-novaclient, a different message is shown: "Attempt to boot from volume - no image supplied". You can see this by doing: nova show <server>. Given that this is not a bug, is there a potential ask here to show a message of some sort in the image field for an instance booted from volume? Such as "booted from volume" or something like that? [1] https://github.com/openstack/python-novaclient/blob/1297cdf71b50c60fb06b1ed436ddd285ff1bf75e/novaclient/v2/shell.py#L2569
Doesn't the cinder volume properties have the image it was generated from ? Perhaps there's something we could do in nova / cinder to propagate this information or at least let know the user the Vm is booted from an image with "booted from image" or something. Since we already have another BZ for the flavor part, I guess we can strip that information from this BZ and let it sit in the other one.
No, the cinder volume properties do not store the image it was generated from, as far as I know. You would need to consult with a cinder expert to find out more about that. The user will know a VM was booted from an image (and not a volume) because the image/image_id will be included in the 'server list' and 'server show'. Did you mean having a message similar to the legacy client where it would say "booted from volume" if the VM was booted from a volume, like I asked in comment 4? Are you asking for a change to python-openstackclient to say something like "booted from volume" instead of leaving the field blank for a boot-from-volume VM?
Well yes ... at least customer will be able to grep or whatever in the outputs instead of " " ... Is that something hard to do ?
I doubt it's "hard", but before we can make a change, we need to understand what change you are asking for. In comment 5 you were talking about volume properties and then you suggested "booted from image". We can't say "booted from image" for VMs booted from an image because they already show the image/image_id in the field. So I asked if you instead meant "booted from volume" for VMs booted from a volume. If you want a python-openstackclient change to show "booted from volume" instead of "" for the image field for VMs booted from a volume, then that is something we can propose upstream. Since you have confirmed that is what you want, I can now triage this issue accordingly.
Oh ... it was a typo and I just saw what you meant. it should have been "booted from volume" sorry I missed that so yes ... that's exactly what we need . I do feel like knowing which image that volume was created from would be better for everybody but having a blank field when there're no images is harder to manage imo.
Understood. I looked briefly in the cinder code and I didn't see any tracking of the image_id used to create a volume, so as far as I can tell, it is not possible to make that association in cinder or nova. However, I am not a cinder expert so I recommend you ask someone from the storage DFG if you want to be certain. If the image_id is actually obtainable from a cinder volume, then we can consider showing that instead of showing "booted from volume". The only potential problem I could see with doing that (if it is even possible) is that the user might be led to believe a VM was booted from an image when it is actually backed by a volume.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Release of components for Red Hat OpenStack Platform 17.0 (Wallaby)), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2022:6543