Open Stack

You are splitting hairs here...

If I was talking to nova about a vm but nova was having an issue
communicating to neutron to get the vm network/ip details it would be
helpful to know the error happened in neutron vs's a generic 500 error.
Or if I ask nova to give me an image list (or snapshot create) and glance
is throwing an error it would be helpful to know the error came from
glance vs's nova.  We have people that integrate to nova vs's integrating
to all the other projects because they can get almost everything they
want/care about directly from nova.

Point being, raising something through the api that an error happened in
another subsystem is better at a minimum from an ops perspective and
creates (imho) a better end-user experience.
____________________________________________
 
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.




On 1/30/15, 2:33 PM, "Everett Toews" <everett.toews at RACKSPACE.COM> wrote:

>On Jan 30, 2015, at 3:17 PM, Jesse Keating <jlk at bluebox.net> wrote:
>
>> On 1/30/15 1:08 PM, Everett Toews wrote:
>>> Project: A client dealing with the API already knows what project
>>> (service) they¹re dealing with. Including this in an API error message
>>> would be redundant. That¹s not necessarily so bad and it could actually
>>> be convenient for client logging purposes to have this there.
>>> 
>> 
>> Is this really true though? When your interaction with nova is being
>>thwarted by a problem with keystone, wouldn't the end user want to see
>>the keystone name in there as a helpful breadcrumb as to where the
>>problem actually lies?
>
>Once I have the token from Keystone, I¹ll be talking directly to the
>services. So either something goes wrong with Keystone and I get no token
>or I get a token and talk directly to a service. Either way a client
>knows who it's talking to.
>
>I suppose one possible case outside of that is token revocation. If I¹m
>talking to a service and the token gets revoked, does the error originate
>in Keystone? I¹m not really sure.
>
>Everett
>
>
>_______________________________________________
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators