openstack team mailing list archive

[Joshua Harlow <harlowja@xxxxxxxxxxxxx>]

Sounds great to me.

Looking forward to that. In the mean-time should there be an attempt at getting something into essex (or not?) that may just be what the grid-dynamics people have done? Thoughts?

-Josh

On 2/15/12 1:25 PM, "Scott Moser" <smoser@xxxxxxxxxx> wrote:

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.