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.
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.
i'm deferring this to rhos‑10.0.z
actually, this should also be for DFG:Storage
Yes, the issue is caused by an (unnecessary) include of api/scheduler manifests. Upstream fix: https://review.openstack.org/#/c/416036/
adjusting to correct component puppet-tripleo
updating with stable/newton gerrit, which is merged
puppet-tripleo-5.5.0-3.el7ost
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.
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