<HTML>
<HEAD>
<TITLE>Re: [Openstack] RHEL / CentOS - interfaces.template</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Ya, it seems like guestfs and netcf are being worked on by RH (at least in some part).<BR>
Maybe someone from there can chime in. <BR>
It would be awesome to just use guestfs and something like “guestnetwork” (using netcf?) for network config or just have it be a part of guestfs. <BR>
Josh<BR>
<BR>
On 2/14/12 2:56 PM, "Pádraig Brady" <<a href="P@draigBrady.com">P@draigBrady.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>On 02/14/2012 06:48 PM, Scott Moser wrote:<BR>
> On Tue, 14 Feb 2012, Leandro Reox wrote:<BR>
><BR>
>> Hi guys,<BR>
>><BR>
>> Anyone already implemented networking injection to RHEL systems acting as a<BR>
>> guest ? If no any plans to make it to Essex final ?<BR>
><BR>
><BR>
> Before we go down the road of trying to write system network configuration<BR>
> scripts for each potential guest OS, I'd suggest that its would be better<BR>
> to either:<BR>
> a.) just accept that 'interfaces' is the openstack format and guests<BR>
> should need to read that.<BR>
> b.) create a OS agnostic interface configuration format.<BR>
><BR>
> While you may be looking at my email address and assuming that I think 'a'<BR>
> is the right answer only to make it harder for anyone else.<BR>
><BR>
> However, the reason I dislike the current solution (or going down a path<BR>
> of implementing population mechanisms for other operating systems) is<BR>
> 1.) you cannot possibly support all possible operating systems<BR>
> 2.) injecting files assumes host OS knowledge (or guestfs knowledge) of<BR>
> the guest filesystem<BR>
> 3.) specific files indicates that the host can somehow determine which<BR>
> format the guest is expecting (or also unacceptable, only allowing<BR>
> this configuration for one OS per cloud).<BR>
> 4.) injecting files via overwriting them is lossy and possibly<BR>
> destructive to a guest (imagine other vpn routes inserted there or<BR>
> something else more advanced).<BR>
><BR>
> I would *much* rather there be a "openstack networking configuration file<BR>
> format" that was put into config_drive if dhcp was not sufficient.<BR>
><BR>
> Then, the guests are just made to read that information that is in a<BR>
> standard, easily documetable format and respond accordingly.<BR>
<BR>
I have to agree with this.<BR>
<BR>
Ideally openstack would not be polluted with all the<BR>
vagaries of guest network configuration.<BR>
Though if --flat_injected is a required and common case,<BR>
then perhaps in the short term it would be worth adding something<BR>
like the griddynamics patch to support the two most common linux formats?<BR>
Until now, we've not considered this a priority.<BR>
<BR>
Notes:<BR>
<BR>
This issue is already tracked at:<BR>
<a href="https://bugs.launchpad.net/nova/+bug/678395">https://bugs.launchpad.net/nova/+bug/678395</a><BR>
<BR>
The Red Hat openstack packages do not have any extra support in this regard<BR>
(especially since this is a guest issue). All file injection patches supporting<BR>
Red Hat (derived) _hosts_, including libguestfs support, are upstream in Essex.<BR>
<BR>
The netcf lib looks interesting. Perhaps it could leverage libguestfs<BR>
(already integrated) to maximise the types and configurations of guests it could target?<BR>
<BR>
Points 1 & 2 above are more general and apply to ssh key injection also I think.<BR>
libguestfs helps a lot to abstract those guest specific issues away.<BR>
<BR>
cheers,<BR>
Pádraig.<BR>
<BR>
_______________________________________________<BR>
Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><BR>
Post to : <a href="openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><BR>
Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><BR>
More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>