On 05/22/2017 05:39 AM, Matthew Booth wrote: > Aside: For a query operation, what's the better user experience when a > single cell is failing: > > 1. The whole query fails. > 2. The user gets incomplete results. > > Either of these are simple to implement. Incomplete results would also > additionally be logged as an ERROR, but I can't think of any way to also > return to the user that there's a problem with the data we returned > without throwing an error.
The rough plan of record was to abuse HTTP 206 as an indicator that something is missing in the result set, and return best information we can reconstruct from the top level database. In the filtered case, that means some stuff might silently get dropped. In the all_instances / paginated case, you would get everything for the project_id of your token, just some returned servers would only have server uuid. We could also put a microversion in place so that something more specific about server list status (all sources reported) was there. No one expects a 500 error on server list, so we definitely don't want to give that to people. -Sean -- Sean Dague http://dague.net __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev