On Fri, Apr 14, 2017 at 2:01 PM, Matt Riedemann <[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.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
