From apevec at redhat.com Fri Nov 12 13:24:53 2010 From: apevec at redhat.com (Alan Pevec) Date: Fri, 12 Nov 2010 14:24:53 +0100 Subject: [Ovirt-devel] Updating oVirt Server to the latest Matahari 0.4.0 schema Message-ID: <4CDD4025.2090304@redhat.com> 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 From apevec at redhat.com Fri Nov 12 21:00:24 2010 From: apevec at redhat.com (Alan Pevec) Date: Fri, 12 Nov 2010 22:00:24 +0100 Subject: [Ovirt-devel] [netcf-devel] Updating oVirt Server to the latest Matahari 0.4.0 schema In-Reply-To: <4CDD9098.6040807@laine.org> References: <4CDD4025.2090304@redhat.com> <4CDD9098.6040807@laine.org> Message-ID: <4CDDAAE8.3060808@redhat.com> 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 From nicolas.ochem at gmail.com Sun Nov 14 12:46:10 2010 From: nicolas.ochem at gmail.com (Nicolas Ochem) Date: Sun, 14 Nov 2010 13:46:10 +0100 Subject: [Ovirt-devel] Updating oVirt Server to the latest Matahari 0.4.0 schema In-Reply-To: <4CDD4025.2090304@redhat.com> References: <4CDD4025.2090304@redhat.com> Message-ID: 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 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: From andrew at beekhof.net Mon Nov 15 13:39:35 2010 From: andrew at beekhof.net (Andrew Beekhof) Date: Mon, 15 Nov 2010 14:39:35 +0100 Subject: [Ovirt-devel] [Matahari] Updating oVirt Server to the latest Matahari 0.4.0 schema In-Reply-To: <4CDD4025.2090304@redhat.com> References: <4CDD4025.2090304@redhat.com> Message-ID: On Fri, Nov 12, 2010 at 2:24 PM, Alan Pevec 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 > From andrew at beekhof.net Mon Nov 15 13:50:29 2010 From: andrew at beekhof.net (Andrew Beekhof) Date: Mon, 15 Nov 2010 14:50:29 +0100 Subject: [Ovirt-devel] Updating oVirt Server to the latest Matahari 0.4.0 schema In-Reply-To: References: <4CDD4025.2090304@redhat.com> Message-ID: On Sun, Nov 14, 2010 at 1: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 > 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 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 > > From apevec at redhat.com Wed Nov 17 13:40:00 2010 From: apevec at redhat.com (Alan Pevec) Date: Wed, 17 Nov 2010 14:40:00 +0100 Subject: [Ovirt-devel] Updating oVirt Server to the latest Matahari 0.4.0 schema In-Reply-To: References: <4CDD4025.2090304@redhat.com> Message-ID: <4CE3DB30.4090900@redhat.com> 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 From nicolas.ochem at gmail.com Thu Nov 18 08:42:57 2010 From: nicolas.ochem at gmail.com (Nicolas Ochem) Date: Thu, 18 Nov 2010 09:42:57 +0100 Subject: [Ovirt-devel] Updating oVirt Server to the latest Matahari 0.4.0 schema In-Reply-To: <4CE3DB30.4090900@redhat.com> References: <4CDD4025.2090304@redhat.com> <4CE3DB30.4090900@redhat.com> Message-ID: > > 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 > > > OK, I'll try again. At the end maybe the problem is not in qpid, but in the way db-omatic locks itself for too long when it has too many things to do and the keepalive timers expire, marking nodes as unavailable. The problems just appear much faster when ruby-qmf is used. > > 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. > > The reason I am asking that is as follows : since the development workforce in ovirt-server is very low, I think it would be better to migrate it to RHEL/centos 6 so that all the efforts do not go in migrating to new fedora every 6 months. On the other end, if matahari is not yet in RHEL6, maybe it's possible to have the server running RHEL6 and the node running fedora 14+ for the time being ? Will RHEL 6.1 matahari include the patches we are discussing ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From javilinux at gmail.com Wed Nov 24 23:38:47 2010 From: javilinux at gmail.com (Javier Ramirez Molina) Date: Thu, 25 Nov 2010 00:38:47 +0100 Subject: [Ovirt-devel] How to test Ovirt Message-ID: Hi, I have just joined the list looking to contribute to the project so excuse me if what I ask is very basic, but I have read the mailing-list archive up to June last year and I did not find the answers. 1. What are the requirements to build the node iso? I'm asking this because I tried to follow the instructions at https://fedorahosted.org/ovirt/wiki/Build But when I run the ./autogen.sh command inside the node directory I get the following error message: checking for main in -lpython2.6... no configure: error: Cannot find python development libraries. I'm running fedora 14 with python 2.7 so I supposed I need to use an older Fedora or is there any other way? 2. How accurate and up to date is the documentation at http://ovirt.et.redhat.com/docs/Using_the_oVirt_Server_Suite_User_Interface/ ? 3. Is using the fedora repositories the best way to install the ovirt-server ? If so, I suppose that using Fedora 14 is the best option or it has to match the version used to build the node iso? Finally I would like to say that although I'm not a developer I'm really looking to help as a tester, helping with documentation or any other way. Regards. From andrew at beekhof.net Fri Nov 26 12:21:01 2010 From: andrew at beekhof.net (Andrew Beekhof) Date: Fri, 26 Nov 2010 13:21:01 +0100 Subject: [Ovirt-devel] Updating oVirt Server to the latest Matahari 0.4.0 schema In-Reply-To: References: <4CDD4025.2090304@redhat.com> <4CE3DB30.4090900@redhat.com> Message-ID: On Thu, Nov 18, 2010 at 9:42 AM, Nicolas Ochem wrote: > >> >>> 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 >> > > OK, I'll try again. At the end maybe the problem is not in qpid, but in the > way db-omatic locks itself for too long when it has too many things to do > and the keepalive timers expire, marking nodes as unavailable. > The problems just appear much faster when ruby-qmf is used. > > >> >> >>> 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. >> > > > > The reason I am asking that is as follows : since the development workforce > in ovirt-server is very low, I think it would be better to migrate it to > RHEL/centos 6 so that all the efforts do not go in migrating to new fedora > every 6 months. We intend/hope this to be a one time change. Mostly the cause is a reduction in the amount of OO in the schema which we didn't feel added value. The plan beyond the next stable release is to only add API calls and never amend/remove them. > On the other end, if matahari is not yet in RHEL6, maybe it's possible to > have the server running RHEL6 and the node running fedora 14+ for the time > being ? Yes, this is possible. One thing that might be worth pursuing is for oVirt to switch behavior based on the name of the schema supported by the client. "oh, i have access to the old schema, i need to call a, b and c" "ah, i have access to the new schema, i need to call x, y and z" > Will RHEL 6.1 matahari include the patches we are discussing ? That is the plan so far. From jboggs at redhat.com Mon Nov 29 13:58:38 2010 From: jboggs at redhat.com (Joey Boggs) Date: Mon, 29 Nov 2010 08:58:38 -0500 Subject: [Ovirt-devel] How to test Ovirt In-Reply-To: References: Message-ID: <4CF3B18E.4010009@redhat.com> On 11/24/2010 06:38 PM, Javier Ramirez Molina wrote: > Hi, > I have just joined the list looking to contribute to the project so > excuse me if what I ask is very basic, but I have read the > mailing-list archive up to June last year and I did not find the > answers. > > 1. What are the requirements to build the node iso? > > I'm asking this because I tried to follow the instructions at > https://fedorahosted.org/ovirt/wiki/Build > > But when I run the ./autogen.sh command inside the node directory I > get the following error message: > > checking for main in -lpython2.6... no > configure: error: Cannot find python development libraries. > > I'm running fedora 14 with python 2.7 so I supposed I need to use an > older Fedora or is there any other way? > > 2. How accurate and up to date is the documentation at > http://ovirt.et.redhat.com/docs/Using_the_oVirt_Server_Suite_User_Interface/ > ? > > 3. Is using the fedora repositories the best way to install the > ovirt-server ? If so, I suppose that using Fedora 14 is the best > option or it has to match the version used to build the node iso? > > Finally I would like to say that although I'm not a developer I'm > really looking to help as a tester, helping with documentation or any > other way. > > Regards. > > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel Quick fix for this is in the configure file line 3461 change from: LIBS="-lpython2.6 $LIBS" to LIBS="-lpython2.7 $LIBS" Also livecd creator is able to generate isos that are different os'es than the one used to build it.