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

[Andrew Beekhof]

On Sun, Nov 14, 2010 at 1:46 PM, Nicolas Ochem <nicolas.ochem at gmail.com> wrote:
> Thanks for the heads-up. A few remarks/questions :
> 1. we should keep the augeas system for assigning network interfaces because
> it's the only way to reliably map the correct interfaces to the correct
> databases entries. Besides there is now support for vlan interfaces creation
> thru augeas, which is not supported in matahari, I assume. matahari returns
> all the vlan-tagged interfaces as if there were real interfaces and we have
> to filter them in host-register
> 2. in april there was a series of commits switching ovirt-server from
> ruby-qpid to ruby-qmf rpm. Those are two implementations of ruby bindings to
> qmf. (see http://mo.morsi.org/blog/node/288 for more details). I have found
> ruby-qmf to be unstable and buggy so I reverted to ruby-qpid in my local
> branch. I would like to know what is the plan in QPID regarding the ruby
> bindings. Is ruby-qpid ditched in profit of ruby-qmf, or the 2 are going to
> cohabit forever ? Because I'd really like to push the revert to ovirt-server
> next. When this is clarified, we can take care of migrating to new matahari.
> 3.what version of matahari is in RHEL 6 ?

I don't believe there is one.  At least I couldn't find one.
The new stuff will likely make it into 6.1.

> what version will be in fedora 14

Currently it is 0.0.5 but we'll push in the new stuff in the coming weeks.

> ? wouldn't it be good to maintain an ovirt version for rhel/centos 6 ?
>
>
> 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')
>>        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
>>
>> _______________________________________________
>> Ovirt-devel mailing list
>> Ovirt-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/ovirt-devel
>
>
> _______________________________________________
> Ovirt-devel mailing list
> Ovirt-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/ovirt-devel
>
>