Sure that makes sense (less dependency on guest file-systems). Although one of my concerns was that I thought this config drive stuff was only in the openstack api and not in the EC2 one. So that limits the market there (especially as openstack really needs some love given to the EC2 stuff)? It seems like cloud-init could work with this netcfg "service" and setup the network, that might be the best approach. Its just cloud-init needs to be made less distro-centric. Is there any plans for that? It seems like it could do this (or interact with python-netcf). -Josh
On 2/15/12 6:35 AM, "Scott Moser" <[email protected]> wrote: On Wed, 15 Feb 2012, Richard W.M. Jones wrote: > On Tue, Feb 14, 2012 at 10:56:18PM +0000, Pádraig Brady wrote: > > The netcf lib looks interesting. Perhaps it could leverage > > libguestfs (already integrated) to maximise the types and > > configurations of guests it could target? > > It's an interesting thought, not one that I'd really thought about > before. It may be possible to do something like using guestmount[1] > to mount the guest's disk(s) and then run netcf in a chroot on those > disks. That would seem to be the minimal disruption to netcf, but I > will have to discuss this with Laine Stump and look at the netcf code ... Its possible I just wasn't clear in my original description, but I really prefer *no* mounting of guests or expectations of their filesystems or knowledge of their internals. I whole-heartedly agree that libguestfs provides an awesome feature set, and if injection needs to be done, its probably the right way to do it. However, even with libguestfs, a 'chroot' makes all sorts of assumptions about the guest that you don't *have* to make if you just attach a config_drive with a description of the network interfaces to the OS and let it deal with that. Personally, the ideal solution to me is that every guest has a management network (which likely comes up as eth0 -- i realize that is non-trivial). On that network, dhcp is available, and after successful acquisition of address via that interface, a network service is available. That network service then provides network configuration for other devices that are attached. Example hack-like script that I'd add to cirrOS. dhclient -i eth0 wget http://169.254.169.254/netcfg/1.0 -O out cirrosNetFromNetCfg out Where 'cirrosNetFromNetCfg' is some utility that I write for cirros that knows how to turn netcfg into cirros specific network configuration. Apparently, having dhcp even on a management only network is non-desireable in some cases. In *that* case, my preferred mechanism is changed a bit, and looks like this to support both cases: cfg_drive_candidate=$(tail -n 1 /proc/partitions) netcfg="/tmp/netcfg" if [ -b "$cfg_drive_candidate" ] && mount -t vfat "$cfg_drive_candidate" /mnt; then if [ -e /mnt/netcfg/1.0 ]; then cp /mnt/netcfg/1.0 "$netcfg" netcfg=/tmp/netcfg fi umount /mnt fi if ! [ -e "$netcfg" ]; then dhclient -i eth0 wget http://169.254.169.254/netcfg/1.0 -O "$netcfg" fi [ -e "$netcfg" ] && cirrosNetFromNetCfg "$netcfg" || { echo "FAIL! no netcfg!"; exit 1; } That way, as the author of cirros, if I want it to run in openstack, I can do everything myself. I don't have to first get 'netcfg' to support cirros configuration or worry about getting a tiny bug fixed in it and propogated back to versions that would be running on old hosts. I don't have to have pick a filesystem that guestfs understands, or make sure that some random linux version is going to be able to 'chroot' into a filesystem after it mounted it. All I had to do was: a.) support vfat (and virtio) b.) write 'cirrosNetFromNetCfg' c.) support dhcp The same general solution can also apply to ssh keys, although I personally think that network configuration is the only thing that I *need* to bootstrap, and then its best to have network metadata services rather as opposed to putting more stuff into the config_drive. IMO its best to put burdon on image creators. It puts power in their hands and makes them able to make images that say "Runs on Openstack Essex" without saying "assuming you have libguestfs support for btrfs and netcfg version 3.2".
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
