<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 1, 2015 at 2:57 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 01/31/2015 05:24 AM, Duncan Thomas wrote:<br>
> Hi<br>
><br>
> This discussion came up at the cinder mid-cycle last week too,<br>
> specifically in the context of 'Can we change the details text in an<br>
> existing error, or is that an unacceptable API change'.<br>
><br>
> I have to second security / operational concerns about exposing too much<br>
> granularity of failure in these error codes.<br>
><br>
> For cases where there is something wrong with the request (item out of<br>
> range, invalid names, feature not supported, etc) I totally agree that<br>
> we should have good, clear, parsable response, and standardisation would<br>
> be good. Having some fixed part of the response (whether a numeric code<br>
> or, as I tend to prefer, a CamelCaseDescription so that I don't have to<br>
> go look it up) and a human readable description section that is subject<br>
> to change seems sensible.<br>
><br>
> What I would rather not see is leakage of information when something<br>
> internal to the cloud goes wrong, that the tenant can do nothing<br>
> against. We certainly shouldn't be leaking internal implementation<br>
> details like vendor details - that is what request IDs and logs are for.<br>
> The whole point of the cloud, to me, is that separation between the<br>
> things a tenant controls (what they want done) and what the cloud<br>
> provider controls (the details of how the work is done).<br>
><br>
> For example, if a create volume request fails because cinder-scheduler<br>
> has crashed, all the tenant should get back is 'Things are broken, try<br>
> again later or pass request id 1234-5678-abcd-def0 to the cloud admin'.<br>
> They should need to or even be allowed to care about the details of the<br>
> failure, it is not their domain.<br>
<br>
</div></div>Sure, the value really is in determining things that are under the<br>
client's control to do differently. A concrete one is a multi hypervisor<br>
cloud with 2 hypervisors (say kvm and docker). The volume attach<br>
operation to a docker instance (which presumably is a separate set of<br>
instance types) can't work. The user should be told that that can't work<br>
with this instance_type if they try it.<br>
<br>
That's actually user correctable information. And doesn't require a<br>
ticket to move forward.<br>
<br>
I also think we could have a detail level knob, because I expect the<br>
level of information exposure might be considered different in public<br>
cloud use case vs. a private cloud at an org level or a private cloud at<br>
a dept level.<br>
<br></blockquote><div><br></div><div>That could turn into a major compatibility issue if what we returned could (and</div><div>probably would between public/private) change between clouds? If we want to encourage</div><div>people to parse this sort of thing I think we need to settle on whether we send the</div><div>information back or not for everyone. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">    -Sean<br>
<span class=""><br>
><br>
><br>
><br>
> On 30 January 2015 at 02:34, Rochelle Grober <<a href="mailto:rochelle.grober@huawei.com">rochelle.grober@huawei.com</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:rochelle.grober@huawei.com">rochelle.grober@huawei.com</a>>> wrote:<br>
><br>
>Â Â Â Hi folks!<br>
><br>
>Â Â Â Changed the tags a bit because this is a discussion for all projects<br>
>Â Â Â and dovetails with logging rationalization/standards/<br>
><br>
>Â Â Â At the Paris summit, we had a number of session on logging that kept<br>
>   circling back to Error Codes. But, these codes would not be http<br>
>Â Â Â codes, rather, as others have pointed out, codes related to the<br>
>Â Â Â calling entities and referring entities and the actions that<br>
>   happened or didn’t. Format suggestions were gathered from the<br>
>   Operators and from some senior developers. The Logging Working<br>
>Â Â Â Group is planning to put forth a spec for discussion on formats and<br>
>Â Â Â standards before the Ops mid-cycle meetup.<br>
><br>
>Â Â Â Working from a Glance proposal on error codes:<br>
>Â Â Â <a href="https://review.openstack.org/#/c/127482/" target="_blank">https://review.openstack.org/#/c/127482/</a> and discussions with<br>
>   operators and devs, we have a strawman to propose. We also have a<br>
>Â Â Â number of requirements from Ops and some Devs.<br>
><br>
>Â Â Â Here is the basic idea:<br>
><br>
>Â Â Â Code for logs would have four segments:<br>
>   Project                 Vendor/Component   Error<br>
>   Catalog number   Criticality<br>
>   Def     [A-Z] [A-Z] [A-Z]        -<br>
>Â Â Â [{0-9}|{A-Z}][A-Z] -Â Â Â Â Â [0000-9999]-Â Â Â Â Â Â Â Â Â Â Â Â [0-9]<br>
>   Ex.     CIN-                    NA-<br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 0001-<br>
>Â Â Â Â 2<br>
>           Cinder                  NetApp<br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â driver error no<br>
>Â Â Â Â Â Â Criticality<br>
>   Ex.     GLA-                   0A-<br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 0051<br>
>Â Â Â Â Â 3<br>
>           Glance                 Api<br>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â error no<br>
>Â Â Â Criticality<br>
>   Three letters for project, Either a two letter vendor code or a<br>
>Â Â Â number and letter for 0+letter for internal component of project<br>
>   (like API=0A, Controller =0C, etc), four digit error number which<br>
>Â Â Â could be subsetted for even finer granularity, and a criticality number.<br>
><br>
>Â Â Â This is for logging purposes and tracking down root cause faster for<br>
>Â Â Â operators, but if an error is generated, why can the same codes be<br>
>   used internally for the code as externally for the logs? This also<br>
>Â Â Â allows for a unique message to be associated with the error code<br>
>   that is more descriptive and that can be pre translated. Again, for<br>
>Â Â Â logging purposes, the error code would not be part of the message<br>
>   payload, but part of the headers. Referrer IDs and other info would<br>
>Â Â Â still be expected in the payload of the message and could include<br>
>   instance ids/names, NICs or VIFs, etc. The message headers is code<br>
>Â Â Â in Oslo.log and when using the Oslo.log library, will be easy to use.<br>
><br>
>Â Â Â Since this discussion came up, I thought I needed to get this info<br>
>Â Â Â out to folks and advertise that anyone will be able to comment on<br>
>   the spec to drive it to agreement. I will be advertising it here<br>
>   and on Ops and Product-WG mailing lists. I’d also like to invite<br>
>   anyone who want to participate in discussions to join them. We’ll<br>
>Â Â Â be starting a bi-weekly or weekly IRC meeting (also announced in the<br>
>Â Â Â stated MLs) in February.<br>
><br>
>Â Â Â And please realize that other than Oslo.log, the changes to make the<br>
>Â Â Â errors more useable will be almost entirely community created<br>
>   standards with community created tools to help enforce them. None<br>
>Â Â Â of which exist yet, FYI.<br>
><br>
>Â Â Â --RockyG<br>
><br>
><br>
><br>
><br>
><br>
><br>
>Â Â Â From: Eugeniya Kudryashova [mailto:<a href="mailto:ekudryashova@mirantis.com">ekudryashova@mirantis.com</a><br>
>Â Â Â <mailto:<a href="mailto:ekudryashova@mirantis.com">ekudryashova@mirantis.com</a>>]<br>
>Â Â Â Sent: Thursday, January 29, 2015 8:33 AM<br>
>Â Â Â To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
</div></div>>Â Â Â <mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span class="">>Â Â Â Subject: [openstack-dev] [api][nova] Openstack HTTP error codes<br>
><br>
><br>
>Â Â Â Hi, all<br>
><br>
><br>
><br>
>Â Â Â Openstack APIs interact with each other and external systems<br>
>Â Â Â partially by passing of HTTP errors. The only valuable difference<br>
>Â Â Â between types of exceptions is HTTP-codes, but current codes are<br>
>   generalized, so external system can’t distinguish what actually<br>
>Â Â Â happened.<br>
><br>
><br>
>Â Â Â As an example two different failures below differs only by error<br>
>Â Â Â message:<br>
><br>
><br>
>Â Â Â request:<br>
><br>
>Â Â Â POST /v2/790f5693e97a40d38c4d5bfdc45acb09/servers HTTP/1.1<br>
><br>
>Â Â Â Host: <a href="http://192.168.122.195:8774" target="_blank">192.168.122.195:8774</a><br>
</span>>Â Â Â <<a href="http://192.168.122.195:8774" target="_blank">http://192.168.122.195:8774</a>><<a href="http://192.168.122.195:8774" target="_blank">http://192.168.122.195:8774</a>><br>
<span class="">><br>
>Â Â Â X-Auth-Project-Id: demo<br>
><br>
>Â Â Â Accept-Encoding: gzip, deflate, compress<br>
><br>
>Â Â Â Content-Length: 189<br>
><br>
>Â Â Â Accept: application/json<br>
><br>
>Â Â Â User-Agent: python-novaclient<br>
><br>
>Â Â Â X-Auth-Token: 2cfeb9283d784cfba694f3122ef413bf<br>
><br>
>Â Â Â Content-Type: application/json<br>
><br>
><br>
>Â Â Â {"server": {"name": "demo", "imageRef":<br>
>Â Â Â "171c9d7d-3912-4547-b2a5-ea157eb08622", "key_name": "test",<br>
>Â Â Â "flavorRef": "42", "max_count": 1, "min_count": 1,<br>
>Â Â Â "security_groups": [{"name": "bar"}]}}<br>
><br>
>Â Â Â response:<br>
><br>
>Â Â Â Â Â HTTP/1.1 400 Bad Request<br>
><br>
>Â Â Â Content-Length: 118<br>
><br>
>Â Â Â Content-Type: application/json; charset=UTF-8<br>
><br>
>Â Â Â X-Compute-Request-Id: req-a995e1fc-7ea4-4305-a7ae-c569169936c0<br>
><br>
>Â Â Â Date: Fri, 23 Jan 2015 10:43:33 GMT<br>
><br>
><br>
>Â Â Â {"badRequest": {"message": "Security group bar not found for project<br>
>Â Â Â 790f5693e97a40d38c4d5bfdc45acb09.", "code": 400}}<br>
><br>
><br>
>Â Â Â and<br>
><br>
><br>
>Â Â Â request:<br>
><br>
>Â Â Â POST /v2/790f5693e97a40d38c4d5bfdc45acb09/servers HTTP/1.1<br>
><br>
>Â Â Â Host: <a href="http://192.168.122.195:8774" target="_blank">192.168.122.195:8774</a><br>
</span>>Â Â Â <<a href="http://192.168.122.195:8774" target="_blank">http://192.168.122.195:8774</a>><<a href="http://192.168.122.195:8774" target="_blank">http://192.168.122.195:8774</a>><br>
<div><div class="h5">><br>
>Â Â Â X-Auth-Project-Id: demo<br>
><br>
>Â Â Â Accept-Encoding: gzip, deflate, compress<br>
><br>
>Â Â Â Content-Length: 192<br>
><br>
>Â Â Â Accept: application/json<br>
><br>
>Â Â Â User-Agent: python-novaclient<br>
><br>
>Â Â Â X-Auth-Token: 24c0d30ff76c42e0ae160fa93db8cf71<br>
><br>
>Â Â Â Content-Type: application/json<br>
><br>
><br>
>Â Â Â {"server": {"name": "demo", "imageRef":<br>
>Â Â Â "171c9d7d-3912-4547-b2a5-ea157eb08622", "key_name": "foo",<br>
>Â Â Â "flavorRef": "42", "max_count": 1, "min_count": 1,<br>
>Â Â Â "security_groups": [{"name": "default"}]}}<br>
><br>
>Â Â Â response:<br>
><br>
>Â Â Â HTTP/1.1 400 Bad Request<br>
><br>
>Â Â Â Content-Length: 70<br>
><br>
>Â Â Â Content-Type: application/json; charset=UTF-8<br>
><br>
>Â Â Â X-Compute-Request-Id: req-87604089-7071-40a7-a34b-7bc56d0551f5<br>
><br>
>Â Â Â Date: Fri, 23 Jan 2015 10:39:43 GMT<br>
><br>
><br>
>Â Â Â {"badRequest": {"message": "Invalid key_name provided.", "code": 400}}<br>
><br>
><br>
>Â Â Â The former specifies an incorrect security group name, and the<br>
>Â Â Â latter an incorrect keypair name. And the problem is, that just<br>
>Â Â Â looking at the response body and HTTP response code an external<br>
>   system can’t understand what exactly went wrong. And parsing of<br>
>   error messages here is not the way we’d like to solve this problem.<br>
><br>
><br>
>Â Â Â Another example for solving this problem is AWS EC2 exception codes [1]<br>
><br>
><br>
>Â Â Â So if we have some service based on Openstack projects it would be<br>
>Â Â Â useful to have some concrete error codes(textual or numeric), which<br>
>Â Â Â could allow to define what actually goes wrong and later correctly<br>
>Â Â Â process obtained exception. These codes should be predefined for<br>
>Â Â Â each exception, have documented structure and allow to parse<br>
>Â Â Â exception correctly in each step of exception handling.<br>
><br>
><br>
>   So I’d like to discuss implementing such codes and its usage in<br>
>Â Â Â openstack projects.<br>
><br>
>Â Â Â [1] -<br>
>Â Â Â <a href="http://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html" target="_blank">http://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html</a><br>
>Â Â Â _______________________________________________<br>
>Â Â Â Product-wg mailing list<br>
</div></div>>Â Â Â <a href="mailto:Product-wg@lists.openstack.org">Product-wg@lists.openstack.org</a> <mailto:<a href="mailto:Product-wg@lists.openstack.org">Product-wg@lists.openstack.org</a>><br>
<span class="im HOEnZb">>Â Â Â <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Duncan Thomas<br>
><br>
><br>
</span><span class="im HOEnZb">> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>