Open Stack

Nova has a config setting for the maximum number of results to be returned by a single call.  You can bump that up so that you can do a nova list —all-tenants and still see everything. However if I am reading the below correctly, then I didn't realize that the —limit –1 apparently by-passes that config option?

___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: David Medberry <openstack at medberry.net<mailto:openstack at medberry.net>>
Date: Wednesday, May 18, 2016 at 4:13 PM
To: "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>" <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>
Subject: [Openstack-operators] Problems (simple ones) at scale... Invisible VMs.

So, we just ran into an "at-sale" issue that shouldn't have been an issue.

Many of the OpenStack CLI tools accept a limit parameter (to limit how much data you get back from a single query). However, much less well documented is that there is an inherent limit that you will run into at a 1000 VMs (not counting deleted ones). Many operators have already exceeded that limit and likely run into this. With nova cli and openstack client, you can simply pass in a limit of -1 to get around this (and though it will still make paged queries, you won't have "invisible" VMs which is what I've begun to call the ones that don't make it into the first/default page.

I can't really call this a bug for Nova (but it is definitely a bug for Cinder which doesn't have a functional get me all of them command and is also limited at 1000 for a single call but you can never get the rest at least in our Liberty environment.)

box:~# nova list  |tail -n +4 |head -n -1 |wc
   1000   16326  416000
box:~# nova list --limit -1  |tail -n +4 |head -n -1 |wc
   1060   17274  440960

(so I recently went over the limit of 1000)

YMMV.

Good luck.

-d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160518/04a81138/attachment.html>