[Openstack] Feedback on Portable Configuration Drive Blueprint

Scott Moser smoser at ubuntu.com
Wed Jun 22 01:33:05 UTC 2011


On Tue, 21 Jun 2011, Vishvananda Ishaya wrote:

>
> > 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.

Yes, and I admit to not having a real good idea on how to allow for 2
types of metadata (1 user, 1 system) in that image.  The only thing I
thought was possibly  just attaching 2 volumes, its not a modern operating
system has issues handling multiple volumes.  You'd just label one
"meta-data" and one would have whatever the user put on it.

> >
> > 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.

Well, it still is limiting. Much in the same way that real users have have
found AWS user-data to be limiting.  There are possibly multiple entities
involved in the launching of an instance.  Ie, "rightscale and end user",
or "landscape and end user" or "turnkey and end user".  With the current
AWS solution, neither one fully controls the content of
http://instance-data/latest/user-data .  They have to share it, meaning
you're forced to do something like cloud-init does with multi-part mime to
allow multiple parts into that single name space.

If you you switch from rightscale to landscape, it is possible that the
agreement on how to share that space (if any) changes, and so your code
has to change.

This could be addressed by the API allowing multiple key,value pairs that
would end up appearing in the filesystem as filename and filecontent.  In
that way, then rightscale or landscape or turnkey just need to allow the
end user to specify some keys, and they specify some keys, and as long as
the 2 don't collide, the namespace can easily be shared.




More information about the Openstack mailing list