Open Stack

On 6/21/2011 1:09 PM, Scott Moser wrote:
> On Tue, 21 Jun 2011, Thorsten von Eicken wrote:
>
>>>> 3. How does one send the configuration drive content?  What is the API
>>>> call where we provide the configuration information and what is the
>>>> expected format?
>>> In another message on this thread, Christopher said :
>>>>> a small ~64MB ISO formatted volume that would be attached and mounted
>>>>> read-only by the guest instance on boot
>>> I think we can greatly increase the functionality of this feature by
>>> removing restrictions.   The essence of this feature is that you're
>>> allowing the user to provide you with some data that you'll then put on a
>>> volume, attach the volume to the guest, and boot the guest.
>>>
>>> That can all be done today within AWS with a utility instance, by doing:
>>>  * launch utility instance
>>>  * attach volume to utility instance
>>>  * populate volume via 'mkisofs' or anything else inside the instance
>>>  * snapshot volume
>>>  * [ delete original volume ]
>>>  * launch instance with --block-device-mapping="....snap-abcdefg"
>>>
>>> So, to me, the only value of this spec is being able to do that list of
>>> things above without the utility instance.
>> While I agree with you and think that what you propose is nice, there is
>> a different aspect that you're perhaps missing, which is simplicity of
>> implementation. There's a huge implementation difference if the host
>> gets handed a small amount of data (say <1MB), drops it into a tempfs or
>> loopback-fs, and makes that available as drive to the guest, vs.
>> creating a mountable volume in the cloud that could be attached to any
>> VM and then mounting that across the network at boot time. Maybe I'm
>> misunderstanding something.
> volumes created at boot-time from snapshots is a requirement for
> "boot-from-volume" (http://wiki.openstack.org/BootFromVolume), so
> utilizing that function make sense to me.
>
> 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
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
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?)  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.

Thorsten