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" <[email protected]> wrote: >On Jan 30, 2015, at 3:17 PM, Jesse Keating <[email protected]> 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 >[email protected] >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
