On 02/02/2015 12:54 AM, Christopher Yeoh wrote: > > > On Sun, Feb 1, 2015 at 2:57 AM, Sean Dague <s...@dague.net > <mailto:s...@dague.net>> wrote: > > On 01/31/2015 05:24 AM, Duncan Thomas wrote: > > Hi > > > > This discussion came up at the cinder mid-cycle last week too, > > specifically in the context of 'Can we change the details text in an > > existing error, or is that an unacceptable API change'. > > > > I have to second security / operational concerns about exposing > too much > > granularity of failure in these error codes. > > > > For cases where there is something wrong with the request (item out of > > range, invalid names, feature not supported, etc) I totally agree that > > we should have good, clear, parsable response, and standardisation > would > > be good. Having some fixed part of the response (whether a numeric > code > > or, as I tend to prefer, a CamelCaseDescription so that I don't > have to > > go look it up) and a human readable description section that is > subject > > to change seems sensible. > > > > What I would rather not see is leakage of information when something > > internal to the cloud goes wrong, that the tenant can do nothing > > against. We certainly shouldn't be leaking internal implementation > > details like vendor details - that is what request IDs and logs > are for. > > The whole point of the cloud, to me, is that separation between the > > things a tenant controls (what they want done) and what the cloud > > provider controls (the details of how the work is done). > > > > For example, if a create volume request fails because cinder-scheduler > > has crashed, all the tenant should get back is 'Things are broken, try > > again later or pass request id 1234-5678-abcd-def0 to the cloud > admin'. > > They should need to or even be allowed to care about the details > of the > > failure, it is not their domain. > > Sure, the value really is in determining things that are under the > client's control to do differently. A concrete one is a multi hypervisor > cloud with 2 hypervisors (say kvm and docker). The volume attach > operation to a docker instance (which presumably is a separate set of > instance types) can't work. The user should be told that that can't work > with this instance_type if they try it. > > That's actually user correctable information. And doesn't require a > ticket to move forward. > > I also think we could have a detail level knob, because I expect the > level of information exposure might be considered different in public > cloud use case vs. a private cloud at an org level or a private cloud at > a dept level. > > > That could turn into a major compatibility issue if what we returned > could (and > probably would between public/private) change between clouds? If we want > to encourage > people to parse this sort of thing I think we need to settle on whether > we send the > information back or not for everyone.
Sure, it's a theoretical concern. We're not going to get anywhere rat holing on theoretical concerns though, lets get some concrete instances out there to discuss. -Sean -- Sean Dague http://dague.net __________________________________________________________________________ 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