On Wed, 15 Feb 2012, Joshua Harlow wrote: > 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)?
You could most certainly just attach "network config-drive" by default if nova is not expecting dhcp to work, then that covers the ec2 api case. > 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 I have no objections to cloud-init being less distro-centric. Credit to Garrett Holmstrom , cloud-init is now in Fedora. Its not finished [1], but, the work is at least known. [1] http://pkgs.fedoraproject.org/gitweb/?p=cloud-init.git;a=blob;f=cloud-init-README.fedora;h=99bf7ab9095d09a6c5435d11138d81e5574a45f7;hb=HEAD I personally would much prefer less interaction with the guest as opposed to more. I realize people will argue for this having something just *try* to configure the guest's networking via mount and /etc/ insertion of some mechanism or another. But the issue with that is it can go wrong, breaking the image, or losing data (ie, by incompletely updating/overwriting /etc/network/interfaces). I'm willing to add a blueprint for openstack F and implement "network config-drive" basically as I've described in the other post. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
