[ovirt-devel] Postponing 3.6.0 second alpha to next week
Hi, due to instability of the current code, we need to postpone second alpha to next week. Maintainers: - please ensure that all packages you maintain builds in jenkins - please ensure that all the dependencies required by your packages are available either in ovirt repository or in an external repository included in ovirt-release repo files. - please ensure that engine is at least able to add a couple of hosts, create a vm on one host and migrate it to the other one. Infra: - please help keeping jenkins monitored and stabilizing it. Community: - please help testing nightly build while stabilizing it for the second alpha release. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Libvirt secrets management - take 2
On 16 Jun 2015, at 18:22, Nir Soffer wrote: > > > - Original Message - >> From: "Michal Skrivanek" >> To: "Nir Soffer" >> Cc: "Francesco Romani" , "devel" , >> "Adam Litke" , "Federico >> Simoncelli" , "Dan Kenigsberg" , >> "Allon Mureinik" , >> "Daniel Erez" , "Eric Blake" >> Sent: Tuesday, June 16, 2015 6:57:35 PM >> Subject: Re: Libvirt secrets management - take 2 >> >> >> >> On 15 Jun 2015, at 17:57, Nir Soffer wrote: >> >>> - Original Message - From: "Michal Skrivanek" To: "Nir Soffer" Cc: "Francesco Romani" , "devel" , "Adam Litke" , "Federico Simoncelli" , "Dan Kenigsberg" , "Allon Mureinik" , "Daniel Erez" , "Eric Blake" Sent: Monday, June 15, 2015 6:20:34 PM Subject: Re: Libvirt secrets management - take 2 On 15 Jun 2015, at 17:06, Nir Soffer wrote: > > > - Original Message - >> From: "Francesco Romani" >> To: "devel" >> Cc: "Adam Litke" , "Federico Simoncelli" >> , "Dan Kenigsberg" >> , "Allon Mureinik" , "Daniel >> Erez" >> , "Michal Skrivanek" >> , "Eric Blake" , "Nir Soffer" >> >> Sent: Monday, June 15, 2015 4:08:09 PM >> Subject: Re: Libvirt secrets management - take 2 >> >> - Original Message - >>> From: "Nir Soffer" >>> To: "Adam Litke" >>> Cc: "devel" , "Francesco Romani" , >>> "Federico Simoncelli" , >>> "Dan Kenigsberg" , "Allon Mureinik" >>> , "Daniel Erez" , >>> "Michal Skrivanek" , "Eric Blake" >>> >>> Sent: Saturday, June 13, 2015 11:14:03 PM >>> Subject: Re: Libvirt secrets management - take 2 >> >> [...] > Flows > = > > Start vm > > - Engine add required secrets to vm description > - Vdsm register temporary secrets with libvirt > - When vm is up or if operation failed, Vdsm remove the temporary > secret > > Migrate vm > -- > - Engine add required secrets to vm description > - Vdsm add secrets to the vm description sent to the destination > - On the destination, Vdsm register temporary secrets with libvirt > - On the destination, when vm is up or if operation failed, Vdsm > remove > the temporary secret >>> >>> On issue with migration - do we have to keep the same auth information >>> as >>> in >>> the original vm xml, or we can create the vm on the destination using >>> different >>> auth xml? >> >> I don't have an answer for this. Need to check and play with this a bit. >> > Hot-plug disk > - > - Engine add secret to disk description > - Vdsm register temporary secret with libvirt > - When disk is successfully plugged, or if operation failed, Vdsm > remove > the temporary secret >> >> OK, what if this VM is migrate afterwards? destination VDSM needs to >> register >> this secret >> to libvirt. >> >> The fact here is that is the source VDSM that orchestrates the >> migration, >> and >> if it has >> forgorgotten the secret, then we need get it back again from Engine and >> pass >> it through the destination VM. >> >> On migration, it is the source VM which orchestrates the flow. Engine >> polls >> source VM for updates, >> and consider the VM migrated only after source exited correctly. >> I don't recall the fine details engine side (need to check), but on VDSM >> side: >> >> - source VDSM receives VM.migrate(destination_uri) >> - source VDSM sends migrationCreate to destination VDSM >> - once destination VDSM created special-purpose VM, source VDSM >> instructs >> libvirt to start the migration >> - source VDSM monitors the migration, report progress, updates the >> downtime >> - migration fails: source VDSM automatically send VM.destroy to >> destination >> VDSM >> - migration succeeds: source VDSM destroy source VM, execution now >> continues >> on destination VM the source side is "destroyed" by qemu automatically. Engine just sends an explicit destroy after the migration is deemed successful in the engine too > > Ok, when we create the special purpose vm, do we include all the devices? it's an exact copy of the source vm. yes > > If this special vm (waiting for migration) is connected to all the disks, > then it is (it goes though preparePaths as any other VM creation) > we only need to register the secrets sent from the source in > migrationCreate, > start the special vm, and one it is running, delete the secrets. probably. Does the source know those secrets? >>> >>> At the time of migration, the source does not know much about
Re: [ovirt-devel] Libvirt secrets management - take 2
- Original Message - > From: "Michal Skrivanek" > To: "Nir Soffer" > Cc: "Francesco Romani" , "devel" , "Adam > Litke" , "Federico > Simoncelli" , "Dan Kenigsberg" , > "Allon Mureinik" , > "Daniel Erez" , "Eric Blake" > Sent: Tuesday, June 16, 2015 6:57:35 PM > Subject: Re: Libvirt secrets management - take 2 > > > > On 15 Jun 2015, at 17:57, Nir Soffer wrote: > > > - Original Message - > >> From: "Michal Skrivanek" > >> To: "Nir Soffer" > >> Cc: "Francesco Romani" , "devel" , > >> "Adam Litke" , "Federico > >> Simoncelli" , "Dan Kenigsberg" , > >> "Allon Mureinik" , > >> "Daniel Erez" , "Eric Blake" > >> Sent: Monday, June 15, 2015 6:20:34 PM > >> Subject: Re: Libvirt secrets management - take 2 > >> > >> > >> On 15 Jun 2015, at 17:06, Nir Soffer wrote: > >> > >>> > >>> > >>> - Original Message - > From: "Francesco Romani" > To: "devel" > Cc: "Adam Litke" , "Federico Simoncelli" > , "Dan Kenigsberg" > , "Allon Mureinik" , "Daniel > Erez" > , "Michal Skrivanek" > , "Eric Blake" , "Nir Soffer" > > Sent: Monday, June 15, 2015 4:08:09 PM > Subject: Re: Libvirt secrets management - take 2 > > - Original Message - > > From: "Nir Soffer" > > To: "Adam Litke" > > Cc: "devel" , "Francesco Romani" , > > "Federico Simoncelli" , > > "Dan Kenigsberg" , "Allon Mureinik" > > , "Daniel Erez" , > > "Michal Skrivanek" , "Eric Blake" > > > > Sent: Saturday, June 13, 2015 11:14:03 PM > > Subject: Re: Libvirt secrets management - take 2 > > [...] > >>> Flows > >>> = > >>> > >>> Start vm > >>> > >>> - Engine add required secrets to vm description > >>> - Vdsm register temporary secrets with libvirt > >>> - When vm is up or if operation failed, Vdsm remove the temporary > >>> secret > >>> > >>> Migrate vm > >>> -- > >>> - Engine add required secrets to vm description > >>> - Vdsm add secrets to the vm description sent to the destination > >>> - On the destination, Vdsm register temporary secrets with libvirt > >>> - On the destination, when vm is up or if operation failed, Vdsm > >>> remove > >>> the temporary secret > > > > On issue with migration - do we have to keep the same auth information > > as > > in > > the original vm xml, or we can create the vm on the destination using > > different > > auth xml? > > I don't have an answer for this. Need to check and play with this a bit. > > >>> Hot-plug disk > >>> - > >>> - Engine add secret to disk description > >>> - Vdsm register temporary secret with libvirt > >>> - When disk is successfully plugged, or if operation failed, Vdsm > >>> remove > >>> the temporary secret > > OK, what if this VM is migrate afterwards? destination VDSM needs to > register > this secret > to libvirt. > > The fact here is that is the source VDSM that orchestrates the > migration, > and > if it has > forgorgotten the secret, then we need get it back again from Engine and > pass > it through the destination VM. > > On migration, it is the source VM which orchestrates the flow. Engine > polls > source VM for updates, > and consider the VM migrated only after source exited correctly. > I don't recall the fine details engine side (need to check), but on VDSM > side: > > - source VDSM receives VM.migrate(destination_uri) > - source VDSM sends migrationCreate to destination VDSM > - once destination VDSM created special-purpose VM, source VDSM > instructs > libvirt to start the migration > - source VDSM monitors the migration, report progress, updates the > downtime > - migration fails: source VDSM automatically send VM.destroy to > destination > VDSM > - migration succeeds: source VDSM destroy source VM, execution now > continues > on destination VM > >> > >> the source side is "destroyed" by qemu automatically. Engine just sends an > >> explicit destroy after the migration is deemed successful in the engine > >> too > >> > >>> > >>> Ok, when we create the special purpose vm, do we include all the devices? > >> > >> it's an exact copy of the source vm. yes > >> > >>> > >>> If this special vm (waiting for migration) is connected to all the disks, > >>> then > >> > >> it is (it goes though preparePaths as any other VM creation) > >> > >>> we only need to register the secrets sent from the source in > >>> migrationCreate, > >>> start the special vm, and one it is running, delete the secrets. > >> > >> probably. Does the source know those secrets? > > > > At the time of migration, the source does not know much about the secrerts. > > > > - qemu got the secret key and connected to
Re: [ovirt-devel] Libvirt secrets management - take 2
On 15 Jun 2015, at 17:57, Nir Soffer wrote: > - Original Message - >> From: "Michal Skrivanek" >> To: "Nir Soffer" >> Cc: "Francesco Romani" , "devel" , >> "Adam Litke" , "Federico >> Simoncelli" , "Dan Kenigsberg" , >> "Allon Mureinik" , >> "Daniel Erez" , "Eric Blake" >> Sent: Monday, June 15, 2015 6:20:34 PM >> Subject: Re: Libvirt secrets management - take 2 >> >> >> On 15 Jun 2015, at 17:06, Nir Soffer wrote: >> >>> >>> >>> - Original Message - From: "Francesco Romani" To: "devel" Cc: "Adam Litke" , "Federico Simoncelli" , "Dan Kenigsberg" , "Allon Mureinik" , "Daniel Erez" , "Michal Skrivanek" , "Eric Blake" , "Nir Soffer" Sent: Monday, June 15, 2015 4:08:09 PM Subject: Re: Libvirt secrets management - take 2 - Original Message - > From: "Nir Soffer" > To: "Adam Litke" > Cc: "devel" , "Francesco Romani" , > "Federico Simoncelli" , > "Dan Kenigsberg" , "Allon Mureinik" > , "Daniel Erez" , > "Michal Skrivanek" , "Eric Blake" > > Sent: Saturday, June 13, 2015 11:14:03 PM > Subject: Re: Libvirt secrets management - take 2 [...] >>> Flows >>> = >>> >>> Start vm >>> >>> - Engine add required secrets to vm description >>> - Vdsm register temporary secrets with libvirt >>> - When vm is up or if operation failed, Vdsm remove the temporary >>> secret >>> >>> Migrate vm >>> -- >>> - Engine add required secrets to vm description >>> - Vdsm add secrets to the vm description sent to the destination >>> - On the destination, Vdsm register temporary secrets with libvirt >>> - On the destination, when vm is up or if operation failed, Vdsm remove >>> the temporary secret > > On issue with migration - do we have to keep the same auth information as > in > the original vm xml, or we can create the vm on the destination using > different > auth xml? I don't have an answer for this. Need to check and play with this a bit. >>> Hot-plug disk >>> - >>> - Engine add secret to disk description >>> - Vdsm register temporary secret with libvirt >>> - When disk is successfully plugged, or if operation failed, Vdsm >>> remove >>> the temporary secret OK, what if this VM is migrate afterwards? destination VDSM needs to register this secret to libvirt. The fact here is that is the source VDSM that orchestrates the migration, and if it has forgorgotten the secret, then we need get it back again from Engine and pass it through the destination VM. On migration, it is the source VM which orchestrates the flow. Engine polls source VM for updates, and consider the VM migrated only after source exited correctly. I don't recall the fine details engine side (need to check), but on VDSM side: - source VDSM receives VM.migrate(destination_uri) - source VDSM sends migrationCreate to destination VDSM - once destination VDSM created special-purpose VM, source VDSM instructs libvirt to start the migration - source VDSM monitors the migration, report progress, updates the downtime - migration fails: source VDSM automatically send VM.destroy to destination VDSM - migration succeeds: source VDSM destroy source VM, execution now continues on destination VM >> >> the source side is "destroyed" by qemu automatically. Engine just sends an >> explicit destroy after the migration is deemed successful in the engine too >> >>> >>> Ok, when we create the special purpose vm, do we include all the devices? >> >> it's an exact copy of the source vm. yes >> >>> >>> If this special vm (waiting for migration) is connected to all the disks, >>> then >> >> it is (it goes though preparePaths as any other VM creation) >> >>> we only need to register the secrets sent from the source in >>> migrationCreate, >>> start the special vm, and one it is running, delete the secrets. >> >> probably. Does the source know those secrets? > > At the time of migration, the source does not know much about the secrerts. > > - qemu got the secret key and connected to the ceph disks. > - libvirt knew about the secret when starting qemu/ hot-plugging a disk, but > now it does not know anything about the secret, except the secret uuid > in the element. So when the VM loses ceph connection and needs to reconnect is the uuid enough? > - vdsm knows about the auth dicts in the disk devices, but does not know the > key (the key cannot be persisted) Assuming it can reconnect (as above) using the auth, can't the new destination VM use the same? > > So engine will have to send the secrets again, so vdsm can send them to the > destination. Doable. But the the vdsm can cache it as well, perha
Re: [ovirt-devel] master broken
The patch was reverted and now we do further investigation. Sorry for the inconvenience, Oved - Original Message - > From: "Martin Betak" > To: "Oved Ourfali" > Cc: devel@ovirt.org > Sent: Tuesday, June 16, 2015 3:00:06 PM > Subject: Re: [ovirt-devel] master broken > > Hi all, > > I am encountering another error when adding host: > > 2015-06-16 13:57:41,058 ERROR > [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand] > (http--0_0_0_0_0_0_0_0-8080-3) [38e7135f] Command > 'org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand' failed: null > 2015-06-16 13:57:41,059 ERROR > [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand] > (http--0_0_0_0_0_0_0_0-8080-3) [38e7135f] Exception: > java.lang.NullPointerException > at > > org.ovirt.engine.core.bll.context.DefaultCompensationContext.snapshotEntityInMemory(DefaultCompensationContext.java:140) > [bll.jar:] > at > > org.ovirt.engine.core.bll.context.DefaultCompensationContext.snapshotNewEntity(DefaultCompensationContext.java:101) > [bll.jar:] > at > > org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand.AddVdsStaticToDb(AddVdsCommand.java:284) > [bll.jar:] > at > > org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand.access$000(AddVdsCommand.java:67) > [bll.jar:] > at > > org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand$1.runInTransaction(AddVdsCommand.java:112) > [bll.jar:] > at > > org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand$1.runInTransaction(AddVdsCommand.java:109) > [bll.jar:] > at > > org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInNewTransaction(TransactionSupport.java:210) > [utils.jar:] > at > > org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand.executeCommand(AddVdsCommand.java:109) > [bll.jar:] > at > > org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1198) > [bll.jar:] > at > > org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1342) > [bll.jar:] > at > > org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1949) > [bll.jar:] > at > > org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:174) > [utils.jar:] > at > > org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:116) > [utils.jar:] > at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1366) > [bll.jar:] > at > org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:361) > [bll.jar:] > at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:459) > [bll.jar:] > at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:441) > [bll.jar:] > at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:397) > [bll.jar:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [rt.jar:1.7.0_75] > at > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > [rt.jar:1.7.0_75] > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [rt.jar:1.7.0_75] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_75] > at > > org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) > [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] > at > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at > > org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at > > org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:114) > [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final] > at > > org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:125) > [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final] > at > > org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:135) > [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final] > at > > org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) > [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] > at > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > at > > org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
Re: [ovirt-devel] master broken
Hi all, I am encountering another error when adding host: 2015-06-16 13:57:41,058 ERROR [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand] (http--0_0_0_0_0_0_0_0-8080-3) [38e7135f] Command 'org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand' failed: null 2015-06-16 13:57:41,059 ERROR [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand] (http--0_0_0_0_0_0_0_0-8080-3) [38e7135f] Exception: java.lang.NullPointerException at org.ovirt.engine.core.bll.context.DefaultCompensationContext.snapshotEntityInMemory(DefaultCompensationContext.java:140) [bll.jar:] at org.ovirt.engine.core.bll.context.DefaultCompensationContext.snapshotNewEntity(DefaultCompensationContext.java:101) [bll.jar:] at org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand.AddVdsStaticToDb(AddVdsCommand.java:284) [bll.jar:] at org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand.access$000(AddVdsCommand.java:67) [bll.jar:] at org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand$1.runInTransaction(AddVdsCommand.java:112) [bll.jar:] at org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand$1.runInTransaction(AddVdsCommand.java:109) [bll.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInNewTransaction(TransactionSupport.java:210) [utils.jar:] at org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand.executeCommand(AddVdsCommand.java:109) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1198) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1342) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1949) [bll.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:174) [utils.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:116) [utils.jar:] at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1366) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:361) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:459) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:441) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:397) [bll.jar:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_75] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_75] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_75] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_75] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:114) [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:125) [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:135) [jboss-as-weld-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.ovirt.engine.core.bll.interceptors.CorrelationIdTrackerInterceptor.aroundInvoke(CorrelationIdTrackerInterceptor.java:13) [bll.jar:] at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source) [:1.7.0_75] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_75] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_75] at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:123) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
Re: [ovirt-devel] vdsm_master_unit-tests_created and vdsm_master_unit-tests_merged have been disabled
Il 16/06/2015 13:27, Piotr Kliczewski ha scritto: > On Tue, Jun 16, 2015 at 10:25 AM, Sandro Bonazzola > wrote: >> Il 16/06/2015 09:53, Piotr Kliczewski ha scritto: >>> On Tue, Jun 16, 2015 at 9:05 AM, Eyal Edri wrote: thanks for the quick action on this, any idea why it was stuck? we solved the mom issues yesterday by updating the mock repos to take latest mom from master snapshot repo. s. - Original Message - > From: "Sandro Bonazzola" > To: devel@ovirt.org, "infra" > Sent: Tuesday, June 16, 2015 9:56:36 AM > Subject: [ovirt-devel] vdsm_master_unit-tests_created and > vdsm_master_unit-tests_merged have been disabled > > Hi, > I disabled vdsm_master_unit-tests_created and > vdsm_master_unit-tests_merged > since they get stuck testing jsonrpc and cause jenkins job to grow over > 500 jobs taking busy for days the slaves. > >>> >>> Are there any logs that I could take a look at? >> >> http://jenkins.ovirt.org/job/vdsm_master_unit-tests_merged/287 >> > > I rerun the job [1] and there seems to be no issue related to jsonrpc tests. > It failed but due to different issue. There was a patch which was merged > yesterday which hopefully fixed the issue. I will monitor the jobs to make > sure that the problem really do not exists. Thanks > > [1] http://jenkins.ovirt.org/job/vdsm_master_unit-tests_merged/288/console > >>> > Please either fix vdsm or the unit tests before enabling these jobs again. > Thanks. > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > -- Eyal Edri Supervisor, RHEV CI EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ) ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel >> >> >> -- >> Sandro Bonazzola >> Better technology. Faster innovation. Powered by community collaboration. >> See how it works at redhat.com -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] vdsm_master_unit-tests_created and vdsm_master_unit-tests_merged have been disabled
On Tue, Jun 16, 2015 at 10:25 AM, Sandro Bonazzola wrote: > Il 16/06/2015 09:53, Piotr Kliczewski ha scritto: >> On Tue, Jun 16, 2015 at 9:05 AM, Eyal Edri wrote: >>> thanks for the quick action on this, >>> any idea why it was stuck? we solved the mom issues yesterday by updating >>> the mock >>> repos to take latest mom from master snapshot repo. >>> >>> s. >>> >>> - Original Message - From: "Sandro Bonazzola" To: devel@ovirt.org, "infra" Sent: Tuesday, June 16, 2015 9:56:36 AM Subject: [ovirt-devel] vdsm_master_unit-tests_created and vdsm_master_unit-tests_merged have been disabled Hi, I disabled vdsm_master_unit-tests_created and vdsm_master_unit-tests_merged since they get stuck testing jsonrpc and cause jenkins job to grow over 500 jobs taking busy for days the slaves. >> >> Are there any logs that I could take a look at? > > http://jenkins.ovirt.org/job/vdsm_master_unit-tests_merged/287 > I rerun the job [1] and there seems to be no issue related to jsonrpc tests. It failed but due to different issue. There was a patch which was merged yesterday which hopefully fixed the issue. I will monitor the jobs to make sure that the problem really do not exists. [1] http://jenkins.ovirt.org/job/vdsm_master_unit-tests_merged/288/console >> Please either fix vdsm or the unit tests before enabling these jobs again. Thanks. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel >>> >>> -- >>> Eyal Edri >>> Supervisor, RHEV CI >>> EMEA ENG Virtualization R&D >>> Red Hat Israel >>> >>> phone: +972-9-7692018 >>> irc: eedri (on #tlv #rhev-dev #rhev-integ) >>> ___ >>> Devel mailing list >>> Devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel > > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Repository closure is currently failing for 3.5
What gave you the idea that 0.9 should be pushed to 3.5? -- Martin Sivák msi...@redhat.com Red Hat Czech RHEV-M SLA / Brno, CZ - Original Message - > Hi, > repository closure is currently failing for 3.5 on: > > 01:18:15 package: ovirt-optimizer-jboss-0.9-1.el6.noarch from > check-custom-el6 > 01:18:15 unresolved deps: > 01:18:15 ovirt-engine-wildfly >= 0:8.2 > > Since Wildfly support is targeted to 3.6 please provide a 3.5 branch for > ovirt-optimizer or give ack for removing ovirt-optimizer from published > rpms. > > Thanks, > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] VDSM from 3.5 branch is currently failing on Fedora 20
On Tue, Jun 16, 2015 at 09:57:23AM +0200, Sandro Bonazzola wrote:
> VDSM from 3.5 branch is currently failing on Fedora 20:
>
> make[1]: Entering directory `/builddir/build/BUILD/vdsm-4.16.20'
> make check-local
> make[2]: Entering directory `/builddir/build/BUILD/vdsm-4.16.20'
> python -c 'import pyflakes; print("pyflakes-%s" % pyflakes.__version__)'
> pyflakes-0.7.3
> find . -path './.git' -prune -type f -o \
> -name '*.py' -o -name '*.py.in' | xargs /usr/bin/pyflakes | \
> grep -w -v "\./vdsm/storage/lvm\.py.*: list comprehension redefines
> 'lv' from line .*" | \
> while read LINE; do echo "$LINE"; false; done
> ./tests/functional/networkTests.py:80: redefinition of unused 'vdsm' from
> line 43
> ./tests/functional/networkTests.py:88: redefinition of unused 'vdsm' from
> line 43
> make[2]: Leaving directory `/builddir/build/BUILD/vdsm-4.16.20'
Thanks for your report.
Here's a fix
https://gerrit.ovirt.org/42414
please review.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] master broken
Fix merged. - Original Message - > From: "Oved Ourfali" > To: "Piotr Kliczewski" > Cc: devel@ovirt.org > Sent: Tuesday, June 16, 2015 11:50:52 AM > Subject: Re: [ovirt-devel] master broken > > Seems like there is part of the add host flow that calls "update" before the > entity is actually saved. > Logically, that's wrong, but we've posted a fix for that to cover this flow, > just to make sure there are no other regressions. > In addition, we'll fix this logic anyway. > > Patch will be merged soon (pending another verification). > > Thanks! > Oved > > - Original Message - > > From: "Oved Ourfali" > > To: "Piotr Kliczewski" > > Cc: devel@ovirt.org > > Sent: Tuesday, June 16, 2015 11:14:56 AM > > Subject: Re: [ovirt-devel] master broken > > > > We're looking into it. > > > > Oved > > > > - Original Message - > > > From: "Piotr Kliczewski" > > > To: devel@ovirt.org > > > Sent: Tuesday, June 16, 2015 11:07:16 AM > > > Subject: [ovirt-devel] master broken > > > > > > Guys, > > > > > > I attempted to add a host using latest master code and got following > > > exception: > > > > > > 2015-06-16 10:01:28,854 WARN > > > [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand] > > > (http--0_0_0_0_0_0_0_0-8080-3) [14cc5839] CanDoAction of action > > > 'AddVds' failed for user admin@internal. Reasons: > > > VAR__ACTION__ADD,VAR__TYPE__HOST,$server > > > 192.168.1.7,VDS_SECURITY_CONNECTION_ERROR,$ErrorMessage Couldn't store > > > fingerprint to db for host 192.168.1.7: > > > javax.persistence.PersistenceException: > > > org.hibernate.id.IdentifierGenerationException: ids for this class > > > must be manually assigned before calling save(): > > > org.ovirt.engine.core.common.businessentities.VdsStatic,VDS_CANNOT_AUTHENTICATE_TO_SERVER > > > 2015-06-16 10:01:41,724 ERROR > > > [org.ovirt.engine.core.utils.transaction.TransactionalInterceptor] > > > (http--0_0_0_0_0_0_0_0-8080-3) [740e96b9] Failed to run operation in a > > > new transaction: javax.persistence.PersistenceException: > > > org.hibernate.id.IdentifierGenerationException: ids for this class > > > must be manually assigned before calling save(): > > > org.ovirt.engine.core.common.businessentities.VdsStatic > > > at > > > org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361) > > > [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final] > > > at > > > org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289) > > > [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final] > > > at > > > org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295) > > > [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final] > > > at > > > org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:876) > > > [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final] > > > at > > > org.jboss.as.jpa.container.AbstractEntityManager.merge(AbstractEntityManager.java:548) > > > [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final] > > > at > > > org.ovirt.engine.core.dao.jpa.AbstractJpaDao.update(AbstractJpaDao.java:60) > > > [dal.jar:] > > > at > > > org.ovirt.engine.core.dao.VdsStaticDAODbFacadeImpl$Proxy$_$$_WeldSubclass.update(VdsStaticDAODbFacadeImpl$Proxy$_$$_WeldSubclass.java) > > > > > > Thanks, > > > Piotr > > > ___ > > > Devel mailing list > > > Devel@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > > > > > > > ___ > > Devel mailing list > > Devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Repository closure is currently failing for 3.5
Hi, repository closure is currently failing for 3.5 on: 01:18:15 package: ovirt-optimizer-jboss-0.9-1.el6.noarch from check-custom-el6 01:18:15 unresolved deps: 01:18:15 ovirt-engine-wildfly >= 0:8.2 Since Wildfly support is targeted to 3.6 please provide a 3.5 branch for ovirt-optimizer or give ack for removing ovirt-optimizer from published rpms. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] master broken
Seems like there is part of the add host flow that calls "update" before the entity is actually saved. Logically, that's wrong, but we've posted a fix for that to cover this flow, just to make sure there are no other regressions. In addition, we'll fix this logic anyway. Patch will be merged soon (pending another verification). Thanks! Oved - Original Message - > From: "Oved Ourfali" > To: "Piotr Kliczewski" > Cc: devel@ovirt.org > Sent: Tuesday, June 16, 2015 11:14:56 AM > Subject: Re: [ovirt-devel] master broken > > We're looking into it. > > Oved > > - Original Message - > > From: "Piotr Kliczewski" > > To: devel@ovirt.org > > Sent: Tuesday, June 16, 2015 11:07:16 AM > > Subject: [ovirt-devel] master broken > > > > Guys, > > > > I attempted to add a host using latest master code and got following > > exception: > > > > 2015-06-16 10:01:28,854 WARN > > [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand] > > (http--0_0_0_0_0_0_0_0-8080-3) [14cc5839] CanDoAction of action > > 'AddVds' failed for user admin@internal. Reasons: > > VAR__ACTION__ADD,VAR__TYPE__HOST,$server > > 192.168.1.7,VDS_SECURITY_CONNECTION_ERROR,$ErrorMessage Couldn't store > > fingerprint to db for host 192.168.1.7: > > javax.persistence.PersistenceException: > > org.hibernate.id.IdentifierGenerationException: ids for this class > > must be manually assigned before calling save(): > > org.ovirt.engine.core.common.businessentities.VdsStatic,VDS_CANNOT_AUTHENTICATE_TO_SERVER > > 2015-06-16 10:01:41,724 ERROR > > [org.ovirt.engine.core.utils.transaction.TransactionalInterceptor] > > (http--0_0_0_0_0_0_0_0-8080-3) [740e96b9] Failed to run operation in a > > new transaction: javax.persistence.PersistenceException: > > org.hibernate.id.IdentifierGenerationException: ids for this class > > must be manually assigned before calling save(): > > org.ovirt.engine.core.common.businessentities.VdsStatic > > at > > org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361) > > [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final] > > at > > org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289) > > [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final] > > at > > org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295) > > [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final] > > at > > org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:876) > > [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final] > > at > > org.jboss.as.jpa.container.AbstractEntityManager.merge(AbstractEntityManager.java:548) > > [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final] > > at > > org.ovirt.engine.core.dao.jpa.AbstractJpaDao.update(AbstractJpaDao.java:60) > > [dal.jar:] > > at > > org.ovirt.engine.core.dao.VdsStaticDAODbFacadeImpl$Proxy$_$$_WeldSubclass.update(VdsStaticDAODbFacadeImpl$Proxy$_$$_WeldSubclass.java) > > > > Thanks, > > Piotr > > ___ > > Devel mailing list > > Devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] vdsm_master_unit-tests_created and vdsm_master_unit-tests_merged have been disabled
Il 16/06/2015 09:53, Piotr Kliczewski ha scritto: > On Tue, Jun 16, 2015 at 9:05 AM, Eyal Edri wrote: >> thanks for the quick action on this, >> any idea why it was stuck? we solved the mom issues yesterday by updating >> the mock >> repos to take latest mom from master snapshot repo. >> >> s. >> >> - Original Message - >>> From: "Sandro Bonazzola" >>> To: devel@ovirt.org, "infra" >>> Sent: Tuesday, June 16, 2015 9:56:36 AM >>> Subject: [ovirt-devel] vdsm_master_unit-tests_created and >>> vdsm_master_unit-tests_merged have been disabled >>> >>> Hi, >>> I disabled vdsm_master_unit-tests_created and vdsm_master_unit-tests_merged >>> since they get stuck testing jsonrpc and cause jenkins job to grow over >>> 500 jobs taking busy for days the slaves. >>> > > Are there any logs that I could take a look at? http://jenkins.ovirt.org/job/vdsm_master_unit-tests_merged/287 > >>> Please either fix vdsm or the unit tests before enabling these jobs again. >>> Thanks. >>> -- >>> Sandro Bonazzola >>> Better technology. Faster innovation. Powered by community collaboration. >>> See how it works at redhat.com >>> ___ >>> Devel mailing list >>> Devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >>> >> >> -- >> Eyal Edri >> Supervisor, RHEV CI >> EMEA ENG Virtualization R&D >> Red Hat Israel >> >> phone: +972-9-7692018 >> irc: eedri (on #tlv #rhev-dev #rhev-integ) >> ___ >> Devel mailing list >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] master broken
We're looking into it. Oved - Original Message - > From: "Piotr Kliczewski" > To: devel@ovirt.org > Sent: Tuesday, June 16, 2015 11:07:16 AM > Subject: [ovirt-devel] master broken > > Guys, > > I attempted to add a host using latest master code and got following > exception: > > 2015-06-16 10:01:28,854 WARN > [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand] > (http--0_0_0_0_0_0_0_0-8080-3) [14cc5839] CanDoAction of action > 'AddVds' failed for user admin@internal. Reasons: > VAR__ACTION__ADD,VAR__TYPE__HOST,$server > 192.168.1.7,VDS_SECURITY_CONNECTION_ERROR,$ErrorMessage Couldn't store > fingerprint to db for host 192.168.1.7: > javax.persistence.PersistenceException: > org.hibernate.id.IdentifierGenerationException: ids for this class > must be manually assigned before calling save(): > org.ovirt.engine.core.common.businessentities.VdsStatic,VDS_CANNOT_AUTHENTICATE_TO_SERVER > 2015-06-16 10:01:41,724 ERROR > [org.ovirt.engine.core.utils.transaction.TransactionalInterceptor] > (http--0_0_0_0_0_0_0_0-8080-3) [740e96b9] Failed to run operation in a > new transaction: javax.persistence.PersistenceException: > org.hibernate.id.IdentifierGenerationException: ids for this class > must be manually assigned before calling save(): > org.ovirt.engine.core.common.businessentities.VdsStatic > at > org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361) > [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final] > at > org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289) > [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final] > at > org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295) > [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final] > at > org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:876) > [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final] > at > org.jboss.as.jpa.container.AbstractEntityManager.merge(AbstractEntityManager.java:548) > [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final] > at > org.ovirt.engine.core.dao.jpa.AbstractJpaDao.update(AbstractJpaDao.java:60) > [dal.jar:] > at > org.ovirt.engine.core.dao.VdsStaticDAODbFacadeImpl$Proxy$_$$_WeldSubclass.update(VdsStaticDAODbFacadeImpl$Proxy$_$$_WeldSubclass.java) > > Thanks, > Piotr > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] master broken
Guys, I attempted to add a host using latest master code and got following exception: 2015-06-16 10:01:28,854 WARN [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand] (http--0_0_0_0_0_0_0_0-8080-3) [14cc5839] CanDoAction of action 'AddVds' failed for user admin@internal. Reasons: VAR__ACTION__ADD,VAR__TYPE__HOST,$server 192.168.1.7,VDS_SECURITY_CONNECTION_ERROR,$ErrorMessage Couldn't store fingerprint to db for host 192.168.1.7: javax.persistence.PersistenceException: org.hibernate.id.IdentifierGenerationException: ids for this class must be manually assigned before calling save(): org.ovirt.engine.core.common.businessentities.VdsStatic,VDS_CANNOT_AUTHENTICATE_TO_SERVER 2015-06-16 10:01:41,724 ERROR [org.ovirt.engine.core.utils.transaction.TransactionalInterceptor] (http--0_0_0_0_0_0_0_0-8080-3) [740e96b9] Failed to run operation in a new transaction: javax.persistence.PersistenceException: org.hibernate.id.IdentifierGenerationException: ids for this class must be manually assigned before calling save(): org.ovirt.engine.core.common.businessentities.VdsStatic at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final] at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final] at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final] at org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:876) [hibernate-entitymanager-4.0.1.Final.jar:4.0.1.Final] at org.jboss.as.jpa.container.AbstractEntityManager.merge(AbstractEntityManager.java:548) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final] at org.ovirt.engine.core.dao.jpa.AbstractJpaDao.update(AbstractJpaDao.java:60) [dal.jar:] at org.ovirt.engine.core.dao.VdsStaticDAODbFacadeImpl$Proxy$_$$_WeldSubclass.update(VdsStaticDAODbFacadeImpl$Proxy$_$$_WeldSubclass.java) Thanks, Piotr ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] VDSM from 3.5 branch is currently failing on Fedora 20
VDSM from 3.5 branch is currently failing on Fedora 20:
make[1]: Entering directory `/builddir/build/BUILD/vdsm-4.16.20'
make check-local
make[2]: Entering directory `/builddir/build/BUILD/vdsm-4.16.20'
python -c 'import pyflakes; print("pyflakes-%s" % pyflakes.__version__)'
pyflakes-0.7.3
find . -path './.git' -prune -type f -o \
-name '*.py' -o -name '*.py.in' | xargs /usr/bin/pyflakes | \
grep -w -v "\./vdsm/storage/lvm\.py.*: list comprehension redefines
'lv' from line .*" | \
while read LINE; do echo "$LINE"; false; done
./tests/functional/networkTests.py:80: redefinition of unused 'vdsm' from line
43
./tests/functional/networkTests.py:88: redefinition of unused 'vdsm' from line
43
make[2]: Leaving directory `/builddir/build/BUILD/vdsm-4.16.20'
make[2]: *** [check-local] Error 1
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/builddir/build/BUILD/vdsm-4.16.20'
make: *** [check-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.fmuLh5 (%check)
Please fix it.
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] vdsm_master_unit-tests_created and vdsm_master_unit-tests_merged have been disabled
On Tue, Jun 16, 2015 at 9:05 AM, Eyal Edri wrote: > thanks for the quick action on this, > any idea why it was stuck? we solved the mom issues yesterday by updating the > mock > repos to take latest mom from master snapshot repo. > > s. > > - Original Message - >> From: "Sandro Bonazzola" >> To: devel@ovirt.org, "infra" >> Sent: Tuesday, June 16, 2015 9:56:36 AM >> Subject: [ovirt-devel] vdsm_master_unit-tests_created and >> vdsm_master_unit-tests_merged have been disabled >> >> Hi, >> I disabled vdsm_master_unit-tests_created and vdsm_master_unit-tests_merged >> since they get stuck testing jsonrpc and cause jenkins job to grow over >> 500 jobs taking busy for days the slaves. >> Are there any logs that I could take a look at? >> Please either fix vdsm or the unit tests before enabling these jobs again. >> Thanks. >> -- >> Sandro Bonazzola >> Better technology. Faster innovation. Powered by community collaboration. >> See how it works at redhat.com >> ___ >> Devel mailing list >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> > > -- > Eyal Edri > Supervisor, RHEV CI > EMEA ENG Virtualization R&D > Red Hat Israel > > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ) > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] vdsm_master_unit-tests_created and vdsm_master_unit-tests_merged have been disabled
thanks for the quick action on this, any idea why it was stuck? we solved the mom issues yesterday by updating the mock repos to take latest mom from master snapshot repo. s. - Original Message - > From: "Sandro Bonazzola" > To: devel@ovirt.org, "infra" > Sent: Tuesday, June 16, 2015 9:56:36 AM > Subject: [ovirt-devel] vdsm_master_unit-tests_created and > vdsm_master_unit-tests_merged have been disabled > > Hi, > I disabled vdsm_master_unit-tests_created and vdsm_master_unit-tests_merged > since they get stuck testing jsonrpc and cause jenkins job to grow over > 500 jobs taking busy for days the slaves. > > Please either fix vdsm or the unit tests before enabling these jobs again. > Thanks. > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > -- Eyal Edri Supervisor, RHEV CI EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ) ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
