Interesting,

So the issue i think with using libvirt is that we want to use netcf inside a VM, not on the outside where we might have libvirt support and could do such an action (this involves file injection which is yucky), ideally we'd use this tool called cloud-init which does first time boot-like initialization (among other things). OpenStack would then write this network information + other metadata (say in the agonistic netcf format) then during first time booting cloud-init would pick that data back up, and write out the VM specific format (among other things it can do). Since we can't guarantee that the VM image that contains cloud-init has libvirt (thats a large dependency) it would be nice if we could just use the python interface (cloud-init is in python) and use the network writing functionality of netcf to do this writing (without libvirt).

That seems doable?

On Tue, Jun 19, 2012 at 8:30 AM, Laine Stump <laine@laine.org> wrote:
On 06/19/2012 10:30 AM, Daniel P. Berrange wrote:
> On Mon, Jun 18, 2012 at 02:21:48PM -0700, Joshua Harlow wrote:
>>    1. How actively maintained is this project, just incase.
> It is a core dependency of libvirt, so it is actively maintained
>
>>    2. Does netcf over-write configurations or does it have the capability
>>    to also merge configs (incase of user provided additions/configuration
>>    extras that we don’t want to over-write).
> The answer depends on the driver you are using. For the Linux drivers
> at least (Debian, Suse & Fedora/RHEL), netcf uses augeas to update
> the configs. When setting the config of an interface, any previous
> config for that interface will normally be discarded. So if there
> are config elements not currently supported by augeas/netcf that
> are required for correct operation, support should be added to
> netcf for them.
>
> From an OpenStack POV, I think I'd actually encourage use of the
> libvirt virNetworkPtr APIs rather than netcf directly. The use of

virInterface, actually :-)

> netcf is only really applicable to the Xen, UML, KVM/QEMU or LXC
> drivers in libvirt. If using something else like libvirt's drivers
> for VMWare, HyperV, VirtualBox, etc then netcf would be a wrong
> choice. By using libvirt, the applicable network device management
> driver would be correctly chosen to match the hypervisor driver.

Another advantage of using libvirt's virInterface API rather than netcf
is that libvirt has builtin RPC, while netcf is a local-machine-only
API. Everything supported by calling netcf directly is also supported in
a similar/identical API in libvirt.

_______________________________________________
netcf-devel mailing list
netcf-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/netcf-devel



--
--
Joshua Harlow (mR.aWesOmo)
facebook.com/jshharlow
flickr.com/jshharlow
YIM: jshharlow