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@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-d...
)
Without persistent ifcfg-eth* files, like with stateless oVirt Node, multiple NICs will
come in random order.
Alan