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 ? what version will be in fedora 14 ? wouldn't it be good to maintain an ovirt version for rhel/centos 6 ?
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@redhat.com
https://www.redhat.com/mailman/listinfo/ovirt-devel