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
__________________________________________________________________________
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
