Consistent Server Side Filtering

Registered by Eddie Ramirez

Implement a consistent API-side filtering across all views. Current filtering options shown at the top of each table is not consistent due to different filtering methods:
    a) Server: Does an API request to each service
    b) Query: does a client-side filtering (using JavaScript)

By detecting and enumerating the common filtering fields available in the APIs, we could show a standard, simpler and more powerful filtering experience to end-users.

Current filtering options are not consistent across all views and does not provide all the power each python-*client provides for such operation.

From the UX/UI perspective
Only two tables provide API-filtering: Project->Instances and Admin->Instances. We can consolidate the user experience across all views.

In order to enable API-filtering we must discover all available filtering options in python-*clients. Once we know the possibilities, we could:

    - Change default filtering (query) and enable "Server" filtering where available. Target Client APIs are:
        * novaclient
        * cinderclient
        * neutronclient
        * keystoneclient
        * glanceclient
        * swiftclient

    - Display a set of options that would enable any user to define which field(s) prefers to filter by.
       We would need to define a minimum amount of fields available on each API.


Affected views should:
    - Show the field name of the current filter. At least one field is consistent across all views: name.
    - Use built-in bootstrap components to render filter options as "Button with dropdowns" (
    - Show current filtering method: equality or regex.
    - Show a "loading spinner" while the request is being resolved.

Wireframes, Mocks, Videos and UI Markup
Existing filter UI
Project-> Instances:
Project-> Volumnes:

Proposed filter UI

The filter should be able to send requests to the APIs

Outside Dependencies
Still need to break down dependencies once we:

- Investigate the current filtering capabilities available in OpenStack services clients
- Investigate if there's any pending patch that provides extended filtering options

Doc Impact
These changes requires an update to existing documentaiton, where we can Illustrate the filtering capabilities and options
available to end-users

Blueprint information

Rob Cresswell
Eddie Ramirez
David Lyle
Series goal:
Accepted for 13.0.0-queens
Milestone target:
milestone icon queens-1
Started by
Rob Cresswell
Completed by
Rob Cresswell

Related branches



Addressed by: [MERGED]
    Change from client filter to server filter in metadata page

Progress and tracking:

Gerrit topic:,topic:bp/server-side-filtering,n,z

Addressed by: [MERGED]
    Server-side filtering Identity->Projects

Addressed by: [MERGED[
    [WIP] Added Server-side/API filtering for swift UI

Addressed by: [MERGED]
    Server-side filtering networks

Addressed by: [MERGED]
    More available filters in servers (Nova)

Addressed by: [MERGED]
    Server-side filtering routers

Addressed by: [ABANDONED]
    WIP - Server-side filtering for project images

Addressed by: [MERGED]
    Provide help-text capability for server-side filter choices

Addressed by:
    Registry-based client/server-side faceted searching [MERGED]

Addressed by: [MERGED]
    Move get_filters to parent Class

Addressed by: [MERGED]
    Server-side filtering for admin volumes

Addressed by: [MERGED]
    Server-side filtering Orchestration

Addressed by: [ABANDONED]
    [WIP] Show message if no matches found when using filters

Addressed by: [ABANDONED]
    Focus on filter input after user selection

Addressed by: [MERGED]
    Server-side filtering vpn

Addressed by: [MERGED]
    Implement admin_filter_first setting in Admin>Volumes

Addressed by: - [MERGED]
    Add server-side filtering Floating IPs


Work Items

This blueprint contains Public information 
Everyone can see this information.


No subscribers.