Bug 1398022 - Wherever the Manila Share Service is Deployed, the Manila API and Scheduler Services Will Also Be Deployed
Summary: Wherever the Manila Share Service is Deployed, the Manila API and Scheduler S...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: puppet-tripleo
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: z2
: 10.0 (Newton)
Assignee: Jan Provaznik
QA Contact: Dustin Schoenbrun
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-23 21:45 UTC by Dustin Schoenbrun
Modified: 2017-03-01 13:35 UTC (History)
13 users (show)

Fixed In Version: puppet-tripleo-5.5.0-3.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-01 13:35:48 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1653500 0 None None None 2017-01-02 12:31:19 UTC
OpenStack gerrit 417363 0 None None None 2017-01-12 12:41:00 UTC
Red Hat Product Errata RHBA-2017:0357 0 normal SHIPPED_LIVE Red Hat OpenStack Platform 10 director Bug Fix Advisory 2017-03-01 18:32:13 UTC

Description Dustin Schoenbrun 2016-11-23 21:45:32 UTC
Description of problem:
No matter where the Manila API and Scheduler services are configured to be deployed, they will always be deployed on the nodes where the Manila Share service is deployed. This can cause issues if there is a requirement for the other services to be on a different type of node than the one the Share service needs to run on. This leads to the API and Scheduler services being deployed not only on the nodes requested, but also wherever the Share service is configured to be installed. At least in terms of the API service, the Manila configuration file on the Manila Share nodes is not configured to run the API service correctly and the service fails on start up. 

Version-Release number of selected component (if applicable):
openstack-puppet-modules-9.3.0-1.el7ost.noarch

How reproducible:
100%

Steps to Reproduce:
1. Deploy an undercloud with director.
2. Before deploying the overcloud, modify the /usr/share/openstack-tripleo-heat-templates/roles_data.yaml file to move the Manila API service from being installed on the Controller nodes to being installed on the Compute nodes.
3. Continue with the overcloud deployment making sure to configure the overcloud to deploy the Manila services.
4. Observe that the Manila API service, while being installed on the Compute node correctly, was also installed on the controller node with the Share service.

Actual results:
The Manila API and Scheduler services are installed wherever the Manila Share service is installed in addition to where they are configured to be installed.

Expected results:
The Manila services shall be installed and configured on the nodes they were assigned to.

Additional info:
One possible culprit for why the API and Scheduler services are always installed where the Share service is installed might be the /usr/share/openstack-puppet/modules/tripleo/manifests/profile/pacemaker/manila.pp file, specifically lines 49-51.

Comment 2 Marius Cornea 2016-11-24 06:23:33 UTC
I can confirm this on my environment. The following Controller role in roles_data.yaml results in the following services running on the Controller nodes:


- name: Controller
  CountDefault: 1
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephClient
    - OS::TripleO::Services::CinderBackup
    - OS::TripleO::Services::CinderVolume
    - OS::TripleO::Services::Core
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::MySQL
    - OS::TripleO::Services::MongoDb
    - OS::TripleO::Services::RabbitMQ
    - OS::TripleO::Services::HAproxy
    - OS::TripleO::Services::Keepalived
    - OS::TripleO::Services::Memcached
    - OS::TripleO::Services::Pacemaker
    - OS::TripleO::Services::Redis
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::ManilaShare
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::VipHosts

overcloud-controller-1
? openstack-manila-api.service                                                loaded failed failed    OpenStack Manila API Server
  openstack-manila-scheduler.service                                          loaded active running   OpenStack Manila Scheduler
? openstack-manila-share.service                                              loaded failed failed    OpenStack Manila Share Service

I'd expect to see only the ManilaShare service loaded on the nodes running the Controller role.

Comment 3 James Slagle 2016-11-28 15:35:51 UTC
i'm deferring this to  rhos‑10.0.z

Comment 4 James Slagle 2016-11-28 15:37:15 UTC
actually, this should also be for DFG:Storage

Comment 6 Jan Provaznik 2017-01-02 12:31:19 UTC
Yes, the issue is caused by an (unnecessary) include of api/scheduler manifests. Upstream fix:
https://review.openstack.org/#/c/416036/

Comment 7 Jon Schlueter 2017-01-12 12:39:48 UTC
adjusting to correct component puppet-tripleo

Comment 8 Jon Schlueter 2017-01-12 12:41:00 UTC
updating with stable/newton gerrit, which is merged

Comment 9 Jon Schlueter 2017-02-14 15:43:17 UTC
puppet-tripleo-5.5.0-3.el7ost

Comment 11 Dustin Schoenbrun 2017-02-27 22:42:22 UTC
I tested the steps above to see if I could deploy the Manila API service separately from the other services with the 2017-02-15.1 build containing the puppet-tripleo-5.5.0-3.el7ost package. I was able to successfully deploy the Manila API service on the compute node and not have it be deployed on the controller node. I also executed some simple API commands to make sure that with the API service deployed on another node that Manila commands could still succeed. These API commands consisted of:

manila service-list
manila type-create
manila create 
manila list
manila delete

This gives me plentiful evidence that the API service can be deployed on another node type other than a controller node and your Manila services will continue to operate successfully. Marking the bug as VERIFIED.

Comment 13 errata-xmlrpc 2017-03-01 13:35:48 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://rhn.redhat.com/errata/RHBA-2017-0357.html


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