Open Stack

On 08/04/2018 05:18 PM, Matt Riedemann wrote:
> On 8/3/2018 9:14 AM, Chris Friesen wrote:
>> I'm of two minds here.
>>
>> On the one hand, you have the case where the end user has accidentally
>> requested some combination of things that isn't normally available, and they
>> need to be able to ask the provider what they did wrong.  I agree that this
>> case is not really an exception, those resources were never available in the
>> first place.
>>
>> On the other hand, suppose the customer issues a valid request and it works,
>> and then issues the same request again and it fails, leading to a violation of
>> that customers SLA.  In this case I would suggest that it could be considered
>> an exception since the system is not delivering the service that it was
>> intended to deliver.
>
> As I'm sure you're aware Chris, it looks like StarlingX has a kind of
> post-mortem query utility to try and figure out where requested resources didn't
> end up yielding a resource provider (for a compute node):
>
> https://github.com/starlingx-staging/stx-nova/commit/71acfeae0d1c59fdc77704527d763bd85a276f9a#diff-94f87e728df6465becce5241f3da53c8R330
>
>
> But as you noted way earlier in this thread, it might not be the actual reasons
> at the time of the failure and in a busy cloud could quickly change.

Just noticed this email, sorry for the delay.

The bit you point out isn't a post-mortem query but rather a way of printing out 
the rejection reasons that were stored (via calls to filter_reject()) at the 
time the request was processed by each filter.

Chris