Bug 1469519 - OpenStack Manilla Services not set to enabled in systemd for reboot
OpenStack Manilla Services not set to enabled in systemd for reboot
Status: CLOSED NOTABUG
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates (Show other bugs)
11.0 (Ocata)
Unspecified Unspecified
medium Severity high
: ---
: ---
Assigned To: Jan Provaznik
Gurenko Alex
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-11 08:28 EDT by Tomas Rusnak
Modified: 2017-07-26 11:09 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-26 11:09:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomas Rusnak 2017-07-11 08:28:13 EDT
Description of problem:
After clean OSP11 install with tripleo and manilla backend enabled, some manila services are not enabled in systemd for reboot.

Version-Release number of selected component (if applicable):
openstack-tripleo-heat-templates-6.0.0-12.el7ost.noarch

How reproducible:
always


Steps to Reproduce:
# systemctl list-unit-files '*openstack*' | grep manila
openstack-manila-api.service                  enabled
openstack-manila-data.service                 disabled
openstack-manila-scheduler.service            enabled
openstack-manila-share.service                disabled

Actual results:
openstack-manila-data.service and openstack-manila-share.service not enabled


Expected results:
openstack-manila-data.service and openstack-manila-share.service enabled by default by heat template


Additional info:
Comment 2 Tom Barron 2017-07-26 11:08:23 EDT
I wouldn't necessarily expect the data service to be enabled as it is an experimental and unsupported service.

share service is a different matter but it runs under pacemaker control rather than under control of systemd so I don't think we want systemctl to report that it's enabled.

If you run 'pcs status' to see which controller the share service runs on, login to that controller, and run 'sudo systemctl status openstack-manila-share' you'll see that the service is loaded and active but "disabled", like so:

$ sudo systemctl status openstack-manila-share
● openstack-manila-share.service - Cluster Controlled openstack-manila-share
   Loaded: loaded (/usr/lib/systemd/system/openstack-manila-share.service; disabled; vendor preset: disabled)
  Drop-In: /run/systemd/system/openstack-manila-share.service.d
           └─50-pacemaker.conf
   Active: active (running) since Sat 2017-07-01 09:17:55 UTC; 3 weeks 4 days ago
...

Same deal for cinder volume (note that it may be running on a different controller):

$ systemctl status openstack-cinder-volume
● openstack-cinder-volume.service - Cluster Controlled openstack-cinder-volume
   Loaded: loaded (/usr/lib/systemd/system/openstack-cinder-volume.service; disabled; vendor preset: disabled)
  Drop-In: /run/systemd/system/openstack-cinder-volume.service.d
           └─50-pacemaker.conf
   Active: active (running) since Sat 2017-07-01 09:17:15 UTC; 3 weeks 4 days ago
...
Comment 3 Tom Barron 2017-07-26 11:09:05 EDT
Closing this one as NOTABUG.  Please re-open if I'm missing someting.

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