Description of problem: $ cinder create 1 --volume-type encrypted --image 0bad7436-9229-4609-953d-c425af2a2525 --poll Shows “bootable: false” Then immediately running “cinder show <id>” shows “bootable: true”. Version-Release number of selected component (if applicable): OSP13
Hey Rajat, While testing on: python3-cinderclient-5.0.1-0.20200326150227.8fa0882.el8ost.noarch What do we expect to happen, have bootable = true from the get go as soon as volume creation starts? As at the moment we still see bootable false during volume creation: Created a volume (overcloud) [stack@undercloud-0 ~]$ cinder create 1 --image cirros --name BootableTest --poll Use "watch -d -n 5 cinder list" during volume creation: Until volume creation completes I still get Bootable = false | ID | Status | Name | Size | Volume Type | Bootable | df3ec4e4-99db-4c28-ac35-a9f674ac61d0 | downloading | BootableTest | 1 | tripleo | false Once download/volume creation completes we get Bootable = True | ID | Status | Name | Size | Volume Type | Bootable | df3ec4e4-99db-4c28-ac35-a9f674ac61d0 | available | BootableTest | 1 | tripleo | true Sounds exactly like the problem Eric initially reported. Same happens without --poll Either I missed something, else this doesn't look fixed yet. Come to think of it how would we know if bootable = true or false until we finish uploading data into volume? Unless we look at the source image's header/info before we actuality finish downloading data. Then again volume creation process starts by carving out a blank volume (boot=false) only later do we start to download data into that empty volume which then may set bootable=true. Tzach
Hi Tzach, The testing is simple, just issue a create volume command and the output will show bootable=True (also status=available and other fields updated). The basic summary of the bug is, when we use --poll then we wait for the volume creation but doesn't update the volume details (when its created) that are output on the terminal. Ofcourse, we can only tell if bootable is set to false until it actually is set on the API, the problem is just to update the details after it's set and show it user.
(In reply to Tzach Shefi from comment #16) > Created a volume > (overcloud) [stack@undercloud-0 ~]$ cinder create 1 --image cirros --name > BootableTest --poll > > Use "watch -d -n 5 cinder list" during volume creation: > Until volume creation completes I still get Bootable = false This bug is just about what shows up with "cinder create --poll", which was not reporting the right info, and was fixed in the cinderclient shell.
verified on: python3-cinderclient-5.0.1-0.20200326150227.8fa0882.el8ost.noarch Looks fine to verify, see below: First lets show output without --poll: (overcloud) [stack@undercloud-0 ~]$ cinder create 1 --image cirros --name WithoutPoll +--------------------------------+----------------------------------------+ | Property | Value | +--------------------------------+----------------------------------------+ | attachments | [] | | availability_zone | nova | | bootable | false | | consistencygroup_id | None | | created_at | 2020-05-11T04:44:39.000000 | | description | None | | encrypted | False | | id | 97c5020c-a5d8-4660-951e-2849205054c1 | | metadata | {} | | migration_status | None | | multiattach | False | | name | WithoutPoll | | os-vol-host-attr:host | controller-1@tripleo_ceph#tripleo_ceph | | os-vol-mig-status-attr:migstat | None | | os-vol-mig-status-attr:name_id | None | | os-vol-tenant-attr:tenant_id | 101152677ec54621af515153927fdf36 | | replication_status | None | | size | 1 | | snapshot_id | None | | source_volid | None | | status | creating | | updated_at | 2020-05-11T04:44:39.000000 | | user_id | 6c539737db634552a9ae75b21d0d6617 | | volume_type | tripleo | +--------------------------------+----------------------------------------+ As expected boot and status fields are not yet updated, this is expected. After a few seconds once volume creation is complete these get updated. When we recreate the same volume again with --poll, both status and bootable fields are updated as expected during initial creation: (overcloud) [stack@undercloud-0 ~]$ cinder create 1 --image cirros --name WithPoll --poll +--------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Property | Value | +--------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | attachments | [] | | availability_zone | nova | | bootable | true -----------------> Correct | | consistencygroup_id | None | | created_at | 2020-05-11T04:46:39.000000 | | description | None | | encrypted | False | | id | c4ded819-508d-4e10-a918-a73b989ba05c | | links | [{'rel': 'self', 'href': 'http://10.0.0.113:8776/v3/101152677ec54621af515153927fdf36/volumes/c4ded819-508d-4e10-a918-a73b989ba05c'}, {'rel': 'bookmark', 'href': 'http://10.0.0.113:8776/101152677ec54621af515153927fdf36/volumes/c4ded819-508d-4e10-a918-a73b989ba05c'}] | | metadata | {} | | migration_status | None | | multiattach | False | | name | WithPoll | | os-vol-host-attr:host | controller-2@tripleo_ceph#tripleo_ceph | | os-vol-mig-status-attr:migstat | None | | os-vol-mig-status-attr:name_id | None | | os-vol-tenant-attr:tenant_id | 101152677ec54621af515153927fdf36 | | replication_status | None | | size | 1 | | snapshot_id | None | | source_volid | None | | status | available -------------> Correct | | updated_at | 2020-05-11T04:46:44.000000 | | user_id | 6c539737db634552a9ae75b21d0d6617 | | volume_image_metadata | {'signature_verified': 'False', 'owner_specified.openstack.md5': '443b7623e27ecf03dc9e01ee93f67afe', 'owner_specified.openstack.sha256': 'a8dd75ecffd4cdd96072d60c2237b448e0c8b2bc94d57f10fdbc8c481d9005b8', 'owner_specified.openstack.object': 'images/cirros', 'image_id': 'a55fa576-277b-4404-917e-f5d116c11b11', 'image_name': 'cirros', 'checksum': '443b7623e27ecf03dc9e01ee93f67afe', 'container_format': 'bare', 'disk_format': 'qcow2', 'min_disk': '0', 'min_ram': '0', 'size': '12716032'} | | volume_type | tripleo | +--------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ Verified working as excepted. Thanks Eric/Rajat, for clarification on verification step.
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, 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/RHBA-2020:3148