https://blueprints.launchpad.net/fuel/+spec/node-list-sorters-and-filters
Implement possibility to sort and filter nodes based on its properties (e.g. name, status, etc) so that user can work efficiently with large number of nodes in Fuel UI
Now user can filter nodes just by their name or MAC address using simple text field only and no special sorters are available for node list. Nodes are automatically sorted by their id attribute that is useless for the end user.
It is rather poor UI for managing large environments. There are many use cases that are desirable to maintain in the Fuel UI. For example, an ability to filter/sort nodes by their deployment status or online state would save some time finding faulty/offline nodes in the list and performing bulk actions (like Delete) on them.
We should introduce a form-based panels on node list screens in UI with filtering and sorting controls based on node attributes.
If there is a predefined list of node attribute values then the filter control should be a dropdown with list of checkboxes, representing these values, with multiple choice support. If node attribute is a number, the dropdown should contain two text fields to set minimum and maximum values for the attribute. In other cases filtering is performed by a single text search field.
Filter bar has some default filters (will be described below) and new ones can be added from the list of all possible filters. Non-default filters can be deleted from the bar.
Applying the filters should be performed by click on Apply button in the filter bar.
User should also have an ability to sort node list by multiple node attributes both in forward (ascending) and reverse (descending) order. The order can be set separately for each sorter (ascending is default).
Sorting bar has default sorter (will be described below) and new ones can be added from the list of all possible sorters. Non-default sorters can be deleted from the bar.
Applying the sorting is performed immediately by adding new sorter or changing an order of the existing one.
Both sorting and filter bars should be extendable for adding custom user filters or sorters and should have Clear All button in order to help user immediately reset the selection to default and not to change each control.
Node list should include info about filtering results: amount of filtered nodes and names of applied filters with its selected values. Node list should also include info about applied sorters.
Existing grouping control in node management panel will be totally replaced by sorting functionality. Sorted node list should be grouped by the sorting parameters to provide the user a UI for effective node group selection. For example, if a node list is sorted by roles and deployment status, then there will be groups by combination of roles and status in the list.
Sorting by node name, IP or MAC address does not involve grouping because these attributes are unique for each node.
Below describes all possible filters for each of node list screens.
Both environment nodes and unallocated nodes screens also should have a simple Search nodes text field for case insensitive filtering nodes by the following attributes:
Below describes all the possible sorters for each of node list screens.
All the sorters above are described with the assumption of direct sorting order (ascending).
SCREEN OF ROLE MANAGEMENT should not have neither filter nor sorting bar because all nodes are always chosen on this screen and sorting by roles only does make sense on the screen.
User selection for filters and sorters is not stored neither on the backend nor in browser cookies for now. This task should be considered after UI settings can be coupled with a particular user. In this case the user will be able to keep his own UI state for every client (browser).
At the same time the selection (except the data from Search field) is automatically translated to page location string now as a simple urlencoded javascript object:
#cluster/1/nodes/list/{%22filter%22%3A{%22roles%22%3A[%22compute%22%2C
%22cinder%22]%2C%22status%22%3A[%22ready%22]}%2C%22sort%22%3A[{%22roles
%22%3A%22asc%22}%2C{%22status%22%3A%22desc%22}]}
User is able to use such url for keeping some filtering and sorting state.
There are mockups for the feature:
The alternative here can be query-based language for filtering and sorting nodes, that looks like:
status = error AND role in (controller, compute) and online = true
ORDER BY name ASC, role DESC
This method is rather flexible and requires no support when adding new node properties. This feature is planned as the next iteration within node management optimization task.
Node list sorting anf filtering can also be done on server side. This way will allow not to transfer all nodes with their data each time through REST API and will increase speed and velocity of server-client interactions. This alternative is out of scope of this task because of the lack of resources and the need of preliminary refactoring of Nailgun API.
Existing grouping attribute of Cluster model is no longer needed.
Filtering and sorting support in Nailgun API is highly desirable but should be considered as a separate task. This specification is about UI changes only.
Since we have a “Data model impact” we have to prepare an Alembic migration that should update clusters to fit the new format.
None.
None.
None.
None.
None.
None.
None.
None.
Primary assignee:
Developers:
Mandatory Design Reviewer:
Approver:
None.
The documentation should cover how the end user experience has been changed.
#fuel-ui on freenode