Add page number to table for pagination

This is really a limitation of the APIs Horizon is calling. They use the marker/limit system which makes it impossible to do as you suggest. There is also heavy resistance in the community to improving on the pagination mechanism in the APIs. That said previous may be an option for at least two services, nova and glance. See http://lists.openstack.org/pipermail/openstack-dev/2013-August/013642.html

This really renders paged viewing useless for any moderately sized site and needs to be addressed in some way.

Minimally by defaulting API_RESULT_PAGE_SIZE = API_RESULT_LIMIT (to effectively disable paging)

If back is possible in nova and glance (which at my site are the two most likely to benefit) then it should be done.

A search field would also be an acceptable option (filter only works on the current page) as this would allow finding know instances/images/volumes/whatever though that may have similar API level issues.

It seems there is agreement that this is a bug and not "invalid", though fixing it may be possible until work is done in other projects. So if none of this is possible at this time, but it is desirable eventually then I think the bug should be set as Low priority (since there's no Stalled option) and noted that further API work is needed (possibly opening bug in or blueprints for the relevant projects).

I think that we should still paginate whether APIs support it or not. I think this will provide for a much better user experience.
1. pagination will reduce the amount of rendering of large data set (which can crash the browser)
2. user should be able to navigate back/more with some indication of where they are currently (page 1/20 for example)
3. filtering should continue to work with paging (allow user to get to relevant data faster)

Ideally, we just make an API call, and regardless of result size, we can still page it on the front-end. Eventually, when there is support for paging on the API side, we can provide a mechanism to sync paging from API to paging on front-end.

I agree that this is a rather big usability problem in the current dashboard. The only real solution is to essentially turn off paging. I also think that for consistency all tables should support the paging mechanism, but that is not as big of an issue. To me it is odd that one table pages data and another does not. I understand the limitations of the APIs, and that is ultimately where this should be fixed. But until that time comes (if it ever comes) we have the ability to perform the paging on the server in horizon, as Thai Tran mentions above. Horizon can fetch all data (up to the API limit) and then return the desired page from there. I know it's not ideal but I think it would be much better than what we have currently.

Would it be possible to add a selection for "Number of items per page"? This way, if users want to browse 100 items at a time, they could select this and it would grab up to 100 items for that page. The limitation of only being able to select "More" to get to the next page might feel a bit less restricting. I'm definitely in agreement it's still not ideal :) Here is a screenshot of what it could look like at the bottom of the table (you can ignore the pagination proposal on the right...):
http://people.redhat.com/~lsurette/OpenStack/Table%20Per%20Page

FWIW the number of items to display per page is currently configurable as a user preference (in Settings -> User settings). It could be nice to also be able to change it per table as per the proposal, though perhaps it should be tracked separately?

Great point, Julie. I've added a new bug with a few extra details from this conversation and tagged it with UX.
https://bugs.launchpad.net/horizon/+bug/1322719

I'm totally agree with people that this is an important UX issue.I don't know how big are the APIs limitations but, as Justin said, if these API limitations are a real problem for pagination issue, those limitations should be fixed.

In my opinion, the idea of take all the data and then manage the pagination in the client side, could have some performance problems (may be there is a project with 100 VMs or even more).

A web application, like Horizon, should be able to manage pagination (using AJAX or not) in all the pages where it displays a list information (instances, volumes, images, etc.). This is a mandatory requirement for any web application. Also, the "items per page" should be configurable per user(this is already accomplished) and, why not, as Julie mentioned, items per page and per view.

Any of you knows the real impact of this change in the APIs (horizon, nova, cinder, glance)?

IMO that should be fixed by means of SearchLight project which caches objects from different OpenStack APIs and thus circumvents the problem of their awkwardness for pagination.

Yes, pagination is possible and is consistent for all types of objects in searchlight. Currently we have nova instances, glance images, and designate items. Cinder volumes should be done by Mitaka 2. Swift integration is also underway.

Realistically Horizon can't handle this in its current format, but have marked as wishlist for reference.

Adding pagination to searchlight-ui will be done in Newton. We have a related BP on it:

https://blueprints.launchpad.net/searchlight/+spec/searchlight-ui-pagination-scrolling

We are considering different options to do the pagination. Currently the approach is showing pre/next link on django panels. We are moving to Angular panels and there's no plan to change how pagination works on django panels at this point.

For future reference, this kind of changes will need a blueprint.