Ovirt devel - Nov 2010 - 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

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 at 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-domsch-network-device-naming.pdf
)

Without persistent ifcfg-eth* files, like with stateless oVirt Node, multiple
NICs will come in random order.

Alan

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 ?


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/ovirt-devel/attachments/20101114/ae49bb46/attachment.htm>

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
>