Additional verbosity information to standard API fault messages within OpenStack common project
> This feature aims to allow adding more verbose details within a standard API fault messages, to let a client/user have more information in case of failures.
> Today, some of the standard failures will be well understood when using just the HTTP error codce, the 'message' and 'details' attributes (such as '404'/ 'Item Not found').
> But, in other cases, such as '500'/'Internal Erro', there might be scenarios in which we would like to give more verbose information regarding the failure, and the 'details' attribute won't be enough for that.
> This feature should be part of the common infrastructure within the Oslo project as all other project should refer and use it.
> More details can be found here:
https:/
Blueprint information
- Status:
- Not started
- Approver:
- Mark McLoughlin
- Priority:
- Undefined
- Drafter:
- Maty Grosz
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Drafting
- Series goal:
- None
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
Could you describe what the Oslo API for this would look like? i.e. what methods, classes, etc. you'd add to Oslo to enable this?
Also, what do you think the timeframe for completing this would be?
Finally, had you planned to propose a session discussing this proposal at the design summit? -- markmc
===
> I have uploaded a new doc describing proposed classes and methods.
> The timeframe for such proposal should be short (no more than a couple of days) in the Oslo project. The 'real' work is to use this proposal in all the projects (nova, cinder, glance etc.). There it might be longer (need to understand first were it can be used)
> Tests within the Oslo project will be basic ones. Integration tests will be added once the proposal will be integrated withing the other projects.
> I proposed a session discussion for the coming summit, as you suggested.
-- maty-grosz
===
I'm not sure why, the class definition tables are empty in the doc when I view it.
As you say, it's important to understand how this API will be used in other projects. I'd like to see some examples of how this API would be integrated with other projects. Without that, it's really impossible to know how workable the proposal is. Thanks. -- markmc
===
Yes, can you verify that the google doc is accurate? The tables at the end are blank for me, too. It would be nice to have the document moved to the wiki where others can comment on it easily, too. -- dhellmann
===
Hey *,
First I would like first to apologize for the time waiting... I will update my blueprint using OpenStack Wiki ASAP.
===
Hey *,
I have uploaded an updated suggested design document to OpenStack Wiki:
https:/
I would like to have your comments, please.
Thanks
Maty
===
Do you have a specific example of a place in an OpenStack project that you want to be able to take advantage of this capability? The PDF you linked provides an example, but it's not clear if it is real or hypothetical.
What are the parameter values in the response? Are those arguments the caller would have passed in to the API?
-- dhellmann
