Open Stack

On Fri, Apr 14, 2017 at 2:01 PM, Matt Riedemann <mriedemos at gmail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170414/a0ae9111/attachment.html>