Bug 1485016 - On Giveback after A Share Service that was Shut Down is Brought Back Up, Manila's Access to Shares is Lost
Summary: On Giveback after A Share Service that was Shut Down is Brought Back Up, Mani...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-manila
Version: 11.0 (Ocata)
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: z4
: 11.0 (Ocata)
Assignee: Tom Barron
QA Contact: Dustin Schoenbrun
Don Domingo
URL:
Whiteboard:
Depends On: 1485015
Blocks: 1483160
TreeView+ depends on / blocked
 
Reported: 2017-08-24 20:50 UTC by Tom Barron
Modified: 2018-02-13 16:38 UTC (History)
2 users (show)

Fixed In Version: openstack-manila-4.0.1-2.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1485015
Environment:
Last Closed: 2018-02-13 16:38:01 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Launchpad 1712842 None None None 2017-08-24 21:05:13 UTC
OpenStack gerrit 499105 None None None 2017-09-01 07:48:04 UTC
OpenStack gerrit 499111 None None None 2017-09-01 07:49:13 UTC
Red Hat Product Errata RHBA-2018:0311 normal SHIPPED_LIVE Red Hat OpenStack Platform 11 Bug Fix and Enhancement Advisory 2018-02-14 00:05:57 UTC

Description Tom Barron 2017-08-24 20:50:26 UTC
+++ This bug was initially created as a clone of Bug #1485015 +++

+++ This bug was initially created as a clone of Bug #1483160 +++

Description of problem:
When the Active share service stops and another, passive share service takes over as the active, when the share service that was stopped comes back, the shares that were on the other share service will become unavailable for Manila to control.

Version-Release number of selected component (if applicable):
openstack-manila-3.0.0-8.el7ost.noarch
openstack-manila-ui-2.5.1-9.el7ost.noarch
puppet-manila-9.5.0-1.el7ost.noarch
python-manilaclient-1.11.0-1.el7ost.noarch
python-manila-3.0.0-8.el7ost.noarch
openstack-manila-share-3.0.0-8.el7ost.noarch

How reproducible:
100%

Steps to Reproduce:
1. Use Infrared to deploy an OSP-10z4 deployment with Manila and with at least 2 controller nodes and any number of compute nodes. I used a NetApp backend for the storage.
2. Disable the active Manila Share service. Observe that the service will start on another controller node.
3. Create a share on the new share service.
4. Re-enable the disabled share service and observe that the share that was created is no longer controllable by Manila. 

Actual results:
Manila shares created on the other share service become uncontrollable when the first share service is reactivated.

Expected results:
Disruption of the share service shall not impact Manila shares.

Additional info:
I looked into how Cinder does Volume service HA and they use a hostgroup for all of the volume services so that the "hostname" of the volume service does not change when another volume service takes over the active role. Chances are something similar will need to happen to Manila as well.

Comment 1 Tom Barron 2017-09-08 09:52:11 UTC
puppet-manila patch 499105 has merged

Comment 2 Tom Barron 2017-09-28 11:29:30 UTC
tripleo-heat-templates patch 499111 has merged

Comment 9 errata-xmlrpc 2018-02-13 16:38:01 UTC
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-2018:0311


Note You need to log in before you can comment on or make changes to this bug.