On 4/14/2017 4:09 PM, Chet Burgess wrote:
On Fri, Apr 14, 2017 at 2:01 PM, Matt Riedemann <[email protected] <mailto:[email protected]>> wrote:On 4/14/2017 3:36 PM, Mathieu Gagné wrote: Can I assume some form of advanced filtering will be proposed to ensure an instance doesn't end up with 1k records? One suggestion would be filtering by date or limiting the number of records returned. The normal pagination filters could be implemented. By default all results from the DB are restricted to 1000 based on the [api]/max_limit config option. We don't have the normal paging filters plumbed through down to the database API, so that would be additional work. Would it be required on the first pass here or is the default 1000 max limit OK for now? Will someone resize or migrate a server hundreds of times? I guess a system like Watcher could do that based on some policies. We don't have clients using anything like watcher and our oldest cloud (almost 4+ years) has VMs that have probably been moved around a few dozen times. I can't think of any use case across our clients where we would have even 100 records. I think its fine to start with no pagination. As mentioned, the other obvious filters are type and status (type would already be implemented for filtering in this new microversion as part of that spec). I think type and status would be the 2 most important. It might be nice to be able to filter on host as well since that would allow you to look at log of "what the host was doing". I don't know if thats searchable/exposed though as I haven't looked at the structure of the record. If we do search on host though we will probably need pagination as that could be a very large data set.
The API is scoped to a single instance, so we wouldn't be listing all migrations for a given host for all instances.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-- Thanks, Matt __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
