Open Stack

On 02/02/2015 12:54 AM, Christopher Yeoh wrote:
> 
> 
> On Sun, Feb 1, 2015 at 2:57 AM, Sean Dague <sean at dague.net
> <mailto:sean at 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