openstack team mailing list archive

[Joshua Harlow <harlowja@xxxxxxxxxxxxx>]

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)?
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

On 2/15/12 6:35 AM, "Scott Moser" <smoser@xxxxxxxxxx> wrote:

On Wed, 15 Feb 2012, Richard W.M. Jones wrote:

> On Tue, Feb 14, 2012 at 10:56:18PM +0000, Pádraig Brady wrote:
> > The netcf lib looks interesting. Perhaps it could leverage
> > libguestfs (already integrated) to maximise the types and
> > configurations of guests it could target?
>
> It's an interesting thought, not one that I'd really thought about
> before.  It may be possible to do something like using guestmount[1]
> to mount the guest's disk(s) and then run netcf in a chroot on those
> disks.  That would seem to be the minimal disruption to netcf, but I
> will have to discuss this with Laine Stump and look at the netcf code ...

Its possible I just wasn't clear in my original description, but I really
prefer *no* mounting of guests or expectations of their filesystems or
knowledge of their internals.

I whole-heartedly agree that libguestfs provides an awesome feature set,
and if injection needs to be done, its probably the right way to do it.

However, even with libguestfs, a 'chroot' makes all sorts of assumptions
about the guest that you don't *have* to make if you just attach a
config_drive with a description of the network interfaces to the OS and
let it deal with that.

Personally, the ideal solution to me is that every guest has a management
network (which likely comes up as eth0 -- i realize that is non-trivial).
On that network, dhcp is available, and after successful acquisition of
address via that interface, a network service is available. That network
service then provides network configuration for other devices that are
attached.  Example hack-like script that I'd add to cirrOS.
  dhclient -i eth0
  wget http://169.254.169.254/netcfg/1.0 -O out
  cirrosNetFromNetCfg out

Where 'cirrosNetFromNetCfg' is some utility that I write for cirros that
knows how to turn netcfg into cirros specific network configuration.

Apparently, having dhcp even on a management only network is
non-desireable in some cases.  In *that* case, my preferred mechanism is
changed a bit, and looks like this to support both cases:
 cfg_drive_candidate=$(tail -n 1 /proc/partitions)
 netcfg="/tmp/netcfg"
 if [ -b "$cfg_drive_candidate" ] &&
    mount -t vfat "$cfg_drive_candidate" /mnt; then
    if [ -e /mnt/netcfg/1.0 ]; then
      cp /mnt/netcfg/1.0 "$netcfg"
      netcfg=/tmp/netcfg
    fi
    umount /mnt
 fi
 if ! [ -e "$netcfg" ]; then
   dhclient -i eth0
   wget http://169.254.169.254/netcfg/1.0 -O "$netcfg"
 fi
 [ -e "$netcfg" ] && cirrosNetFromNetCfg "$netcfg" ||
   { echo "FAIL! no netcfg!"; exit 1; }

That way, as the author of cirros, if I want it to run in openstack, I can
do everything myself.  I don't have to first get 'netcfg' to support
cirros configuration or worry about getting a tiny bug fixed in it and
propogated back to versions that would be running on old hosts.  I don't
have to have pick a filesystem that guestfs understands, or make sure that
some random linux version is going to be able to 'chroot' into a
filesystem after it mounted it.

All I had to do was:
 a.) support vfat (and virtio)
 b.) write 'cirrosNetFromNetCfg'
 c.) support dhcp

The same general solution can also apply to ssh keys, although I
personally think that network configuration is the only thing that I
*need* to bootstrap, and then its best to have network metadata services
rather as opposed to putting more stuff into the config_drive.

IMO its best to put burdon on image creators.  It puts power in their
hands and makes them able to make images that say
"Runs on Openstack Essex" without saying "assuming you have libguestfs
support for btrfs and netcfg version 3.2".