Bug 1411125

Summary: Resource OS::TripleO::Services::ManilaApi not found causes Overcloud deploy failure
Product: Red Hat OpenStack Reporter: Kevin Jones <kejones>
Component: openstack-tripleo-heat-templatesAssignee: Jiri Stransky <jstransk>
Status: CLOSED ERRATA QA Contact: Dustin Schoenbrun <dschoenb>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 10.0 (Newton)CC: aschultz, cschwede, jjoyce, jschluet, kejones, mburns, rhel-osp-director-maint
Target Milestone: z3Keywords: TestOnly, Triaged, ZStream
Target Release: 10.0 (Newton)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-tripleo-heat-templates-5.2.0-18.el7ost Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-06-28 14:44:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Set of templates that do complete if Manila resources are commented out. none

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:
100%

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.

https://access.redhat.com/errata/RHBA-2017:1585