Bug 1347447
| Summary: | High Availability to Protect Instances in Red Hat Enterprise Linux OpenStack Platform 7 with cinder boot volumes on cinder.volume.drivers.ibm.storwize_svc.StorwizeSVCDriver and no-shared-storage option - instance in error state | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Andreas Karis <akaris> | ||||
| Component: | openstack-cinder | Assignee: | Eric Harney <eharney> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | nlevinki <nlevinki> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 7.0 (Kilo) | CC: | aludwar, berrange, dasmith, egafford, eglynn, eharney, kchamart, lixqin, sbauza, scohen, sferdjao, sgordon, srevivo, vromanso | ||||
| Target Milestone: | async | Keywords: | ZStream | ||||
| Target Release: | 7.0 (Kilo) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 1371963 1371969 (view as bug list) | Environment: | |||||
| Last Closed: | 2016-11-16 14:52:49 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: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1371963, 1371969 | ||||||
| Attachments: |
|
||||||
|
Description
Andreas Karis
2016-06-16 22:43:28 UTC
Hi, Any news regarding this BZ? Is this a known issue? Thanks, Andreas I'm running into this issue with a customer as well. Customer is doing a suite of nova evacuate tests with the compute HA configured. This issue has been fixed in master branch which will be contained in Newton release. Refer to the fix in https://review.openstack.org/#/c/299673/ Can we get a backport for this? We can backport the fix to community branch theoretically following the community process. But the community requires the backport must match the master commit. The files change a lot from Kilo to Mitaka, even the file name. So it is not recommend to do the backport. You can update the function unmap_vol_from_host in your file cinder/volume/drivers/ibm/storwize_svc/helpers.py according to the fix in https://review.openstack.org/#/c/299673/, just like: def unmap_vol_from_host(self, volume_name, host_name): """Unmap the volume and delete the host if it has no more mappings.""" LOG.debug('enter: unmap_vol_from_host: volume %(volume_name)s from ' 'host %(host_name)s' % {'volume_name': volume_name, 'host_name': host_name}) # Check if the mapping exists resp = self.ssh.lsvdiskhostmap(volume_name) if not len(resp): LOG.warning(_LW('unmap_vol_from_host: No mapping of volume ' '%(vol_name)s to any host found.') % {'vol_name': volume_name}) return found = False if host_name is None: if len(resp) > 1: LOG.warning(_LW('unmap_vol_from_host: Multiple mappings of ' 'volume %(vol_name)s found, no host ' 'specified.') % {'vol_name': volume_name}) return else: host_name = resp[0]['host_name'] found = True else: for h in resp.select('host_name'): if h == host_name: found = True if not found: LOG.warning(_LW('unmap_vol_from_host: No mapping of volume ' '%(vol_name)s to host %(host)s found.') % {'vol_name': volume_name, 'host': host_name}) # We now know that the mapping exists if found: self.ssh.rmvdiskhostmap(host_name, volume_name) # If this host has no more mappings, delete it resp = self.ssh.lshostvdiskmap(host_name) if not len(resp): self.delete_host(host_name) LOG.debug('leave: unmap_vol_from_host: volume %(volume_name)s from ' 'host %(host_name)s' % {'volume_name': volume_name, 'host_name': host_name}) Or you can send us your files under volume/drivers/ibm/storwize_svc/ and we can provide you a private patch. Hello,
Thanks for the info! Just to be clear: the patched version of this function looks like this ...
~~~
def unmap_vol_from_host(self, volume_name, host_name):
"""Unmap the volume and delete the host if it has no more mappings."""
LOG.debug('Enter: unmap_vol_from_host: volume %(volume_name)s from '
'host %(host_name)s.',
{'volume_name': volume_name, 'host_name': host_name})
# Check if the mapping exists
resp = self.ssh.lsvdiskhostmap(volume_name)
if not len(resp):
LOG.warning(_LW('unmap_vol_from_host: No mapping of volume '
'%(vol_name)s to any host found.'),
{'vol_name': volume_name})
return host_name
if host_name is None:
if len(resp) > 1:
LOG.warning(_LW('unmap_vol_from_host: Multiple mappings of '
'volume %(vol_name)s found, no host '
'specified.'), {'vol_name': volume_name})
return
else:
host_name = resp[0]['host_name']
else:
found = False
for h in resp.select('host_name'):
if h == host_name:
found = True
if not found:
LOG.warning(_LW('unmap_vol_from_host: No mapping of volume '
'%(vol_name)s to host %(host)s found.'),
{'vol_name': volume_name, 'host': host_name})
return host_name
# We now know that the mapping exists
self.ssh.rmvdiskhostmap(host_name, volume_name)
LOG.debug('Leave: unmap_vol_from_host: volume %(volume_name)s from '
'host %(host_name)s.',
{'volume_name': volume_name, 'host_name': host_name})
return host_name
~~~
However, as this is not compatible with the code we run, you make a slightly different change (it's the same principle, but you apply it differently):
~~~
[root@overcloud-controller-0 site-packages]# diff cinder/volume/drivers/ibm/storwize_svc/helpers.py.back cinder/volume/drivers/ibm/storwize_svc/helpers.py
337a338
>
351a353
> found = False
359a362
> found = True
361d363
< found = False
371c373,374
< self.ssh.rmvdiskhostmap(host_name, volume_name)
---
> if found:
> self.ssh.rmvdiskhostmap(host_name, volume_name)
~~~
Do I correctly understand?
Thanks!
Yes, you're correct. ok I we just tested this out with the customer, the fix works Thanks, xiaoqin @red hat engineering: we need a backport for this fix - comment 14 - for OSP 7. 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://rhn.redhat.com/errata/RHBA-2016-2030.html |