Updating oVirt Server to the latest Matahari 0.4.0 schema

Hi all,

I looked at patching oVirt Server to work with the latest Matahari schema, from
Matahari's 'next' branch, version 0.4.0.
ovirt-server depends on matahari version 0.0.5, which is currently latest in Fedora, and
it is used during Node registration, to enumerate hardware information.
Usage extracted from src/host-browser/host-register.rb is as follows:

host_list = @qmfc.objects(:package => 'com.redhat.matahari.host', :class =>
'Host')
host properties used:
	object_id
	object_id.agent_key
	uuid
         hostname
	hypervisor
	arch
	memory

This is all good, those properties do exist in new Matahari 0.4.0 schema, patch for this
part would be simply:
--- a/src/host-browser/host-register.rb
+++ b/src/host-browser/host-register.rb
@@ -143,7 +143,7 @@ class HostRegister < Qmf::ConsoleHandler
          debugputs "Agent #{agent.key}.connected!"
          agent_connected(agent)
  
-        host_list = @qmfc.objects(:package => 'com.redhat.matahari', :class
=> 'host')
+        host_list = @qmfc.objects(:package => 'com.redhat.matahari.host',
:class => 'Host')
  	puts "host_list length is #{host_list.length}"
          host_list.each do |host|
              if host.object_id.agent_key == agent.key


Next, old Matahari has 1:N relationship between host and cpu objects, ovirt-server uses it
by retrieving a list of cpus for each host:

cpu_info = @qmfc.objects(:package => 'com.redhat.matahari', :class =>
'cpu', 'host' => host.object_id)
cpu properties used:
	cpunum
	corenum
	numcores
	vendor
	model
	family
	cpuid_lvl
	speed
	cache
	flags[0..251]

New Matahari changed the model, here are CPU-related properties from 0.4.0 Host object,
there isn't separate cpu class anymore:
     processors        uint8               ReadOnly          The number of physical CPUs.
     cores             uint8               ReadOnly          The total number of processor
cores.
     model             long-string         ReadOnly          The processor(s) model
description.

"model" is descriptive string, so it's not good enough to replace old CPU
details.
On the other hand, oVirt does not really use all those CPU properties, they are just
copied into ovirt database.
CPU information could be used to check migration compatibility, but this should be done
through libvirt/libvirt-qpid anyway.
So I would propose ovirt-server to just remove cpus table, what does ovirt-devel say?


Last are network interfaces, also 1:N relationship:
nic_info = @qmfc.objects(:package => 'com.redhat.matahari', :class =>
'nic', 'host' => host.object_id)
nic properties used:
	macaddr
	interface
		seems to be bug in host-register.rb, it uses "interface_name" property which
doesn't exist in matahari 0.0.5 QMF schema!
	bandwidth

"nic" class is gone, there's new class
'com.redhat.matahari.net:network' with "hostname" property only and
following methods:
'status' Check a network interface
'stop' Stop a network interface
'start' Start a network interface
'destroy' Remove network interface
'list' List IP addresses
'describe' Obtain XML description of a network interface status

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.

Alan

[Laine Stump]

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?

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