Description of problem: =================================== Starting with Monday's build, the test automation is tripping up on launch a application from the application details page (clicking the launch button). I debugged the issue down to a new step in the "wizard" has been added and looking at it, the step looks like its roughly a duplicate of the last (expected) page so curious if this was on purpose because it seems like it is not needed. refer to the screen shots, the new page now displays before the final page (which is the one the automation has been coded for up to this point). Version-Release number of selected component (if applicable): ================================================================= aeolus-conductor-0.13.14-1.el6cf.noarch
Created attachment 617226 [details] new page in wizard
Created attachment 617227 [details] expected page
It's not a duplicated step, this workflow is the same as starting a new deployment from the Monitor page. Previously, launching from deployables#show redirected to the second page of the wizard and set the deployment name to the same name as the deployable had. It was changed because of #859503
It is duplicated... the name and cluster selections definitely are, just curious on why this cannot all be on a single page.
It's not duplicated. You should not be able to do the cluster selection on the second page, you are only allowed to to that only on the first step. Could you explain the steps necessary for changing the cluster on both the first and the second page of the workflow? I can't reproduce it. The second page is the overview of deployment which is about to launch. You have only the option to change its name.
Using aeolus-conductor-0.13.18-1.el6cf I'm seeing the same behaviour Dave reported. In the last step of the launch wizard I was allowed to change the cluster. The application was actually deployed on the cluster I selected last.
Created attachment 625227 [details] Page changed Checked in puddle 4 , the second page does not have cluster selection . rpm -qa|grep aeolus aeolus-conductor-0.13.18-1.el6cf.noarch aeolus-conductor-daemons-0.13.18-1.el6cf.noarch aeolus-configure-2.8.9-1.el6cf.noarch aeolus-all-0.13.18-1.el6cf.noarch rubygem-aeolus-image-0.3.0-12.el6.noarch aeolus-conductor-doc-0.13.18-1.el6cf.noarch rubygem-aeolus-cli-0.7.4-1.el6cf.noarch
Re-Opening this bug .. Seeing it again .. rpm -qa|grep aeolus rubygem-aeolus-image-0.3.0-12.el6.noarch aeolus-conductor-daemons-0.13.18-1.el6cf.noarch rubygem-aeolus-cli-0.7.4-1.el6cf.noarch aeolus-conductor-doc-0.13.18-1.el6cf.noarch aeolus-all-0.13.18-1.el6cf.noarch aeolus-configure-2.8.9-1.el6cf.noarch
Created attachment 628260 [details] cluster_selection
Pull request sent to remove the realm selection dropbox: https://github.com/aeolusproject/conductor/pull/130
Acked and merged the pull request.
c2272b41008c50c7ba107ec24e4cc519cc2378f4 on 1.1 df705c849eb4b9c2fd04fa8ec32700fee39406b7 on master
Created attachment 632247 [details] cluster_selection_removed
rpm -qa|grep aeolus rubygem-aeolus-image-0.3.0-12.el6.noarch rubygem-aeolus-cli-0.7.5-1.el6cf.noarch aeolus-conductor-doc-0.13.20-1.el6cf.noarch aeolus-configure-2.8.9-1.el6cf.noarch aeolus-conductor-daemons-0.13.20-1.el6cf.noarch aeolus-all-0.13.20-1.el6cf.noarch aeolus-conductor-0.13.20-1.el6cf.noarch
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. http://rhn.redhat.com/errata/RHEA-2012-1516.html