Jump to: navigation, search


< Horizon
Revision as of 14:54, 25 June 2013 by Tim Schnell (talk | contribs) (Requirements)


The following requirements have been discussed and have generally been accepted as valuable enough for resource devotion (at some point in time). Tim Schnell has prioritized what he considers the top 5 using an ease of implementation vs. immediate Return on Investment algorithm that he just made up. Feel free to help re-prioritize at any point in time.

Prioritized Requirements

1)Topology Graph- Building a visual Topology Graph that describes the various resources, parameters, and relationships that exist based on a submitted Template is the number 1 priority with the expectation that it will provide Heat with a much needed visual for key stakeholders as well as a solid building block that many other requirements will be dependent on. We expect this to serve in a "persistent central command" manner, in the sense that it will be the primary view to quickly assess the health of its stack deployment. Eventually we expect many other integrated Openstack services to be UI dependencies of the Topology Graph, such as Monitoring and Autoscale. Process Workflow on Topology Graph - In much the same way that the Visual Workflow should reflect the current tasks that are executing, it would be useful for the Topology Graph to reflect the current state of things during the workflow. For example, as a resource completes successfully it could change from gray to green or give some type of visual success indicator. Maintain State in Topology Graph - In addition to the Topology Graph being available during Workflow, it should also be available while the deployment stack exists. It's resources should reflect the current state, if a resource in particular is in a failed state then it should be reflected as red or failed in some way on the Topology Graph.

2) Logging - Abstracting Heat Engine and API logging from the internals and displaying them in the UI will allow Heat developers to easily debug and assess issues for ease of development as well as production level maintainability.

3) Update Customer Experience - This is a catch-all requirement that represents low-hanging UI fruit that will increase the usability of the UI with some fairly simple modifications (listed below)

  • Adding navigation breadcrumbs/general navigation improvement
  • Persisting a link to the original (whole) template for reference
  • Providing template in an easy digestible json view
  • Making it easy to Ctrl-A (Select entire template for copy/paste purposes)
  • Put a button to copy directly to clipboard
  • Filter Workflows/Deployments by (Date/Name/Search)

4) Clone Template Parameters - Providing template parameters can get repetitive, especially when the parameters are very similar. Giving the user the ability to clone HTML form inputs and then edit them would reduce the overhead on spinning up a new template (especially in the event that a parameter has a typing error).

5) Auto-Refresh - A general requirement that all pages (where applicable), will accurately reflect the state of the task/object being viewed. Whether using AJAX loops to ping for new information or web sockets to broadcast realtime data, it is important that the UI engenders the trust of the user by being as accurate as possible to the actual state of the workflow/deployment/etc...

Other Requirements

Visual and/or Textual Representation of Workflow - This is a more task-oriented alternative view to the Topology Graph. Ideally it would list out all tasks/sub-tasks, in sequential order, that are required for the workflow to complete. These tasks will also accurately reflect their state as the workflow progresses whether they are complete, pending, or in a failed state.

Retry Task - In the case that a task fails in the workflow, it should be possible to attempt to correct the environment that caused the failure and then retry or restart the workflow without having to start from the beginning. Use Case - If the template is attempting to create 4 servers but hits the server quota at 3, the user can go and delete unused servers so that the workflow can successfully create all 4 servers.

Edit and Retry Task - Debatably NOT an actual requirement, a user could want to edit the template json in the case of a failure and then retry the task. This, in practice, has proven only a neat idea and not actually useful as most individual tasks do not fail because of the template json but rather an environment setup problem in which case, you would have to cancel the workflow and start over. Will wait for this to become a real problem that cannot be solved by other means.

CURL Commands - During Workflow, in addition to displaying the state of the tasks, it would be useful for the UI to display the curl commands (or curl command-equivalents) that are being executed so that it is easy to see what endpoints are being hit.

Template Creator - Using the same Graphics Engine as the Topology Graph, create a GUI interface for creating/editing templates. Liz Blanchard from Redhat has created wireframes detailing this out.