OpenStack Dashboard (Horizon)

new launch instance breaks if instances are lauched quickly

Bug #1552895 reported by Doug Fish
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Confirmed
Medium
Unassigned
OpenStack Dashboard (Horizon) next

Bug Description

I've found that if I launch a 2nd instance very quickly following an initial launch instance it can break the new angular launch instance wizard.

The key to recreating the problem is to click Launch Instance the 2nd time before the initial instance even appears in the table. When this happens the launch instance wizard disappears when the page refresh occurs, then clicking launch instance wizard again results in a defective wizard being shown. See the attached images.

This error is in the javascript console:
"Error: $scope.strings is undefined
magicSearchController@http://9.5.124.58/dashboard/static/dashboard/js/0172fde87c9b.js:4346:598
invoke@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:913:8
$ControllerProvider/this.$get</</<@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1106:26
nodeLinkFn/<@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1049:58
forEach@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:705:562
nodeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1049:17
delayedNodeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1074:1
compositeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:993:1
nodeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1052:14
compositeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:993:1
compositeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:993:99
compositeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:993:99
nodeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1052:14
delayedNodeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1074:1
compositeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:993:1
nodeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1052:14
compositeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:993:1
compositeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:993:99
compositeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:993:99
nodeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1052:14
compositeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:993:1
compositeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:993:99
publicLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:985:110
createBoundTranscludeFn/boundTranscludeFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:995:8
controllersBoundTransclude@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1056:8
link@http://9.5.124.58/dashboard/static/dashboard/js/0172fde87c9b.js:4486:6
invokeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1093:81
nodeLinkFn@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1052:147
compileTemplateUrl/<@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1072:1
processQueue@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1326:257
scheduleProcessQueue/<@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1327:135
$RootScopeProvider/this.$get</Scope.prototype.$eval@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1364:595
$RootScopeProvider/this.$get</Scope.prototype.$digest@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1360:109
$RootScopeProvider/this.$get</Scope.prototype.$apply@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1365:244
done@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1142:112
completeRequest@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1159:20
requestLoaded@http://9.5.124.58/dashboard/static/dashboard/js/7fd3f7d69c71.js:1153:1
" "<transfer-table class="ng-scope" help-text="ctrl.helpText" tr-model="ctrl.tableData">"

Tags: angularjs
Revision history for this message
Doug Fish (drfish) wrote :
Rob Cresswell (robcresswell-deactivatedaccount)
Changed in horizon:
importance: Undecided → High
status: New → Confirmed
milestone: none → mitaka-rc1
Revision history for this message
Matt Borland (palecrow) wrote :

I'm looking into this. First off, I can't recreate the issue.

I do notice in:

horizon/static/framework/widgets/magic-search/magic-search.controller.js

that there is some blind assumption that $scope.strings exists; however, this is pretty logical as when I trace the relationship between hz-magic-search-bar to magic-search that it should always have something for the strings. horizon/static/framework/widgets/magic-search/hz-magic-search-bar.directive.js always sets a default (seemingly) and this is always passed via the associated template to the magic-search directive.

I do see another problem, which is that there is a hard-coded template path that may fail, in horizon/static/framework/widgets/magic-search/hz-magic-search-bar.html . I'll see if there's some correlation there.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to horizon (master)

Fix proposed to branch: master
Review: https://review.openstack.org/290072

Changed in horizon:
assignee: nobody → Matt Borland (palecrow)
status: Confirmed → In Progress
Revision history for this message
Matt Borland (palecrow) wrote :

I added a patch that puts some band-aids on property assumptions in the magic-search controller code. It's possible this is enough to fix the issue for the moment.

Revision history for this message
Doug Fish (drfish) wrote :

I can't recreate the failure today. I'll look through it again tomorrow. Obviously it's hard to evaluate the solution without being able to recreate the problem reliably.

Revision history for this message
Itxaka Serrano (itxaka) wrote :

I also cant recreate. I have seen this before thought and all the times it looked like the javascript files were only partially loaded for some reason, but a server restart or a cache cleanup always fixed it.

Revision history for this message
Matt Borland (palecrow) wrote :

Status check: I believe that no one has re-created the issue. The current 'fix' code does fix another problem in an unrelated, unmerged patch, but I'd like some direction from a core as to how to appropriately manage this bug's status.

Revision history for this message
Rob Cresswell (robcresswell-deactivatedaccount) wrote :

I can't recreate either, so marking as incomplete for now. Feel free to remove yourself from the bug Matt.

Changed in horizon:
status: In Progress → Incomplete
milestone: mitaka-rc1 → none
importance: High → Undecided
Revision history for this message
Timur Sufiev (tsufiev-x) wrote :

I can confirm that I've the same issue as well, when 2 conditions were met: most of Horizon js files were uncompressed (compression enabled and offline, but the files themselves excluded from compression in _scripts.html file) and Horizon were run by PyCharm in Debug mode. But even with these 2 conditions I wasn't able to reproduce the issue steadily :(.

My impression is that it's somehow related to loading timings, but cannot say more due to the difficulties with reproducing it.

OpenStack Infra (hudson-openstack)
Changed in horizon:
assignee: Matt Borland (palecrow) → Travis Tripp (travis-tripp)
status: Incomplete → In Progress
Travis Tripp (travis-tripp)
Changed in horizon:
assignee: Travis Tripp (travis-tripp) → Matt Borland (palecrow)
importance: Undecided → Medium
tags: added: angularjs
Rob Cresswell (robcresswell-deactivatedaccount)
Changed in horizon:
milestone: none → newton-2
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on horizon (master)

Change abandoned by Matt Borland (<email address hidden>) on branch: master
Review: https://review.openstack.org/290072

Rob Cresswell (robcresswell-deactivatedaccount)
Changed in horizon:
milestone: newton-2 → newton-3
Rob Cresswell (robcresswell-deactivatedaccount)
Changed in horizon:
status: In Progress → Confirmed
assignee: Matt Borland (palecrow) → nobody
milestone: newton-3 → next
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.