Open Stack

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 <corvus at inaugust.com> wrote:
> 
> Sean Dague <sean at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev