Putting on my "sorry-but-it-is-my-job-to-get-in-your-way" hat (aka security), let's be careful how generous we are with the user and data we hand back. It should give enough information to be useful but no more. I don't want to see us opened to weird attack vectors because we're exposing internal state too generously.
In short let's aim for a slow roll of extra info in, and evaluate each data point we expose (about a failure) before we do so. Knowing more about a failure is important for our users. Allowing easy access to information that could be used to attack / increase impact of a DOS could be bad. I think we can do it but it is important to not swing the pendulum too far the other direction too fast (give too much info all of a sudden). --Morgan Sent via mobile > On Jan 31, 2015, at 08:57, James E. Blair <cor...@inaugust.com> wrote: > > Sean Dague <s...@dague.net> writes: > >>> On 01/31/2015 05:24 AM, Duncan Thomas wrote: >>> 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). >> >> 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. > > I agree that we should find the right balance. Some anecdata from > infra-as-a-user: we have seen OpenStack sometimes unable to allocate a > public IP address for our servers when we cycle them too quickly with > nodepool. That shows up as an opaque error for us, and it's only by > chatting with the operators that we know what's going on, yet, there > might be things we can do to reduce the occurrence (like rebuild nodes > instead of destroying them; delay before creating again; etc.). > > So I would suggest that when we search for the sweet spot of how much > detail to include, we be somewhat generous with the user, who after all, > is likely to be technically competent and frustrated if they are > replacing systems that they can control and diagnose with a black box > that has a habit of saying "no" at random times for no discernible > reason. > > -Jim > > __________________________________________________________________________ > 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 __________________________________________________________________________ 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
