Bug 1411125 - Resource OS::TripleO::Services::ManilaApi not found causes Overcloud deploy failure
Summary: Resource OS::TripleO::Services::ManilaApi not found causes Overcloud deploy f...
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
Target Milestone: z3
: 10.0 (Newton)
Assignee: Jiri Stransky
QA Contact: Dustin Schoenbrun
Depends On:
TreeView+ depends on / blocked
Reported: 2017-01-08 15:05 UTC by Kevin Jones
Modified: 2017-06-28 14:44 UTC (History)
7 users (show)

Fixed In Version: openstack-tripleo-heat-templates-5.2.0-18.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-06-28 14:44:12 UTC
Target Upstream Version:

Attachments (Terms of Use)
Set of templates that do complete if Manila resources are commented out. (7.97 KB, application/x-gzip)
2017-01-08 19:46 UTC, Kevin Jones
no flags Details

System ID Private Priority Status Summary Last Updated
OpenStack gerrit 396662 0 None None None 2017-05-24 14:38:40 UTC
Red Hat Product Errata RHBA-2017:1585 0 normal SHIPPED_LIVE Red Hat OpenStack Platform 10 director Bug Fix Advisory 2017-06-28 18:42:51 UTC

Description Kevin Jones 2017-01-08 15:05:32 UTC
Description of problem:
Overcloud deploy fails when including roles_data.yaml template complaining about OS::TripleO::Services::ManilaApi not being found.

Version-Release number of selected component (if applicable):
10 from CDN

How reproducible:

Steps to Reproduce:
1. Deploy overcloud with below command and attached templates
2. Deployment fails in servicechain steps complaining about resource not being found

Actual results:
Overcloud deploy fails with below message:

 u'message': u"Failed to run action [action_ex_id=399e121e-f3a1-4ba2-8d59-502626350aeb, action_cls='<class 'mistral.actions.action_factory.DeployStackAction'>', attributes='{}', params='{u'container': u'overcloud', u'timeout': 60}']\n ERROR: Failed to validate: : resources.ControllerServiceChain: : The Resource Type (OS::Tripleo::Services::ManilaApi) could not be found.",
 u'status': u'FAILED'}

Expected results:
Overcloud deploy should proceed with manila resources being found.

Additional info:

Deploy command:
time openstack overcloud deploy \
--templates \
-r ~/templates/roles_data.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
-e ~/templates/storage-environment.yaml \
-e ~/templates/network-environment.yaml \
-e ~/templates/firstboot/firstboot.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml \
-e ~/templates/ironic.yaml \
--control-scale 1 \
--compute-scale 1 \
--ceph-storage-scale 0 \
--compute-flavor compute \
--control-flavor control \
--ceph-storage-flavor ceph-storage \
--timeout 60 \
--ntp-server time.google.com \
--libvirt-type qemu

Comment 1 Kevin Jones 2017-01-08 15:06:47 UTC
Created attachment 1238402 [details]
Templates used to deploy overcloud with ironic

Comment 2 Kevin Jones 2017-01-08 19:46:25 UTC
Created attachment 1238443 [details]
Set of templates that do complete if Manila resources are commented out.

Comment 3 Christian Schwede (cschwede) 2017-02-10 15:18:05 UTC
There has been an error in the naming upstream. Actually these services were called OS::Tripleo::Services::ManilaApi (note the lowercase "o" in Tripleo).

There is an related bug upstream: https://bugs.launchpad.net/tripleo/+bug/1640871

This has been fixed upstream meanwhile: https://review.openstack.org/#/c/396317/

And downstream fixed in version openstack-tripleo-heat-templates-5.2.0-3.el7ost

@Kevin: can you please check if the issue still exists with the latest openstack-tripleo-heat-templates package?

Comment 4 Jon Schlueter 2017-02-15 14:33:48 UTC
According to our records, this should be resolved by openstack-tripleo-heat-templates-5.2.0-3.el7ost.  This build is available now.

Comment 5 Kevin Jones 2017-02-27 13:36:01 UTC
I have verified on a recent RHOSP10 deployment that using the roles_data.yaml and leaving the manila services in does not break the deployment. I believe this issue is resolved.

Comment 8 Dustin Schoenbrun 2017-06-07 15:47:20 UTC
We've completed several deployment with and without Manila across OSP-10 and OSP-11 over the past several months without issue from the Manila API service and since this seems to have been caused by a typo in the naming of the services and we've done a bunch of deployments without issue, I'm going to mark this as Verified.

Comment 10 errata-xmlrpc 2017-06-28 14:44:12 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.


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