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 Dague

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to