Bug 1594033
| Summary: | cinder does not show bootable flag consistently when when creating a volume w/ --poll | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Eric Harney <eharney> |
| Component: | python-cinderclient | Assignee: | Rajat Dhasmana <rdhasman> |
| Status: | CLOSED ERRATA | QA Contact: | Tzach Shefi <tshefi> |
| Severity: | medium | Docs Contact: | Chuck Copello <ccopello> |
| Priority: | medium | ||
| Version: | 13.0 (Queens) | CC: | abishop, amcleod, apevec, cschwede, eharney, gcharot, gfidente, jschluet, ltoscano, rdhasman, srevivo |
| Target Milestone: | beta | Keywords: | Triaged |
| Target Release: | 16.1 (Train on RHEL 8.2) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | python-cinderclient-5.0.1-0.20200326130221.8fa0882.el8ost | Doc Type: | Bug Fix |
| Doc Text: |
Before this update, the latest volume attributes were not updated during poll, and the volume data was incorrect on the display screen. With this update, volume attributes update correctly during poll and the correct volume data appears on the display screen.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-07-29 07:49:26 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Eric Harney
2018-06-21 22:21:33 UTC
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 |