manila-share sometimes fails to be restarted

Bug #1706699 reported by Alex Kavanagh
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Manila Charm
Triaged
Low
Unassigned

Bug Description

The manila-share service in the manila charm sometimes fails to restart after the configuration has changed. The config comes from the manila-generic backend configuration charm; the service gets stuck as there is nothing to then kick configuring the manila-share service and restarting it. A manual restart fixes the problem.

Changed in charm-manila:
importance: Undecided → High
Changed in charm-manila:
status: New → In Progress
assignee: nobody → Alex Kavanagh (ajkavanagh)
milestone: none → 17.08
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-manila (master)

Fix proposed to branch: master
Review: https://review.openstack.org/492491

Revision history for this message
Alex Kavanagh (ajkavanagh) wrote :

Fix proposed fix puts a 'band-aid' on the bug in that it is recovered from on the next 'update-status' hook. As the bug only seems to present itself during Amulet tests during deployment, and only ever during deployment, this is now a low priority bug.

Changed in charm-manila:
importance: High → Low
status: In Progress → Triaged
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-manila (master)

Reviewed: https://review.openstack.org/492491
Committed: https://git.openstack.org/cgit/openstack/charm-manila/commit/?id=df96346eb9ce729a58a57a96f756551c398068e0
Submitter: Jenkins
Branch: master

commit df96346eb9ce729a58a57a96f756551c398068e0
Author: Alex Kavanagh <email address hidden>
Date: Thu Aug 10 12:34:09 2017 +0100

    Enable worker-multiplier on manila

    This change draws on the charms.openstack and layer-openstack-api
    changes to provide the ability to configure the number of workers that
    the manila charm starts for API usage.

    It also:
     * Packages the manila charm into a venv. This is because the
       subordinate charms are ALSO reactive, which means that different
       versions of either charms.reactive or charms.openstack could be
       overwritten from the subordinate charm.
     * Band-aid an issue with manila-share not being started even though all
       of the config is properly set. This uses the update-status hook to
       check to see if the manila-share service should be running.
       (Bug: #1706699)
     * Work-around for a bug in python-manilaclient (Bug: #1707303) which
       caused basic_deployment test 400 to fail.

    Change-Id: I0ea0f14fb69bea5d2008ed70d72ba27c98c96679
    Depends-On: I3cea350e536306655f5f109ec67ae7f0fba35fda
    Depends-On: Id4145ffaa622727523003015d7012ece2f0eae4f
    Related-Bug: #1677543
    Partial-Bug: #1706699
    Related-Bug: #1707303

James Page (james-page)
Changed in charm-manila:
milestone: 17.08 → 17.11
James Page (james-page)
Changed in charm-manila:
milestone: 17.11 → 18.02
Ryan Beisner (1chb1n)
Changed in charm-manila:
milestone: 18.02 → 18.05
James Page (james-page)
Changed in charm-manila:
milestone: 18.05 → 18.08
James Page (james-page)
Changed in charm-manila:
milestone: 18.08 → 18.11
James Page (james-page)
Changed in charm-manila:
milestone: 18.11 → 19.04
David Ames (thedac)
Changed in charm-manila:
milestone: 19.04 → 19.07
David Ames (thedac)
Changed in charm-manila:
milestone: 19.07 → 19.10
David Ames (thedac)
Changed in charm-manila:
milestone: 19.10 → 20.01
James Page (james-page)
Changed in charm-manila:
milestone: 20.01 → 20.05
David Ames (thedac)
Changed in charm-manila:
milestone: 20.05 → 20.08
Changed in charm-manila:
assignee: Alex Kavanagh (ajkavanagh) → nobody
milestone: 20.08 → none
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.