Open Stack

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