Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1600391 - Deploy command fails immediately without running any commands
Summary: Deploy command fails immediately without running any commands
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-heat
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: Zane Bitter
QA Contact: Ronnie Rasouli
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-12 07:21 UTC by PURANDHAR SAIRAM MANNIDI
Modified: 2018-08-09 13:04 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-08-09 13:04:21 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
OpenStack Storyboard 2002966 None None None 2018-07-12 22:19:39 UTC

Comment 4 Zane Bitter 2018-07-12 21:09:31 UTC
Where it's failing is in calculating the frozen definition for all existing resources at the start of an update. There are several software deployments that reference {get_attr: [Compute, attributes, nova_server_resource]}. To calculate the frozen definition, all intrinsic functions must be resolved, and this one is resolving with an error. AIUI the patch https://review.openstack.org/511735 improves the error message but does not result in the error being caught and handled anywhere, so the problem will still occur.

It's notable that getting the frozen definition generally uses the property values stored in the database at the time the resource was created or updated - so there are no intrinsic functions left to resolve, and we should never get into this situation. My best guess is that one of the software deployment group resources has never actually been created, and therefore never had its resolved properties stored. I can't see another reason that this error would crop up.

One possible way to fix this comes to mind: it's only necessary to calculate the frozen_definition for resources that are being updated in place, but the code currently does this for all existing resources. The problem should be avoided if we both:

* Remove the compute role from the templates altogether; and
* Change the code so that we don't calculate the frozen definition for resources that are going to be deleted in the update, like so:

diff --git a/heat/engine/update.py b/heat/engine/update.py
index 84f203664c..0ae1b647fe 100644
--- a/heat/engine/update.py
+++ b/heat/engine/update.py
@@ -39,7 +39,8 @@ class StackUpdate(object):
         self.rollback = rollback
 
         self.existing_snippets = dict((n, r.frozen_definition())
-                                      for n, r in self.existing_stack.items())
+                                      for n, r in self.existing_stack.items()
+                                      if n in new_stack)
 
     def __repr__(self):
         if self.rollback:

Comment 13 Thomas Hervé 2018-07-23 13:21:15 UTC
The deployment was fixed by restoring both the heat and neutron database. Still waiting to here from the scale out.


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