<HTML>
<HEAD>
<TITLE>Re: [Openstack] RHEL / CentOS - interfaces.template</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Sounds great to me.<BR>
<BR>
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?<BR>
<BR>
-Josh<BR>
<BR>
On 2/15/12 1:25 PM, "Scott Moser" <<a href="smoser@ubuntu.com">smoser@ubuntu.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>On Wed, 15 Feb 2012, Joshua Harlow wrote:<BR>
<BR>
> Sure that makes sense (less dependency on guest file-systems).<BR>
> 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.<BR>
> So that limits the market there (especially as openstack really needs<BR>
> some love given to the EC2 stuff)?<BR>
<BR>
You could most certainly just attach "network config-drive" by default if<BR>
nova is not expecting dhcp to work, then that covers the ec2 api case.<BR>
<BR>
> It seems like cloud-init could work with this netcfg "service" and setup the network, that might be the best approach.<BR>
<BR>
> 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).<BR>
> -Josh<BR>
<BR>
I have no objections to cloud-init being less distro-centric. Credit to<BR>
Garrett Holmstrom , cloud-init is now in Fedora. Its not finished [1],<BR>
but, the work is at least known.<BR>
<BR>
[1] <a href="http://pkgs.fedoraproject.org/gitweb/?p=cloud-init.git;a=blob;f=cloud-init-README.fedora;h=99bf7ab9095d09a6c5435d11138d81e5574a45f7;hb=HEAD">http://pkgs.fedoraproject.org/gitweb/?p=cloud-init.git;a=blob;f=cloud-init-README.fedora;h=99bf7ab9095d09a6c5435d11138d81e5574a45f7;hb=HEAD</a><BR>
<BR>
<BR>
I personally would much prefer less interaction with the guest as opposed<BR>
to more. I realize people will argue for this having something just *try*<BR>
to configure the guest's networking via mount and /etc/ insertion of some<BR>
mechanism or another. But the issue with that is it can go wrong,<BR>
breaking the image, or losing data (ie, by incompletely updating/overwriting<BR>
/etc/network/interfaces).<BR>
<BR>
I'm willing to add a blueprint for openstack F and implement "network<BR>
config-drive" basically as I've described in the other post.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>