Open Stack

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