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