openstack team mailing list archive

[Vishvananda Ishaya <vishvananda@xxxxxxxxx>]

> If you don't like the name, thats fine, thats why I suggested it be made
> configurable.  Additionally, I want the user to bypass openstack
> completely, and give what looks like garbage to it, but the VM will
> understand.
> 
> This is something Amazon did right in their user data.  You can give
> whatever you want in it, and it can be obtained from inside the instance
> bit-for-bit.  The only real restriction is a 16k limit (which I would hope
> is not duplicated here).
> 
> I'm hoping that this "config drive" can be used in the same way.  I'm not
> asking you to implement OVF ISO transport, I'm asking you to let the
> entity that launches the instance decide what exactly the contents are.

The problem is that there are two types of data as exemplified by user data and metadata in the amazon world.  Some data needs to be configuratble by the user, but some should be set by the cloud.

> 
> My suggestion really is to keep openstack providing dynamically
> provisioned hardware (and disk contents).  As you've been burned in the
> past, so have others.  Very simply, you can *not* come up with a solution
> that will will be easy for all current and future operating systems.
> 
> By letting the entity launching the instance indicate what the contents of
> the disk are, your only restriction on future guests is that they can read
> the disk.

I understand the push to go towards a really general solution, but if we go too general we sacrifice ease of use.  I think we need a middle ground here.  Allow for some data to be set by the user in whatever format, and allow some to be set by the cloud in a standard format.

Personally, I think forcing a specific disk format like fat32 is not too extreme.  If we provide r/w access and a binary blob for whatever user data I think we have found a good middle ground between flexibility and ease of use.

Vish