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

[Adam Stokes]

>  > 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. 
If the device is accessible via /files/sys/class/net/<interface> then netcf will
capture anything made available through that file structure.

For example, the mac address can be pulled through reading:

/sys/class/net/<intername>/address

HTH
Adam

[Matahari] Updating oVirt Server to the latest Matahari 0.4.0 schema

[Laine Stump]

On 11/16/2010 02:28 PM, Adam Stokes wrote:
> >> 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.
>  If the device is accessible via /files/sys/class/net/<interface>  then netcf will
> capture anything made available through that file structure. 
Correct. It will *see* anything there, but will not report it unless it 
has an ifcfg file associated with it (and is not enslaved to another 
interface, eg a bridge or bond - in that case it will only be visible 
from within the xml data for the master interface)


So with the existing oVirt node, you could examine /sys for the list of 
name/mac-addres, then plug that info into netcf XML and let netcf do the 
configuring and bring up the interfaces. Of course with this simple 
method you'd be missing potentially useful information, such as whether 
or not two interfaces were actually the same device, sharing the same 
ethernet port (thus making the act of bonding them together for higher 
bandwidth rather pointless); I don't know if you need to do anything so 
complicated, though.