Open Stack

On Tue, 21 Jun 2011, Thorsten von Eicken wrote:

> > I agree that there is a difference in difficulty of implementation between
> > a "quick fix" and a more generic fix.  I believe what I'm suggesting is a
> > generic fix that will address longer term needs of openstack, and do so in
> > a fairly clean way.
> I don't think a simple local loopback volume is a "quick fix". There

I really do think its a quick fix.  You have these *really* nice building
blocks that are being added to openstack, but you don't want to use them,
because it will make things more difficult right now.

Instead we'd be adding a 3rd type of disk (instance-store, ebs,
config-drive -- sorry for using AWS terms I'm just more familiar with
them, and I think others generally understand them). As the
etherpad/thread originally raised, there are decisions that have to be
made specifically for this new type of disk, like:
 * can it be detached?
 * what size can it be?
 * is it read/write ?

Those questions are already (or will have to be solved) for the other
types.  If you use those other types, you inherit their behavior.

Ignoring the need for "meta-data" (provided by the cloud itself), we can
almost implement this as a normal user of the API with *no* further
changes to openstack.  (See my original message regarding doing this with
a utility instance.)  That almost says to me that openstack should not
bother with this, but let it be sorted out at a layer above.  Thats what
brought me to suggest basically a mechanism for dropping the need for a
utility instance.

> just is a huge difference between passing a few KB of config data in a
> secure way to an instance and adding a network disk volume at boot. I

I would not insist that at all that this needs to be a volume is, in fact
a network block storage.  It might suffice to be an 'instance-store' type.
I only suggested at one point that if it *were* a network block storage,
then the semantics would be already defined, and existing behavior (with
existing API entry points) could be used to modify the volume content on
shutdown and startup.

> sure want the latter, but not confuse it with the former. When passing
> some keys/creds into an instance, I rather not have to deal with the
> security implications of a network volume (for example, can someone else
> snapshot the contents and use that to "impersonate" the instance or get
> at the creds?)

I think that network block storage is next to useless if openstack
cannot correctly manage that.  I'd even go so far as to say openstack's
momentum and reputation would be severely tarnished if a bug leaked data
from one account to another.  Surely Rackspace or any other
openstack-user/cloud-provider would be more than a little interested in
making sure that one user does not get access to another user's volumes.

Simply, I really don't think you "have to deal with" that.  It had better
already work.

> Also, I don't know whether network attached volumes are
> a feature that all OpenStack implementations must implement. Given how
> many clouds don't have that, and the extra HW cost required to make it
> work in a reasonable manner, I wonder whether it's smart to require it,
> and if you don't you loose the configuration data feature.

network block storage does not imply/require that it be high end iscsi
devices.  We have nova-volume that works right now with commodity grade
hardware/software.