Given that there’s already the ability to start listing from a specific VM/UUID, it seems like we should add some pagination functionality in there. Maybe we need to add an “—all” flag or something which is non-admin and returns all VMs for the specific tenant. Then if someone really does want all 10,000 VMs they’re running in a tenant they can get them, and still honor osapi_max_limit (per subsequent paged call).
Alternatively (or perhaps in addition to?) if there are more results than the osapi_max_limit, or some other limit set, we should tell people “showing 1000 of 10,000 results, use –marker <last uuid> to show the next 1000” or something. Limits are something people tend to be OK with, but having to dig into un/under-documented issues is what makes them straight up angry. If there’s something we can do to help alleviate that it seems worth investigating. On 5/18/16, 5:26 PM, "James Downs" <e...@egon.cc> wrote: >On Wed, May 18, 2016 at 04:37:42PM -0600, David Medberry wrote: > >> It seems to bypass it... or I'm running into a LOWER limit (undocumented). >> So help on limit -1 says it is still limited by osapi_max_limit > >You're looking for: > >--marker <marker> The last server UUID of the previous page; > displays list of servers after "marker". > >This is much faster than increasing the size of results, at least in >sufficiently >large environments. > >Cheers, >-j > >_______________________________________________ >OpenStack-operators mailing list >OpenStack-operators@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
