[Ovirt-devel] [netcf-devel] Updating oVirt Server to the latest Matahari 0.4.0 schema

[Alan Pevec]

On 11/12/2010 08:08 PM, Laine Stump wrote:
> On 11/12/2010 08:24 AM, Alan Pevec wrote:
>> Matahari now basically wraps netcf calls in its network agent, so properties like MAC are not directly available, it can be extracted from netcf XML, output of the 'describe' method.
>>
>> But there's more to it since, netcf can also configure interfaces (not yet in Matahari schema, but it is planned).
>> Currently, ovirt-server provides network configuration which is downloaded by the Node on boot and applied (via augeas).
>> Question is should ovirt-server switch fully to netcf (via Matahari)?
>> I'm not sure how does netcf handle unstable interface names, seems that it relies on them being stable which is not the case in the stateless environment like oVirt Node.
>
> I don't know if this description helps answer your question, but : each
> time netcf is run (actually, each time a netcf API is called, via the
> magic of checking file timestamps) the complete config is reread from
> the standard network config files and the XML is reconstructed as
> necessary. netcf has no config of its own to potentially conflict with
> the system config, nor to modify/update it.
>
> I'm not sure exactly what you mean by "unstable", though. Can you expand?

Ah ok, so it relies on network config files i.e. it won't discover unconfigured but present NICs and also it won't show mac at address if HWADDR is not present in ifcfg file.
Matahari then needs to keep the code for enumerating NICs at the lower level, to support stateless Node.

By "unstable" I mean that eth* device names are not consistent across reboots, solution for which was discussed at LPC last week http://linux.dell.com/files/presentations/Linux_Plumbers_Conf_2010/matt-domsch-network-device-naming.pdf )

Without persistent ifcfg-eth* files, like with stateless oVirt Node, multiple NICs will come in random order.

Alan