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

[Alan Pevec]

On 11/14/2010 01:46 PM, Nicolas Ochem 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

yes, configuring network via augeas will stay. As it seems, netcf doesn't really satisfy requirements, so we'll not use it in Matahari.

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

right, ruby-qmf is the way forward, so we should make it work

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

please file bugs in Fedora/qpid-cpp component (that's SRPM for ruby-qmf)
https://bugzilla.redhat.com/buglist.cgi?component=qpid-cpp&product=Fedora

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

Matahari is not yet in RHEL6, will be in 6.1. Fedora 14 would get latest version which is still being developed on Matahari 'next' branch and that's why I started looking at patching ovirt-server to adjust to it, so that Fedora update doesn't break it.

Alan