Mistral Dashboard Executions Screen
Summary
========
1. Fix and improve Executions screen UI.
2. Follow OpenStack Horizon look and feel.
Motivation
========
1. Lack of Executions screen UI functions
Mock
====
Needed!
Description
=========
Implement the following GUI:
1. Executions list
a. Columns are:
* ID - Link to open Execution Overview
* Workflow - Link to Workflows screen
* Input - A "View" link that opens a dialog and shows the result of execution-get-input API request)
* Output - A "View" link that opens a dialog and shows the result of execution-
* Created at
* Updated at
* State (tooltip will show state info)
* Tasks - A "View" link that navigates to the Tasks screen with the Execution ID as filter.
* Actions - Delete button and a drop down of other actions:
- Update description (Opens a dialog)
- Pause (Update state to PAUSED)
- Resume (Update state to RUNNING)
- Cancel (Update state to ERROR)
Only valid transitions will be displayed (according to workflow/states.py)
b. Sort allowed by ID, worflow, created at, updated at, state. Default sort by "updated_at" DESC
client side sorting until API v3)
c. Filter by workflow and state.
2. Execution overview
a. Shows the following info:
* ID - Link to open Execution Overview
* Description
* Workflow - Link to Workflows screen
* Input (automatically sends request to execution-get-input API)
* Output (automatically sends request to execution-
* Created at
* Updated at
* Tasks - A "View" link that navigates to the Tasks screen with the Execution ID as filter.
* State
* State info
3. Execution delete
a. From an action menu button in the row
b. From top level button to allow multi delete.
4. Execution update
a. Selection of either state or description with radio button
b. Updating state will have a drop down with RUNNING, PAUSED, SUCCESS, ERROR.
5. Auto refresh the entire screen
6. Pagination
a. Based upon the server side API implementation
b. Based upon Horizon:
c. Page size will be taken from user -> settings -> items per page
7. Execution create is currently out of scope and exists in the workflows screen.
Outside Dependencies
==================
API calls are supported (Mistral base API):
execution-delete
execution-get
execution-get-input
execution-
execution-list
execution-update
Doc Impact
=========
1. Add explanation to the new UI elements
2. Add explanation to the new flow
Blueprint information
- Status:
- Complete
- Approver:
- Renat Akhmerov
- Priority:
- High
- Drafter:
- Gal Margalit
- Direction:
- Approved
- Assignee:
- Gal Margalit
- Definition:
- Approved
- Series goal:
- Accepted for mitaka
- Implementation:
-
Implemented
- Milestone target:
-
2.0.0
- Started by
- Gal Margalit
- Completed by
- Renat Akhmerov
Related branches
Related bugs
Sprints
Whiteboard
I like and agree with the description of this BP. Thanks for such a detailed explanation.
Just two things to pay attention to:
1. b. Sort allowed by all columns. Default sort by "updated_at" DESC
Mistral API v2 doesn't really allow flexible sorting, it's going to be fixed as part of API v3. So I think the only way for now is to do sorting on a client side.
Gal: The implementation will be at the client side until we move to API v3.
4. b. Updating state will have a drop down with RUNNING, PAUSED, SUCCESS, ERROR.
a) We need to limit this set of options depending on the current execution state. So that, for example, if it's already in RUNNING state then it doesn't make sense to display RUNNING option.
melisha: Of course. Can you please mention all the rules that are not obvious as the one you mentioned? Can a use change state to ERROR? If so, why?
rakhmerov: sure, basically all valid transitions are defined in workflow/states.py module. Answering your question: stopping workflow with an error is valid and can be done via API, the case most obvious case for this is if I already see that my workflow will already never complete successfully for some reason (either the underlying environment is not in a proper state or the workflow itself is not designed correctly) so it doesn't make sense to wait.
b) Isn't it better to display separate buttons/links such as "pause", "resume" etc.
melisha: Good idea. I agree.
2. a. melisha: We should also add state_info to the Execution overview.
For example, if the execution is in ERROR state - the state_info will usually contain the reason.
I think it will also be useful that if the state_info is not null - it will be used as a tooltip for the "State" column in the execution table.
rakhmerov: agree
Please don't forget the 'description' param of Execution.--xylan, 2015.07.09
Gerrit topic: https:/
Addressed by: https:/
Added delete button to execution screen ui on mistral-dashboard
Gerrit topic: https:/
Gerrit topic: https:/
Addressed by: https:/
Added execution get method to mistral-dashboard api
Addressed by: https:/
mistral-
Addressed by: https:/
mistral-
Addressed by: https:/
mistral-
Addressed by: https:/
mistral-
Addressed by: https:/
mistral-
Gerrit topic: https:/
Addressed by: https:/
UI: Task & Execution screen refactored
Addressed by: https:/
UI: Task & Execution screen refactored
Addressed by: https:/
UI: Execution update - table actions
Addressed by: https:/
UI: Execution update - update description modal
Addressed by: https:/
UI: Execution pagination on client side
Addressed by: https:/
UI: Execution screen auto refresh
Addressed by: https:/
UI: Execution screen state info tooltip
Addressed by: https:/
UI: table pagination logic encapsulation
Addressed by: https:/
UI: fixed workflow execution don't work
