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