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

[Andrew Beekhof]

On Fri, Nov 12, 2010 at 2:24 PM, Alan Pevec <apevec at redhat.com> wrote:
> 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')

Adam's patch changes that to:

'com.redhat.matahari', :class => 'Host'

Sorry for the confusion.
We don't anticipate changing it again (unless the convention is for
lowercase class names?)

>        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.

Do you have an example of the old output?
Perhaps its something we can/should add back.

> 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.

We can absolutely add an accessor for getting an interface's MAC
Adam and i discussed doing that already.

>
> 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
>
> _______________________________________________
> Matahari mailing list
> Matahari at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/matahari
>