[AMBARI-22804] Install Wizard final deployment of services from multiple mpacks#199
Conversation
…h names hard-coded to be <mpackId>-<mpackVersion>.
…-mpack-deployment # Conflicts: # ambari-web/app/styles/application.less # ambari-web/app/styles/wizard.less # ambari-web/app/templates/installer.hbs
# Conflicts: # ambari-web/app/styles/application.less # ambari-web/app/styles/wizard.less # ambari-web/app/templates/installer.hbs
# Conflicts: # ambari-web/app/styles/application.less # ambari-web/app/styles/wizard.less # ambari-web/app/templates/installer.hbs
# Conflicts: # ambari-web/app/styles/application.less # ambari-web/app/styles/wizard.less
…-mpack-deployment # Conflicts: # ambari-web/app/controllers/wizard/step7_controller.js # ambari-web/app/styles/application.less # ambari-web/app/styles/bootstrap_overrides.less # ambari-web/app/styles/wizard.less # ambari-web/app/templates/wizard/downloadMpacks.hbs # ambari-web/app/templates/wizard/selectMpacks.hbs # ambari-web/app/templates/wizard/verifyProducts.hbs
…-mpack-deployment
|
Refer to this link for build results (access rights to CI server needed): |
| background-color: inherit; | ||
| } | ||
| .wizard .wizard-body .wizard-nav { | ||
| min-width: 250px; |
There was a problem hiding this comment.
On narrow screen wizard-body will jump to bottom, better to leave previous styles
There was a problem hiding this comment.
No, my changes ensure that the wizard-body stays where it should even if the screen is very narrow (although hopefully nobody is using Ambari on that small of a screen, since the UI is really not designed for it).
…-mpack-deployment # Conflicts: # ambari-web/app/templates/wizard/step2.hbs
|
Refer to this link for build results (access rights to CI server needed): |
| {{else}} | ||
| <button type="button" class="icon-button retry-button" disabled="disabled"></button> | ||
| {{/if}} | ||
| </span> |
There was a problem hiding this comment.
IMO we can directly bind it and use bootstrap classes instead.
{{bindAttr class=":btn :btn-default :retry-button mpack.failed::disabled"}}
There was a problem hiding this comment.
mpack.failed:disabled would have inverted the logic. mpack.failed::disabled disables it when mpack.failed is false. So as long as the value of mpack.failed is false (or null) the button would remain disabled, doesn't matter it is in-progress or it succeeds. Your if else code above is also doing the exact same thing
There was a problem hiding this comment.
I tried this suggestion and a couple other options, including binding the disabled attribute directly, but the results were not satisfactory. It looks like in this specific situation, the existing code is a satisfactory solution, if not the most elegant.
4 participants
What changes were proposed in this pull request?
Orchestrate final steps to install services from multiple mpacks using latest API, including creating service groups, creating version definitions, and deploying services.
How was this patch tested?
All tests passing:
20334 passing (24s)
125 pending