Re: [Openstack-operators] Problems (simple ones) at scale... Invisible VMs.

Sorry, my email client didn’t properly thread replies, so I just saw Simon’s reply. Seems that setting limit -1 is effectively telling it to paginate, so feel free to ignore that suggestion :-D We should perhaps still consider a better way to let people know that’s happening. At the very least

Re: [Openstack-operators] Problems (simple ones) at scale... Invisible VMs.

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

Re: [Openstack-operators] Problems (simple ones) at scale... Invisible VMs.

In fact, both of you are correct. When passing '--limit -1' to the Nova client, it will issue multiple requests to the API using the --marker option until it receives no more data [1]. So the server-side limit (osapi_max_limit parameter) isn't by-passed, it's just the client that deals with it.

Re: [Openstack-operators] Problems (simple ones) at scale... Invisible VMs.

I don't think --marker does at all what I want. The --limit -1 does doe multiple successive queries (with a marker) automagically returning a single list as CLI output to nova list. That really IS what I want (and what some of our automation is written around.) Thanks! On Wed, May 18, 2016 at

Re: [Openstack-operators] Problems (simple ones) at scale... Invisible VMs.

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 The last server UUID of the previous page;

Re: [Openstack-operators] Problems (simple ones) at scale... Invisible VMs.

We just hit this and replaced a call to nova with a direct database query - literally yesterday! Chris Morgan Sent from my iPhone > On May 18, 2016, at 6:13 PM, David Medberry wrote: > > So, we just ran into an "at-sale" issue that shouldn't have been an issue. > >

Re: [Openstack-operators] Problems (simple ones) at scale... Invisible VMs.

3 PM > To: "openstack-operators@lists.openstack.org" < > openstack-operators@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.

Re: [Openstack-operators] Problems (simple ones) at scale... Invisible VMs.

enstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org>" <openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org>> Subject: [Openstack-operators] Problems (simple ones) at scale... Invisible VMs. So, we just ran into an "at-

[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