From fabiand at redhat.com Thu Apr 3 09:04:07 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Thu, 03 Apr 2014 11:04:07 +0200 Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <80562838.4387376.1396256928698.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <859671594.4143833.1396169171061.JavaMail.zimbra@redhat.com> <1396247995.3043.4.camel@fdeutsch-laptop.local> <80562838.4387376.1396256928698.JavaMail.zimbra@redhat.com> Message-ID: <1396515847.3057.34.camel@fdeutsch-laptop.local> Am Montag, den 31.03.2014, 05:08 -0400 schrieb Barak Azulay: > > ----- Original Message ----- > > From: "Fabian Deutsch" > > To: "Barak Azulay" > > Cc: arch at ovirt.org, "node-devel" , "Douglas Landgraf" > > Sent: Monday, March 31, 2014 9:39:55 AM > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > Am Sonntag, den 30.03.2014, 04:46 -0400 schrieb Barak Azulay: > > > I assume that this new schema is handling also the frist upgrade from > > > the old name schema. > > > > Hey Barak, > > > > could you explain what the first upgrade to the old schema name was for > > you? > > There are 2 scenarios that needs to be considered: > 1 older engine with new rhevh (with new name schema) > * customer with rhev 3.4 tries to upgrade a 3.4 cluster level rhevh to the latest rhevh (with new name schema ... 3.4 cluster level) Mh. What about picking up Alon's (IIRC) suggestion to use subdirs. The "old" names would reside in the path where they are now. And new isos are placed in a subdirectory, where the name of the subdirectory is the targeted version (e.g. 3.4/ would contain Node's for 3.4) That way we don't collide with the old scheme. Newer isos could be brought to old Engines by doing some fancy symlinking. > 2 newer engine supporting older clustrers: > * assume you have 3.4 engine out with several ISOs located in the same dir, > Than there is an upgrade to 3.5 where the name schema changes (and in the same dir you have old name schema and new name schema), > Than you want to upgrade a 3.4 cluster level rhevh to the latest rhevh (with new name schema ... 3.4 cluster level) Maybe this is also solvable by using subdirs as described above. But maybe I'm not getting you right. - fabian > In both cases the UI should suggest the best fit for upgrade, > While for #2 we can add some logic to the engine to handle both cases (ugly and problematic), > For #1 above there is very little we can do. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From fabiand at redhat.com Thu Apr 3 09:09:47 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Thu, 03 Apr 2014 11:09:47 +0200 Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1396251915.3043.24.camel@fdeutsch-laptop.local> <890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com> Message-ID: <1396516187.3057.38.camel@fdeutsch-laptop.local> Am Montag, den 31.03.2014, 04:52 -0400 schrieb Alon Bar-Lev: > > Besides that, we could investigate how yum is handling different > dist > > tags on packages in the same repo. > > I.e.: > > node-3.0-0.fc19.rpm > > node-3.0-0.el6.rpm > > In the same repo. > > no... it should be: > > node-fc19-3.0-0.fc19.rpm > node-centos-3.0-0.fc19.rpm > node-fc19-3.0-0.el6.rpm > node-centos-3.0-0.el6.rpm I don't favor such a direction. If the user want's this he could deploy the "alien" isos manually. > As there is no reason why I would not like centos hosts for my fedora > engine :) > > And there is no reason why we should not allow keeping these available > side-by-side. > > > > If the el6 variant is installed on the Engine side, does yum > > automatically update to the 3.1 el6 variant when it comes out? Or > does > > yum ignore the different dist-tags? > > > > > Pre-release: > > > ovirt-node-iso-3.4.0-0.$(sequence).$(branch).$(date).dist.rpm > > > > Could you please give an example for this. > > You can see lots of examples at other projects[1] > > [1] http://resources.ovirt.org/pub/ovirt-snapshot/rpm/fc19/noarch/ Thanks. > > And - as noted above - I could live with dropping the date for the > > wrapper-rpms - tho it is still handy to have them. > > Why is it handy, what is it serve? I was about to say t get have an idea about the build date, and having an incrementing number. But all this can either be achieved by looking at the iso contents or by simple incrementing numbers aka (spec) release numbers. > > > > > Released: > > > ovirt-node-iso-3.4.z-1.dist.rpm > > > > would you replase z in that string above? > > Each stable release/fix release you issue z is incremented async of > any other package. > > > > > > Please note that the downstream component is eliminated in > upstream, > > > > Could you please exaplain this a bit more. > > You wrote: > > > > > > ovirt-node-iso--...iso > > This means that you have no upstream version for your own use... > ovirt-target-version is of ovirt, but what is the version of the node? Oh right. Well the "node" version can be retrieved by looking at the version of the contained ovirt-node pkg. We don't need to expose it in the name. That's actually what I want to avoid - to expose the node version - because this isn't helpful to th euser - even worse - it is confusing. Greetings! fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From alonbl at redhat.com Thu Apr 3 09:41:23 2014 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 3 Apr 2014 05:41:23 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1396516187.3057.38.camel@fdeutsch-laptop.local> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1396251915.3043.24.camel@fdeutsch-laptop.local> <890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com> <1396516187.3057.38.camel@fdeutsch-laptop.local> Message-ID: <760216481.935128.1396518083947.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Fabian Deutsch" > To: "Alon Bar-Lev" > Cc: arch at ovirt.org, "node-devel" , "Douglas Landgraf" > Sent: Thursday, April 3, 2014 12:09:47 PM > Subject: Re: [node-devel] Versioning of oVirt Node > > Am Montag, den 31.03.2014, 04:52 -0400 schrieb Alon Bar-Lev: > > > Besides that, we could investigate how yum is handling different > > dist > > > tags on packages in the same repo. > > > I.e.: > > > node-3.0-0.fc19.rpm > > > node-3.0-0.el6.rpm > > > In the same repo. > > > > no... it should be: > > > > node-fc19-3.0-0.fc19.rpm > > node-centos-3.0-0.fc19.rpm > > node-fc19-3.0-0.el6.rpm > > node-centos-3.0-0.el6.rpm > > I don't favor such a direction. If the user want's this he could deploy > the "alien" isos manually. Why alien? I would like fedora engine and the most stable host I can get. Or I would like to experiment with the next fedora on separate datacenter. Nothing should be alien. > > > As there is no reason why I would not like centos hosts for my fedora > > engine :) > > > > And there is no reason why we should not allow keeping these available > > side-by-side. > > > > > > > If the el6 variant is installed on the Engine side, does yum > > > automatically update to the 3.1 el6 variant when it comes out? Or > > does > > > yum ignore the different dist-tags? > > > > > > > Pre-release: > > > > ovirt-node-iso-3.4.0-0.$(sequence).$(branch).$(date).dist.rpm > > > > > > Could you please give an example for this. > > > > You can see lots of examples at other projects[1] > > > > [1] http://resources.ovirt.org/pub/ovirt-snapshot/rpm/fc19/noarch/ > > Thanks. > > > > And - as noted above - I could live with dropping the date for the > > > wrapper-rpms - tho it is still handy to have them. > > > > Why is it handy, what is it serve? > > I was about to say t get have an idea about the build date, and having > an incrementing number. > But all this can either be achieved by looking at the iso contents or by > simple incrementing numbers aka (spec) release numbers. > > > > > > > > Released: > > > > ovirt-node-iso-3.4.z-1.dist.rpm > > > > > > would you replase z in that string above? > > > > Each stable release/fix release you issue z is incremented async of > > any other package. > > > > > > > > > Please note that the downstream component is eliminated in > > upstream, > > > > > > Could you please exaplain this a bit more. > > > > You wrote: > > > > > > > > > ovirt-node-iso--...iso > > > > This means that you have no upstream version for your own use... > > ovirt-target-version is of ovirt, but what is the version of the node? > > Oh right. Well the "node" version can be retrieved by looking at the > version of the contained ovirt-node pkg. We don't need to expose it in > the name. > > That's actually what I want to avoid - to expose the node version - > because this isn't helpful to th euser - even worse - it is confusing. On the contrary... the node version is the part that is important, this is the upstream version of the component, and should not be hidden. > > Greetings! > fabian > From fabiand at redhat.com Thu Apr 3 09:45:25 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Thu, 03 Apr 2014 11:45:25 +0200 Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <760216481.935128.1396518083947.JavaMail.zimbra@redhat.com> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1396251915.3043.24.camel@fdeutsch-laptop.local> <890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com> <1396516187.3057.38.camel@fdeutsch-laptop.local> <760216481.935128.1396518083947.JavaMail.zimbra@redhat.com> Message-ID: <1396518325.3057.43.camel@fdeutsch-laptop.local> Am Donnerstag, den 03.04.2014, 05:41 -0400 schrieb Alon Bar-Lev: > > ----- Original Message ----- > > From: "Fabian Deutsch" > > To: "Alon Bar-Lev" > > Cc: arch at ovirt.org, "node-devel" , "Douglas Landgraf" > > Sent: Thursday, April 3, 2014 12:09:47 PM > > Subject: Re: [node-devel] Versioning of oVirt Node > > > > Am Montag, den 31.03.2014, 04:52 -0400 schrieb Alon Bar-Lev: > > > > Besides that, we could investigate how yum is handling different > > > dist > > > > tags on packages in the same repo. > > > > I.e.: > > > > node-3.0-0.fc19.rpm > > > > node-3.0-0.el6.rpm > > > > In the same repo. > > > > > > no... it should be: > > > > > > node-fc19-3.0-0.fc19.rpm > > > node-centos-3.0-0.fc19.rpm > > > node-fc19-3.0-0.el6.rpm > > > node-centos-3.0-0.el6.rpm > > > > I don't favor such a direction. If the user want's this he could deploy > > the "alien" isos manually. > > Why alien? I would like fedora engine and the most stable host I can get. > Or I would like to experiment with the next fedora on separate datacenter. > Nothing should be alien. > > > > > > As there is no reason why I would not like centos hosts for my fedora > > > engine :) > > > > > > And there is no reason why we should not allow keeping these available > > > side-by-side. > > > > > > > > > > If the el6 variant is installed on the Engine side, does yum > > > > automatically update to the 3.1 el6 variant when it comes out? Or > > > does > > > > yum ignore the different dist-tags? > > > > > > > > > Pre-release: > > > > > ovirt-node-iso-3.4.0-0.$(sequence).$(branch).$(date).dist.rpm > > > > > > > > Could you please give an example for this. > > > > > > You can see lots of examples at other projects[1] > > > > > > [1] http://resources.ovirt.org/pub/ovirt-snapshot/rpm/fc19/noarch/ > > > > Thanks. > > > > > > And - as noted above - I could live with dropping the date for the > > > > wrapper-rpms - tho it is still handy to have them. > > > > > > Why is it handy, what is it serve? > > > > I was about to say t get have an idea about the build date, and having > > an incrementing number. > > But all this can either be achieved by looking at the iso contents or by > > simple incrementing numbers aka (spec) release numbers. > > > > > > > > > > > Released: > > > > > ovirt-node-iso-3.4.z-1.dist.rpm > > > > > > > > would you replase z in that string above? > > > > > > Each stable release/fix release you issue z is incremented async of > > > any other package. > > > > > > > > > > > > Please note that the downstream component is eliminated in > > > upstream, > > > > > > > > Could you please exaplain this a bit more. > > > > > > You wrote: > > > > > > > > > > > > ovirt-node-iso--...iso > > > > > > This means that you have no upstream version for your own use... > > > ovirt-target-version is of ovirt, but what is the version of the node? > > > > Oh right. Well the "node" version can be retrieved by looking at the > > version of the contained ovirt-node pkg. We don't need to expose it in > > the name. > > > > That's actually what I want to avoid - to expose the node version - > > because this isn't helpful to th euser - even worse - it is confusing. > > On the contrary... the node version is the part that is important, this is the upstream version of the component, and should not be hidden. We keep the version for the "real" component which is the ovirt-node package. Further more we could say that the ovirt-node-iso component is a component on it's own with it's own version. Because the ISO is squashing many packages I don't see a hard reason why it should have the version of the ovirt-node package. And my suggestion is to let the ovirt-node-iso component follow the overall/project version. For us "No(o)dlers"" it would be interesting to see the ovirt-node version. For "vdsmlers" the vdsm version would be interesting. But to the consumer the oVirt version for which it cna be used is probably the most interesting - after all it should be a black box ;) - fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From alonbl at redhat.com Thu Apr 3 11:03:54 2014 From: alonbl at redhat.com (Alon Bar-Lev) Date: Thu, 3 Apr 2014 07:03:54 -0400 (EDT) Subject: [node-devel] Versioning of oVirt Node In-Reply-To: <1396518325.3057.43.camel@fdeutsch-laptop.local> References: <1396006625.2943.43.camel@fdeutsch-laptop.local> <1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com> <1396251915.3043.24.camel@fdeutsch-laptop.local> <890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com> <1396516187.3057.38.camel@fdeutsch-laptop.local> <760216481.935128.1396518083947.JavaMail.zimbra@redhat.com> <1396518325.3057.43.camel@fdeutsch-laptop.local> Message-ID: <1781260404.958120.1396523034984.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Fabian Deutsch" > To: "Alon Bar-Lev" > Cc: arch at ovirt.org, "node-devel" , "Douglas Landgraf" > Sent: Thursday, April 3, 2014 12:45:25 PM > Subject: Re: [node-devel] Versioning of oVirt Node > > Am Donnerstag, den 03.04.2014, 05:41 -0400 schrieb Alon Bar-Lev: > > > > > > > > > > > > > Released: > > > > > > ovirt-node-iso-3.4.z-1.dist.rpm > > > > > > > > > > would you replase z in that string above? > > > > > > > > Each stable release/fix release you issue z is incremented async of > > > > any other package. > > > > > > > > > > > > > > > Please note that the downstream component is eliminated in > > > > upstream, > > > > > > > > > > Could you please exaplain this a bit more. > > > > > > > > You wrote: > > > > > > > > > > > > > > > ovirt-node-iso--...iso > > > > > > > > This means that you have no upstream version for your own use... > > > > ovirt-target-version is of ovirt, but what is the version of the node? > > > > > > Oh right. Well the "node" version can be retrieved by looking at the > > > version of the contained ovirt-node pkg. We don't need to expose it in > > > the name. > > > > > > That's actually what I want to avoid - to expose the node version - > > > because this isn't helpful to th euser - even worse - it is confusing. > > > > On the contrary... the node version is the part that is important, this is > > the upstream version of the component, and should not be hidden. > > We keep the version for the "real" component which is the ovirt-node > package. > Further more we could say that the ovirt-node-iso component is a > component on it's own with it's own version. Component version that builds the output is important. As a change in that component will result in different output. So there must be a trace for that version. > Because the ISO is squashing many packages I don't see a hard reason why > it should have the version of the ovirt-node package. > And my suggestion is to let the ovirt-node-iso component follow the > overall/project version. The version of the process that builds is important, for example, let's say you build an image using component-v1, then build another image using component-v2, now, you find a severe bug in component-v1 and want to fix only this bug and release component-v1.1, how can you do this, how can you know that you have component-v1, component-v2, component-v1.1 is v1.1 > v2 ? > For us "No(o)dlers"" it would be interesting to see the ovirt-node > version. > For "vdsmlers" the vdsm version would be interesting. > But to the consumer the oVirt version for which it cna be used is > probably the most interesting - after all it should be a black box ;) Even a black box should have a version to enable proper release engineering... There must be a way to trace back a component from output to source, and be able to rebuild it to produce the exact output. This is required so that this "black box" may fixed, bugs may be assigned to right version, bug will be resolved at right version etc... Alon From fabiand at redhat.com Thu Apr 3 13:40:04 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Thu, 03 Apr 2014 15:40:04 +0200 Subject: [node-devel] Just for a short time - F20 draft builds Message-ID: <1396532404.3057.49.camel@fdeutsch-laptop.local> Hey, after some time we finally got working draft of Node based on Fedora 19 and 20 again. This build below is only the base image build, which does not contain vdsm, so is not usable with Engine: http://jenkins.ovirt.org/job/node-devel/2413/ Greetings fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From lxfwill at gmail.com Fri Apr 4 02:38:36 2014 From: lxfwill at gmail.com (=?GB2312?B?ue22oQ==?=) Date: Thu, 3 Apr 2014 22:38:36 -0400 Subject: [node-devel] VM xp is down. Exit message: unsupported configuration: spice graphics are not supported with this QEMU. Message-ID: ovirt-engine version 3.4.0 RC3 qemu-kvm version 1.6.1 vdsm version 4.14.6 libvirt version 1.1.3 messages as follow: Apr 3 22:30:48 localhost vdsm vm.Vm ERROR vmId=`a4ea786e-2c1c-4159-86e0-8744c54b3bbe`::The vm start process failed#012Traceback (most recent call last):#012 File "/usr/share/vdsm/vm.py", line 2249, in _startUnderlyingVm#012 self._run()#012 File "/usr/share/vdsm/vm.py", line 3170, in _run#012 self._connection.createXML(domxml, flags),#012 File "/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py", line 92, in wrapper#012 ret = f(*args, **kwargs)#012 File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2920, in createXML#012 if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)#012libvirtError: unsupported configuration: spice graphics are not supported with this QEMU Apr 3 22:30:50 localhost vdsm vm.Vm WARNING vmId=`a4ea786e-2c1c-4159-86e0-8744c54b3bbe`::trying to set state to Powering down when already Down Apr 3 22:30:50 localhost vdsm root WARNING File: /var/lib/libvirt/qemu/channels/a4ea786e-2c1c-4159-86e0-8744c54b3bbe.com.redhat.rhevm.vdsm already removed Apr 3 22:30:50 localhost vdsm root WARNING File: /var/lib/libvirt/qemu/channels/a4ea786e-2c1c-4159-86e0-8744c54b3bbe.org.qemu.guest_agent.0 already removed libvirtd.log as follow: 2014-04-04 02:30:48.363+0000: 988: debug : virStorageFileGetMetadata:1090 : path=/rhev/data-center/mnt/192.168.1.130:_home_root_iso/64ac0f5a-82b2-4bae-8b74-794a0bcecf27/images/11111111-1111-1111-1111-111111111111/xp.iso format=1 uid=107 gid=107 probe=0 2014-04-04 02:30:48.363+0000: 988: debug : virStorageFileGetMetadataRecurse:1022 : path=/rhev/data-center/mnt/192.168.1.130:_home_root_iso/64ac0f5a-82b2-4bae-8b74-794a0bcecf27/images/11111111-1111-1111-1111-111111111111/xp.iso format=1 uid=107 gid=107 probe=0 2014-04-04 02:30:48.366+0000: 988: debug : virStorageFileGetMetadataInternal:770 : path=/rhev/data-center/mnt/192.168.1.130:_home_root_iso/64ac0f5a-82b2-4bae-8b74-794a0bcecf27/images/11111111-1111-1111-1111-111111111111/xp.iso, fd=25, format=1 2014-04-04 02:30:48.422+0000: 988: debug : virStorageFileGetMetadata:1090 : path=/rhev/data-center/mnt/192.168.1.130:_home_root_images/817df10f-ebe3-48ec-9e97-7c34aec1b00c/images/7eb012db-d3f3-4374-a24e-044946528f26/a2ec5f90-cc8a-43b1-bc8c-429536445a4d format=1 uid=107 gid=107 probe=0 2014-04-04 02:30:48.422+0000: 988: debug : virStorageFileGetMetadataRecurse:1022 : path=/rhev/data-center/mnt/192.168.1.130:_home_root_images/817df10f-ebe3-48ec-9e97-7c34aec1b00c/images/7eb012db-d3f3-4374-a24e-044946528f26/a2ec5f90-cc8a-43b1-bc8c-429536445a4d format=1 uid=107 gid=107 probe=0 2014-04-04 02:30:48.425+0000: 988: debug : virStorageFileGetMetadataInternal:770 : path=/rhev/data-center/mnt/192.168.1.130:_home_root_images/817df10f-ebe3-48ec-9e97-7c34aec1b00c/images/7eb012db-d3f3-4374-a24e-044946528f26/a2ec5f90-cc8a-43b1-bc8c-429536445a4d, fd=25, format=1 2014-04-04 02:30:48.457+0000: 988: debug : qemuProcessStart:3710 : Preparing monitor state 2014-04-04 02:30:48.457+0000: 988: debug : qemuProcessStart:3742 : Assigning domain PCI addresses 2014-04-04 02:30:48.457+0000: 988: debug : qemuDomainPCIAddressReserveAddr:2108 : Reserving PCI slot 0000:00:03.0 (multifunction='off') 2014-04-04 02:30:48.457+0000: 988: debug : qemuDomainPCIAddressReserveAddr:2108 : Reserving PCI slot 0000:00:02.0 (multifunction='off') 2014-04-04 02:30:48.457+0000: 988: debug : qemuDomainPCIAddressReserveAddr:2108 : Reserving PCI slot 0000:00:04.0 (multifunction='off') 2014-04-04 02:30:48.457+0000: 988: debug : qemuDomainPCIAddressReserveAddr:2108 : Reserving PCI slot 0000:00:05.0 (multifunction='off') 2014-04-04 02:30:48.457+0000: 988: debug : qemuDomainPCIAddressReserveAddr:2108 : Reserving PCI slot 0000:00:01.0 (multifunction='off') 2014-04-04 02:30:48.457+0000: 988: debug : qemuDomainPCIAddressGetNextSlot:2264 : PCI slot 0000:00:01 already in use 2014-04-04 02:30:48.457+0000: 988: debug : qemuDomainPCIAddressGetNextSlot:2264 : PCI slot 0000:00:02 already in use 2014-04-04 02:30:48.457+0000: 988: debug : qemuDomainPCIAddressGetNextSlot:2264 : PCI slot 0000:00:03 already in use 2014-04-04 02:30:48.457+0000: 988: debug : qemuDomainPCIAddressGetNextSlot:2264 : PCI slot 0000:00:04 already in use 2014-04-04 02:30:48.457+0000: 988: debug : qemuDomainPCIAddressGetNextSlot:2264 : PCI slot 0000:00:05 already in use 2014-04-04 02:30:48.457+0000: 988: debug : qemuDomainPCIAddressGetNextSlot:2307 : Found free PCI slot 0000:00:06 2014-04-04 02:30:48.457+0000: 988: debug : qemuDomainPCIAddressReserveAddr:2108 : Reserving PCI slot 0000:00:06.0 (multifunction='off') 2014-04-04 02:30:48.457+0000: 988: debug : qemuDomainPCIAddressReserveAddr:2108 : Reserving PCI slot 0000:00:03.0 (multifunction='off') 2014-04-04 02:30:48.457+0000: 988: debug : qemuDomainPCIAddressReserveAddr:2108 : Reserving PCI slot 0000:00:02.0 (multifunction='off') 2014-04-04 02:30:48.457+0000: 988: debug : qemuDomainPCIAddressReserveAddr:2108 : Reserving PCI slot 0000:00:04.0 (multifunction='off') 2014-04-04 02:30:48.457+0000: 988: debug : qemuDomainPCIAddressReserveAddr:2108 : Reserving PCI slot 0000:00:05.0 (multifunction='off') 2014-04-04 02:30:48.457+0000: 988: debug : qemuDomainPCIAddressReserveAddr:2108 : Reserving PCI slot 0000:00:01.0 (multifunction='off') 2014-04-04 02:30:48.457+0000: 988: debug : qemuProcessStart:3747 : Building emulator command line 2014-04-04 02:30:48.457+0000: 988: debug : virArchFromHost:176 : Mapped x86_64 to 29 (x86_64) 2014-04-04 02:30:48.457+0000: 988: debug : qemuBuildCommandLine:7655 : conn=0x7fded815c5a0 driver=0x7fded814f0d0 def=0x7fdec800a040 mon=0x7fdec8006cf0 json=1 qemuCaps=0x7fdec80020b0 migrateFrom=(null) migrateFD=-1 snapshot=(nil) vmop=0 2014-04-04 02:30:48.467+0000: 988: error : qemuBuildGraphicsSPICECommandLine:7171 : unsupported configuration: spice graphics are not supported with this QEMU 2014-04-04 02:30:48.467+0000: 988: debug : qemuProcessStop:4129 : Shutting down VM 'xp' pid=0 flags=2 2014-04-04 02:30:48.482+0000: 988: debug : qemuProcessKill:4088 : vm=xp pid=0 flags=5 2014-04-04 02:30:48.482+0000: 988: debug : virProcessKillPainfully:269 : vpid=0 force=1 2014-04-04 02:30:48.482+0000: 988: debug : qemuDomainCleanupRun:2257 : driver=0x7fded814f0d0, vm=xp 2014-04-04 02:30:48.482+0000: 988: debug : qemuProcessAutoDestroyRemove:4656 : vm=xp 2014-04-04 02:30:48.482+0000: 988: debug : virCloseCallbacksUnset:165 : vm=xp, uuid=a4ea786e-2c1c-4159-86e0-8744c54b3bbe, cb=0x7fdee1118c50 2014-04-04 02:30:48.482+0000: 988: debug : qemuDomainObjEndJob:1165 : Stopping job: modify (async=none) -------------- next part -------------- An HTML attachment was scrubbed... URL: From fdeutsch at redhat.com Tue Apr 8 14:35:04 2014 From: fdeutsch at redhat.com (Fabian Deutsch) Date: Tue, 8 Apr 2014 10:35:04 -0400 (EDT) Subject: [node-devel] Cancelled: oVirt Node weekly meeting Message-ID: <1770405049.2832362.1396967704342.JavaMail.zimbra@redhat.com> A single instance of the following meeting has been cancelled: Subject: oVirt Node weekly meeting Organiser: "Fabian Deutsch" Location: irc://irc.oftc.net#ovirt Time: Tuesday, 15 April, 2014, 3:00:00 PM - 3:30:00 PM GMT +01:00 Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna Invitees: node-devel at ovirt.org *~*~*~*~*~*~*~*~*~* -------------- next part -------------- A non-text attachment was scrubbed... Name: meeting.ics Type: text/calendar Size: 1492 bytes Desc: not available URL: From fabiand at redhat.com Fri Apr 11 14:41:54 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Fri, 11 Apr 2014 16:41:54 +0200 Subject: [node-devel] New oVirt Node available for 3.3 and 3.4 Message-ID: <1397227314.6569.28.camel@fdeutsch-laptop.local> Hey, there is a new oVirt Node build available here: http://resources.ovirt.org/releases/3.4/iso/ovirt-node-iso-3.4-20140410.0.el6.iso This build can be used for oVirt 3.4 and oVirt 3.3 as well. Greetings fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From fabiand at redhat.com Tue Apr 22 13:51:27 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Tue, 22 Apr 2014 15:51:27 +0200 Subject: [node-devel] oVirt Node Weekly Meeting Minutes -- 2014-04-22 Message-ID: <1398174687.15955.14.camel@fdeutsch-laptop.local> Minutes: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-04-22-13.00.html Minutes (text): http://ovirt.org/meetings/ovirt/2014/ovirt.2014-04-22-13.00.txt Log: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-04-22-13.00.log.html ================================= #ovirt: oVirt Node Weekly Meeting ================================= Meeting started by fabiand at 13:00:02 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2014/ovirt.2014-04-22-13.00.log.html . Meeting summary --------------- * Agenda (fabiand, 13:00:20) * oVirt 3.5 (fabiand, 13:00:28) * Other Items (fabiand, 13:00:32) * oVirt 3.5 (fabiand, 13:01:48) * LINK: 3.5. feature list: https://bugzilla.redhat.com/buglist.cgi?quicksearch=875088 1038616 1053435 (fabiand, 13:08:30) * LINK: https://github.com/fabiand/ovirt-appliance/ (fabiand, 13:15:58) * ACTION: fabiand to follow up with rbarry on 3.5 feature (fabiand, 13:45:36) * ACTION: jboggs to sync with didi on hosted-engine-setup and consuming appliance images (fabiand, 13:47:19) * Other Items (fabiand, 13:47:27) Meeting ended at 13:49:56 UTC. Action Items ------------ * fabiand to follow up with rbarry on 3.5 feature * jboggs to sync with didi on hosted-engine-setup and consuming appliance images Action Items, by person ----------------------- * fabiand * fabiand to follow up with rbarry on 3.5 feature * jboggs * jboggs to sync with didi on hosted-engine-setup and consuming appliance images * rbarry * fabiand to follow up with rbarry on 3.5 feature * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * fabiand (91) * jboggs (27) * xevilstar (12) * ovirtbot (4) * doron (3) * knesenko (1) * clarkee_ (1) * JC (1) * rbarry (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From fabiand at redhat.com Thu Apr 24 14:57:07 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Thu, 24 Apr 2014 16:57:07 +0200 Subject: [node-devel] Node Design ideas - And what you would like to see in or how you would like to see Node Message-ID: <1398351427.4298.35.camel@fdeutsch-laptop.local> Hey, lately - well for some time now - I noticed how often I asked myself why we had this or that bug, or why it was so hard to implement some features. For example. Getting iSCSI and EFI right in our installer is still "fragile". Because it's hard to get right. Or enabling and disabling services easily with standard tools at runtime on our Fedora based images is not possible, because it's not easily implementable with bind mounts (well, cumbersome). Or enable "live plugins" - plugins which can be installed at runtime. They are also difficult because of our use of bind mounts. Because of this I thought about how we could - from the ground up - change some designs to leverage more existing code (and have less code to maintain) and make some feature development easier. The two areas I looked at are already mentioned. It's the (a) installer - which is complex because of all the storage enumeration [0], EFI, iSCSI and it's age - and (b) how we work with the read-only rootfs - aka the LiveCD based design. For (a) I looked into Fedora's anaconda [1]. It has support for EFI, iSCSI and so one. Even high-level features to configure networking or add users (for which we also maintain some code). And for (b) I thought about a design based around LVM and thin volumes [2][3]. But changing parts of Node might result in Node having different properties. For example - Using the LVM based approach above would increase the size of the runtime rootfs to ~1GB. OTOH it would allow an arbitrary number of "layers" (for e.g. live plugins). And thus - before I start to think (only to think) about bigger changes in Node - I would like to know what properties of Node _you_ like, and which you would like to keep. Some ideas about what you could like or not: - installation size (~250MB)? - runtime size (~250MB)? - way of installation (kargs)? - TUI (simple instaler, setup)? - "firmware-like" feeling (read-only rootfs)? - ... And also - what changes you would like to see which ain't there yet! Greetings fabian -- [0] http://gerrit.ovirt.org/gitweb?p=ovirt-node.git;a=blob;f=src/ovirtnode/storage.py [1] https://github.com/fabiand/imgbased/ [2] https://git.fedorahosted.org/cgit/anaconda.git/ [3] http://dummdida.tumblr.com/post/82392428141/imgbased-or-keeping-the-nature-of-node -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From dfediuck at redhat.com Fri Apr 25 07:53:58 2014 From: dfediuck at redhat.com (Doron Fediuck) Date: Fri, 25 Apr 2014 03:53:58 -0400 (EDT) Subject: [node-devel] Node Design ideas - And what you would like to see in or how you would like to see Node In-Reply-To: <1398351427.4298.35.camel@fdeutsch-laptop.local> References: <1398351427.4298.35.camel@fdeutsch-laptop.local> Message-ID: <85220746.11382084.1398412438889.JavaMail.zimbra@redhat.com> Sharing with ovirt devel list to get additional awareness. ----- Original Message ----- From: "Fabian Deutsch" To: "node-devel" Sent: Thursday, April 24, 2014 5:57:07 PM Subject: [node-devel] Node Design ideas - And what you would like to see in or how you would like to see Node Hey, lately - well for some time now - I noticed how often I asked myself why we had this or that bug, or why it was so hard to implement some features. For example. Getting iSCSI and EFI right in our installer is still "fragile". Because it's hard to get right. Or enabling and disabling services easily with standard tools at runtime on our Fedora based images is not possible, because it's not easily implementable with bind mounts (well, cumbersome). Or enable "live plugins" - plugins which can be installed at runtime. They are also difficult because of our use of bind mounts. Because of this I thought about how we could - from the ground up - change some designs to leverage more existing code (and have less code to maintain) and make some feature development easier. The two areas I looked at are already mentioned. It's the (a) installer - which is complex because of all the storage enumeration [0], EFI, iSCSI and it's age - and (b) how we work with the read-only rootfs - aka the LiveCD based design. For (a) I looked into Fedora's anaconda [1]. It has support for EFI, iSCSI and so one. Even high-level features to configure networking or add users (for which we also maintain some code). And for (b) I thought about a design based around LVM and thin volumes [2][3]. But changing parts of Node might result in Node having different properties. For example - Using the LVM based approach above would increase the size of the runtime rootfs to ~1GB. OTOH it would allow an arbitrary number of "layers" (for e.g. live plugins). And thus - before I start to think (only to think) about bigger changes in Node - I would like to know what properties of Node _you_ like, and which you would like to keep. Some ideas about what you could like or not: - installation size (~250MB)? - runtime size (~250MB)? - way of installation (kargs)? - TUI (simple instaler, setup)? - "firmware-like" feeling (read-only rootfs)? - ... And also - what changes you would like to see which ain't there yet! Greetings fabian -- [0] http://gerrit.ovirt.org/gitweb?p=ovirt-node.git;a=blob;f=src/ovirtnode/storage.py [1] https://github.com/fabiand/imgbased/ [2] https://git.fedorahosted.org/cgit/anaconda.git/ [3] http://dummdida.tumblr.com/post/82392428141/imgbased-or-keeping-the-nature-of-node From fabiand at redhat.com Tue Apr 29 13:37:32 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Tue, 29 Apr 2014 15:37:32 +0200 Subject: [node-devel] oVirt Node Weekly Meeting Minutes -- 2014-04-29 Message-ID: <1398778652.4473.14.camel@fdeutsch-laptop.local> Minutes: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-04-29-13.03.html Minutes (text): http://ovirt.org/meetings/ovirt/2014/ovirt.2014-04-29-13.03.txt Log: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-04-29-13.03.log.html ================================= #ovirt: oVirt Node Weekly Meeting ================================= Meeting started by fabiand at 13:03:17 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2014/ovirt.2014-04-29-13.03.log.html . Meeting summary --------------- * Agenda (fabiand, 13:03:55) * Build Status (3.0.5) (fabiand, 13:04:16) * Feature Status for 3.5 (fabiand, 13:04:21) * Mailinglist Merge (fabiand, 13:05:00) * Action Item Review (fabiand, 13:06:51) * Other Items (fabiand, 13:06:57) * Build Status (fabiand, 13:07:02) * node-3.0 branch is looking good (fabiand, 13:07:18) * ACTION: fabiand to prepare beta until next week (fabiand, 13:08:55) * ACTION: fabiand jboggs rbarry to test beta (fabiand, 13:09:02) * LINK: Current node-3.0 is http://gerrit.ovirt.org/gitweb?p=ovirt-node.git;a=commit;h=2544837e28af149aed7e6bf23eef7e324397fe0c (fabiand, 13:09:42) * Feature Status for 3.5 (fabiand, 13:09:53) * Bug 875088 - [RFE] ovirt-node-registration - a generic node registration (fabiand, 13:11:18) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=875088 (fabiand, 13:11:22) * LINK: Feature page: http://www.ovirt.org/Features/Node/GenericNodeRegistration (fabiand, 13:13:20) * AGREED: Go for generic-registration feature (fabiand, 13:14:55) * Bug 1038616 - [RFE] Support for hosted engine (fabiand, 13:15:48) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1038616 (fabiand, 13:15:52) * No updates on hosted engine plugin (fabiand, 13:17:02) * LINK: Feature Page: http://www.ovirt.org/Node_Hosted_Engine (fabiand, 13:19:24) * AGREED: Go for hosted-engine-plugin (fabiand, 13:19:38) * Bug 1053435 - [RFE] oVirt virtual appliance (fabiand, 13:22:58) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1053435 (fabiand, 13:23:02) * AGREED: Go for ovirt-virtual-appliance feature (fabiand, 13:23:43) * Mailinglist Merge (fabiand, 13:24:21) * ACTION: fabiand to take care of merge (fabiand, 13:28:56) * Action Item Review (fabiand, 13:29:10) * Other Items (fabiand, 13:29:29) Meeting ended at 13:33:55 UTC. Action Items ------------ * fabiand to prepare beta until next week * fabiand jboggs rbarry to test beta * fabiand to take care of merge Action Items, by person ----------------------- * fabiand * fabiand to prepare beta until next week * fabiand jboggs rbarry to test beta * fabiand to take care of merge * jboggs * fabiand jboggs rbarry to test beta * rbarry * fabiand jboggs rbarry to test beta * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * fabiand (98) * rbarry (10) * jboggs (6) * bkp (5) * ovirtbot (5) * SvenKieske (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From fabiand at redhat.com Tue Apr 29 13:52:45 2014 From: fabiand at redhat.com (Fabian Deutsch) Date: Tue, 29 Apr 2014 15:52:45 +0200 Subject: [node-devel] Attention: Mailing List Change Message-ID: <1398779565.4473.21.camel@fdeutsch-laptop.local> All: To open Node related topics to a wider audience and improve the overall project communication, the Node team has agreed on this weeks meeting to merge the [node-devel] list into the (also quite fresh) [devel] mailinglist. This note is an announcement that in about one week time this will get done. What will happen: 1) Subscribers from [node-devel] will be migrated to the [devel] list. 2) Archives from [node-devel] (this list) will be left as is, and available for searching on the list.ovirt.org/mailman site. Please note that the [devel] mailinglist is of a higher volume. If you have _any_ comments or concerns, let me know. Thanks fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: