Open Stack

On 4/14/2017 4:09 PM, Chet Burgess wrote:
> On Fri, Apr 14, 2017 at 2:01 PM, Matt Riedemann <mriedemos at gmail.com
> <mailto: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.

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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 

Thanks,

Matt