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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
