Description of problem: when you try to download the logs file you get a huge stack trace exception instead of a clear error Version-Release number of selected component (if applicable): 2018-10-02.2 puddle How reproducible: 100% Steps to Reproduce: 1.install osp14 via a customized job with a breakpoint before deployment 2.log in 3.press the question mark at the top of the page 4.press 'DEBUG' button 5.press 'download logs'
It seems that there is a problem in publish_ui_logs_to_swift workflow: Failed to handle action completion [error=Can not evaluate YAQL expression [expression=task().result.select($._id), error=u'_id', data={}] (undercloud) [stack@undercloud-0 ~]$ openstack workflow execution output show c25f375e-116f-42a1-b561-5e64006e1811 { "result": "Failed to handle action completion [error=Can not evaluate YAQL expression [expression=task().result.select($._id), error=u'_id', data={}], wf=tripleo.plan_management.v1.publish_ui_logs_to_swift, task=get_messages, action=zaqar.claim_messages]:\nTraceback (most recent call last):\n File \"/usr/lib/python2.7/site-packages/mistral/engine/task_handler.py\", line 110, in _on_action_complete\n task.on_action_complete(action_ex)\n File \"/usr/lib/python2.7/site-packages/osprofiler/profiler.py\", line 159, in wrapper\n result = f(*args, **kwargs)\n File \"/usr/lib/python2.7/site-packages/mistral/engine/tasks.py\", line 381, in on_action_complete\n self.complete(state, state_info)\n File \"/usr/lib/python2.7/site-packages/osprofiler/profiler.py\", line 159, in wrapper\n result = f(*args, **kwargs)\n File \"/usr/lib/python2.7/site-packages/mistral/engine/tasks.py\", line 221, in complete\n data_flow.publish_variables(self.task_ex, self.task_spec)\n File \"/usr/lib/python2.7/site-packages/mistral/workflow/data_flow.py\", line 215, in publish_variables\n task_ex.published = expr.evaluate_recursively(branch_vars, expr_ctx)\n File \"/usr/lib/python2.7/site-packages/mistral/expressions/__init__.py\", line 100, in evaluate_recursively\n data[key] = _evaluate_item(data[key], context)\n File \"/usr/lib/python2.7/site-packages/mistral/expressions/__init__.py\", line 79, in _evaluate_item\n return evaluate(item, context)\n File \"/usr/lib/python2.7/site-packages/mistral/expressions/__init__.py\", line 71, in evaluate\n return evaluator.evaluate(expression, context)\n File \"/usr/lib/python2.7/site-packages/mistral/expressions/yaql_expression.py\", line 159, in evaluate\n cls).evaluate(trim_expr, data_context)\n File \"/usr/lib/python2.7/site-packages/mistral/expressions/yaql_expression.py\", line 113, in evaluate\n \", data=%s]\" % (expression, str(e), data_context)\nYaqlEvaluationException: Can not evaluate YAQL expression [expression=task().result.select($._id), error=u'_id', data={}]\n" }
By looking at the error message, It seems that the failing expression does not handle the case when there are no messages?
Running: $ mistral execution-create tripleo.plan_management.v1.publish_ui_logs_to_swift Works fine for me on a recent tripleo master install Is the `tripleo` queue present in the output of $ openstack messaging queue list ?
This is the get_messages task from the error message above: get_messages: action: zaqar.claim_messages on-success: - format_messages: <% task().result.len() > 0 %> input: queue_name: <% $.logging_queue_name %> ttl: 60 grace: 60 publish: status: SUCCESS messages: <% task().result %> message_ids: <% task().result.select($._id) %> It says that the "task().result.select($._id)" failed to run. Yes, this does suggest that the action failed. On my setup, the "logging_queue_name" queue ("tripleo-ui-logging" by default) is not present. This workflow still finishes fine.
Note that my environment doesn't yet have any tripleo-ui messages because I'm currently unable to log in due this bug[1]. [1]: https://bugs.launchpad.net/tripleo/+bug/1801778
If this bug requires doc text for errata release, please set the 'Doc Type' and provide draft text according to the template in the 'Doc Text' field. The documentation team will review, edit, and approve the text. If this bug does not require doc text, please set the 'requires_doc_text' flag to -.
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-2019:0446