Re: [ovirt-devel] [QE][ACTION REQUIRED] postponing beta release due to basic sanity test failure

[Allon Mureinik]

- Original Message -
 From: Sandro Bonazzola sbona...@redhat.com
 To: devel@ovirt.org, us...@ovirt.org
 Sent: Friday, June 27, 2014 10:44:51 AM
 Subject: [ovirt-devel] [QE][ACTION REQUIRED] postponing beta release due to 
 basic sanity test failure
 
 Hi,
 while performing basic sanity test on 3.5.0 beta candidate I've seen the
 following bugs:
 
 Bug 1113882 - [ ERROR ] Failed to execute stage 'Closing up': [ERROR]::oVirt
 sdk is disconnected from the server.
 Bug 1113891 - storage domains are listed twice
Fixed - thanks Daniel!

 Bug 1113898 - New Virtual Machine dialog drop down list are all empty
 
 Bug 1113898 make impossible to create a new VM, so basic sanity test failed.
 We need to postpone beta release until this one is fixed.
 
 repoclosure test failed on F19:
 http://lists.ovirt.org/pipermail/users/2014-June/025475.html
 
 Since candidate beta build failed sanity test, I'm going to rebuild engine
 from master and repeat sanity test on the new build.
 
 --
 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
 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ENGINE] thoughts about LinqUtils

[Allon Mureinik]

IMO, we have too many classes that do the same (useless) thing - 
org.ovirt.engine.core.utils.linq.LinqUtils and 
org.ovirt.engine.core.common.utils.ListUtils, which both have no place in 
oVirt-engine.
Why not scrap both of them, upgrade commons-collections to the modern 4.0 and 
use org.apache.commons.collections4.CollectionUtils which has all of their 
functionality, fully-tested, and maintained by someone else?

- Original Message -
 From: Moti Asayag masa...@redhat.com
 To: Yair Zaslavsky yzasl...@redhat.com
 Cc: devel@ovirt.org
 Sent: Thursday, August 21, 2014 9:04:05 AM
 Subject: Re: [ovirt-devel] [ENGINE] thoughts about LinqUtils
 
 
 
 - Original Message -
  From: Yair Zaslavsky yzasl...@redhat.com
  To: devel@ovirt.org
  Sent: Thursday, August 21, 2014 5:50:44 AM
  Subject: [ovirt-devel] [ENGINE] thoughts about LinqUtils
  
  Hi Engine developers (and others :) ),
  I would like to share some thoughts  questions with you about the future
  of
  LinqUtils
  
  1. Location of LinqUtils
  
  Currently LinqUtils resides at utils.
  However, as LinqUtils contains some non engine related code, I think it
  should be moved to the new uutils (universal utils) project.
  uutils was introduced during the work on AAA, in order to provide a set of
  utilities that are not engine related, and hopefully in the future will be
  published as a separate artifcat on
  maven central (Alon, feel free to correct me here :) )
  
 
 +1
 You'd probably have to address the entire org.ovirt.engine.core.utils.linq
 package
 and not just that specific class.
 A sort of a clean-up is also required (i.e. remove IDE generated comments),
 seems
 like a good chance to do it.
 
  2. The name LinqUtils - Linq comes from c#. I think these days are way
  behind
  us (3 years or so now?) i would like to suggest renaming the class.
  CollectionUtils? Any other suggestions are more than welcome
  
 
 +1
 
  
  
  Thanks,
  Yair
  ___
  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] [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.5.0 status - Go / No Go

[Allon Mureinik]

- Original Message -
 From: Sandro Bonazzola sbona...@redhat.com
 To: us...@ovirt.org, devel@ovirt.org
 Sent: Tuesday, September 30, 2014 5:46:15 PM
 Subject: Re: [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.5.0 status - Go /
 No Go
 
 Il 29/09/2014 08:34, Sandro Bonazzola ha scritto:
  Hi,
  We were supposed to start composing oVirt 3.5.0 GA today 2014-09-29 but we
  still have 3 blockers.
  
  Maintainers:
  - Please be sure that 3.5 snapshot satisfy release criteria[9]
  - Please be sure that no pending patches are going to block the release
  - If any patch must block the GA release please raise the issue as soon as
  possible.
  - If any packages need a rebase please raise the issue as soon as possible.
  - Be aware that packages that doesn't need a rebase must be re-built with
  final release versioning from the RC3 tag.
  - Please provide ETA for new blockers for rescheduling an RC4 and a GA
  release.
  
  The bug tracker [1] shows 3 blockers:
  Bug ID  Whiteboard  Status  Summary
  1147085 storage POSTMemory volumes not deleted when 
  removing a vm with
  snapshots
  1146073 sla POSTFailing to Attach a Storage Domain 
  without Disk Profiles
  to a Data Center 3.5
  1127460 storage NEW VM abnormal stop after LV refreshing 
  when using thin
  provisioning on block storage
 
 Today we have:
 Bug IDWhiteboard  Status  Summary
 1127460   storage POSTVM abnormal stop after LV refreshing 
 when using thin
 provisioning on block storage
The proposed VDSM patch should work, but it does not resolve the situation 
properly wrt selinux.
A proper fix should be provided to the underlying layers (see BZ 1147923 for EL 
and BZ 1147910 for Fedora).
I'd like to hear more voices here, but IMHO, not supporting enabled selinux 
envs on EL7/F20 is a no-go for GA.

 1147971   storage NEW Snapshot locked after successful live 
 storage migration
This bug requires two (simple) patches, both of which are acked and verified on 
upstream/master.
I think they can be backported and merged by EOD, unless Daniel or Ravi (the 
respective patch authors) see a problem I don't.

 
 ETA?
 
 
 
 
  
  The following bugs are keyworded as Regression and not marked as
  blockers[10]
  
  Bug ID  Whiteboard  Status  Summary
  1142647 gluster NEW supervdsm leaks memory when using 
  glusterfs
  1138144 storage NEW Failed to autorecover storage domain 
  after unblocking
  connection with host
We're unable to confirm this issue (seems as though it's caused by a bug that 
was there since 3.1, at least).
It's targeted for 3.5.1, and should not block the GA.

  1147085 storage POSTMemory volumes not deleted when 
  removing a vm with
  snapshots
This is already MODIFIED.

  1118349 storage NEW [vdsm] Creating DataCenter 3.5 using 
  master domain V1
  fails with InquireNotSupportedError
This is an edge case of an edge case.
Although this technically is a regression, there's no real-world situation that 
would lead to this, 
and it should not block 3.5.0

  
  
  Feature freeze is now effective, and branch has been created.
  All new patches must be backported to 3.5 branch too.
  Features completed are marked in green on Features Status Table [2]
  
  There are still 69 bugs [3] targeted to 3.5.0.
  Excluding node and documentation bugs we still have 46 bugs [4] targeted to
  3.5.0.
  
  More in detail [5]:
  
  Whiteboard  NEW ASSIGNEDPOSTTotal
  docs13  1   0   14
  gluster 4   0   2   6
  i18n0   0   1   1
  infra   1   0   0   1
  integration 0   0   1   1
  node9   4   0   13
  ppc 2   0   4   6
  sla 10  0   3   13
  storage 2   1   3   6
I did some scrubbing here. The only two remaining storage issues are the ones 
mentioned above, that are indeed blockers.

  virt3   1   4   8
  Total   44  7   18  69
  
  
  Maintainers / Assignee:
  - Please ensure that completed features are marked in green on Features
  Status Table [2]
  - If you find a blocker bug please remember to add it to the tracker [1]
  - Please fill release notes, the page has been created here [6]
  - Please review results from Third Test Day on the etherpad [7] and on the
  mailing lists
  - Please update the target to 3.5.1 or later for bugs that won't be in
  3.5.0:
it will ease gathering the blocking bugs for next releases.
  
  Community:
  - You're welcome to join us testing last release candidate or nightly
  builds and getting involved in oVirt Quality Assurance[8]
  
  [1] http://bugzilla.redhat.com/1073943
  

Re: [ovirt-devel] [QE][ACTION REQUIRED] oVirt 3.5.1 RC status

[Allon Mureinik]

- Original Message -
 From: Sandro Bonazzola sbona...@redhat.com
 To: nsof...@redhat.com, Darshan Narayana Murthy dnara...@redhat.com, 
 us...@ovirt.org, devel@ovirt.org, infra
 in...@ovirt.org
 Sent: Wednesday, November 26, 2014 10:15:11 AM
 Subject: [ovirt-devel] [QE][ACTION REQUIRED] oVirt 3.5.1 RC status
 
 Hi,
 We're going to start composing oVirt 3.5.1 RC on *2014-12-02 08:00 UTC* from
 3.5 branch.
 In order to stabilize the release a new branch ovirt-engine-3.5.1 will be
 created from the same git hash used for composing the RC.
 
 The bug tracker [1] shows 3 open blocker:
 Bug IDWhiteboard  Status  Summary
 1162640   gluster POSTsupervdsm segfault in libgfapi while 
 querying volume
 status detail
 1160846   sla NEW Can't add disk to VM without specifying 
 disk profile when
 the storage domain has more than one disk profile
 1159839   storage POSTNew FC LUNs are not detected on 
 hypervisor without a
 reboot
Patch was merged on master - just needs backporting and merging there too.
Seems simple enough.
Nir - ETA on this pleaes?

 
 
 The following bugs have been keyworded as Regression and not marked as
 blockers:
 
 Bug IDWhiteboard  Status  Target  Summary
 1160846   sla NEW --- Can't add disk to VM without 
 specifying disk profile
 when the storage domain has more than one disk profile
 1118349   storage NEW 3.5.1   [vdsm] Creating DataCenter 3.5 
 using master domain
 V1 fails with InquireNotSupportedError
Not interesting - this is indeed not a blocker.

 
 
 In order to stabilize the release a new branch ovirt-engine-3.5.1 will be
 created from the same git hash used for composing the RC.
 
 Maintainers:
 - Please be sure that 3.5 snapshot allow to create VMs before *2014-12-01
 15:00 UTC*
 - Please be sure that no pending patches are going to block the release
 before *2014-12-01 15:00 UTC*
 - If any patch must block the RC release please raise the issue as soon as
 possible.
 - Please provide an ETA for the pending blockers as soon as possible.
 
 Infra:
 - Please check Jenkins status for 3.5 jobs and sync with relevant maintainers
 if there are issues.
 
 There are still 98 bugs [2] targeted to 3.5.1.
 Excluding node and documentation bugs we still have 71 bugs [3] targeted to
 3.5.1.
 
 Maintainers / Assignee:
 - Please review bugs marked as Regression and add to blocker if they're real
 regressions.
 - Please add the bugs to the tracker if you think that 3.5.1 should not be
 released without them fixed.
 - Please update the target to 3.5.2 or later for bugs that won't be in 3.5.1:
   it will ease gathering the blocking bugs for next releases.
 - Please fill release notes, the page has been created here [4]
 
 Community:
 - If you're testing oVirt 3.5 nightly snapshot, please add yourself to the
 test page [5]
 
 
 [1] http://bugzilla.redhat.com/1155170
 [2] http://goo.gl/7G0PDV
 [3] http://goo.gl/6gUbVr
 [4] http://www.ovirt.org/OVirt_3.5.1_Release_Notes
 [5] http://www.ovirt.org/Testing/oVirt_3.5.1_Testing
 
 
 --
 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
 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] findbugs errors -- any way to prevent mad bot from rampant -1s?

[Allon Mureinik]

- Original Message -
 From: Greg Sheremeta gsher...@redhat.com
 To: in...@ovirt.org, devel@ovirt.org
 Cc: Eyal Edri ee...@redhat.com
 Sent: Tuesday, December 9, 2014 1:52:01 AM
 Subject: findbugs errors -- any way to prevent mad bot from rampant -1s?
 
 Hi,
 
 Is there any way to prevent this [1] from happening?
 
 Some patch got merged that findbugs complains about. Basically no
 patches can be merged until that is fixed and everybody rebases
 everything (because the bot -1's everything). That doesn't seem right.

What really doesn't seem is that:
a. a maintainer merged a patch that doesn't pass findbugs.
b. it's been a couple of days and this hasn't been fixed yet.

Having said that, I posted a fix[1] for the last issue, pending front-end 
maintainers' review

[1] http://gerrit.ovirt.org/#/c/36002/

 
 [1] http://i.imgur.com/NNHx1bq.png
 
 --
 Greg Sheremeta
 Red Hat, Inc.
 Sr. Software Engineer, RHEV
 Cell: 919-807-1086
 gsher...@redhat.com
 ___
 Infra mailing list
 in...@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/infra
 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Move bugs to ON_QA based on snapshot builds?

[Allon Mureinik]

- Original Message -
 From: Lior Vernia lver...@redhat.com
 To: devel@ovirt.org, in...@ovirt.org
 Sent: Wednesday, January 28, 2015 10:44:44 AM
 Subject: Move bugs to ON_QA based on snapshot builds?
 
 Hello everyone,
 
 I wanted to suggest that we automate the change of oVirt 3.6 bug status
 from MODIFIED to ON_QA based on nightly snapshot builds.
 
 The motivation should be clear: when bugs are fixed on the master
 branch, the fix becomes readily available for verification as soon as
 the next snapshot is built (and there's indeed someone to verify on the
 master branch - the same person who was working on the master branch and
 opened the bug!).
 
 We currently only move them to ON_QA on milestone builds (e.g. alpha,
 beta), but I don't think that's right for an open source project - the
 status of bugs (targeted to the nearest release) should be up-to-date
 with the actual state of the master branch.
 
 We've encountered the problem testing features for 3.6 the last couple
 of weeks, and since it's gonna be a long version this situation will
 likely occur often. So far I've been moving bugs to ON_QA myself, but I
 don't really want to follow the snapshot builds manually (nor move the
 bugs to ON_QA as soon as they're merged, in case the snapshot build
 doesn't happen).
 
 The downside would be that bugs could be VERIFIED at an early point in
 the development, and later regressions could occur that would render the
 verification obsolete. But this could happen just the same between
 release milestones...
 
 Thoughts?

I'm all for this.
By the time we reach Alpha, we'll have several hundred bugs in MODIFIED - if 
all of these are dumped to ON_QA simultaneously it will be impossible to 
manage/prioritize.

+1.

 
 Yours, Lior.
 ___
 Infra mailing list
 in...@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/infra
 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] REST api and template creation

[Allon Mureinik]

The fix looks simple enough.

Amit - can you backport it please?

- Original Message -
 From: Juan Hernández jhern...@redhat.com
 To: Christopher Pereira krip...@imatronix.cl, devel@ovirt.org, Allon 
 Mureinik amure...@redhat.com,
 aavi...@redhat.com
 Sent: Monday, May 11, 2015 12:48:49 PM
 Subject: Re: [ovirt-devel] REST api and template creation
 
 On 05/09/2015 09:08 AM, Christopher Pereira wrote:
  Template creation is failing, because Engine is not receiving the alias
  which apparently is required since 3.5.
  This is the XML sent to engine. Alias is there.
  API bug?
  
 
 Yes, this is a bug in the API. It is fixed already in 3.6:
 
   SDK and REST ignore template's disk attributes
   https://bugzilla.redhat.com/1110798
 
 It didn't happen before 3.5 because the backend didn't check the content
 of the alias. That changed in 3.5 as part of the fix for a different bug:
 
   Create template from vm with empty disk alias should block with
 canDoAction
   https://bugzilla.redhat.com/1110304
 
 As far as I know there is no workaround, so you will have to wait for a
 release containing the fix. Currently it is targeted for 3.6, but we
 could retarget for 3.5.
 
 Allon, Amit, can we retarget bug 1110798 to the next 3.5.z?
 
  template
  nameUDSP_ovirt-22/name
  descriptionUDS pub for ovirt at 2015-05-09 08:36:58/description
  vm id=3774dcd0-9e1a-47af-9560-fde85f46bfa1
  disks
  disk id=f96b3718-3ccf-42f4-8537-e20dc5dd7bc3
  nametest/name
  *aliastest/alias *
  storage_domains
  storage_domain
  id=07326302-2c80-4d55-a7a2-ea79c55855e3/
  /storage_domains
  /disk
  /disks
  /vm
  cluster id=0001-0001-0001-0001-019d/
  /template
  
  On 09-05-2015 3:34, Adolfo wrote:
  Hello all,
 
  My name is Adolfo, i'm in charge of developing of UDS (you can see
  something about it on ovirt home page, the case study
  http://www.ovirt.org/Universidad_de_Sevilla_Case_Study. ).
 
  Recently (a couple of days ago), i started to test UDS against ovirt
  3.5, and sudenlty Template creation as was supported previously does
  not works. :(
 
  The idea is allow to create the template in the storage that the
  administrator of UDS selects.
 
  The process is simple and was working perfectly before to 3.5 release
  (on 3.4, 3.3, 3.2 as long as i can remember). After getting all the
  data we need, we do the following (code follows):
 
  vm is the origin vm:
 
  # Create disks description to be created in specified
  storage domain, one for each disk
  sd =
  params.StorageDomains(storage_domain=[params.StorageDomain(id=storageId)])
 
  dsks = []
  for dsk in vm.disks.list():
  dks.append(params.Disk(id=dsk.get_id(),
  storage_domains=sd, name='test', alias='test'))
 
  disks = params.Disks(disk=dsks)
 
  template = params.Template(
  name=name,
  vm=params.VM(id=vm.get_id(), disks=disks),
  cluster=params.Cluster(id=cluster.get_id()),
  description=comments
  )
 
  return api.templates.add(template).get_id()
 
  This is the debug output of the request:
 
  POST /api/templates HTTP/1.1
  Host: ovirt.dkmon.com
  Accept-Encoding: identity
  Content-Length: 2656
  Filter: False
  cookie: JSESSIONID=2Ihu3uUWFhvl2xbsi5i7yBip.undefined
  Prefer: persistent-auth
  Content-type: application/xml
  Accept: application/xml
 
  template
  nameUDSP_ovirt-21/name
  descriptionUDS pub for ovirt at 2015-05-09 08:27:06/description
  vm id=3774dcd0-9e1a-47af-9560-fde85f46bfa1
  disks
  disk
  href=/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3
  id=f96b3718-3ccf-42f4-8537-e20dc5dd7bc3
  actions
  link
  href=/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3/deactivate
  rel=deactivate/
  link
  href=/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3/activate
  rel=activate/
  link
  href=/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3/export
  rel=export/
  link
  href=/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3/move
  rel=move/
  /actions
  nameno-os_Dsk1/name
  descriptionSmall empty disk/description
  link
  href=/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3/permissions
  rel=permissions/
  link
  href=/api/vms/3774dcd0-9e1a-47af-9560-fde85f46bfa1/disks/f96b3718-3ccf-42f4-8537-e20dc5dd7bc3/statistics
  rel=statistics/
  vm
  href=/api/vms/3774dcd0

Re: [ovirt-devel] Can't reach webadmin after nightly update from master

[Allon Mureinik]

the devel list is probably more appropriate for this question.

Yevgeny, IIRC you handled something similar recently, no?

- Original Message -
 From: Michael Burman mbur...@redhat.com
 To: in...@ovirt.org
 Sent: Thursday, April 9, 2015 12:05:13 PM
 Subject: Can't reach webadmin after nightly update from master
 
 Hi All,
 
 since morning update from master i can't reach the webadmin page(stay's
 white)- ovirt-engine-3.6.0-0.0.master.20150408232225.git029791c.el6.noarch
 
 in engine.log i see:
 ERROR [org.ovirt.engine.core.bll.InitBackendServicesOnStartupBean] (MSC
 service thread 1-2) [] Failed to initialize backend: org.jboss.
 weld.exceptions.WeldException: WELD-49 Unable to invoke [method]
 @PostConstruct private
 org.ovirt.engine.core.vdsbroker.ResourceManager.init() on org.ovirt
 .engine.core.vdsbroker.ResourceManager@36d207f6
 
 
 cat jboss.repo
 [jboss]
 #baseurl=http://download.devel.redhat.com/devel/candidates/JBEAP/JBEAP-6.3.2.CP.CR1/composes/JBEAP-6.3.2-RHEL-6/Server/x86_64/os/
 baseurl=http://download.eng.tlv.redhat.com/pub/rhel/devel/candidates/JBEAP/composing/latest-JBEAP-6.4-RHEL-6/compose/Server/x86_64/os/
 enabled=1
 gpgcheck=0
 http_caching=all
 
 Thanks in advance,
 
 
 
 --
 Michael Burman
 RedHat Israel, RHEV-M QE Network Team
 
 Mobile: 054-5355725
 IRC: mburman
 ___
 Infra mailing list
 in...@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/infra
 
 
 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Live export/import

[Allon Mureinik]

Another way, if you have a domain to spare, would be to detach the domain 
containing the VM and attaching it to another setup.
Otherwise, you're limited to either an export domain (which requires copying 
twice, as you mentioned), or some manual procedure like you suggested.

- Original Message -
 From: Christopher Pereira krip...@imatronix.cl
 To: devel@ovirt.org
 Sent: Saturday, June 20, 2015 2:48:20 AM
 Subject: [ovirt-devel] Live export/import
 
 Hi,
 
 I would like to migrate a VM between two different ovirt installations with
 minimum down time.
 
 Using a export domain is slow (requires copying twice) and requires to stop
 the VM.
 
 It seems like the best option is to 1) create a snapshot, 2) transfer the
 backing chain images and OVF files to the destination storage domain 3) stop
 the VM, 4) transfer the active snapshot and 5) import the VM from the
 destination storage domain.
 
 Can you please comment and suggest other alternatives?
 
 Thanks.
 
 ___
 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] Unable to import templates

[Allon Mureinik]

- Original Message -
 From: Christopher Pereira krip...@imatronix.cl
 To: devel@ovirt.org
 Sent: Tuesday, May 26, 2015 1:44:16 AM
 Subject: [ovirt-devel] Unable to import templates
 
 Hi,
 
 A user was unable to import a VM template from a gluster export storage
 because of various reasons, and since I'm afraid this could hit many
 users (losing many days waiting for import tasks to...fail) I would like
 to share the issues and some ideas with you:
 
 1) Slowness:
 
 FYI, working with sparse files on GlusterFS mounts will be very slow
 until https://bugzilla.redhat.com/show_bug.cgi?id=1220173 is implemented.
 Maybe the same applies also to other network file-systems.
 
 2) Engine Task timeout:
 
 The last times the user tried to import this template (using nightly
 builds), the task was apparently deleted by Engine because of timeout
 while the qemu-img process continued running (and consuming resources).
 I'm not sure, but I believe the tasks are deleted by Engine after 4 or 5
 days no matter if the qemu-img process is still running (!?).
 Thus, slow import tasks will never finish.
 Can someone please confirm?
 Maybe we can improve something here to support long import tasks.
Sounds like a bug.
Could you please report it with all the logs, etc. attached?


 
 3) Wrong SPM:
 
 If $SRC is on host-1, $DST on host-2 and SPM is host-3, the image will
 be unnecessarily crossing host-3 and kill the cluster performance.
 I guess Engine should choose automatically the appropriate SPM host
 depending on the tasks (host-1 or host-2 in this case).
 But it seems like oVirt doesn't currently support changing the SPM when
 there are running tasks, based on the fact that the user gets a warning
 when trying to do it manually.
Moving around SPM is WAY too dangerous to do per operation.
Looking forward, this should be part of the non-SPM architecture, probably 
after 3.6.0.

 
 4) Convert Optimization:
 
 I see oVirt is running:
 /usr/bin/qemu-img convert -t none -T none -f raw $SRC -O raw $DST
 
 In this case, $SRC is in raw format and there are no backing chains.
 
 Shouldn't we do a simple 'cp --sparse=always' instead of a 'qemu-img
 convert' in this case?
 I guess qemu-img should be doing this optimization for us, but maybe
 this raw-to-raw conversion use case is just to silly and will not be
 considered by qemu-img maintainers.
Definitely worth checking

 
 ___
 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] AppErrors cleanup

[Allon Mureinik]

Hi all,

A recent bug [1] reported as part of the translation effort alerted me to the 
fact that we have a lot (and I mean a LOT - over 100 per file) of deprecated, 
unused keys in the various AppErrors files that serve no purpose and just take 
up space and waste translators time when they examine them.

To make a long story short - I've just merged a patch to remove all these 
useless messages, and enforce via unit tests that EVERY key there should have a 
corresponding constant in the EngineMessage or EngineError enums.

Many thanks to my reviewers!
I know this was an tedious patch that couldn't have been too fun to review.


-Allon

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1244766
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Vdsm: extending maintainers team

[Allon Mureinik]

Congrats guys!


On Sun, Aug 9, 2015 at 5:24 PM, Doron Fediuck dfedi...@redhat.com wrote:

 Congratulations all!

 On Thu, Aug 6, 2015 at 12:20 PM, Francesco Romani from...@redhat.com
 wrote:

 Thanks everyone!

 I'm honoured and very happy to have reached this milestone, and this is a
 very strong incentive to increase even further commitment!

 Bests,

 --

 *From: *Sandro Bonazzola sbona...@redhat.com
 *To: *Federico Simoncelli fsimo...@redhat.com, David Caro Estevez 
 dc...@redhat.com, Eyal Edri ee...@redhat.com
 *Cc: *devel@ovirt.org
 *Sent: *Wednesday, August 5, 2015 1:48:34 PM
 *Subject: *Re: [ovirt-devel] Vdsm: extending maintainers team


 I think we had enough acks :-)

 On Wed, Aug 5, 2015 at 1:39 PM, Federico Simoncelli fsimo...@redhat.com
 wrote:

 On Tue, Aug 4, 2015 at 11:31 AM, Barak Azulay bazu...@redhat.com
 wrote:
 
  - Original Message -
  From: Dan Kenigsberg dan...@redhat.com
  To: devel@ovirt.org
  Cc: pklic...@redhat.com
  Sent: Tuesday, August 4, 2015 11:58:53 AM
  Subject: [ovirt-devel] Vdsm: extending maintainers team
 
  If you follow Vdsm development, you probably have noticed that we are
  short of active maintainers.
 
  Thankfully, we have have great developers that - in my opinion - can
  fill that gap. I am impressed by the quality of their reviews, their
  endurance, and most importantly - their ability to unbreak whatever
  code they approve.
 
  I'd like to nominate
  - Nir Soffer - for storage
 
  the above should be endorsed by Federico

 Endorsed! Good luck Nir!

  - Francesco Romani - for virt
 
  +1
 
  - Piotr Kliczewski - for infra
 
  +1

 Congrats guys!

 --
 Federico
 ___
 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




 --
 Francesco Romani
 RedHat Engineering Virtualization R  D
 Phone: 8261328
 IRC: fromani

 ___
 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] Requiring Java 8 during runtime

[Allon Mureinik]

I think it's a really bad practice to have different modules in the same
project with different language versions.

For GWT it seems to be required, but for the rest of the backend, I think
we should have one patch that moves the entire project in one go.
We can have the various maintainers ack it to show their consent.

On Mon, Oct 26, 2015 at 1:17 PM, Juan Hernández  wrote:

> On 10/26/2015 12:05 PM, Martin Mucha wrote:
> > not strictly related question: are we going to raise language level as
> well? So we can start using JDK8 features like lambdas etc?
> >
> > M.
> >
>
> Shortly after merging that patch I'll merge another one to raise the
> language level in the RESTAPI:
>
>   restapi: Use Java 8 as source and target
>   https://gerrit.ovirt.org/46288
>
> Doing the same in other components is up to their maintainers. I think
> that should be done everywhere, except where the use of GWT doesn't
> allow to do it.
>
> > - Original Message -
> >> Hello,
> >>
> >> As you probably know oVirt Engine 4 will use WildFly 10, and that
> >> requires Java 8. The version of WildFly that we currently use is 8.2.1,
> >> and it can work with both Java 7 and Java 8. In order to ease the
> >> transition I'm about to merge the following patch, that will require
> >> Java 8 during runtime:
> >>
> >>   core: Require Java 8 during runtime
> >>   https://gerrit.ovirt.org/46872
> >>
> >> The implication of this for you is that you must make sure that you have
> >> Java 8 installed in the machine where you run your the engine. Fedora 22
> >> only supports Java 8, so that isn't a problem. EL6 supports both Java 7
> >> and Java 8, so make sure that you have Java 8 installed:
> >>
> >>   yum -y install java-1.8.0-openjdk-devel
> >>
> >> If you have objections please speak now, otherwise I will merge the
> >> patch tomorrow.
> >>
> >> Regards,
> >> Juan Hernandez
> >>
> >> --
> >> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> >> 3ºD, 28016 Madrid, Spain
> >> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat
> S.L.
> >> ___
> >> 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
> >
>
>
> --
> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> 3ºD, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
> ___
> 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] OVF_STORE volumes are not updated

[Allon Mureinik]

This is what we discussed on BZ#1268842, right?

On Mon, Oct 5, 2015 at 11:35 AM, Christopher Pereira 
wrote:

> Hi,
>
> I noticed that OVF_STORE volumes are not generated periodically as
> expected [1].
> It seems like the OVF_STORE volumes are only generated when the Storage
> Domain is detached from Engine, which is not feasible if we want to keep
> the VMs running.
>
> 1) Is there any way to force the OVF_STORE volume creation without
> detaching the Storage Domain?
>
> This would be very usefull for disaster recovery, since Storage Domains
> can be backed up and VM can be reimported.
> But if the OVF_STORE volumes are not updated, critical information like
> the ID of the VM active snapshot will get lost.
> If the VM is restored with a previous snapshot (not the last one), all
> information written after the last snapshot known by the OVF_STORE will get
> lost.
>
> 2) On the other hand, the only way I know to re-read the OVF_STORE content
> with the VM information contained in a Storage Domain, is by detaching and
> re-attaching it.
> I wonder if there is also any way to re-read the OVF_STORE?
>
> [1] : This is can be verified very easily by changing a running VM
> properties (change its name or create a snapshot), copying the whole
> storage domain and importing it into another Engine (POOL_UID and CHECKSUM
> must be removed from metadata in order to be able to attach to another
> Datacenter).
>
> PS: I'm on 3.6 RC. 1.
> ___
> 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] Abandoning old patches

[Allon Mureinik]

Hi guys,

Gerrit is our front yard, and we'd like to keep it clean, tidy, and
welcoming to newcommers.

We have a jenkins job waiting to act as a roomba just waiting to be
switched on (thanks Eyal!).
It will send out an email about patches being stale for over 300 days and
will force abandon patches stale over 600 old.

What we need you to do:
Go over your patches and make sure you haven't missed anything. If you have
a path that old that for some obscure reason still has merit, just comment
on it that it's still relevant to bump its last modification date (or
better yet - answer the review, rebase it, and push for it to get merged).

To search for such patches, you can use the "status:open age:300d" search
string in gerrit.
So, e.g, for your own patches, you could use "status:open age:300d
owner:self", or as a quick link:
https://gerrit.ovirt.org/#/q/status:open+age:300d+owner:self


Thanks,
Your friendly neighbourhood cleanup patrol
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] Coverage reports

[Allon Mureinik]

Awesome!

Infra stakeholders - any chance to have this pushed to the devel list once
a month (or some other reasonable period)?

On Fri, Nov 27, 2015 at 8:57 PM, Nir Soffer  wrote:

> Hi all,
>
> Thanks to Edward, we have now coverage reports in jenkins.
>
> The way to access the report on jenkins is to use this url:
> http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/
> /artifact/exported-artifacts/htmlcov/index.html
>
> Here is an example, hopefully it will be accessible when you try:
>
> http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/648/artifact/exported-artifacts/htmlcov/index.html
>
> Todo:
>
> - Easy way to access the report from gerrit
>   It should be easy to add a link the coverage report in the comment added
>   by jenkins after a build finish.
>
> - Store the coverage reports for longer time, maybe a week?
>
> - We have only 45% coverage instead of the minimum, 100%.
>
>   Note that coverage of 25% can mean *no* code was run by the tests.
> The only code
>   running was the functions and class definitions. Here is an example:
>
> http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/648/artifact/exported-artifacts/htmlcov/_home_jenkins_workspace_vdsm_master_check-patch-fc23-x86_64_vdsm_vdsm_storage_devicemapper_py.html
>
>   Modules that were never imported during the tests have 0% coverage:
>
> http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/648/artifact/exported-artifacts/htmlcov/_home_jenkins_workspace_vdsm_master_check-patch-fc23-x86_64_vdsm_vdsm_storage_hsm_py.html
>
> - coverage creates lot of useless noise in the jenkins logs, need to
> slicense
>   this output.
>
> http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/648/consoleFull
>   I did not find a way to do this in nosetests, may need hacking
>   nose coverage plugin.
>
> - The report includes only the tests in the tests directory.
>
>We have additional tests in lib/vdsm/infra/* which are not
> included. We should
>move these to the tests directory.
>
> - The report is using absolute paths, but we like shorter relative paths.
>
>   I don't see a way to configure nosetests or coverage to generate
> relative paths.
>   May need hacking of the generated html/json in htmlcov.
>
> - Add "make coverage" target for running coverage locally
>
> - An easy way to enable coverage for the functional tests or for running
>   a single test module.
>
>   Can be done using nosetests --cover* options. Should be documented in
>   tests/README, and maybe automated using a script or Makefile.
>   When running locally, one would like to have the script open the report
>   in the browser automatically:
>   xdg-open tests/htmlcov/index.html
>
> - An easy way to enable coverage when testing flows in vdsm
>
>   Petr sent a patch for enabling coverage using vdsm.conf:
>   https://gerrit.ovirt.org/49168
>   We discussed adding vdsm-coverage package that will make it easy to setup
>
> Nir
> ___
> 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] AppErrors cleanup

[Allon Mureinik]

Same has been done for AuditLogMessages.properties (vs. the AuditLogType
enum).

On Wed, Jul 29, 2015 at 3:51 PM, Allon Mureinik <amure...@redhat.com> wrote:

> Hi all,
>
> A recent bug [1] reported as part of the translation effort alerted me to
> the fact that we have a lot (and I mean a LOT - over 100 per file) of
> deprecated, unused keys in the various AppErrors files that serve no
> purpose and just take up space and waste translators time when they examine
> them.
>
> To make a long story short - I've just merged a patch to remove all these
> useless messages, and enforce via unit tests that EVERY key there should
> have a corresponding constant in the EngineMessage or EngineError enums.
>
> Many thanks to my reviewers!
> I know this was an tedious patch that couldn't have been too fun to review.
>
>
> -Allon
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1244766
> ___
> 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] Question about https://gerrit.ovirt.org/#/c/49860/

[Allon Mureinik]

Adding devel list, which was dropped by mistake.

On Thu, Dec 10, 2015 at 1:56 PM, Allon Mureinik <amure...@redhat.com> wrote:

>
>
> On Wed, Dec 9, 2015 at 6:51 PM, Vojtech Szocs <vsz...@redhat.com> wrote:
>
>> Hi Allon,
>>
>> not sure if you saw my email (below) but I was wondering
>> what's your opinion about test method naming conventions.
>>
> ​Generally agree with that, and I tried excluding them where possible - if
> I missed any, please say so.
> ​
>
>
>>
>> Also, regarding patch https://gerrit.ovirt.org/#/c/49910/
>> why not simply exclude all Java files under src/test/java
>> for all projects? (What's the advantage of having per-file
>> exclude list of test classes?)
>>
> ​I hat overly-broad exclusions.
> There are a ton of badly named method in test classes, and I don't want to
> encourage any more.
> Although if you think this is getting out of hand, we could just do that...
> ​
>
>
>>
>> To address other files, like "Other GWT-related classes"
>> in [1] -- did you consider adding some source-level Java
>> annotation like @DontCheckMethodNames or similar? (Again,
>> avoid per-file exclude list of other classes.)
>>
> ​Yeah, but I don't want to have to write my own checker - this is a
> standard checkstyle check...
>
>
>>
>> [1]
>> https://gerrit.ovirt.org/#/c/49910/4/build-tools-root/checkstyles/src/main/resources/checkstyle-suppressions.xml
>>
>> Thanks,
>> Vojtech
>>
>>
>> - Forwarded Message -
>> From: "Vojtech Szocs" <vsz...@redhat.com>
>> To: "devel" <devel@ovirt.org>
>> Sent: Monday, December 7, 2015 8:00:36 PM
>> Subject: [ovirt-devel] Question about https://gerrit.ovirt.org/#/c/49860/
>>
>> Hi Allon!
>>
>> patch in $subject modifies test method name from:
>>
>>   testGetLocaleFromStringString_withDefault
>>
>> to:
>>
>>   testGetLocaleFromStringStringWithDefault
>>
>> I've always thought that Java test method names should be
>> as much readable as possible, because in Java tests, the
>> method name is used to describe the particular test case.
>>
>> (Unfortunately, Java test frameworks don't do a good job
>> in this area.. please correct me if I'm wrong.)
>>
>> So with JS/Jasmine we can do this:
>>
>>  describe('LocaleUtils', function () {
>>it('should extract locale from given String', function () {
>>  // actual test code
>>});
>>  });
>>
>> but in Java we usually do this:
>>
>>   // _
>>   void testGetLocaleFromStringString_withDefault
>>
>> which is already far from readable, and this:
>>
>>   testGetLocaleFromStringStringWithDefault
>>
>> makes it even worse.. Even though it complies with Java
>> method naming convention, it totally obfuscates what is
>> that particular test case about, which means people who
>> want to maintain such tests need to spend time studying
>> what the test is actually doing..
>>
>> What's your take on this?
>>
>> Regards,
>> Vojtech
>> ___
>> 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] Improving our github presense

[Allon Mureinik]

More on the same topic:

The engine currently has 3 open issue reports, all of them about a
year and half old:
https://github.com/oVirt/ovirt-engine/issues

Can we close them please?

On Wed, Nov 18, 2015 at 10:48 PM, David Caro  wrote:
> On 11/18 18:08, David Caro wrote:
>> On 11/18 17:16, Roman Mohr wrote:
>> > On Wed, Nov 18, 2015 at 2:47 PM, Ewoud Kohl van Wijngaarden <
>> > ewoud+ov...@kohlvanwijngaarden.nl> wrote:
>> >
>> > > On Wed, Nov 18, 2015 at 12:49:44AM +0200, Nir Soffer wrote:
>> > > > Hi all,
>> > > >
>> > > > Looking in ovirt github page, there are only 2 members:
>> > > > https://github.com/orgs/oVirt/people
>> > > >
>> > > > Is is possible to add automatically all contributors to this list?
>> > >
>> > > Why is that needed? It implies those people can actually do something on
>> > > the org while it's just a mirror. If you actually look at contributors,
>> > > then github will find them.
>> > > https://github.com/oVirt/vdsm/graphs/contributors
>> > > for example.
>> > >
>> >
>> > I would appreciate if we would have more people in the organization there,
>> > although it is only a mirror.
>> > We would then also mirror the liveliness of our project on one of the most
>> > important software platforms.
>>
>>
>> Fair enough, I can create a 'developers' group there with only read rights 
>> and
>> add people, any of you that wants to be added there, please reply this 
>> message
>> only to me (to avoid spamming the list) with your github user and I'll send 
>> you
>> an invite.
>>
>> Let's get noticed :)
>
>
> A couple things:
>
> * I have sent a bunch of invites to those that had any commits on vdsm or
>  engine (only the first pages of the list in github) and had their users 
> linked
>  there, if you don't want to accept it just ignore it
>
> * Anyone that has accepted the invite, pleas set yourself as public member, so
>   everyone can see that we are a bunch behind oVirt :)
>
>>
>> >
>> >
>> >
>> > > ___
>> > > Devel mailing list
>> > > Devel@ovirt.org
>> > > http://lists.ovirt.org/mailman/listinfo/devel
>> > >
>> >
>> > Roman
>>
>> > ___
>> > Infra mailing list
>> > in...@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/infra
>>
>>
>> --
>> David Caro
>>
>> Red Hat S.L.
>> Continuous Integration Engineer - EMEA ENG Virtualization R
>>
>> Tel.: +420 532 294 605
>> Email: dc...@redhat.com
>> IRC: dcaro|dcaroest@{freenode|oftc|redhat}
>> Web: www.redhat.com
>> RHT Global #: 82-62605
>
>
>
> --
> David Caro
>
> Red Hat S.L.
> Continuous Integration Engineer - EMEA ENG Virtualization R
>
> Tel.: +420 532 294 605
> Email: dc...@redhat.com
> IRC: dcaro|dcaroest@{freenode|oftc|redhat}
> Web: www.redhat.com
> RHT Global #: 82-62605
>
> ___
> 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] Diamonds are a (Java) developer's best friends

[Allon Mureinik]

Hi team,

Back in the day, somewhere between the discovery of fire and the wheel,
Java 5 introduced generics. This was a great step forwards, but also
created some of the most horrible boiler-plated code you could imagine:

Map = new HashMap();

Java 7 improved the situation by adding generic type inference, a.k.a the
diamond operator [1]:

Map = new HashMap<>();

This style is defacto the standard of the engine, with new patches using it
and patches to fix old code that doesn't use it being accepted pretty
quickly.

Since we defacto agreed on this standard, I'd like to put my money where my
mouth is, and make it a declarative standard.
I have a series of patches [2] that fix **all** the occurrences of
non-diamond declarations [3][4][5] (well, except for anonymous
implementations like we have in the DAOs) and adds a checkstyle validation
[6] to prevent further declarations like this from entering the project in
the future.

Engine maintainers, please review and assist in getting this series merged.
The rebase will be hellacious as it is, and I'd like to minimize the effort
as much as possible.


Thanks,
Allon


[1]
http://docs.oracle.com/javase/7/docs/technotes/guides/language/type-inference-generic-instance-creation.html
[2]
https://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:diamond
[3] https://gerrit.ovirt.org/49490
[4] https://gerrit.ovirt.org/49491
[5] https://gerrit.ovirt.org/49492
[6] https://gerrit.ovirt.org/49493
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] DRBD Integration with oVirt

[Allon Mureinik]

Then definitely don't go the Cinder route. We make WAY too many
Ceph-centric assumptions there.

I wonder how much effort it would be to implement a DRBD domain in a
similar fashion to the existing block domains.

On Mon, Jun 13, 2016 at 7:54 PM, Hayley Swimelar <hay...@linbit.com> wrote:

>
>
> On 06/13/2016 09:51 AM, Allon Mureinik wrote:
>
>> Maybe I'm being daft, but I'm missing something basic here.
>> What's the end goal? A DRBD Storage Domain in oVirt?
>>
>>
> Hi Allon,
>
> A DRBD Storage Domain in oVirt is the goal, yes.
>
> On Fri, Jun 3, 2016 at 9:13 PM, Hayley Swimelar <hay...@linbit.com> wrote:
>>
>> Hello all,
>>>
>>> A DRBD integration into oVirt is currently being planned.
>>>
>>> DRBD provides replicated, highly available block storage. For those
>>> unfamiliar with DRBD more information can be found here:
>>> https://www.drbd.org/en/comp/drbd-linux-driver
>>>
>>> DRBD 9 is the latest version of DRBD and interacts with DRBD Manage which
>>> is a daemon exposed via a D-Bus api. More information can be found here:
>>> https://www.drbd.org/en/comp/drbdmanage
>>>
>>> DRBD Manage handles the creation, assignment, etc. of DRBD volumes and is
>>> the interface through which Cinder manages DRBD.
>>>
>>> We are looking for advice on how best to have oVirt communicate with DRBD
>>> Manage and we have come to two options:
>>>
>>> 1) Use Cinder. Although we are integrated into Cinder, there are concerns
>>> about the need to set up a complete Cinder instance to provide access to
>>> DRBD.
>>>
>>> 2) The alternative to Cinder would be to have the oVirt Engine
>>> communicate
>>> directly to DRBD Manage via D-Bus.
>>>
>>> Any advice on the best way to achieve this would be much appreciated.
>>>
>>> --
>>> Hayley Swimelar
>>> LINBIT | Keeping the Digital World Running
>>> DRBD — Corosync — Pacemaker
>>> +1-503-573-1262 x212
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>>
>>>
>>>
>>
> --
> Hayley Swimelar
> LINBIT | Keeping the Digital World Running
> DRBD — Corosync — Pacemaker
> +1-503-573-1262 x212
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] DRBD Integration with oVirt

[Allon Mureinik]

Maybe I'm being daft, but I'm missing something basic here.
What's the end goal? A DRBD Storage Domain in oVirt?

On Fri, Jun 3, 2016 at 9:13 PM, Hayley Swimelar  wrote:

> Hello all,
>
> A DRBD integration into oVirt is currently being planned.
>
> DRBD provides replicated, highly available block storage. For those
> unfamiliar with DRBD more information can be found here:
> https://www.drbd.org/en/comp/drbd-linux-driver
>
> DRBD 9 is the latest version of DRBD and interacts with DRBD Manage which
> is a daemon exposed via a D-Bus api. More information can be found here:
> https://www.drbd.org/en/comp/drbdmanage
>
> DRBD Manage handles the creation, assignment, etc. of DRBD volumes and is
> the interface through which Cinder manages DRBD.
>
> We are looking for advice on how best to have oVirt communicate with DRBD
> Manage and we have come to two options:
>
> 1) Use Cinder. Although we are integrated into Cinder, there are concerns
> about the need to set up a complete Cinder instance to provide access to
> DRBD.
>
> 2) The alternative to Cinder would be to have the oVirt Engine communicate
> directly to DRBD Manage via D-Bus.
>
> Any advice on the best way to achieve this would be much appreciated.
>
> --
> Hayley Swimelar
> LINBIT | Keeping the Digital World Running
> DRBD — Corosync — Pacemaker
> +1-503-573-1262 x212
> ___
> 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] gerrit.ovirt.org migration

[Allon Mureinik]

Congrats guys, and thanks for your efforts!

>From some very basic clicking around and basic reviewing it indeed seems
faster, although this is a very raw first impression.

-Allon

On Sun, Jul 10, 2016 at 6:37 PM, Eyal Edri  wrote:

> Back up now.
>
> It is running now with 30GB RAM, 8 cores and better network, so overall we
> should see a major improvement.
> Please report any issues to infra is seen.
> e.
>
> On Sun, Jul 10, 2016 at 6:33 PM, Eyal Edri  wrote:
>
>> One last update to reboot it so it'll get all the goodies from 6.8
>> updated OS.
>> So it'll be up in a min.
>>
>> On Sun, Jul 10, 2016 at 6:28 PM, Shlomo Ben David 
>> wrote:
>>
>>> Hi All,
>>>
>>> The gerrit.ovirt.org migration process completed successfully.
>>> The server is up and running.
>>>
>>> Best Regards,
>>>
>>> Shlomi Ben-David | Software Engineer | Red Hat ISRAEL
>>> IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci)
>>>
>>> OPEN SOURCE - 1 4 011 && 011 4 1
>>>
>>> On Sun, Jul 10, 2016 at 5:35 PM, Shlomo Ben David 
>>> wrote:
>>>
 Hi All,

 Today we are planning to migrate gerrit.ovirt.org server to a new
 bigger instance on Amazon to improve performance.

- The migration will start at 18:00 IDT
- Estimate migration end time 19:00 IDT.


- During the migration the server will not be available (you won't
be able to send patches or review code)


- The server will be down for about an hour, but if we'll be able
to restore it before we'll let you know.


- An email will be sent at the end of the migration process.


 Best Regards,

 Shlomi Ben-David | Software Engineer | Red Hat ISRAEL
 Phone: +972-54-8008858
 IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci)

 OPEN SOURCE - 1 4 011 && 011 4 1

>>>
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>>
>> --
>> Eyal Edri
>> Associate Manager
>> RHEV DevOps
>> EMEA ENG Virtualization R
>> Red Hat Israel
>>
>> phone: +972-9-7692018
>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>
>
>
>
> --
> Eyal Edri
> Associate Manager
> RHEV DevOps
> EMEA ENG Virtualization R
> 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

[ovirt-devel] [ATTENTION] oVirt Engine tests now use Mockito 2.6.5

[Allon Mureinik]

Good morning Engine developers,

As of this morning, oVirt Engine has migrated to the next generation
of Mockito, specifically, the latest available version - 2.6.5 (well,
the latest version at the time this email was issued. Their z-stream
are as small as a single patch, and thus REALLY fast).

First of all - a big shout-out to everyone who took the time to review
and comment on this patch series.

Why did we do this?
1. The Mockito 1.x generation is no longer supported, and we want to
work with a live, maintained, library.
2. Support for Java 8 syntax.
3. Improved generics support, lending to cleaner code.
4. Improved performance.

Unfortunately(?), the Mockito 2.x generation isn't 100% backwards
compatible. Here are the main changes you need to know about.

**"Sneaky" Behavior Changes:**
1. In Mockito 1.x, stubbing a mock and then not using this recorded
behavior was not an issue (besides the fact that you're probably
writing unused code :-)). In Mokcito 2.x, by default, having unused
stubbing will fail your test. Usually, the best course of action is to
remove these useless stubbings (as I've done for most of the
occurrences in the code). If this isn't easily possible (e.g., these
stubbings are inherited from a base class), or if removing them would
actually make the test less easy to follow, you can use the
org.mockito.junit.MockitoJUnitRunner.Silent runner to revert to
Mockito 1.x's behavior.

2. In Mockito 1.x, any(Class) also matches nulls (e.g.,
any(SomeClass.class) would match any instance of SomeClass or null).
In Mockito 2.x, any(Class) *no longer matches nulls*. In order to also
match nulls you could use any() or nullable(Class).


**Code Changes**
1. Mockito 2.x's ArgumentMatcher no longer extend Hamcrest's Matcher,
and was in fact converted to a [functional] interface. Beyond the
simple change of using "implements" instead of "extends", this also
means you can write much cleaner code and have your matchers as
anonymous lambdas. If you still want to use a Hamcrest matcher for
your stubbing, you can use
org.mockito.hamcrest.MockitoHamcrest#argThat.

2. anyListOf/anySetOf/anyCollectionOf/anyMapOf are now deprecated and
should not be used (well, at least mostly - see below). Their
counterparts, anyList/anySet/anyCollection/anyMap no longer return raw
types, but generalized ones. Utilizing Java 8's type inference,
Mockito 2.x allows you to use the simpler versions without getting
unchecked assignments warnings. Note that this capability depends on
Java's language level, so frontend projects that still use Java 7 will
have to use the deprecated versions, unfortunately. I've already
applied this change to the entire backend, but you should note it when
writing new patches.

3. anyObject() is deprecated - just use any() instead. I've already
applied this change to the entire project, but you should note it when
writing new patches.

4. org.mockito.runners.MockitoJUnitRunner has been hollowed out and
deprecated. Use org.mockito.junit.MockitoJUnitRunner (or
org.mockito.junit.MockitoJUnitRunner.Silent, as explained above)
instead. I've already applied this change to the entire project, but
you should note it when writing new patches.

5. org.mockito.Matchers has been hollowed out and deprecated. Use
org.mockito.ArgumentMatchers instead. I've already applied this change
to the entire project, but you should note it when writing new
patches.



Additional information is available on Mockito's website [1], and
specifically the "What's new in Mockito 2" page [2].
If you have any other questions, feel free to reply to this thread or
contact me directly.


Have a great mocking day,
Allon


[1] http://site.mockito.org/
[2] https://github.com/mockito/mockito/wiki/What%27s-new-in-Mockito-2
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Redundant stomp connection for SPM

[Allon Mureinik]

In the jsonrpc era, I can't think, offhand, about a good reason to
keep these two connections.

Liron - any insight?

On Tue, Jan 24, 2017 at 6:18 PM, Roy Golan  wrote:
> +storage ping
>
> On 17 January 2017 at 12:19, Piotr Kliczewski 
> wrote:
>>
>> It should be enough to subscribe to irs specific queues. Instead of
>> creating new client we can rely on status of a subscription.
>>
>> On Tue, Jan 17, 2017 at 10:54 AM, Roy Golan  wrote:
>> > For each SPM host the engine creates a different stomp connection (See
>> > JsonRpcIIrsServer.java) . This also means another client connection to
>> > maintain on the SPM machine.
>> >
>> > What is the reason we still have it and what does it guarantee? Please
>> > add
>> > any info here prior to opening a bug to remove it for 4.2.
>> >
>> >
>> >
>> > ___
>> > 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] Failure on start VM in ovirt-system-tests from patches merged to master on the 25/10/2016

[Allon Mureinik]

jar:5.2.4.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.8.0_111]
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_111]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_111]
> at java.lang.reflect.Method.invoke(Method.java:498)
> [rt.jar:1.8.0_111]
> at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$
> SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74)
> [weld-core-impl-2.3.5.Final.jar:2.3.5.Final]
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.
> executeAroundInvoke(InterceptorMethodHandler.java:84)
> [weld-core-impl-2.3.5.Final.jar:2.3.5.Final]
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.
> executeInterception(InterceptorMethodHandler.java:72)
> [weld-core-impl-2.3.5.Final.jar:2.3.5.Final]
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.
> invoke(InterceptorMethodHandler.java:56) [weld-core-impl-2.3.5.Final.
> jar:2.3.5.Final]
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecorato
> rStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79)
> [weld-core-impl-2.3.5.Final.jar:2.3.5.Final]
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecorato
> rStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68)
> [weld-core-impl-2.3.5.Final.jar:2.3.5.Final]
> at org.ovirt.engine.core.bll.scheduling.SchedulingManager$
> Proxy$_$$_WeldSubclass.schedule(Unknown Source) [bll.jar:]
> at 
> org.ovirt.engine.core.bll.RunVmCommand.getVdsToRunOn(RunVmCommand.java:818)
> [bll.jar:]
> at org.ovirt.engine.core.bll.RunVmCommand.runVm(RunVmCommand.java:231)
> [bll.jar:]
> at 
> org.ovirt.engine.core.bll.RunVmCommand.perform(RunVmCommand.java:414)
> [bll.jar:]
> at 
> org.ovirt.engine.core.bll.RunVmCommand.executeVmCommand(RunVmCommand.java:339)
> [bll.jar:]
> at 
> org.ovirt.engine.core.bll.VmCommand.executeCommand(VmCommand.java:106)
> [bll.jar:]
>
>
> On Thu, Oct 27, 2016 at 5:12 AM, Allon Mureinik <amure...@redhat.com>
> wrote:
>
>> Seems like we cleared up the engine issues related to the recent
>> injection changes.
>>
>> I am now seeing stop errors, e.g.:
>>
>> {"jsonrpc": "2.0", "id": "ea0c564f-bc17-4fc2-8f1b-67c4d28257c6", "result": 
>> {"cpuStatistics": {"1": {"cpuUser": "3.07", "nodeIndex": 0, "cpuSys": 
>> "3.00", "cpuIdle": "93.93"}, "0": {"cpuUser": "1.67", "nodeIndex": 0, 
>> "cpuSys": "2.07", "cpuIdle": "96.26"}}, "numaNodeMemFree": {"0": 
>> {"memPercent": 83, "memFree": "359"}}, "memShared": 0, "thpState": "always", 
>> "ksmMergeAcrossNodes": true, "vmCount": 0, "memUsed": "20", 
>> "storageDomains": {"b2bb3220-1eb3-426a-90c2-5e236aefbe1a": {"code": 0, 
>> "actual": true, "version": 0, "acquired": true, "delay": "0.000840117", 
>> "lastCheck": "7.1", "valid": true}, "3130195a-73f9-4490-b554-98a9205cead6": 
>> {"code": 0, "actual": true, "version": 4, "acquired": true, "delay": 
>> "0.00150771", "lastCheck": "7.5", "valid": true}, 
>> "1a9e202b-83b7-4bdc-9b0c-e76b83676068": {"code": 0, "actual": true, 
>> "version": 4, "acquired": true, "delay": "0.000590956",
>> 2016-10-26 21:51:09,878 DEBUG 
>> [org.ovirt.engine.core.utils.timer.FixedDelayJobListener] 
>> (DefaultQuartzScheduler7) [6d206bd1] Rescheduling 
>> DEFAULT.org.ovirt.engine.core.bll.tasks.CommandCallbacksPoller.invokeCallbackMethods#-9223372036854775783
>>  as there is no unfired trigger.
>> 2016-10-26 21:51:28,705 DEBUG 
>> [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) 
>> [383dd6a0] Heartbeat exceeded. Closing channel
>> 2016-10-26 21:51:28,708 DEBUG 
>> [org.ovirt.vdsm.jsonrpc.client.reactors.Reactor] (SSL Stomp Reactor) 
>> [383dd6a0] Internal server error: null: java.lang.NullPointerException
>>  at 
>> org.ovirt.vdsm.jsonrpc.client.reactors.SSLClient.write(SSLClient.java:102) 
>> [vdsm-jsonrpc-java-client.jar:]
>

Re: [ovirt-devel] Failure on start VM in ovirt-system-tests from patches merged to master on the 25/10/2016

[Allon Mureinik]

@Infra - the last experimental job I saw was from ~17:30 local Israel time.
Any idea why another one isn't being triggered (or am I just being daft)?

On Wed, Oct 26, 2016 at 6:27 PM, Allon Mureinik <amure...@redhat.com> wrote:

> Yipes.
> [1] should fix that, waiting for the CI to run to merge.
>
> [1] https://gerrit.ovirt.org/#/c/65768/
>
> On Wed, Oct 26, 2016 at 3:42 PM, Nadav Goldin <ngol...@redhat.com> wrote:
>
>> Unfortunately it is still failing, see[1], the repository used was
>> built from commit [2]. If you want to check the logs same links
>> apply(just replace build number 2759->2782)
>>
>>
>>
>> [1] http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/2782
>> [2] https://gerrit.ovirt.org/#/c/65740/
>>
>> On Wed, Oct 26, 2016 at 11:33 AM, Tal Nisan <tni...@redhat.com> wrote:
>> > Should be fixed now on master as those patches were just merged:
>> >
>> > https://gerrit.ovirt.org/#/c/65738/ - "Move InjectorRule to VdsBroker":
>> > aligns the InjectorRule's package with the Injector so it can
>> essentially be
>> > used wherever the Injector is used [+12, -4]
>> > https://gerrit.ovirt.org/#/c/65739 - "InjectorRule: override injector
>> > anyway": Fixes a bug in InjectorRule where the Injector is only mocked
>> if
>> > you call InjectorRule.bind [+6, -1]
>> > https://gerrit.ovirt.org/#/c/65740 - "core: InjectorRule for injecting
>> > members": Fixes a bug in InjectorRule to allow using
>> Injector.injectMembers
>> > when using it [+18, -5]
>> > https://gerrit.ovirt.org/#/c/65725 - "core: Fix AuditLogging": The
>> actual
>> > fix. Basically, goes over all the places that create an
>> AuditLoggableBase
>> > that needs injecting and take care of it [+155, -160]
>> >
>> >
>> > On Wed, Oct 26, 2016 at 10:04 AM, Nadav Goldin <ngol...@redhat.com>
>> wrote:
>> >>
>> >> Hi,
>> >> We have new failure on OST from patches merged to master yesterday,
>> >> the failure started after the merge of [1], but as there were quite a
>> >> few patches merged quickly I can't make sure it is the one causing
>> >> it(OST aren't ran per-patch).
>> >> The test that fails is [2] when attempting to start the VM.
>> >>
>> >> The error from the API side:
>> >>
>> >> RequestError:
>> >> status: 500
>> >> reason: Internal Server Error
>> >> detail: javax.ejb.EJBException: java.lang.NullPointerException
>> >> at
>> >> org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInNoTx(
>> CMTTxInterceptor.java:213)
>> >> at
>> >> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInte
>> rceptor.java:265)
>> >> at
>> >> org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxIntercep
>> tor.java:374)
>> >> at
>> >> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTT
>> xInterceptor.java:243)
>> >> at
>> >> org.jboss.invocation.InterceptorContext.proceed(InterceptorC
>> ontext.java:340)
>> >> 
>> >>
>> >> In the engine logs there are a few 'java.lang.NullPointerException'
>> >> errors:
>> >>
>> >> 2016-10-25 11:53:52,845 INFO
>> >> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase]
>> >> (org.ovirt.thread.pool-6-thread-2) [5e6a88be] Failed to get vds
>> >> 'd60db21f-95f0-487b-9f17-44861e2610a7', error: null
>> >> 2016-10-25 11:53:52,864 DEBUG
>> >> [org.ovirt.engine.core.utils.timer.FixedDelayJobListener]
>> >> (DefaultQuartzScheduler5) [] Rescheduling
>> >>
>> >> DEFAULT.org.ovirt.engine.core.bll.tasks.AsyncTaskManager.tim
>> erElapsed#-9223372036854775787
>> >> as there is no unfired trigger.
>> >> ...
>> >> 2016-10-25 11:53:52,845 DEBUG
>> >> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogableBase]
>> >> (org.ovirt.thread.pool-6-thread-2) [5e6a88be] Exception:
>> >> java.lang.NullPointerException
>> >> at
>> >> org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLog
>> ableBase.getVdsStatic(AuditLogableBase.java:633)
>> >> [dal.jar:]
>> >> at
>> >> org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLog
>> ableBase.getVdsName(AuditLogableBase.java:504)
>> >>

Re: [ovirt-devel] Failure on start VM in ovirt-system-tests from patches merged to master on the 25/10/2016

[Allon Mureinik]

Now I also see it in the CI.

I merged the patch so we can squeeze in as many CI runs as possible before
the weekend.

On Thu, Oct 27, 2016 at 11:38 AM, Allon Mureinik <amure...@redhat.com>
wrote:

> [Adding Martin Sivak.]
>
> That reproduces on my setup too, but didn't see it in CI, and is not
> related to the recent injection issues.
>
> Martin - This issue seems to have been introduced in your patch 0e4ae6b.
> I'm not sure eaxctly why java doesn't like the @NotNull annotation on
> schedule, but ampyrically it does, as removing it solves the issue.
> I've posted https://gerrit.ovirt.org/65784 to do so - please review (or
> suggest a better solution, of course :-))
>
> Thanks,
> Allon
>
> On Thu, Oct 27, 2016 at 9:12 AM, Yaniv Kaul <yk...@redhat.com> wrote:
>
>> I still fail to run a VM:
>> 2016-10-27 02:01:02,849 ERROR [org.ovirt.engine.core.bll.RunVmOnceCommand]
>> (default task-17) [78897d21] Command 
>> 'org.ovirt.engine.core.bll.RunVmOnceCommand'
>> failed: HV000186: The constraint of type 'javax.valida
>> tion.constraints.NotNull' defined on 'schedule.' has
>> multiple matching constraint validators which is due to an additional value
>> handler of type 'org.hibernate.validator.internal.engine.valuehandli
>> ng.OptionalValueUnwrapper'. It is unclear which value needs validating.
>> Clarify configuration via @UnwrapValidatedValue.
>> 2016-10-27 02:01:02,849 ERROR [org.ovirt.engine.core.bll.RunVmOnceCommand]
>> (default task-17) [78897d21] Exception: 
>> javax.validation.UnexpectedTypeException:
>> HV000186: The constraint of type 'javax.validation.con
>> straints.NotNull' defined on 'schedule.' has multiple
>> matching constraint validators which is due to an additional value handler
>> of type 'org.hibernate.validator.internal.engine.valuehandling.Optio
>> nalValueUnwrapper'. It is unclear which value needs validating. Clarify
>> configuration via @UnwrapValidatedValue.
>> at org.hibernate.validator.internal.engine.constraintvalidation
>> .ConstraintTree.getConstraintValidatorInstanceForAutomaticUn
>> wrapping(ConstraintTree.java:266) [hibernate-validator-5.2.4.Fin
>> al.jar:5.2.4.Fin
>> al]
>> at org.hibernate.validator.internal.engine.constraintvalidation
>> .ConstraintTree.getInitializedConstraintValidator(ConstraintTree.java:163)
>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>> at org.hibernate.validator.internal.engine.constraintvalidation
>> .ConstraintTree.validateConstraints(ConstraintTree.java:116)
>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>> at org.hibernate.validator.internal.engine.constraintvalidation
>> .ConstraintTree.validateConstraints(ConstraintTree.java:87)
>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>> at org.hibernate.validator.internal.metadata.core.MetaConstrain
>> t.validateConstraint(MetaConstraint.java:73)
>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>> at org.hibernate.validator.internal.engine.ValidatorImpl.valida
>> teConstraintsForGroup(ValidatorImpl.java:1488)
>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>> at org.hibernate.validator.internal.engine.ValidatorImpl.valida
>> teReturnValueForSingleGroup(ValidatorImpl.java:1459)
>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>> at org.hibernate.validator.internal.engine.ValidatorImpl.valida
>> teReturnValueForGroup(ValidatorImpl.java:1422)
>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>> at org.hibernate.validator.internal.engine.ValidatorImpl.valida
>> teReturnValueInContext(ValidatorImpl.java:1338)
>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>> at org.hibernate.validator.internal.engine.ValidatorImpl.valida
>> teReturnValue(ValidatorImpl.java:317) [hibernate-validator-5.2.4.Fin
>> al.jar:5.2.4.Final]
>> at org.hibernate.validator.internal.engine.ValidatorImpl.valida
>> teReturnValue(ValidatorImpl.java:277) [hibernate-validator-5.2.4.Fin
>> al.jar:5.2.4.Final]
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> [rt.jar:1.8.0_111]
>> at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> [rt.jar:1.8.0_111]
>> at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> [rt.jar:1.8.0_111]
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> [rt.jar:1.8.0_111]
>> at 
>> org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:38)
>> [weld-core-impl-2.3.5.Final.jar:2.3

Re: [ovirt-devel] Failure on start VM in ovirt-system-tests from patches merged to master on the 25/10/2016

[Allon Mureinik]

The 004 CI is now passing, and it fails on 006.
I merged a patch for the failure, let's see where we get next.

On Thu, Oct 27, 2016 at 3:13 PM, Allon Mureinik <amure...@redhat.com> wrote:

> Now I also see it in the CI.
>
> I merged the patch so we can squeeze in as many CI runs as possible before
> the weekend.
>
> On Thu, Oct 27, 2016 at 11:38 AM, Allon Mureinik <amure...@redhat.com>
> wrote:
>
>> [Adding Martin Sivak.]
>>
>> That reproduces on my setup too, but didn't see it in CI, and is not
>> related to the recent injection issues.
>>
>> Martin - This issue seems to have been introduced in your patch 0e4ae6b.
>> I'm not sure eaxctly why java doesn't like the @NotNull annotation on
>> schedule, but ampyrically it does, as removing it solves the issue.
>> I've posted https://gerrit.ovirt.org/65784 to do so - please review (or
>> suggest a better solution, of course :-))
>>
>> Thanks,
>> Allon
>>
>> On Thu, Oct 27, 2016 at 9:12 AM, Yaniv Kaul <yk...@redhat.com> wrote:
>>
>>> I still fail to run a VM:
>>> 2016-10-27 02:01:02,849 ERROR [org.ovirt.engine.core.bll.RunVmOnceCommand]
>>> (default task-17) [78897d21] Command 
>>> 'org.ovirt.engine.core.bll.RunVmOnceCommand'
>>> failed: HV000186: The constraint of type 'javax.valida
>>> tion.constraints.NotNull' defined on 'schedule.' has
>>> multiple matching constraint validators which is due to an additional value
>>> handler of type 'org.hibernate.validator.internal.engine.valuehandli
>>> ng.OptionalValueUnwrapper'. It is unclear which value needs validating.
>>> Clarify configuration via @UnwrapValidatedValue.
>>> 2016-10-27 02:01:02,849 ERROR [org.ovirt.engine.core.bll.RunVmOnceCommand]
>>> (default task-17) [78897d21] Exception: 
>>> javax.validation.UnexpectedTypeException:
>>> HV000186: The constraint of type 'javax.validation.con
>>> straints.NotNull' defined on 'schedule.' has multiple
>>> matching constraint validators which is due to an additional value handler
>>> of type 'org.hibernate.validator.internal.engine.valuehandling.Optio
>>> nalValueUnwrapper'. It is unclear which value needs validating. Clarify
>>> configuration via @UnwrapValidatedValue.
>>> at org.hibernate.validator.internal.engine.constraintvalidation
>>> .ConstraintTree.getConstraintValidatorInstanceForAutomaticUn
>>> wrapping(ConstraintTree.java:266) [hibernate-validator-5.2.4.Fin
>>> al.jar:5.2.4.Fin
>>> al]
>>> at org.hibernate.validator.internal.engine.constraintvalidation
>>> .ConstraintTree.getInitializedConstraintValidator(ConstraintTree.java:163)
>>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>>> at org.hibernate.validator.internal.engine.constraintvalidation
>>> .ConstraintTree.validateConstraints(ConstraintTree.java:116)
>>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>>> at org.hibernate.validator.internal.engine.constraintvalidation
>>> .ConstraintTree.validateConstraints(ConstraintTree.java:87)
>>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>>> at org.hibernate.validator.internal.metadata.core.MetaConstrain
>>> t.validateConstraint(MetaConstraint.java:73)
>>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>>> at org.hibernate.validator.internal.engine.ValidatorImpl.valida
>>> teConstraintsForGroup(ValidatorImpl.java:1488)
>>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>>> at org.hibernate.validator.internal.engine.ValidatorImpl.valida
>>> teReturnValueForSingleGroup(ValidatorImpl.java:1459)
>>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>>> at org.hibernate.validator.internal.engine.ValidatorImpl.valida
>>> teReturnValueForGroup(ValidatorImpl.java:1422)
>>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>>> at org.hibernate.validator.internal.engine.ValidatorImpl.valida
>>> teReturnValueInContext(ValidatorImpl.java:1338)
>>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>>> at org.hibernate.validator.internal.engine.ValidatorImpl.valida
>>> teReturnValue(ValidatorImpl.java:317) [hibernate-validator-5.2.4.Fin
>>> al.jar:5.2.4.Final]
>>> at org.hibernate.validator.internal.engine.ValidatorImpl.valida
>>> teReturnValue(ValidatorImpl.java:277) [hibernate-validator-5.2.4.Fin
>>> al.jar:5.2.4.Final]
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> [rt.jar:1.8.0_1

Re: [ovirt-devel] Failure on start VM in ovirt-system-tests from patches merged to master on the 25/10/2016

[Allon Mureinik]

And now the CI job is [finally] passing.
Piotr/Eli - the stomp timeout may be worth investigating, but it's
definitely NOT the root cause of the previous failures, so feel free to
deprioritize it as you see fit.

Thanks to everyone who helped debug/investigate/review these issues, and
sorry for the noise.

On Thu, Oct 27, 2016 at 6:40 PM, Allon Mureinik <amure...@redhat.com> wrote:

> The 004 CI is now passing, and it fails on 006.
> I merged a patch for the failure, let's see where we get next.
>
> On Thu, Oct 27, 2016 at 3:13 PM, Allon Mureinik <amure...@redhat.com>
> wrote:
>
>> Now I also see it in the CI.
>>
>> I merged the patch so we can squeeze in as many CI runs as possible
>> before the weekend.
>>
>> On Thu, Oct 27, 2016 at 11:38 AM, Allon Mureinik <amure...@redhat.com>
>> wrote:
>>
>>> [Adding Martin Sivak.]
>>>
>>> That reproduces on my setup too, but didn't see it in CI, and is not
>>> related to the recent injection issues.
>>>
>>> Martin - This issue seems to have been introduced in your patch 0e4ae6b.
>>> I'm not sure eaxctly why java doesn't like the @NotNull annotation on
>>> schedule, but ampyrically it does, as removing it solves the issue.
>>> I've posted https://gerrit.ovirt.org/65784 to do so - please review (or
>>> suggest a better solution, of course :-))
>>>
>>> Thanks,
>>> Allon
>>>
>>> On Thu, Oct 27, 2016 at 9:12 AM, Yaniv Kaul <yk...@redhat.com> wrote:
>>>
>>>> I still fail to run a VM:
>>>> 2016-10-27 02:01:02,849 ERROR [org.ovirt.engine.core.bll.RunVmOnceCommand]
>>>> (default task-17) [78897d21] Command 
>>>> 'org.ovirt.engine.core.bll.RunVmOnceCommand'
>>>> failed: HV000186: The constraint of type 'javax.valida
>>>> tion.constraints.NotNull' defined on 'schedule.' has
>>>> multiple matching constraint validators which is due to an additional value
>>>> handler of type 'org.hibernate.validator.internal.engine.valuehandli
>>>> ng.OptionalValueUnwrapper'. It is unclear which value needs validating.
>>>> Clarify configuration via @UnwrapValidatedValue.
>>>> 2016-10-27 02:01:02,849 ERROR [org.ovirt.engine.core.bll.RunVmOnceCommand]
>>>> (default task-17) [78897d21] Exception: 
>>>> javax.validation.UnexpectedTypeException:
>>>> HV000186: The constraint of type 'javax.validation.con
>>>> straints.NotNull' defined on 'schedule.' has multiple
>>>> matching constraint validators which is due to an additional value handler
>>>> of type 'org.hibernate.validator.internal.engine.valuehandling.Optio
>>>> nalValueUnwrapper'. It is unclear which value needs validating. Clarify
>>>> configuration via @UnwrapValidatedValue.
>>>> at org.hibernate.validator.internal.engine.constraintvalidation
>>>> .ConstraintTree.getConstraintValidatorInstanceForAutomaticUn
>>>> wrapping(ConstraintTree.java:266) [hibernate-validator-5.2.4.Fin
>>>> al.jar:5.2.4.Fin
>>>> al]
>>>> at org.hibernate.validator.internal.engine.constraintvalidation
>>>> .ConstraintTree.getInitializedConstraintValidator(ConstraintTree.java:163)
>>>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>>>> at org.hibernate.validator.internal.engine.constraintvalidation
>>>> .ConstraintTree.validateConstraints(ConstraintTree.java:116)
>>>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>>>> at org.hibernate.validator.internal.engine.constraintvalidation
>>>> .ConstraintTree.validateConstraints(ConstraintTree.java:87)
>>>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>>>> at org.hibernate.validator.internal.metadata.core.MetaConstrain
>>>> t.validateConstraint(MetaConstraint.java:73)
>>>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>>>> at org.hibernate.validator.internal.engine.ValidatorImpl.valida
>>>> teConstraintsForGroup(ValidatorImpl.java:1488)
>>>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>>>> at org.hibernate.validator.internal.engine.ValidatorImpl.valida
>>>> teReturnValueForSingleGroup(ValidatorImpl.java:1459)
>>>> [hibernate-validator-5.2.4.Final.jar:5.2.4.Final]
>>>> at org.hibernate.validator.internal.engine.ValidatorImpl.valida
>>>> teReturnValueForGroup(ValidatorImpl.java:1422)
>>>> [hibernate-validator-5.2.4.Final.ja

[ovirt-devel] MockConfigRule for default values

[Allon Mureinik]

​​
Hi all,

One of my long time frustrations with MockConfigRule was the bloating it
caused by forcing you to mock each and every ConfigValue you may use, when
more often than not you don't really care about the value but just was your
test to not fail with a NullPointerException.

I've recently merged a series of patches to address this and return the
default value for any ConfigValues that is not explicitly specified. In
other words, this aligns MockConfigRule's behavior with the production code
- if a value is specified, return it, and if not, return the default from
the annotation.

This change has no effect on values you explicitly mock, and if you
particularly need a certain ConfigValues to return null, you may state so
implicitly, either inline when you construct the Rule:

@Rule
public static MockConfigRule mcr = new
MockConfigRule(mockConfig(ConfigValues.SomeValue, null));

Or later on when you need it:

@Test
public void someTest() {
mcr.mockConfigValue(ConfigValues.SomeOtherValue, null);
}

Additional details can be found on the website:
http://www.ovirt.org/develop/dev-process/unit-testing-utilities/mockconfigrule/

-Allon
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt Engine checkstyle upgrade

[Allon Mureinik]

On Mon, Mar 27, 2017 at 3:09 PM, Allon Mureinik <amure...@redhat.com> wrote:

> Indeed, Greg.thanks
>
> As a temporary solution, you could cherry-pick https://gerrit.
> ovirt.org/#/c/74611 and work above it.
> It should solve the issue (even though IMHO it isn't ready for merging to
> master).
>
> Vojta - are you updating https://gerrit.ovirt.org/#/c/74611 as per my
> comments there, or should I take it over?
>
I literally have no idea who I did made this typo.
I meant "Vojtech", of course.​



>
> On Mon, Mar 27, 2017 at 3:03 PM, Greg Sheremeta <gsher...@redhat.com>
> wrote:
>
>> From the comments in 74619
>>
>> "" "
>> So, tl;dr - it /won't/ work with this patch but without 74611. This patch
>> should be applied before 74611
>> "" "
>>
>> On Mon, Mar 27, 2017 at 7:42 AM, Marek Libra <mli...@redhat.com> wrote:
>>
>>> With
>>>   https://gerrit.ovirt.org/#/c/74619/
>>>
>>> applied, following is still failing:
>>>   make gwt-debug DEBUG_MODULE=webadmin DEV_EXTRA_BUILD_FLAGS_GWT_DEFA
>>> ULTS="-Dgwt.cssResourceStyle=pretty -Dgwt.userAgent=gecko1_8"
>>>
>>> with message:
>>> [WARNING] The requested profile "gwt-user" could not be activated
>>> because it does not exist.
>>> [ERROR] Failed to execute goal 
>>> org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check
>>> (checkstyle) on project webadmin: Failed during checkstyle configuration:
>>> Exception was thrown while processing /home/mlibra/IdeaProjects/ovir
>>> t-engine/frontend/webadmin/modules/gwt-extension/src/main/
>>> java/org/ovirt/engine/ui/uioverrides/org/slf4j/Logger.java: can't parse
>>> argument number: For input string: "" -> [Help 1]
>>>
>>>
>>> Any hint, please?
>>> Marek
>>>
>>>
>>>
>>> On Fri, Mar 24, 2017 at 4:14 PM, Vojtech Szocs <vsz...@redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Mar 24, 2017 at 3:51 PM, Vojtech Szocs <vsz...@redhat.com>
>>>> wrote:
>>>>
>>>>> Found the problem after debugging NlsCheck.
>>>>>
>>>>> First of all, it checks all kinds of Java sources, including the
>>>>> generated ones. That's silly and one of the reasons why Checkstyle
>>>>> execution takes a rather long time. I'll fix that.
>>>>>
>>>>> Next, when checking a Java source that contains string "{}" (without
>>>>> quotes) it will log the problem, but Checkstyle message logging infra
>>>>> things that "{}" is a placeholder to resolve, but it's not, and it fails 
>>>>> on
>>>>> NumberFormatException. I'll fix that too.
>>>>>
>>>>
>>>> ​https://gerrit.ovirt.org/#/c/74611/​
>>>>
>>>>
>>>>> Vojtech
>>>>>
>>>>>
>>>>> On Fri, Mar 24, 2017 at 3:19 PM, Vojtech Szocs <vsz...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Allon,
>>>>>>
>>>>>> I think I found some strange Checkstyle related problems on master.
>>>>>>
>>>>>> Engine build with (GWT compilation enabled) works OK.
>>>>>>
>>>>>> Next, trying to start GWT debugger:
>>>>>>
>>>>>> $ make gwt-debug DEBUG_MODULE=webadmin \
>>>>>>   DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=gecko1_8,safari"
>>>>>> \
>>>>>>   DEV_EXTRA_BUILD_FLAGS="-Dgwt.logLevel=INFO -Dgwt.locale=en_US
>>>>>> -Dgwt.compiler.localWorkers=1" \
>>>>>>   DEV_BUILD_GWT_SUPER_DEV_MODE=1
>>>>>>
>>>>>> maven-checkstyle-plugin:check execution fails on
>>>>>>
>>>>>>   frontend/webadmin/modules/gwt-extension/src/main/java/org/ov
>>>>>> irt/engine/ui/uioverrides/org/ovirt/engine/core/compat/Forma
>>>>>> tterDotnet.java
>>>>>>   can't parse argument number: (\\d)\\: For input string: "(\\d)\\"
>>>>>>
>>>>>> the class isn't used, removed it, retry. Now it fails on:
>>>>>>
>>>>>>   frontend/webadmin/modules/gwt-extension/src/main/java/org/ov
>>>>>> irt/engine/ui/uioverrides/org/slf4j/Logger.java
>>>>>>   can't 

[ovirt-devel] oVirt Engine checkstyle upgrade

[Allon Mureinik]

Hi all,

As per [1], I've just merged a series of patches that upgrades the oVirt
engine to use the latest maven-checkstyle-plugin and checkstyle packages.

Please note that the newer checkstyle is a tad stricter than the old one we
used to have (read: it contains several fixes for bugs where the old
checkstyle was supposed to find issues but missed them).
I also took the opportunity and added a couple of new checks that enforce
rules we were de-facto adhering to anyway.

If any problems come up, please let me know.


-Your friendly neighborhood cleanup dude

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1433408
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt Engine checkstyle upgrade

[Allon Mureinik]

On Mon, Mar 27, 2017 at 8:48 PM, Vojtech Szocs <vsz...@redhat.com> wrote:

>
>
> On Mon, Mar 27, 2017 at 2:10 PM, Allon Mureinik <amure...@redhat.com>
> wrote:
>
>>
>>
>> On Mon, Mar 27, 2017 at 3:09 PM, Allon Mureinik <amure...@redhat.com>
>> wrote:
>>
>>> Indeed, Greg.thanks
>>>
>>> As a temporary solution, you could cherry-pick https://gerrit.ovi
>>> rt.org/#/c/74611 and work above it.
>>> It should solve the issue (even though IMHO it isn't ready for merging
>>> to master).
>>>
>>> Vojta - are you updating https://gerrit.ovirt.org/#/c/74611 as per my
>>> comments there, or should I take it over?
>>>
>> I literally have no idea who I did made this typo.
>> I meant "Vojtech", of course.​
>>
>
> ​In Czech language, Vojta actually means Vojtech, in a less formal way =)
>
​In that case, I totally meant to type that :-)
​

>
> I've just updated https://gerrit.ovirt.org/#/c/74611/ according to your
> comments.
>
​I cleaned up some white-spacing noise there that seemed unrelated to the
patch and merged.
>From my local testing, using -Pgwtdev now works just find.

Votech (or Vojta, if you prefer ^_^) - many thanks for your efforts here.

Marek, and everyone else - please let me know if this still causes you any
grief.​




>
> The reason why GWT debugger fails to start is because one of the
> non-localized strings (which comes from `gwt-extension` and therefore
> shouldn't be checked in the first place..) contains a {} placeholder,
> NlsCheck logs it, and eventually crashes because it thinks it's a log
> message placeholder, but it's just something we want printed out.
>
>
>>
>>
>>
>>>
>>> On Mon, Mar 27, 2017 at 3:03 PM, Greg Sheremeta <gsher...@redhat.com>
>>> wrote:
>>>
>>>> From the comments in 74619
>>>>
>>>> "" "
>>>> So, tl;dr - it /won't/ work with this patch but without 74611. This
>>>> patch should be applied before 74611
>>>> "" "
>>>>
>>>> On Mon, Mar 27, 2017 at 7:42 AM, Marek Libra <mli...@redhat.com> wrote:
>>>>
>>>>> With
>>>>>   https://gerrit.ovirt.org/#/c/74619/
>>>>>
>>>>> applied, following is still failing:
>>>>>   make gwt-debug DEBUG_MODULE=webadmin DEV_EXTRA_BUILD_FLAGS_GWT_DEFA
>>>>> ULTS="-Dgwt.cssResourceStyle=pretty -Dgwt.userAgent=gecko1_8"
>>>>>
>>>>> with message:
>>>>> [WARNING] The requested profile "gwt-user" could not be activated
>>>>> because it does not exist.
>>>>> [ERROR] Failed to execute goal 
>>>>> org.apache.maven.plugins:maven-checkstyle-plugin:2.17:check
>>>>> (checkstyle) on project webadmin: Failed during checkstyle configuration:
>>>>> Exception was thrown while processing /home/mlibra/IdeaProjects/ovir
>>>>> t-engine/frontend/webadmin/modules/gwt-extension/src/main/ja
>>>>> va/org/ovirt/engine/ui/uioverrides/org/slf4j/Logger.java: can't parse
>>>>> argument number: For input string: "" -> [Help 1]
>>>>>
>>>>>
>>>>> Any hint, please?
>>>>> Marek
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Mar 24, 2017 at 4:14 PM, Vojtech Szocs <vsz...@redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 24, 2017 at 3:51 PM, Vojtech Szocs <vsz...@redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Found the problem after debugging NlsCheck.
>>>>>>>
>>>>>>> First of all, it checks all kinds of Java sources, including the
>>>>>>> generated ones. That's silly and one of the reasons why Checkstyle
>>>>>>> execution takes a rather long time. I'll fix that.
>>>>>>>
>>>>>>> Next, when checking a Java source that contains string "{}" (without
>>>>>>> quotes) it will log the problem, but Checkstyle message logging infra
>>>>>>> things that "{}" is a placeholder to resolve, but it's not, and it 
>>>>>>> fails on
>>>>>>> NumberFormatException. I'll fix that too.
>>>>>>>
>>>>>>
>>>>>> ​https://gerrit.ovirt.org/#/c/74611/​
>>>>>&

Re: [ovirt-devel] Line of death for tests

[Allon Mureinik]

Issue reported on Mockito:
https://github.com/mockito/mockito/issues/990


On Thu, Mar 16, 2017 at 8:36 PM, Allon Mureinik <amure...@redhat.com> wrote:

> The root cause seems to be MigrateVmCommandTest and its relation to
> MigrateVmCommand.
>
> A common misconception is that if an object is annotated with
> @InjectMocks, Mockito will inject its @Mocks and @Spys to fields annotated
> with @Inject.
> This is, as noted, not correct - Mockito will attempt to injcet its mocks
> to *ALL* the fields, regardless of annotations.
>
> And here's where things start getting funky.
> Since the new field you introduced is an Object, any mock would be a
> possible match for it. If more than one mock fits the field (as you have in
> the test - dbFacade and vmValidator), Mockito silently skips injecting it,
> and leaves it null (not sure if this is a bug or an intentional ugly
> behavior) - need to look into this further.
> Even worse, this failure breaks the mocking sequence, so the mocked object
> isn't spied. When you attempt to stub it's behavior (e.g., with doReturn,
> as the first line of 
> testValidationFailsWhenVmHasDisksPluggedWithScsiReservation
> does), it will fail with a NotAMockException). From there on, it's all down
> hill.
>
> The good news is that this test doesn't really need to inject mocks, so
> just removing that annotation solves the issue. I've posted a patch [1],
> please review it.
>
> I'll also organize an MCVE reproducer and report a bug against mockito,
> and we'll see if there's any chance to get it solved any time soon.
>
> -Allon
>
> [1] https://gerrit.ovirt.org/#/q/topic:MigrateVmCommandTest
>
> On Thu, Mar 16, 2017 at 11:55 AM, Shmuel Melamud <smela...@redhat.com>
> wrote:
>
>> Hi!
>>
>> I've found yesterday a very strange bug, most likely in Mockito. Hard
>> to believe it really happens, but I've reproduced it in different
>> environmentы and several revisions of oVirt master.
>>
>> I've added the following line into MigrateVmCommand:
>>
>>  private Integer actualDowntime;
>> +private Object actualDowntimeLock;
>>
>> This line causes ALL tests to fail with NullPointerException. Some
>> tests print such a stack trace:
>>
>> java.lang.NullPointerException
>> at org.mockito.internal.junit.util.TestName.getTestName(TestNam
>> e.java:11)
>> at org.mockito.internal.junit.MismatchReportingTestListener.tes
>> tFinished(MismatchReportingTestListener.java:29)
>> at org.mockito.internal.runners.DefaultInternalRunner$1$1.testF
>> inished(DefaultInternalRunner.java:56)
>> at org.junit.runner.notification.SynchronizedRunListener.testFi
>> nished(SynchronizedRunListener.java:56)
>> at org.junit.runner.notification.RunNotifier$7.notifyListener(R
>> unNotifier.java:190)
>> ...
>>
>> Name of the field doesn't matter, but type matters - changing the type
>> to Integer solved the problem.
>>
>> Does anybody has an idea why this happens and how to fix it?
>>
>> Shmuel
>> ___
>> 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] [ OST Failure Report ] [ oVirt master ] [ 12-07-2017 ] [ 004_basic_sanity.live_storage_migration ]

[Allon Mureinik]

Definitely looks like it's related to that patch series.

I'm on it.

On Thu, Jul 13, 2017 at 11:18 AM, Evgheni Dereveanchin 
wrote:

> Hi, we have OST failing on Master
>
> Test failed: [ 004_basic_sanity.live_storage_migration ]
> Link to suspected patches: https://gerrit.ovirt.org/#/c/79246/
> Link to Job: http://jenkins.ovirt.org/job/test-repo_ovirt_
> experimental_master/7555/
> Error snippet from the log: http://jenkins.ovirt.org/job/test-repo_ovirt_
> experimental_master/7555/artifact/exported-artifacts/
> basic-suit-master-el7/test_logs/basic-suite-master/post-
> 004_basic_sanity.py/
>
> 
>
> [Cannot move Virtual Disk. The disk vm0_disk0 is plugged to non-Down VMs: vm0]
>
> 
>
> 
>
> 2017-07-12 12:19:32,547-04 INFO  
> [org.ovirt.engine.core.bll.storage.disk.MoveDisksCommand] (default task-2) 
> [4cbc2554-837c-4f76-94db-3e9312eee9d9] Running command: MoveDisksCommand 
> internal: false. Entities affected :  ID: 
> eb4127a6-cc05-4aea-9250-9792447e77e8 Type: DiskAction group 
> CONFIGURE_DISK_STORAGE with role type USER
> 2017-07-12 12:19:32,552-04 INFO  
> [org.ovirt.engine.core.bll.AddDeprecatedApiEventCommand] (default task-4) 
> [5cb4e759] Running command: AddDeprecatedApiEventCommand internal: false.
> 2017-07-12 12:19:32,616-04 INFO  
> [org.ovirt.engine.core.bll.snapshots.CreateAllSnapshotsFromVmCommand] 
> (default task-4) [568e6d7d-3a5f-4f97-bb39-8b4d2d4ae1da] Lock Acquired to 
> object 
> 'EngineLock:{exclusiveLocks='[f66c92f3-474f-4b89-8ba3-56a583ddad89=VM]', 
> sharedLocks=''}'
> 2017-07-12 12:19:32,642-04 INFO  
> [org.ovirt.engine.core.bll.storage.lsm.LiveMigrateVmDisksCommand] (default 
> task-2) [4cbc2554-837c-4f76-94db-3e9312eee9d9] Lock Acquired to object 
> 'EngineLock:{exclusiveLocks='[eb4127a6-cc05-4aea-9250-9792447e77e8=DISK]', 
> sharedLocks='[4c13d9f7-faf7-4b43-90f7-5ac7438efb80=VM]'}'
> 2017-07-12 12:19:32,658-04 INFO  
> [org.ovirt.engine.core.bll.snapshots.CreateAllSnapshotsFromVmCommand] 
> (default task-4) [568e6d7d-3a5f-4f97-bb39-8b4d2d4ae1da] Running command: 
> CreateAllSnapshotsFromVmCommand internal: false. Entities affected :  ID: 
> f66c92f3-474f-4b89-8ba3-56a583ddad89 Type: VMAction group 
> MANIPULATE_VM_SNAPSHOTS with role type USER
> 2017-07-12 12:19:32,681-04 INFO  
> [org.ovirt.engine.core.bll.snapshots.CreateSnapshotCommand] (default task-4) 
> [568e6d7d-3a5f-4f97-bb39-8b4d2d4ae1da] Running command: CreateSnapshotCommand 
> internal: true. Entities affected :  ID: ---- 
> Type: Storage
> 2017-07-12 12:19:32,691-04 WARN  
> [org.ovirt.engine.core.bll.storage.lsm.LiveMigrateVmDisksCommand] (default 
> task-2) [4cbc2554-837c-4f76-94db-3e9312eee9d9] Validation of action 
> 'LiveMigrateVmDisks' failed for user admin@internal-authz. Reasons: 
> VAR__ACTION__MOVE,VAR__TYPE__DISK,ACTION_TYPE_FAILED_DISK_PLUGGED_TO_NON_DOWN_VMS,$DiskName
>  vm0_disk0,$VmList vm0
> 2017-07-12 12:19:32,692-04 INFO  
> [org.ovirt.engine.core.bll.storage.lsm.LiveMigrateVmDisksCommand] (default 
> task-2) [4cbc2554-837c-4f76-94db-3e9312eee9d9] Lock freed to object 
> 'EngineLock:{exclusiveLocks='[eb4127a6-cc05-4aea-9250-9792447e77e8=DISK]', 
> sharedLocks='[4c13d9f7-faf7-4b43-90f7-5ac7438efb80=VM]'}'
> 2017-07-12 12:19:32,701-04 ERROR 
> [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default 
> task-2) [] Operation Failed: [Cannot move Virtual Disk. The disk vm0_disk0 is 
> plugged to non-Down VMs: vm0]
>
> 
>
> --
> Regards,
> Evgheni Dereveanchin
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 12-07-2017 ] [ 004_basic_sanity.live_storage_migration ]

[Allon Mureinik]

On Thu, Jul 13, 2017 at 1:24 PM, Eyal Edri <ee...@redhat.com> wrote:

>
>
> On Thu, Jul 13, 2017 at 12:50 PM, Allon Mureinik <amure...@redhat.com>
> wrote:
>
>> https://gerrit.ovirt.org/#/c/79381/ should solve this.
>>
>> I'm waiting for the "regular" CI to complete before merging.
>>
>
> Did you try running the manual job with it? [1]
>
> [1] http://jenkins.ovirt.org/view/oVirt%20system%20tests/
> job/ovirt-system-tests_manual/
>

​I reproduced the error on my own system, and verified the fix there.
If the fix is fine the manual job is great. If it isn't, and you need to
debug, it's much less comfortable.


Regardless - the patch is merged now, so the next OST run should be OK.


Sorry for the noise.​

>
>
>>
>> On Thu, Jul 13, 2017 at 11:35 AM, Allon Mureinik <amure...@redhat.com>
>> wrote:
>>
>>> Definitely looks like it's related to that patch series.
>>>
>>> I'm on it.
>>>
>>> On Thu, Jul 13, 2017 at 11:18 AM, Evgheni Dereveanchin <
>>> edere...@redhat.com> wrote:
>>>
>>>> Hi, we have OST failing on Master
>>>>
>>>> Test failed: [ 004_basic_sanity.live_storage_migration ]
>>>> Link to suspected patches: https://gerrit.ovirt.org/#/c/79246/
>>>> Link to Job: http://jenkins.ovirt.org/job/test-repo_ovirt_experiment
>>>> al_master/7555/
>>>> Error snippet from the log: http://jenkins.ovirt.org/
>>>> job/test-repo_ovirt_experimental_master/7555/artifact/export
>>>> ed-artifacts/basic-suit-master-el7/test_logs/basic-suite-mas
>>>> ter/post-004_basic_sanity.py/
>>>>
>>>> 
>>>>
>>>> [Cannot move Virtual Disk. The disk vm0_disk0 is plugged to non-Down VMs: 
>>>> vm0]
>>>>
>>>> 
>>>>
>>>> 
>>>>
>>>> 2017-07-12 12:19:32,547-04 INFO  
>>>> [org.ovirt.engine.core.bll.storage.disk.MoveDisksCommand] (default task-2) 
>>>> [4cbc2554-837c-4f76-94db-3e9312eee9d9] Running command: MoveDisksCommand 
>>>> internal: false. Entities affected :  ID: 
>>>> eb4127a6-cc05-4aea-9250-9792447e77e8 Type: DiskAction group 
>>>> CONFIGURE_DISK_STORAGE with role type USER
>>>> 2017-07-12 12:19:32,552-04 INFO  
>>>> [org.ovirt.engine.core.bll.AddDeprecatedApiEventCommand] (default task-4) 
>>>> [5cb4e759] Running command: AddDeprecatedApiEventCommand internal: false.
>>>> 2017-07-12 12:19:32,616-04 INFO  
>>>> [org.ovirt.engine.core.bll.snapshots.CreateAllSnapshotsFromVmCommand] 
>>>> (default task-4) [568e6d7d-3a5f-4f97-bb39-8b4d2d4ae1da] Lock Acquired to 
>>>> object 
>>>> 'EngineLock:{exclusiveLocks='[f66c92f3-474f-4b89-8ba3-56a583ddad89=VM]', 
>>>> sharedLocks=''}'
>>>> 2017-07-12 12:19:32,642-04 INFO  
>>>> [org.ovirt.engine.core.bll.storage.lsm.LiveMigrateVmDisksCommand] (default 
>>>> task-2) [4cbc2554-837c-4f76-94db-3e9312eee9d9] Lock Acquired to object 
>>>> 'EngineLock:{exclusiveLocks='[eb4127a6-cc05-4aea-9250-9792447e77e8=DISK]', 
>>>> sharedLocks='[4c13d9f7-faf7-4b43-90f7-5ac7438efb80=VM]'}'
>>>> 2017-07-12 12:19:32,658-04 INFO  
>>>> [org.ovirt.engine.core.bll.snapshots.CreateAllSnapshotsFromVmCommand] 
>>>> (default task-4) [568e6d7d-3a5f-4f97-bb39-8b4d2d4ae1da] Running command: 
>>>> CreateAllSnapshotsFromVmCommand internal: false. Entities affected :  ID: 
>>>> f66c92f3-474f-4b89-8ba3-56a583ddad89 Type: VMAction group 
>>>> MANIPULATE_VM_SNAPSHOTS with role type USER
>>>> 2017-07-12 12:19:32,681-04 INFO  
>>>> [org.ovirt.engine.core.bll.snapshots.CreateSnapshotCommand] (default 
>>>> task-4) [568e6d7d-3a5f-4f97-bb39-8b4d2d4ae1da] Running command: 
>>>> CreateSnapshotCommand internal: true. Entities affected :  ID: 
>>>> ---- Type: Storage
>>>> 2017-07-12 12:19:32,691-04 WARN  
>>>> [org.ovirt.engine.core.bll.storage.lsm.LiveMigrateVmDisksCommand] (default 
>>>> task-2) [4cbc2554-837c-4f76-94db-3e9312eee9d9] Validation of action 
>>>> 'LiveMigrateVmDisks' failed for user admin@internal-authz. Reasons: 
>>>> VAR__ACTION__MOVE,VAR__TYPE__DISK,ACTION_TYPE_FAILED_DISK_PLUGGED_TO_NON_DOWN_VMS,$DiskName
>>>>  vm0_disk0,$VmList vm0
>>>> 2017-07-12 12:19:32,692-04 INFO  
>>>> [org.ovirt.engine.core.bll.storage.lsm.LiveMigrateVmDisksCommand] (default 
>>>> task-2) [4cbc2554-837c-4f76-94db-3e9312eee9d9] Lock free

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 12-07-2017 ] [ 004_basic_sanity.live_storage_migration ]

[Allon Mureinik]

https://gerrit.ovirt.org/#/c/79381/ should solve this.

I'm waiting for the "regular" CI to complete before merging.

On Thu, Jul 13, 2017 at 11:35 AM, Allon Mureinik <amure...@redhat.com>
wrote:

> Definitely looks like it's related to that patch series.
>
> I'm on it.
>
> On Thu, Jul 13, 2017 at 11:18 AM, Evgheni Dereveanchin <
> edere...@redhat.com> wrote:
>
>> Hi, we have OST failing on Master
>>
>> Test failed: [ 004_basic_sanity.live_storage_migration ]
>> Link to suspected patches: https://gerrit.ovirt.org/#/c/79246/
>> Link to Job: http://jenkins.ovirt.org/job/test-repo_ovirt_experiment
>> al_master/7555/
>> Error snippet from the log: http://jenkins.ovirt.org/
>> job/test-repo_ovirt_experimental_master/7555/artifact/
>> exported-artifacts/basic-suit-master-el7/test_logs/basic-
>> suite-master/post-004_basic_sanity.py/
>>
>> 
>>
>> [Cannot move Virtual Disk. The disk vm0_disk0 is plugged to non-Down VMs: 
>> vm0]
>>
>> 
>>
>> 
>>
>> 2017-07-12 12:19:32,547-04 INFO  
>> [org.ovirt.engine.core.bll.storage.disk.MoveDisksCommand] (default task-2) 
>> [4cbc2554-837c-4f76-94db-3e9312eee9d9] Running command: MoveDisksCommand 
>> internal: false. Entities affected :  ID: 
>> eb4127a6-cc05-4aea-9250-9792447e77e8 Type: DiskAction group 
>> CONFIGURE_DISK_STORAGE with role type USER
>> 2017-07-12 12:19:32,552-04 INFO  
>> [org.ovirt.engine.core.bll.AddDeprecatedApiEventCommand] (default task-4) 
>> [5cb4e759] Running command: AddDeprecatedApiEventCommand internal: false.
>> 2017-07-12 12:19:32,616-04 INFO  
>> [org.ovirt.engine.core.bll.snapshots.CreateAllSnapshotsFromVmCommand] 
>> (default task-4) [568e6d7d-3a5f-4f97-bb39-8b4d2d4ae1da] Lock Acquired to 
>> object 
>> 'EngineLock:{exclusiveLocks='[f66c92f3-474f-4b89-8ba3-56a583ddad89=VM]', 
>> sharedLocks=''}'
>> 2017-07-12 12:19:32,642-04 INFO  
>> [org.ovirt.engine.core.bll.storage.lsm.LiveMigrateVmDisksCommand] (default 
>> task-2) [4cbc2554-837c-4f76-94db-3e9312eee9d9] Lock Acquired to object 
>> 'EngineLock:{exclusiveLocks='[eb4127a6-cc05-4aea-9250-9792447e77e8=DISK]', 
>> sharedLocks='[4c13d9f7-faf7-4b43-90f7-5ac7438efb80=VM]'}'
>> 2017-07-12 12:19:32,658-04 INFO  
>> [org.ovirt.engine.core.bll.snapshots.CreateAllSnapshotsFromVmCommand] 
>> (default task-4) [568e6d7d-3a5f-4f97-bb39-8b4d2d4ae1da] Running command: 
>> CreateAllSnapshotsFromVmCommand internal: false. Entities affected :  ID: 
>> f66c92f3-474f-4b89-8ba3-56a583ddad89 Type: VMAction group 
>> MANIPULATE_VM_SNAPSHOTS with role type USER
>> 2017-07-12 12:19:32,681-04 INFO  
>> [org.ovirt.engine.core.bll.snapshots.CreateSnapshotCommand] (default task-4) 
>> [568e6d7d-3a5f-4f97-bb39-8b4d2d4ae1da] Running command: 
>> CreateSnapshotCommand internal: true. Entities affected :  ID: 
>> ---- Type: Storage
>> 2017-07-12 12:19:32,691-04 WARN  
>> [org.ovirt.engine.core.bll.storage.lsm.LiveMigrateVmDisksCommand] (default 
>> task-2) [4cbc2554-837c-4f76-94db-3e9312eee9d9] Validation of action 
>> 'LiveMigrateVmDisks' failed for user admin@internal-authz. Reasons: 
>> VAR__ACTION__MOVE,VAR__TYPE__DISK,ACTION_TYPE_FAILED_DISK_PLUGGED_TO_NON_DOWN_VMS,$DiskName
>>  vm0_disk0,$VmList vm0
>> 2017-07-12 12:19:32,692-04 INFO  
>> [org.ovirt.engine.core.bll.storage.lsm.LiveMigrateVmDisksCommand] (default 
>> task-2) [4cbc2554-837c-4f76-94db-3e9312eee9d9] Lock freed to object 
>> 'EngineLock:{exclusiveLocks='[eb4127a6-cc05-4aea-9250-9792447e77e8=DISK]', 
>> sharedLocks='[4c13d9f7-faf7-4b43-90f7-5ac7438efb80=VM]'}'
>> 2017-07-12 12:19:32,701-04 ERROR 
>> [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default 
>> task-2) [] Operation Failed: [Cannot move Virtual Disk. The disk vm0_disk0 
>> is plugged to non-Down VMs: vm0]
>>
>> 
>>
>> --
>> Regards,
>> Evgheni Dereveanchin
>>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] Help get oVirt's add featured on Stack Overflow

[Allon Mureinik]

Spotted in the wild! [1]

[1] http://imgur.com/ZVFsbPg

On Mon, Jul 3, 2017 at 2:34 PM, Allon Mureinik <amure...@redhat.com> wrote:

> As Nicolas stated below, and as evident by [1], ladies and gentlemen - we
> are live.
>
> First person to share an actual screenshot of Stack Overflow displaying
> this add gets a +2 on his next engine patch :-)
>
>
> And thanks again to Eldan for designing the add and to all the upvoters.
>
> [1] https://meta.stackoverflow.com/ads/display/349017
>
> On Fri, Jun 30, 2017 at 4:30 AM, Jeff Burns <admiral...@gmail.com> wrote:
>
>> This is an excellent thing.  Thanks Eldan.  I've cast my vote.
>>
>> On Thu, Jun 29, 2017 at 12:38 PM <nico...@devels.es> wrote:
>>
>>> El 2017-06-29 17:27, Allon Mureinik escribió:
>>> > Hi lists,
>>> >
>>> > Thanks to Eldan, we have a community ad for oVirt proposed on Stack
>>> > Overflow [1].
>>> > Now, we need some upvotes (current threshold is 6) before SO starts
>>> > serving it.
>>> >
>>>
>>> Unless some hater downvotes, it has just reached the 6 votes threshold
>>> ;-)
>>>
>>> > Have a SO account?
>>> > Want to help?
>>> > Just drop by and upvote.
>>> >
>>> > Have a great weekend,
>>> > Allon
>>> >
>>> > [1] https://meta.stackoverflow.com/a/351453/2422776 [1]
>>> >
>>> > Links:
>>> > --
>>> > [1] https://meta.stackoverflow.com/a/351453/2422776
>>> >
>>> > ___
>>> > Users mailing list
>>> > us...@ovirt.org
>>> > http://lists.ovirt.org/mailman/listinfo/users
>>> ___
>>> Users mailing list
>>> us...@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Help get oVirt's add featured on Stack Overflow

[Allon Mureinik]

Hi lists,

Thanks to Eldan, we have a community ad for oVirt proposed on Stack
Overflow [1].
Now, we need some upvotes (current threshold is 6) before SO starts serving
it.

Have a SO account?
Want to help?
Just drop by and upvote.


Have a great weekend,
Allon


[1] https://meta.stackoverflow.com/a/351453/2422776
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] Help get oVirt's add featured on Stack Overflow

[Allon Mureinik]

As Nicolas stated below, and as evident by [1], ladies and gentlemen - we
are live.

First person to share an actual screenshot of Stack Overflow displaying
this add gets a +2 on his next engine patch :-)


And thanks again to Eldan for designing the add and to all the upvoters.

[1] https://meta.stackoverflow.com/ads/display/349017

On Fri, Jun 30, 2017 at 4:30 AM, Jeff Burns <admiral...@gmail.com> wrote:

> This is an excellent thing.  Thanks Eldan.  I've cast my vote.
>
> On Thu, Jun 29, 2017 at 12:38 PM <nico...@devels.es> wrote:
>
>> El 2017-06-29 17:27, Allon Mureinik escribió:
>> > Hi lists,
>> >
>> > Thanks to Eldan, we have a community ad for oVirt proposed on Stack
>> > Overflow [1].
>> > Now, we need some upvotes (current threshold is 6) before SO starts
>> > serving it.
>> >
>>
>> Unless some hater downvotes, it has just reached the 6 votes threshold
>> ;-)
>>
>> > Have a SO account?
>> > Want to help?
>> > Just drop by and upvote.
>> >
>> > Have a great weekend,
>> > Allon
>> >
>> > [1] https://meta.stackoverflow.com/a/351453/2422776 [1]
>> >
>> > Links:
>> > --
>> > [1] https://meta.stackoverflow.com/a/351453/2422776
>> >
>> > ___
>> > Users mailing list
>> > us...@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/users
>> ___
>> Users mailing list
>> us...@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ basic_suite_master ] [004_basic_sanity.disk_operations]

[Allon Mureinik]

Benny, can you make heads or tails of this?

On Sat, Jul 29, 2017 at 8:25 PM, Dusan Fodor  wrote:

> Hello all,
> could you please take a look at this?
>
> Test failed: 004_basic_sanity.disk_operations
> Link to all test logs: http://jenkins.ovirt.org/job/ovirt-master_change-
> queue-tester/1518/artifact/
> Error snippet:
> 11:57:18 [basic-suit] Error while running thread
> 11:57:18 [basic-suit] Traceback (most recent call last):
> 11:57:18 [basic-suit]   File "/usr/lib/python2.7/site-packages/lago/utils.py",
> line 58, in _ret_via_queue
> 11:57:18 [basic-suit] queue.put({'return': func()})
> 11:57:18 [basic-suit]   File "/usr/lib/python2.7/site-
> packages/ovirtlago/testlib.py", line 59, in wrapper
> 11:57:18 [basic-suit] return func(get_test_prefix(), *args, **kwargs)
> 11:57:18 [basic-suit]   File "/usr/lib/python2.7/site-
> packages/ovirtlago/testlib.py", line 78, in wrapper
> 11:57:18 [basic-suit] prefix.virt_env.engine_vm().get_api(api_ver=4),
> *args, **kwargs
> 11:57:18 [basic-suit]   File "/home/jenkins/workspace/
> ovirt-master_change-queue-tester/ovirt-system-tests/
> basic-suite-master/test-scenarios/004_basic_sanity.py", line 330, in
> live_storage_migration
> 11:57:18 [basic-suit] disk_service.get().status, types.DiskStatus.OK)
> 11:57:18 [basic-suit]   File "/usr/lib/python2.7/site-
> packages/ovirtlago/testlib.py", line 251, in assert_equals_within_long
> 11:57:18 [basic-suit] func, value, LONG_TIMEOUT,
> allowed_exceptions=allowed_exceptions
> 11:57:18 [basic-suit]   File "/usr/lib/python2.7/site-
> packages/ovirtlago/testlib.py", line 217, in assert_equals_within
> 11:57:18 [basic-suit] res = func()
> 11:57:18 [basic-suit]   File "/home/jenkins/workspace/
> ovirt-master_change-queue-tester/ovirt-system-tests/
> basic-suite-master/test-scenarios/004_basic_sanity.py", line 329, in
> 
> 11:57:18 [basic-suit] len(vm_service.snapshots_service().list()) == 1
> and \
> 11:57:18 [basic-suit]   File "/usr/lib64/python2.7/site-
> packages/ovirtsdk4/services.py", line 17648, in list
> 11:57:18 [basic-suit] return self._internal_get(headers, query, wait)
> 11:57:18 [basic-suit]   File "/usr/lib64/python2.7/site-
> packages/ovirtsdk4/service.py", line 202, in _internal_get
> 11:57:18 [basic-suit] return future.wait() if wait else future
> 11:57:18 [basic-suit]   File "/usr/lib64/python2.7/site-
> packages/ovirtsdk4/service.py", line 53, in wait
> 11:57:18 [basic-suit] return self._code(response)
> 11:57:18 [basic-suit]   File "/usr/lib64/python2.7/site-
> packages/ovirtsdk4/service.py", line 199, in callback
> 11:57:18 [basic-suit] self._check_fault(response)
> 11:57:18 [basic-suit]   File "/usr/lib64/python2.7/site-
> packages/ovirtsdk4/service.py", line 123, in _check_fault
> 11:57:18 [basic-suit] self._raise_error(response, body)
> 11:57:18 [basic-suit]   File "/usr/lib64/python2.7/site-
> packages/ovirtsdk4/service.py", line 109, in _raise_error
> 11:57:18 [basic-suit] raise error
> 11:57:18 [basic-suit] Error: Fault reason is "Operation Failed". Fault
> detail is "Entity not found: null". HTTP response code is 404.
>
> Thanks
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] DBUnit upgrade and format change

[Allon Mureinik]

Hi all,

In an attempt to make maintaining Engine's DAO tests a bit more manageable,
yesterday I've merged patches to upgrade the DBUnit version we're using to
the latest available version, 2.5.3 [1], and changed the format to flat-XML
[2], ending up with a fixures.xml file which is almost 10K lines shorter.

What do you need to know about this change? Frankly, not much.

The format itself is pretty self-descriptive. To add a row to a table in
the test database, just add a row to fixtures.xml: 
Note that you can pretty much add such a row wherever you want in the file,
but in the interest of maintainability, please group rows from the same
tables together, and leave an empty line between tables (as the file
currently is).

Note also that DBUnit 2.5.3 doesn't seem to allow timezones, offsets or
whitespaces at the end of timestamp values. Since our tests don't really
depend on them, I just removed the handful of instances we had. If anyone
wants to take a deeper look, I'd gladly review it :-)


If this change causes trouble to anyone (it shouldn't - it was tested both
on my machine and in the CI, several times), please let me know.


You friendly neighborhood cleanup guy,
Allon

[1] https://gerrit.ovirt.org/#/c/76678/
[2] https://gerrit.ovirt.org/#/c/76679/
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Snapshots & clone support from datastore

[Allon Mureinik]

Not sure I understand the question. Could you give an example of what you
mean perhpas?

On Tue, Jun 20, 2017 at 10:01 PM, Deepak Jagtap <deepak.jag...@maxta.com>
wrote:

> Hi Allon,
>
>
> After going through current vdsm code base, noticed that after taking a
> snapshot vm starts referring the newly created qcow image/volume.
>
> For internal snapshots which are not qcow  is it configurable somehow so
> that vm continues doing writes to same base image?
>
>
> Thanks & Regards,
>
> Deepak
> --
> *From:* Deepak Jagtap
> *Sent:* Tuesday, June 6, 2017 3:37:03 PM
> *To:* Allon Mureinik
> *Cc:* devel@ovirt.org
> *Subject:* Re: [ovirt-devel] Snapshots & clone support from datastore
>
>
> Thanks Allon!
>
>
> Best Regards,
>
> Deepak
> --
> *From:* Allon Mureinik <amure...@redhat.com>
> *Sent:* Tuesday, June 6, 2017 2:43:17 PM
> *To:* Deepak Jagtap
> *Cc:* devel@ovirt.org
> *Subject:* Re: [ovirt-devel] Snapshots & clone support from datastore
>
> Unfortunately, there's no such integration point at the moment.
>
> On Tue, Jun 6, 2017 at 5:57 AM, Deepak Jagtap <deepak.jag...@maxta.com>
> wrote:
>
>> Hey Guys,
>>
>>
>> I am newbie to ovirt, and wanted to confirm whats the best way to
>> leverage snapshot, clone features
>>
>> provided by the datastore filesystem.
>>
>> I have a btrfs datastore exported and wanted use btrfs snapshots for vm
>> snapshot & clones.
>>
>> Does ovirt offers any hooks/APIs so that image snapshots are created by
>> the filesystem?
>>
>>
>> Thanks & Regards,
>>
>> Deepak
>>
>>
>>
>> ___
>> 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] AppErrors.properties merged together

[Allon Mureinik]

On Wed, Jun 21, 2017 at 9:12 AM, Allon Mureinik <amure...@redhat.com> wrote:

>
>
> On Tue, Jun 13, 2017 at 2:55 PM, Vojtech Szocs <vsz...@redhat.com> wrote:
>
>> Hi Jakub, thanks for taking the effort to simplify AppErrors handling!
>>
>> The AppErrors.properties file and its localized variants should live in a
>> single location, e.g. frontend/webadmin/modules/frontend. We should
>> avoid having multiple AppErrors.properties copies spread across the
>> codebase.
>>
> Yes
>
> please!
> Why do we even have these three copies?
> I vaguely recall an explanation that there's a "default" properties file
> (the backend one?), and then the others can overrie specific keys (e.g., to
> make the user portal simpler and remove admin complexities) -  but it
> doesn't seem as though the this is how it's used.
>
>
>> The backend dal (data access layer) module has its own copy of
>> AppErrors.properties file. One option is to copy it from the source
>> location during Engine build, another option is to simply use symlinks.
>>
> Why
>
> do even have this file? For REST API/SDK errors?
>
>
>> In any case, there should be a unit test that ensures all EngineMessage
>> enum members are reflected as methods in AppErrors interface. This will
>> give us the confidence that backend EngineMessage's have proper strings
>> associated with them.
>>
> We've had
> the opposite test for quite a long time:
>
> https://github.com/oVirt/ovirt-engine/commits/
> 0c7d7e7101142b95bd78e76be08dbb121c0c90f7/frontend/webadmin/
> modules/frontend/src/test/java/org/ovirt/engine/ui/
> frontend/AppErrorsTest.java
>
> But in indeed did's have a test for missing methods in the AppErrors
> interface.
> I tried cooking up a simple test and found that we're missing several
> hundred(!) keys, so I just carpet-bomb added them all, to be sorted out
> later:
> https://gerrit.ovirt.org/#/c/78354/
>
> However, I'm getting a weird GWT error when I try to build the application:
>
> [ERROR] Errors in 'gen/org/ovirt/engine/ui/frontend/com_gwtplatform_mvp_
> client_DesktopGinjector_DesktopGinjectorGinjector_fragment.java'
> [INFO]   [ERROR] Line 50: Failed to resolve
> 'org.ovirt.engine.ui.frontend.VdsmErrors' via deferred binding
>
> I'm obviously doing something stupid I shouldn't be doing, but I must
> admit I don't understand what I'm doing wrong.
> Some advice from our residenant GWT experts (yes Vojtech, I'm pointing at
> you :-)) woul be appreciated.
>

The

weirest thing is that CI actually passes on this, but I get the
aforementioned error locally when I run

$ mvn clean install -Pgwt-admin -Dgwt.userAgent=safari

Now I'm sure I'm doing something stupid - just not sure what.

>
>
>> Regards,
>> Vojtech
>>
>>
>> On Mon, Jun 12, 2017 at 8:51 PM, Jakub Niedermertl <jnied...@redhat.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> there is a patch [1] removing `AppErrors.properties` from webadmin
>>> project to simplify edits of AppErrors/EngineMessage. AppErrors.properties
>>> from webadmin project will be merged to AppErrors.properties in frontend
>>> project. This requires some manual resolutions of conflicts of translation
>>> values.
>>>
>>> I'd like to kindly ask you to review altered translation values. They
>>> are mostly just typos.
>>>
>>> Thanks.
>>> Jakub
>>>
>>> [1]: https://gerrit.ovirt.org/#/c/76215/
>>>
>>
>>
>> ___
>> 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] AppErrors.properties merged together

[Allon Mureinik]

On Tue, Jun 13, 2017 at 2:55 PM, Vojtech Szocs  wrote:

> Hi Jakub, thanks for taking the effort to simplify AppErrors handling!
>
> The AppErrors.properties file and its localized variants should live in a
> single location, e.g. frontend/webadmin/modules/frontend. We should avoid
> having multiple AppErrors.properties copies spread across the codebase.
>
Yes

please!
Why do we even have these three copies?
I vaguely recall an explanation that there's a "default" properties file
(the backend one?), and then the others can overrie specific keys (e.g., to
make the user portal simpler and remove admin complexities) -  but it
doesn't seem as though the this is how it's used.


> The backend dal (data access layer) module has its own copy of
> AppErrors.properties file. One option is to copy it from the source
> location during Engine build, another option is to simply use symlinks.
>
Why

do even have this file? For REST API/SDK errors?


> In any case, there should be a unit test that ensures all EngineMessage
> enum members are reflected as methods in AppErrors interface. This will
> give us the confidence that backend EngineMessage's have proper strings
> associated with them.
>
We've had
the opposite test for quite a long time:

https://github.com/oVirt/ovirt-engine/commits/0c7d7e7101142b95bd78e76be08dbb121c0c90f7/frontend/webadmin/modules/frontend/src/test/java/org/ovirt/engine/ui/frontend/AppErrorsTest.java

But in indeed did's have a test for missing methods in the AppErrors
interface.
I tried cooking up a simple test and found that we're missing several
hundred(!) keys, so I just carpet-bomb added them all, to be sorted out
later:
https://gerrit.ovirt.org/#/c/78354/

However, I'm getting a weird GWT error when I try to build the application:

[ERROR] Errors in
'gen/org/ovirt/engine/ui/frontend/com_gwtplatform_mvp_client_DesktopGinjector_DesktopGinjectorGinjector_fragment.java'
[INFO]   [ERROR] Line 50: Failed to resolve
'org.ovirt.engine.ui.frontend.VdsmErrors' via deferred binding

I'm obviously doing something stupid I shouldn't be doing, but I must admit
I don't understand what I'm doing wrong.
Some advice from our residenant GWT experts (yes Vojtech, I'm pointing at
you :-)) woul be appreciated.


> Regards,
> Vojtech
>
>
> On Mon, Jun 12, 2017 at 8:51 PM, Jakub Niedermertl 
> wrote:
>
>> Hi all,
>>
>> there is a patch [1] removing `AppErrors.properties` from webadmin
>> project to simplify edits of AppErrors/EngineMessage. AppErrors.properties
>> from webadmin project will be merged to AppErrors.properties in frontend
>> project. This requires some manual resolutions of conflicts of translation
>> values.
>>
>> I'd like to kindly ask you to review altered translation values. They are
>> mostly just typos.
>>
>> Thanks.
>> Jakub
>>
>> [1]: https://gerrit.ovirt.org/#/c/76215/
>>
>
>
> ___
> 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] [ENGINE] standardizing query creation

[Allon Mureinik]

Hi list,

As you may have noticed, there's a bit of an ambiguity on how query objects
are created - some have a constructor from a parameters object, some have a
constructor from a parameters object and an EngineContext, and some have
both.

This ambiguity leads to all sorts of annoying bugs where some queries can't
be used as internal queries (because they lack the proper constructor), or
other queries couldn't be used without a context.

I just merged a series of patches to streamline queries creation and
eliminate the problem.
Looking forwards, queries should have a single constructor receiving a
parameters object and a context and pass them on to super. A unit test was
added to enforce this constructor's existence in build time. From a
caller's perspective, nothing's changed, and all of the
Backend#run[Internal]Query methods were left unchanged.

The build, CI and OST suite were ran on this patch series and everything
seems to be in order, but please let me know if you encounter any issues.


-Allon
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Snapshots & clone support from datastore

[Allon Mureinik]

Unfortunately, there's no such integration point at the moment.

On Tue, Jun 6, 2017 at 5:57 AM, Deepak Jagtap 
wrote:

> Hey Guys,
>
>
> I am newbie to ovirt, and wanted to confirm whats the best way to leverage
> snapshot, clone features
>
> provided by the datastore filesystem.
>
> I have a btrfs datastore exported and wanted use btrfs snapshots for vm
> snapshot & clones.
>
> Does ovirt offers any hooks/APIs so that image snapshots are created by
> the filesystem?
>
>
> Thanks & Regards,
>
> Deepak
>
>
>
> ___
> 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] [ OST Failure Report ] [ oVirt master ] [ 2017-09-11 ]

[Allon Mureinik]

After some digging around, this patch was indeed the reason for the failure.
A partial revert was posted to gerrit, and manually running OST on it shows
it solves the issue.
I merged the patch, and Eyal (S) will continue working on a real solution
to BZ1185782 next week.



On Thu, Sep 14, 2017 at 3:09 PM, Eyal Shenitzky  wrote:

> I will take a dipper look on the failure
>
> On Thu, Sep 14, 2017 at 3:02 PM, Eyal Edri  wrote:
>
>> However, the patch [1] does looks related to the 'add disk' [2] failure
>> we're seeing.
>> Can you check?
>>
>> [1] https://gerrit.ovirt.org/#/c/80993/19
>> [2] http://jenkins.ovirt.org/job/ovirt-master_change-queue-t
>> ester/2503/testReport/(root)/004_basic_sanity/add_disk/
>>
>> On Thu, Sep 14, 2017 at 2:46 PM, Eyal Edri  wrote:
>>
>>> I think this error should already be fixed and was caused by the fact we
>>> cleaned old 'qemu-kvm' pkgs from tested repos,
>>> but the patch [1] for adding kvm_common wasn't merged yet.
>>>
>>> Both were around 20 hours ago, so the timeslot fits.
>>> If we'll look at recent CQ jobs, its not failing anymore on this part [2]
>>>
>>> [1] https://gerrit.ovirt.org/#/c/79818/
>>> [2] http://jenkins.ovirt.org/blue/organizations/jenkins/ovir
>>> t-master_change-queue-tester/detail/ovirt-master_change-queu
>>> e-tester/2554/pipeline
>>>
>>> On Thu, Sep 14, 2017 at 2:31 PM, Eyal Shenitzky 
>>> wrote:
>>>
 Hi all,

 I am the owner of the suspicious patch.

 There is no connection between the failure error and the patch,
 The patch related to the engine, and the error related to VDSM
 dependencies issue.

 Regards,
 Eyal Shenitzky

 On Thu, Sep 14, 2017 at 1:16 PM, Dan Kenigsberg 
 wrote:

> On Thu, Sep 14, 2017 at 12:45 PM, Dusan Fodor 
> wrote:
> >
> > Link to suspected patch:
> > https://gerrit.ovirt.org/#/c/80993/19
>
> May I please ask for these emails to include the summary line of the
> suspected patch, as well as its component and owner? The owner should
> be on the CC line. I want to quickly judge if a failure falls under my
> responsibility.
>
> >
> > Link to job:
> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2498/
> >
> > Link to all logs:
> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-teste
> r/2498/artifact/exported-artifacts/basic-suit-master-el7/moc
> k_logs/mocker-epel-7-x86_64.el7.init/
> >
> > Error snippet from log:
> >
> > 
> >
> > DEBUG util.py:533:  Executing command: ['/usr/bin/yum',
> '--installroot',
> > '/var/lib/mock/epel-7-x86_64-01b5c106167c9b71f022fe64bb4fa43
> a-167519/root/',
> > '--releasever', '7', 'install', '@buildsys-build', 'grubby', 'lago',
> > 'lago-ovirt', 'ovirt-engine-sdk-python', 'python-netaddr',
> > 'python-ovirt-engine-sdk4', '--setopt=tsflags=nocontexts'] with env
> {'LANG':
> > 'en_US.UTF-8', 'LD_PRELOAD': '/var/tmp/tmp.mock.RxN7kZ/$LIB
> /nosync.so',
> > 'TERM': 'vt100', 'SHELL': '/bin/bash', 'LC_MESSAGES': 'C.UTF-8',
> > 'STD_CI_STAGE': 'basic_suite_master', 'http_proxy':
> > 'http://proxy01.phx.ovirt.org:3128', 'STD_CI_YUMREPOS': '',
> 'STD_CI_DISTRO':
> > 'el7', 'HOSTNAME': 'mock', 'PROMPT_COMMAND': 'printf
> > "\\033]0;\\007"', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin
> ',
> > 'HOME': '/builddir', 'PS1': ' \\s-\\v\\$ '} and shell
> False
> > DEBUG util.py:450:  Failed to set locale, defaulting to C
> > DEBUG util.py:450:  Error: Package: python-lago-0.41.0-1.el7.cento
> s.noarch
> > (lago)
> > DEBUG util.py:450: Requires: qemu-kvm-rhev >= 2.1.2
> > DEBUG util.py:450:  Error: Package: python-lago-0.41.0-1.el7.cento
> s.noarch
> > (lago)
> > DEBUG util.py:450: Requires: qemu-img-rhev >= 2.1.2
> >
> > 
> >
> >
> > ___
> > 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
>



 --
 Regards,
 Eyal Shenitzky

 ___
 Devel mailing list
 Devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/devel

>>>
>>>
>>>
>>> --
>>>
>>> Eyal edri
>>>
>>>
>>> ASSOCIATE MANAGER
>>>
>>> RHV DevOps
>>>
>>> EMEA VIRTUALIZATION R
>>>
>>>
>>> Red Hat EMEA 
>>>  TRIED. TESTED. TRUSTED.
>>> 
>>> phone: +972-9-7692018 <+972%209-769-2018>
>>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>>
>>
>>
>>
>> --
>>
>> Eyal edri
>>
>>
>> ASSOCIATE MANAGER
>>
>> RHV DevOps
>>
>> EMEA 

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 2017-09-07 ] [import_template_from_glance]

[Allon Mureinik]

That was more a less the my guess from the brief look I took at the
stacktrace.

I don't want to +2 a patch in the network area, but I'd suggest merging
this patch (which seems right regardless of the recent failure), and see if
it solves the OST issue.

On Mon, Sep 11, 2017 at 9:47 PM, Roy Golan  wrote:

>
>
> On Mon, 11 Sep 2017 at 21:30 Roy Golan  wrote:
>
>> I think I solved it with https://gerrit.ovirt.org/#/c/81636/  so the
>> revert can be reverted. +Martin Mucha  want to test
>> it? It is working on my end.
>>
>> sorry its this https://gerrit.ovirt.org/c/81637/2
>
>>
>> On Mon, 11 Sep 2017 at 18:41 Dan Kenigsberg  wrote:
>>
>>> On Mon, Sep 11, 2017 at 4:46 PM, Dusan Fodor  wrote:
>>> >
>>> > Hello all,
>>> > this same error still causes OST to fail.
>>> >
>>>
>>> We are aware of it, but do not understand it at all.
>>>
>>> Anyway, a revert is proposed and https://gerrit.ovirt.org/#/c/81618/
>>> would be merged once approved by CI.
>>>
>>> >
>>> > Jobs:
>>> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2466
>>> >
>>> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2471
>>> >
>>> > Logs:
>>> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-
>>> tester/2466/artifact/exported-artifacts/basic-suit-master-
>>> el7/test_logs/basic-suite-master/post-002_bootstrap.py/
>>> lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
>>> >
>>> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-
>>> tester/2471/artifact/exported-artifacts/basic-suit-master-
>>> el7/test_logs/basic-suite-master/post-002_bootstrap.py/
>>> lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
>>> >
>>> >
>>> > On Mon, Sep 11, 2017 at 1:22 PM, Eyal Edri  wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Mon, Sep 11, 2017 at 1:21 PM, Dan Kenigsberg 
>>> wrote:
>>> >>>
>>> >>> On Mon, Sep 11, 2017 at 8:59 AM, Dan Kenigsberg 
>>> wrote:
>>> >>> > On Thu, Sep 7, 2017 at 6:12 PM, Evgheni Dereveanchin
>>> >>> >  wrote:
>>> >>> >> Test failed: [ import_template_from_glance ]
>>> >>> >>
>>> >>> >> Link to suspected patches:
>>> >>> >> https://gerrit.ovirt.org/#/c/80450/
>>> >>> >
>>> >>> > Martin, this is "core: when initializing MacPool also register in
>>> it
>>> >>> > nics in snapshots"
>>> >>> > and the error seems somewhat related to it
>>> >>>
>>> >>> Gil, can you tell us which is the last Engine patch that passed OST?
>>> I
>>> >>> tried to build https://gerrit.ovirt.org/#/c/76309/ but I'm guessing
>>> >>> that "ci please build" does not work on merged patches.
>>> >>
>>> >>
>>> >> Not sure I follow, the latest working engine should be deployed to
>>> tested repo,
>>> >> So if you'll run the manual job w/o any custom repos it should work (
>>> if it doesn't, then it means something slipped in the tested repo and we
>>> should investigate ).
>>> >>
>>> >> But anyhow, your 'ci please build' also worked, and produced RPMs on
>>> the job, so you can still try it:
>>> >>
>>> >> Patch Set 26:
>>> >> Build Successful
>>> >> http://jenkins.ovirt.org/job/ovirt-engine_master_build-
>>> artifacts-on-demand-fc25-x86_64/377/ : SUCCESS
>>> >> http://jenkins.ovirt.org/job/ovirt-engine_master_build-
>>> artifacts-on-demand-el7-x86_64/428/ : SUCCESS
>>> >>
>>> >>
>>> >>>
>>> >>>
>>> >>> >
>>> >>> >>
>>> >>> >> Link to Job:
>>> >>> >> http://jenkins.ovirt.org/job/ovirt-master_change-queue-
>>> tester/2397/
>>> >>> >>
>>> >>> >> Link to logs:
>>> >>> >> http://jenkins.ovirt.org/job/ovirt-master_change-queue-
>>> tester/2397/artifact/exported-artifacts/basic-suit-master-
>>> el7/test_logs/basic-suite-master/post-002_bootstrap.py/
>>> lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log
>>> >>> >>
>>> >>> >> Error snippet from log:
>>> >>> >>
>>> >>> >> 
>>> >>> >>
>>> >>> >> 2017-09-07 08:21:48,657-04 INFO
>>> >>> >> [org.ovirt.engine.core.bll.AddVmTemplateCommand]
>>> >>> >> (EE-ManagedThreadFactory-engineScheduled-Thread-21) [74b41edb]
>>> Lock Acquired
>>> >>> >> to object
>>> >>> >> 'EngineLock:{exclusiveLocks='[2c2b56b5-cac6-469d-b0e0-
>>> 9744309ca8c1=TEMPLATE,
>>> >>> >> CirrOS_0.3.5_for_x86_64_glance_template=TEMPLATE_NAME]',
>>> sharedLocks='[]'}'
>>> >>> >> 2017-09-07 08:21:48,675-04 INFO
>>> >>> >> [org.ovirt.engine.core.bll.AddVmTemplateCommand]
>>> >>> >> (EE-ManagedThreadFactory-engineScheduled-Thread-21) [74b41edb]
>>> Running
>>> >>> >> command: AddVmTemplateCommand internal: true. Entities affected
>>> :  ID:
>>> >>> >> d279c4e9-09e7-4dd9-9eff-10b31ee2adfc Type: StoragePoolAction
>>> group
>>> >>> >> CREATE_TEMPLATE with role type USER
>>> >>> >> 2017-09-07 08:21:48,695-04 INFO
>>> >>> >> [org.ovirt.engine.core.bll.storage.disk.
>>> CreateAllTemplateDisksCommand]
>>> >>> >> (EE-ManagedThreadFactory-engineScheduled-Thread-21) [74b41edb]
>>> Running
>>> >>> >> command: CreateAllTemplateDisksCommand internal: 

Re: [ovirt-devel] URGENT! OST broken! please stop merging patches to ovirt-engine!

[Allon Mureinik]

The relevant path is most definitely the cause for Sunday's issue:

2017-08-30 04:38:52,542-04 ERROR
[org.ovirt.engine.core.bll.RunVmOnceCommand] (default task-18)
[5c4b4916-9832-4460-a391-cac53ef8f19a] Error during ValidateFailure.:
java.lang.ClassCastException:
org.ovirt.engine.core.common.businessentities.storage.LunDisk cannot
be cast to org.ovirt.engine.core.common.businessentities.storage.DiskImage
at 
org.ovirt.engine.core.bll.RunVmCommand.lambda$checkDisksInBackupStorage$1(RunVmCommand.java:1105)
[bll.jar:]
at 
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
[rt.jar:1.8.0_141]
at java.util.HashMap$ValueSpliterator.tryAdvance(HashMap.java:1641)
[rt.jar:1.8.0_141]
at 
java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126)
[rt.jar:1.8.0_141]
at 
java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:498)
[rt.jar:1.8.0_141]
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485)
[rt.jar:1.8.0_141]
at 
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
[rt.jar:1.8.0_141]
at 
java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:230)
[rt.jar:1.8.0_141]
at 
java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:196)
[rt.jar:1.8.0_141]
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
[rt.jar:1.8.0_141]
at 
java.util.stream.ReferencePipeline.anyMatch(ReferencePipeline.java:449)
[rt.jar:1.8.0_141]
at 
org.ovirt.engine.core.bll.RunVmCommand.checkDisksInBackupStorage(RunVmCommand.java:1106)
[bll.jar:]
at 
org.ovirt.engine.core.bll.RunVmCommand.validate(RunVmCommand.java:1020)
[bll.jar:]
at 
org.ovirt.engine.core.bll.RunVmOnceCommand.validate(RunVmOnceCommand.java:87)
[bll.jar:]
at 
org.ovirt.engine.core.bll.CommandBase.internalValidate(CommandBase.java:848)
[bll.jar:]
at 
org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:402)
[bll.jar:]
at 
org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.execute(DefaultBackendActionExecutor.java:13)
[bll.jar:]
at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:499) 
[bll.jar:]
at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:481) 
[bll.jar:]
at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:434) 
[bll.jar:]


On Wed, Aug 30, 2017 at 2:13 PM, Barak Korren  wrote:

> We have two unresolved issues that are currently causing all master
> OST runs to fail and preventing us from effectively finding
> regressions.
>
> The 1st issue, which was already reported on Sunday, is a regression
> that is causing vm_run to fail and was probably introduced by this
> patch:
> https://gerrit.ovirt.org/#/c/79033/41
>
> Here is a recent run that failed with this:
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2147/
>
> Logs are here:
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-
> tester/2147/artifact/exported-artifacts/basic-suit-master-
> el7/test_logs/basic-suite-master/post-002_bootstrap.py/
>
> The 2nd issue is a new one, that seems to be causing add-host failures
> and I've just send another email about it. The gist of this is that
> I'm siing the following failures in the supervdsm logs, and vdsm is
> not loading:
>
> MainThread::ERROR::2017-08-30
> 05:55:59,476::initializer::53::root::(_lldp_init) Failed to enable
> LLDP on eth1
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/vdsm/network/initializer.py",
> line 51, in _lldp_init
> Lldp.enable_lldp_on_iface(device)
>   File "/usr/lib/python2.7/site-packages/vdsm/network/lldp/lldpad.py",
> line 30, in enable_lldp_on_iface
> lldptool.enable_lldp_on_iface(iface, rx_only)
>   File "/usr/lib/python2.7/site-packages/vdsm/network/lldpad/lldptool.py",
> line 46, in enable_lldp_on_iface
> raise EnableLldpError(rc, out, err, iface)
> EnableLldpError: (1,
> "timeout\n'M0001C304000c04eth1000badminStatus0002rx' command
> timed out.\n", '', 'eth1')
> MainThread::DEBUG::2017-08-30
> 05:55:59,477::cmdutils::133::root::(exec_cmd) /usr/sbin/lldptool
> get-lldp -i eth0 adminStatus (cwd None)
>
>
> This failure does not seem to have been introduced by the platform and
> not oVirt code, because it also happens on code that already passed
> OST a few days ago.
>
> Please avoid merging any patches except to the purpose of resolving
> these issues. Nothing is making it into the 'tested' and nightly
> snapshot repos anyway ATM.
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
___
Devel mailing list
Devel@ovirt.org

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt Master ] [ bootstrap.verify_add_hosts ] [ 18/10/17 ]

[Allon Mureinik]

The missing deps issue happened again this morning [1]:

Traceback (most recent call last):
  File "/tmp/ovirt-q04eYYi5Ym/pythonlib/otopi/context.py", line 133,
in _executeMethod
method['method']()
  File "/tmp/ovirt-q04eYYi5Ym/otopi-plugins/otopi/packagers/yumpackager.py",
line 256, in _packages
if self._miniyum.buildTransaction():
  File "/tmp/ovirt-q04eYYi5Ym/pythonlib/otopi/miniyum.py", line 920,
in buildTransaction
raise yum.Errors.YumBaseError(msg)
YumBaseError: [u'vdsm-4.20.3-205.git15d3b78.el7.centos.x86_64 requires
libvirt-daemon-kvm >= 3.2.0-14.el7_4.3',
u'10:qemu-kvm-ev-2.9.0-16.el7_4.5.1.x86_64 requires ipxe-roms-qemu >=
20170123-1.git4e85b27.el7_4.1']
2017-10-19 01:36:37,275-0400 ERROR otopi.context
context._executeMethod:152 Failed to execute stage 'Package
installation': [u'vdsm-4.20.3-205.git15d3b78.el7.centos.x86_64
requires libvirt-daemon-kvm >= 3.2.0-14.el7_4.3',
u'10:qemu-kvm-ev-2.9.0-16.el7_4.5.1.x86_64 requires ipxe-roms-qemu >=
20170123-1.git4e85b27.el7_4.1']

We need to fix the missing packages (broken repo?) issue ASAP, as it
would mast any other real problems we may have there


[1] 
http://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-tests_master_check-patch-el7-x86_64/1977/artifact/exported-artifacts/basic-suite-master__logs/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/host-deploy/ovirt-host-deploy-20171019013637-lago-basic-suite-master-host-0-4a91e03d.log/*view*/


On Thu, Oct 19, 2017 at 10:29 AM, Martin Perina  wrote:

>
>
> On Thu, Oct 19, 2017 at 7:35 AM, Dan Kenigsberg  wrote:
>
>> On Wed, Oct 18, 2017 at 2:40 PM, Daniel Belenky 
>> wrote:
>>
>>> Hi all,
>>>
>>> *The following test is failing:* 002_bootstrap.verify_add_hosts
>>> *All logs from failing job
>>> *
>>> *Only 2 engine patches participated in the test, so the suspected
>>> patches are:*
>>>
>>>1. *https://gerrit.ovirt.org/#/c/82542/2*
>>>
>>>2. *https://gerrit.ovirt.org/#/c/82545/3
>>>*
>>>
>>> Due to the fact that when this error first introduced we had another
>>> error, the CI can't automatically detect the specific patch.
>>>
>>> *Error snippet from logs: **ovirt-host-deploy-ansible log
>>> 
>>> (Full log)*
>>>
>>> TASK [ovirt-host-deploy-firewalld : Enable firewalld rules] 
>>> 
>>> failed: [lago-basic-suite-master-host-0] (item={u'service': u'glusterfs'}) 
>>> => {"changed": false, "failed": true, "item": {"service": "glusterfs"}, 
>>> "msg": "ERROR: Exception caught: org.fedoraproject.FirewallD1.Exception: 
>>> INVALID_SERVICE: 'glusterfs' not among existing services Permanent and 
>>> Non-Permanent(immediate) operation, Services are defined by port/tcp 
>>> relationship and named as they are in /etc/services (on most systems)"}
>>>
>>>
>>> *Error from HOST 0 firewalld
>>> log: lago-basic-suite-master-host-0/_var_log/firewalld/
>>> 
>>>  (Full
>>> log)*
>>>
>>> 2017-10-15 16:51:24 ERROR: INVALID_SERVICE: 'glusterfs' not among existing 
>>> services
>>>
>>>
>> Ondra, would such an error propagate through the playbook to Engine and
>> fail the add-host flow? (I think it should!)
>>
>
> ​We didn't do that so far, because of EL 7.3​
> ​. We need firewalld from 7.4 to have all available services in place (I
> don't remember but I think imageio service was the one delivered only in
> firewalld from 7.4). So  up until now we ingore non-existent firewalld
> service, but if needed we can turn this on and fail host deploy.
> ​
> ​
>
>>
>> Do you know which package provide the glusterfs firewalld service, and
>> why it is missing from the host?
>>
>
> ​So we have used 'glusterfs​' firewalld service per Sahina recommendation,
> which is included in glusterfs-server package from version 3.7.6 [1]. But
> this package is not installed when installing packages for cluster with
> gluster capabilities enabled. So now I'm confused: don't we need
> glusterfs-server package? If not and we need those ports open because they
> are used by services from different already installed 

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt Master ] [ bootstrap.verify_add_hosts ] [ 18/10/17 ]

[Allon Mureinik]

These patches are part of the engine backend - the failure happens WAY
beforehand, they don't look related as far as I can tell.

Subsequent failures of the same suite seem to have different errors, e.g.:

Traceback (most recent call last):
  File "/tmp/ovirt-y8uX2TlUiq/pythonlib/otopi/context.py", line 133,
in _executeMethod
method['method']()
  File "/tmp/ovirt-y8uX2TlUiq/otopi-plugins/otopi/packagers/yumpackager.py",
line 256, in _packages
if self._miniyum.buildTransaction():
  File "/tmp/ovirt-y8uX2TlUiq/pythonlib/otopi/miniyum.py", line 920,
in buildTransaction
raise yum.Errors.YumBaseError(msg)
YumBaseError: [u'vdsm-4.20.3-202.git6826cec.el7.centos.x86_64 requires
libvirt-daemon-kvm >= 3.2.0-14.el7_4.3',
u'10:qemu-kvm-ev-2.9.0-16.el7_4.5.1.x86_64 requires ipxe-roms-qemu >=
20170123-1.git4e85b27.el7_4.1']


Has something changed in the way OST sets up repos/hosts?


On Wed, Oct 18, 2017 at 2:40 PM, Daniel Belenky  wrote:

> Hi all,
>
> *The following test is failing:* 002_bootstrap.verify_add_hosts
> *All logs from failing job
> *
> *Only 2 engine patches participated in the test, so the suspected patches
> are:*
>
>1. *https://gerrit.ovirt.org/#/c/82542/2*
>
>2. *https://gerrit.ovirt.org/#/c/82545/3
>*
>
> Due to the fact that when this error first introduced we had another
> error, the CI can't automatically detect the specific patch.
>
> *Error snippet from logs: **ovirt-host-deploy-ansible log
> 
> (Full log)*
>
> TASK [ovirt-host-deploy-firewalld : Enable firewalld rules] 
> 
> failed: [lago-basic-suite-master-host-0] (item={u'service': u'glusterfs'}) => 
> {"changed": false, "failed": true, "item": {"service": "glusterfs"}, "msg": 
> "ERROR: Exception caught: org.fedoraproject.FirewallD1.Exception: 
> INVALID_SERVICE: 'glusterfs' not among existing services Permanent and 
> Non-Permanent(immediate) operation, Services are defined by port/tcp 
> relationship and named as they are in /etc/services (on most systems)"}
>
>
> *Error from HOST 0 firewalld
> log: lago-basic-suite-master-host-0/_var_log/firewalld/
> 
>  (Full
> log)*
>
> 2017-10-15 16:51:24 ERROR: INVALID_SERVICE: 'glusterfs' not among existing 
> services
>
> --
>
> DANIEL BELENKY
>
> RHV DEVOPS
>
> EMEA VIRTUALIZATION R
> 
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 2017-11-13 ] [add_master_storage_domain]

[Allon Mureinik]

It's most definitely not THAT patch.
Could be one of the earlier patches in the series, though.

Looking.

On Mon, Nov 13, 2017 at 10:54 AM, Barak Korren  wrote:

> On 13 November 2017 at 10:08, Nir Soffer  wrote:
> >
> >
> > On Mon, Nov 13, 2017 at 9:56 AM Barak Korren  wrote:
> >>
> >> Test failed: [ add_master_storage_domain ]
> >>
> >> Link to suspected patches:
> >> - https://gerrit.ovirt.org/#/c/83849/4
> >
> >
> > This fixes grammar in few error messages, I don't see how this can cause
> > failures unless someone is depending on the error text...
> >
> Previous test with engine patches before it was successful:
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3769
> This one included the following patches which were the two commits
> leading up to the failing one:
> - https://gerrit.ovirt.org/#/c/83920/4
> - https://gerrit.ovirt.org/#/c/83918/2
>
> Also following tests with no engine patches were also successful:
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3780/
> so this eliminates suspicion for unrelated infra issues.
>
> I think that is sufficient grounds for suspicion.
>
> >>
> >> This seems to be a fairly consistent regression as all patches that
> >> follow the patch above exhibit the same issue when tested, this list
> >> of similarly failing patches includes:
> >> - https://gerrit.ovirt.org/#/c/83940/2
> >> - https://gerrit.ovirt.org/#/c/83608/7
> >> - https://gerrit.ovirt.org/#/c/83815/3
> >> The following patch is an exception because it simply failed to build:
> >> - https://gerrit.ovirt.org/#/c/83370/9
> >>
> >> Link to Job:
> >> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3770/
> >>
> >> Link to all logs:
> >>
> >> http://jenkins.ovirt.org/job/ovirt-master_change-queue-
> tester/3770/artifact/exported-artifacts/basic-suit-master-
> el7/test_logs/basic-suite-master/post-002_bootstrap.py/
> >>
> >> Error snippet from log:
> >>
> >> 
> >>
> >> Fault reason is "Operation Failed". Fault detail is "[Failed to attach
> >> Storage due to an error on the Data Center master Storage Domain.
> >> -Please activate the master Storage Domain first.]". HTTP response code
> is
> >> 409.
> >>
> >> 
> >>
> >>
> >>
> >> --
> >> Barak Korren
> >> RHV DevOps team , RHCE, RHCi
> >> Red Hat EMEA
> >> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
> >> ___
> >> Devel mailing list
> >> Devel@ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
> ___
> 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] [ OST Failure Report ] [ oVirt master ] [ 2017-11-13 ] [add_master_storage_domain]

[Allon Mureinik]

Both are merged, let's see how OST fares

On Mon, Nov 13, 2017 at 12:00 PM, Allon Mureinik <amure...@redhat.com>
wrote:

> I merged 83920 with dependencies. Perhaps gerrit doesn't handle such
> chains properly (or perhaps our CI is misusing the API?).
>
> WRT current issues, posted two patches upstream:
> - https://gerrit.ovirt.org/#/c/83986/ - fixes the GWT build that was
> broken this morning, preventing a proper build altogether
> - https://gerrit.ovirt.org/#/c/83987/ - should fix the OST regression you
> noted.
>
> I'm waiting for the CI to finish running on both and will merge.
>
> On Mon, Nov 13, 2017 at 11:26 AM, Barak Korren <bkor...@redhat.com> wrote:
>
>> On 13 November 2017 at 11:10, Allon Mureinik <amure...@redhat.com> wrote:
>> > Commit 86bf82e746404145e8b97df46f514086e4f82e69 is probably the
>> offending
>> > commit, taking a deeper look now, should have a fix within the hour
>> >
>>
>> Hmm, I see what happened there, that commit is
>> https://gerrit.ovirt.org/c/83920, so it was tested at:
>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3769
>> and passed.
>>
>> BUT, it was tested along with https://gerrit.ovirt.org/#/c/83918/2
>> that was merged earlier as far as git ordering goes, but somehow was
>> assumed to be a later patch. When we test multiple patches from the
>> same project we essentially use packages built from the one we deem to
>> be the latest. So in this case only the packages from 83918 were
>> actually tested.
>>
>> We went to great lengths to preserve correct patch ordering by
>> preserving the order of event notifications reaching us from gerrit.
>> But here it seems we ended out with out-of-order patches. Do you have
>> any idea how did we end up with this? Do you remember what was the
>> sequence in which you clicked the 'merge' button on the different
>> patches?
>>
>> --
>> Barak Korren
>> RHV DevOps team , RHCE, RHCi
>> Red Hat EMEA
>> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 2017-11-13 ] [add_master_storage_domain]

[Allon Mureinik]

Commit 86bf82e746404145e8b97df46f514086e4f82e69 is probably the offending
commit, taking a deeper look now, should have a fix within the hour

On Mon, Nov 13, 2017 at 9:55 AM, Barak Korren  wrote:

> Test failed: [ add_master_storage_domain ]
>
> Link to suspected patches:
> - https://gerrit.ovirt.org/#/c/83849/4
> This seems to be a fairly consistent regression as all patches that
> follow the patch above exhibit the same issue when tested, this list
> of similarly failing patches includes:
> - https://gerrit.ovirt.org/#/c/83940/2
> - https://gerrit.ovirt.org/#/c/83608/7
> - https://gerrit.ovirt.org/#/c/83815/3
> The following patch is an exception because it simply failed to build:
> - https://gerrit.ovirt.org/#/c/83370/9
>
> Link to Job:
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3770/
>
> Link to all logs:
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-
> tester/3770/artifact/exported-artifacts/basic-suit-master-
> el7/test_logs/basic-suite-master/post-002_bootstrap.py/
>
> Error snippet from log:
>
> 
>
> Fault reason is "Operation Failed". Fault detail is "[Failed to attach
> Storage due to an error on the Data Center master Storage Domain.
> -Please activate the master Storage Domain first.]". HTTP response code is
> 409.
>
> 
>
>
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
> ___
> 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] [ OST Failure Report ] [ oVirt master ] [ 2017-11-13 ] [add_master_storage_domain]

[Allon Mureinik]

I merged 83920 with dependencies. Perhaps gerrit doesn't handle such chains
properly (or perhaps our CI is misusing the API?).

WRT current issues, posted two patches upstream:
- https://gerrit.ovirt.org/#/c/83986/ - fixes the GWT build that was broken
this morning, preventing a proper build altogether
- https://gerrit.ovirt.org/#/c/83987/ - should fix the OST regression you
noted.

I'm waiting for the CI to finish running on both and will merge.

On Mon, Nov 13, 2017 at 11:26 AM, Barak Korren <bkor...@redhat.com> wrote:

> On 13 November 2017 at 11:10, Allon Mureinik <amure...@redhat.com> wrote:
> > Commit 86bf82e746404145e8b97df46f514086e4f82e69 is probably the
> offending
> > commit, taking a deeper look now, should have a fix within the hour
> >
>
> Hmm, I see what happened there, that commit is
> https://gerrit.ovirt.org/c/83920, so it was tested at:
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3769
> and passed.
>
> BUT, it was tested along with https://gerrit.ovirt.org/#/c/83918/2
> that was merged earlier as far as git ordering goes, but somehow was
> assumed to be a later patch. When we test multiple patches from the
> same project we essentially use packages built from the one we deem to
> be the latest. So in this case only the packages from 83918 were
> actually tested.
>
> We went to great lengths to preserve correct patch ordering by
> preserving the order of event notifications reaching us from gerrit.
> But here it seems we ended out with out-of-order patches. Do you have
> any idea how did we end up with this? Do you remember what was the
> sequence in which you clicked the 'merge' button on the different
> patches?
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] failing check-patch on ovirt-engine

[Allon Mureinik]

Probably another instead of [1].
Retriggering the job should probably clear the issue up.

[1] http://lists.ovirt.org/pipermail/devel/2017-November/031840.html

On Sun, Nov 12, 2017 at 5:53 PM, Greg Sheremeta  wrote:

> Hi,
>
> I'm seeing a weird issue in ovirt-engine check-patch.
>
> There's no way this failure is related to my patch [
> https://gerrit.ovirt.org/#/c/83950/], which is a 1 character typo fix in
> the constants file.
>
> Anyone have any ideas or also seeing this? It seems random, too --
> sometimes 1 or 2 of the jobs will succeed [el7, fc25] but the other will
> fail. Etc.
>
>
> *14:48:08* + automation/packaging-setup-tests.sh*14:48:08* + trap popd 
> 0*14:48:08* +++ readlink -f automation/packaging-setup-tests.sh*14:48:08* ++ 
> dirname 
> /home/jenkins/workspace/ovirt-engine_master_check-patch-fc26-x86_64/ovirt-engine/automation/packaging-setup-tests.sh*14:48:08*
>  + pushd 
> /home/jenkins/workspace/ovirt-engine_master_check-patch-fc26-x86_64/ovirt-engine/automation/..*14:48:08*
>  ~ ~*14:48:08* + export 
> PYTHONPATH=packaging/pythonlib:packaging/setup:*14:48:08* + 
> PYTHONPATH=packaging/pythonlib:packaging/setup:*14:48:08* + python -m pytest 
> packaging/setup*14:48:08* = test session starts 
> ==*14:48:08* platform linux2 -- Python 2.7.14, 
> pytest-3.2.3, py-1.4.34, pluggy-0.4.0*14:48:08* rootdir: 
> /home/jenkins/workspace/ovirt-engine_master_check-patch-fc26-x86_64/ovirt-engine,
>  inifile:*14:48:08* collected 0 items / 1 errors*14:48:08* *14:48:08* 
>  ERRORS 
> *14:48:08*  ERROR collecting 
> packaging/setup/tests/ovirt_engine_setup/engine_common/test_database.py 
> *14:48:08* ImportError while importing test module 
> '/home/jenkins/workspace/ovirt-engine_master_check-patch-fc26-x86_64/ovirt-engine/packaging/setup/tests/ovirt_engine_setup/engine_common/test_database.py'.*14:48:08*
>  Hint: make sure your test modules/packages have valid Python 
> names.*14:48:08* Traceback:*14:48:08* 
> packaging/setup/tests/ovirt_engine_setup/engine_common/test_database.py:19: 
> in *14:48:08* import ovirt_engine_setup.engine_common.database as 
> under_test  # isort:skip # noqa: E402*14:48:08* 
> packaging/setup/ovirt_engine_setup/engine_common/database.py:30: in 
> *14:48:08* from otopi import base*14:48:08* E   ImportError: No 
> module named otopi*14:48:08* !!! Interrupted: 1 errors during 
> collection *14:48:08* === 1 error 
> in 0.33 seconds *14:48:08* + popd*14:48:08* ~
>
>
>
> -- Forwarded message --
> From: Code Review 
> Date: Sun, Nov 12, 2017 at 10:31 AM
> Subject: Change in ovirt-engine[master]: engine: typo fix snaphot ->
> snapshot
> To: Greg Sheremeta 
>
>
> Jenkins CI *posted comments* on this change.
>
> View Change 
>
> Patch set 1:Continuous-Integration -1
>
> Build Failed
>
> http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch
> -fc25-x86_64/17231/ : FAILURE
>
> http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch
> -fc26-x86_64/157/ : FAILURE
>
> http://jenkins.ovirt.org/job/ovirt-engine_master_check-patch
> -el7-x86_64/33193/ : SUCCESS
>
>
> To view, visit change 83950 . To
> unsubscribe, visit settings .
> Gerrit-Project: ovirt-engine
> Gerrit-Branch: master
> Gerrit-MessageType: comment
> Gerrit-Change-Id: I88b4d75855c0abe2f0eddd8b282c172205db2e42
> Gerrit-Change-Number: 83950
> Gerrit-PatchSet: 1
> Gerrit-Owner: Greg Sheremeta 
> Gerrit-Reviewer: Alexander Wels 
> Gerrit-Reviewer: Greg Sheremeta 
> Gerrit-Reviewer: Jenkins CI
> Gerrit-Reviewer: Tal Nisan 
> Gerrit-Reviewer: Vojtech Szocs 
> Gerrit-Reviewer: gerrit-hooks 
> Gerrit-Comment-Date: Sun, 12 Nov 2017 15:31:27 +
> Gerrit-HasComments: No
>
>
>
> --
>
> GREG SHEREMETA
>
> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
>
> Red Hat NA
>
> 
>
> gsher...@redhat.comIRC: gshereme
> 
>
> ___
> Infra mailing list
> in...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Subject: [ OST Failure Report ] [ oVirt master ] [ 26.11.17 ] [ 001_initialize_engine ]

[Allon Mureinik]

On Mon, Nov 27, 2017 at 2:30 PM, Allon Mureinik <amure...@redhat.com> wrote:

> The analysis is completely wrong.
>
> The offending patch is [1]. I assume the reason for the failure is that
> gap between when the CI passed (Nov 21) and when it was merged (Nov 26). In
> the five days in between, other patches entered master and invalidated this
> CI result.
>
> To quote the job's log:
> """
>
> *16:36:04* [ovirt-master_change-queue-tester] Running shell script*16:36:05* 
> Testing 5 changes:*16:36:05* - 84680,2 (ovirt-engine) - 
> https://gerrit.ovirt.org/#/c/84680/2*16:36:05* - 84681,2 (ovirt-engine) - 
> https://gerrit.ovirt.org/#/c/84681/2*16:36:05* - 84039,4 (ovirt-engine) - 
> https://gerrit.ovirt.org/#/c/84039/4*16:36:05* - 84609,3 (vdsm) - 
> https://gerrit.ovirt.org/#/c/84609/3*16:36:05* - 84480,8 (vdsm) - 
> https://gerrit.ovirt.org/#/c/84480/8*16:36:05*
>
> """
>
>
> I noticed this by chance yesterday and merged [2] (which is listed as the
> probable cause here, of all things!) to fix it.
>
​The statement in parenthesis is not true - my apologies, wrong link
clicked.
Regardless, the rest of the analysis is correct, and the problem has
already been fixed. Engine develoeprs are advised to rebase on top of [2]
below.
​


>
> Once the change queue catches up to this, you should be OK.
>
> [1] https://gerrit.ovirt.org/#/c/84039/
> [2] https://gerrit.ovirt.org/#/c/84687/
>
> On Sun, Nov 26, 2017 at 7:25 PM, Gal Ben Haim <gbenh...@redhat.com> wrote:
>
>> Suspected patches:
>> https://gerrit.ovirt.org/#/c/84618/2
>>
>> Link to Job:
>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4158/
>>
>> Link to all logs:
>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-teste
>> r/4158/artifact/exported-artifacts/basic-suit-master-el7/
>>
>> Error snippet from "ovirt-engine-setup.log":
>>
>> 017-11-26 11:48:42,863-0500 DEBUG 
>> otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.execute:926 
>> execute-output: ['/usr/share/ovirt-engine/dbscripts/schema.sh', '-s', 
>> 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l', 
>> '/var/log/ovirt-engine/setup/ovirt-engine-setup-20171126114742-1yt09f.log', 
>> '-c', 'apply'] stderr:
>> FATAL: Operation aborted, found duplicate version: 04020770
>>
>> 2017-11-26 11:48:42,863-0500 ERROR 
>> otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema schema._misc:374 
>> schema.sh: FATAL: Operation aborted, found duplicate version: 04020770
>> 2017-11-26 11:48:42,863-0500 DEBUG otopi.context context._executeMethod:143 
>> method exception
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133, in 
>> _executeMethod
>> method['method']()
>>   File 
>> "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py",
>>  line 376, in _misc
>> raise RuntimeError(_('Engine schema refresh failed'))
>> RuntimeError: Engine schema refresh failed
>> 2017-11-26 11:48:42,864-0500 ERROR otopi.context context._executeMethod:152 
>> Failed to execute stage 'Misc configuration': Engine schema refresh failed
>>
>>
>>
>> --
>> *GAL bEN HAIM*
>> RHV DEVOPS
>>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Subject: [ OST Failure Report ] [ oVirt master ] [ 26.11.17 ] [ 001_initialize_engine ]

[Allon Mureinik]

The analysis is completely wrong.

The offending patch is [1]. I assume the reason for the failure is that gap
between when the CI passed (Nov 21) and when it was merged (Nov 26). In the
five days in between, other patches entered master and invalidated this CI
result.

To quote the job's log:
"""

*16:36:04* [ovirt-master_change-queue-tester] Running shell
script*16:36:05* Testing 5 changes:*16:36:05* - 84680,2 (ovirt-engine)
- https://gerrit.ovirt.org/#/c/84680/2*16:36:05* - 84681,2
(ovirt-engine) - https://gerrit.ovirt.org/#/c/84681/2*16:36:05* -
84039,4 (ovirt-engine) -
https://gerrit.ovirt.org/#/c/84039/4*16:36:05* - 84609,3 (vdsm) -
https://gerrit.ovirt.org/#/c/84609/3*16:36:05* - 84480,8 (vdsm) -
https://gerrit.ovirt.org/#/c/84480/8*16:36:05*

"""


I noticed this by chance yesterday and merged [2] (which is listed as the
probable cause here, of all things!) to fix it.

Once the change queue catches up to this, you should be OK.

[1] https://gerrit.ovirt.org/#/c/84039/
[2] https://gerrit.ovirt.org/#/c/84687/

On Sun, Nov 26, 2017 at 7:25 PM, Gal Ben Haim  wrote:

> Suspected patches:
> https://gerrit.ovirt.org/#/c/84618/2
>
> Link to Job:
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4158/
>
> Link to all logs:
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-
> tester/4158/artifact/exported-artifacts/basic-suit-master-el7/
>
> Error snippet from "ovirt-engine-setup.log":
>
> 017-11-26 11:48:42,863-0500 DEBUG 
> otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.execute:926 
> execute-output: ['/usr/share/ovirt-engine/dbscripts/schema.sh', '-s', 
> 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l', 
> '/var/log/ovirt-engine/setup/ovirt-engine-setup-20171126114742-1yt09f.log', 
> '-c', 'apply'] stderr:
> FATAL: Operation aborted, found duplicate version: 04020770
>
> 2017-11-26 11:48:42,863-0500 ERROR 
> otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema schema._misc:374 
> schema.sh: FATAL: Operation aborted, found duplicate version: 04020770
> 2017-11-26 11:48:42,863-0500 DEBUG otopi.context context._executeMethod:143 
> method exception
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133, in 
> _executeMethod
> method['method']()
>   File 
> "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py",
>  line 376, in _misc
> raise RuntimeError(_('Engine schema refresh failed'))
> RuntimeError: Engine schema refresh failed
> 2017-11-26 11:48:42,864-0500 ERROR otopi.context context._executeMethod:152 
> Failed to execute stage 'Misc configuration': Engine schema refresh failed
>
>
>
> --
> *GAL bEN HAIM*
> RHV DEVOPS
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt 4.1 ] [ 27-11-2017] [ 001_initialize_engine.test_initialize_engine ]

[Allon Mureinik]

I doubt that patch has anything to do with ovirt-imageio not starting.

Daniel/Nir - any insight?

On Mon, Nov 27, 2017 at 5:11 PM, Dafna Ron  wrote:

> *Hi, *
>
> * We have a failure reported in ovirt 4.1 on ovirt-imageio not starting
> and causing initialize_engine to fail I am not sure the reported patch is
> related but it was reported by cq as the cause of the failure. Link and
> headline of suspected patches: Renamed disable-multipath.sh script to
> blacklist_all_disks.sh - https://gerrit.ovirt.org/#/c/84520/
> *
>
>
> *Link to Job:*
> * http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1384/
> *
>
>
> *Link to all logs:*
>
>
> * http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1384/artifact
> 
> (Relevant) error snippet from the log:  From lago log: *
>
> [ ERROR ] Failed to execute stage 'Closing up': Failed to start service 
> 'ovirt-imageio-proxy'
>
>
>
> Stacktrace
>
>   File "/usr/lib64/python2.7/unittest/case.py", line 369, in run
> testMethod()
>   File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
>   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 59, in 
> wrapper
> return func(get_test_prefix(), *args, **kwargs)
>   File 
> "/home/jenkins/workspace/ovirt-4.1_change-queue-tester/ovirt-system-tests/upgrade-from-prevrelease-suite-4.1/test-scenarios-before-upgrade/001_initialize_engine.py",
>  line 46, in test_initialize_engine
> result.code, 0, 'engine-setup failed. Exit code is %s' % result.code
>   File "/usr/lib/python2.7/site-packages/nose/tools/trivial.py", line 29, in 
> eq_
> raise AssertionError(msg or "%r != %r" % (a, b))
> "engine-setup failed. Exit code is 1\n >> begin captured 
> logging << \nlago.plugins.vm: INFO: * Copy 
> /home/jenkins/workspace/ovirt-4.1_change-queue-tester/ovirt-system-tests/upgrade-from-prevrelease-suite-4.1/engine-answer-file.conf
>  to lago-upgrade-from-prevrelease-suite-4-1-engine:/tmp/answer-file-pre: 
> \x1b[0m\x1b[0m\nlago.ssh: DEBUG: start 
> task:e48d997a-49c2-4a9e-a87a-b99e79b4d47b:Get ssh client for 
> lago-upgrade-from-prevrelease-suite-4-1-engine:\nlago.ssh: DEBUG: Still got 
> 100 tries for lago-upgrade-from-prevrelease-suite-4-1-engine\nlago.ssh: 
> DEBUG: end task:e48d997a-49c2-4a9e-a87a-b99e79b4d47b:Get ssh client for 
> lago-upgrade-from-prevrelease-suite-4-1-engine:\nlago.plugins.vm: INFO: * 
> Copy 
> /home/jenkins/workspace/ovirt-4.1_change-queue-tester/ovirt-system-tests/upgrade-from-prevrelease-suite-4.1/engine-answer-file.conf
>  to lago-upgrade-from-prevrelease-suite-4-1-engine:/tmp/answer-file-pre: 
> \x1b[32mSuccess\x1b[0m (in 0:00:00)\nlago.ssh: DEBUG: start 
> task:8d1fe1d8-ad8f-4523-a0ce-94e9849a4403:Get ssh client for 
> lago-upgrade-from-prevrelease-suite-4-1-engine:\nlago.ssh: DEBUG: Still got 
> 100 tries for lago-upgrade-from-prevrelease-suite-4-1-engine\nlago.ssh: 
> DEBUG: end task:8d1fe1d8-ad8f-4523-a0ce-94e9849a4403:Get ssh client for 
> lago-upgrade-from-prevrelease-suite-4-1-engine:\nlago.ssh: DEBUG: Running 
> 50e4d668 on lago-upgrade-from-prevrelease-suite-4-1-engine: engine-setup 
> --config-append=/tmp/answer-file-pre\nlago.ssh: DEBUG: Command 50e4d668 on 
> lago-upgrade-from-prevrelease-suite-4-1-engine returned with 1\nlago.ssh: 
> DEBUG: Command 50e4d668 on lago-upgrade-from-prevrelease-suite-4-1-engine 
> output:\n [ INFO  ] Stage: Initializing\n[ INFO  ] Stage: Environment setup\n 
>  Configuration files: 
> ['/etc/ovirt-engine-setup.conf.d/10-packaging-jboss.conf', 
> '/etc/ovirt-engine-setup.conf.d/10-packaging.conf', '/tmp/answer-file-pre']\n 
>  Log file: 
> /var/log/ovirt-engine/setup/ovirt-engine-setup-20171127081018-s7jb49.log\n
>   Version: otopi-1.5.2 (otopi-1.5.2-1.el7.centos)\n[ INFO  ] Stage: 
> Environment packages setup\n[ INFO  ] Yum Status: Downloading Packages\n[ 
> INFO  ] Yum Download/Verify: iproute-3.10.0-87.el7.x86_64\n[ INFO  ] Yum 
> Status: Check Package Signatures\n[ INFO  ] Yum Status: Running Test 
> Transaction\n[ INFO  ] Yum Status: Running Transaction\n[ INFO  ] Yum update: 
> 1/2: iproute-3.10.0-87.el7.x86_64\n[ INFO  ] Yum updated: 2/2: iproute\n[ 
> INFO  ] Yum Verify: 1/2: iproute.x86_64 0:3.10.0-87.el7 - u\n[ INFO  ] Yum 
> Verify: 2/2: iproute.x86_64 0:3.10.0-54.el7 - ud\n[ INFO  ] Stage: Programs 
> detection\n[ INFO  ] Stage: Environment setup\n[ INFO  ] Stage: Environment 
> customization\n \n  --== PRODUCT OPTIONS ==--\n \n
>  \n  --== PACKAGES ==--\n \n[ INFO  ] Checking for an 
> update for Setup...\n  No update for Setup found\n \n 
>  --== NETWORK CONFIGURATION ==--\n \n[WARNING] Host name engine has 
> no domain 

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 23-11-2017 ] [ 001_initialize_engine.test_initialize_engine ]

[Allon Mureinik]

Didi - we just saw a report of a similar failure on engine-4.1's OST.
COuld you please backport these patches there too?

On Mon, Nov 27, 2017 at 2:57 PM, Yedidyah Bar David <d...@redhat.com> wrote:

> On Mon, Nov 27, 2017 at 10:38 AM, Yedidyah Bar David <d...@redhat.com>
> wrote:
>
>> On Sun, Nov 26, 2017 at 7:24 PM, Nir Soffer <nsof...@redhat.com> wrote:
>> > I think we need to check and report which  process is listening on a
>> port
>> > when starting a server on that port fail.
>>
>> How do you know that a server was "started on that port", and that
>> if failed specifically because it failed to bind?
>>
>> There is no standardized (Unix) way to mark that a service wants to
>> listen on a specific port, or that it failed because a specific port
>> was bound by some other process.
>>
>> There are various classical *inetd* daemons, and modern systemd.socket,
>> that listen *instead* of some service. Then they can manage the port
>> resources and perhaps do something intelligent about them.
>>
>> >
>> > Didi, do you think we can integrate this in the deploy code, or this
>> > should be implemented in each server?
>>
>> It should be quite easy to patch otopi's services.state to run something
>> if start fails, e.g. 'ss -anp' or whatever you want.
>>
>> It should even be not-too-hard to do this in a self-contained plugin,
>> so can be part of otopi-debug-plugins.
>>
>> If we decide that something needs to be implemented by each server,
>> perhaps "something" should be to be controlled by a systemd.socket unit.
>> Didn't try, though, to see what this actually buys us.
>>
>> >
>> > Maybe when deployment fails, the deploy code can report all the
>> > listening sockets and the processes bound to these sockets?
>>
>> Pushed now:
>>
>> https://gerrit.ovirt.org/84699 core: Name TRANSACTION_INIT
>> https://gerrit.ovirt.org/84700 plugins: debug: Add debug_failure
>> https://gerrit.ovirt.org/84701 automation: Test failure
>>
>> Will merge soon, if all goes well.
>>
>
> Merged them.
>
> Pushed to OST:
>
> https://gerrit.ovirt.org/84710
>
> Dafna - thanks for opening the bug on ovirt-imageio, but I am not
> sure anyone can do much about it without more info, such as might
> be provided by above patches. When I suggested below to open BZ
> I meant on otopi or host-deploy to provide more debugging info,
> not for imageio - obviously no harm in opening it, and it's good
> to have it even if only for reference.
>
>
>>
>> Feel free to open BZ for other things discussed above, if relevant.
>>
>> >
>> > Nir
>> >
>> > On Sun, Nov 26, 2017 at 7:11 PM Gal Ben Haim <gbenh...@redhat.com>
>> wrote:
>> >>
>> >> The failure is not consistent.
>> >>
>> >> On Sun, Nov 26, 2017 at 5:33 PM, Yaniv Kaul <yk...@redhat.com> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Sun, Nov 26, 2017 at 4:53 PM, Gal Ben Haim <gbenh...@redhat.com>
>> >>> wrote:
>> >>>>
>> >>>> We still see this issue on the upgrade suite from latest release to
>> >>>> master [1].
>> >>>> I don't see any evidence in "/var/log/messages" [2] that
>> >>>> "ovirt-imageio-proxy" was started twice.
>> >>>
>> >>>
>> >>> Since it's not a registered port and a high port, could it be used by
>> >>> something else (what are the odds though ?
>> >>> Is it consistent?
>> >>> Y.
>> >>>
>> >>>>
>> >>>>
>> >>>> [1]
>> >>>> http://jenkins.ovirt.org/blue/rest/organizations/jenkins/pip
>> elines/ovirt-master_change-queue-tester/runs/4153/nodes/123/
>> steps/241/log/?start=0
>> >>>>
>> >>>> [2]
>> >>>> http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovir
>> t-master_change-queue-tester/4153/artifact/exported-artifac
>> ts/upgrade-from-release-suit-master-el7/test_logs/upgrade-
>> from-release-suite-master/post-001_initialize_engine.py/
>> lago-upgrade-from-release-suite-master-engine/_var_log/messages/*view*/
>> >>>>
>> >>>> On Fri, Nov 24, 2017 at 8:16 PM, Dafna Ron <d...@redhat.com> wrote:
>> >>>>>
>> >>>>> there were two different patches reported as failing cq today with
>

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 23-11-2017 ] [ 001_initialize_engine.test_initialize_engine ]

[Allon Mureinik]

Daniel/Nir?

On Thu, Nov 23, 2017 at 5:29 PM, Dafna Ron  wrote:

> Hi,
>
> We have a failing on test 001_initialize_engine.test_initialize_engine.
>
> This is failing with error Failed to start service 'ovirt-imageio-proxy
>
>
> *Link and headline ofto suspected patches: *
>
>
> * build: Make resulting RPMs architecture-specific -
> https://gerrit.ovirt.org/#/c/84534/ 
> Link to Job:
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4055
> *
>
>
> *Link to all logs:*
>
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-
> tester/4055/artifact/
>
> *http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4055/artifact/exported-artifacts/upgrade-from-release-suit-master-el7/test_logs/upgrade-from-release-suite-master/post-001_initialize_engine.py/lago-upgrade-from-release-suite-master-engine/_var_log/messages/*view*/
> *
>
>
>
> * (Relevant) error snippet from the log:  *from lago log:
>
> Failed to start service 'ovirt-imageio-proxy
>
> messages logs:
>
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine systemd: 
> Starting Session 8 of user root.
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: Traceback (most recent call last):
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: File "/usr/bin/ovirt-imageio-proxy", line 85, in 
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: status = image_proxy.main(args, config)
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: File 
> "/usr/lib/python2.7/site-packages/ovirt_imageio_proxy/image_proxy.py", line 
> 21, in main
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: image_server.start(config)
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: File 
> "/usr/lib/python2.7/site-packages/ovirt_imageio_proxy/server.py", line 45, in 
> start
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: WSGIRequestHandler)
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: File "/usr/lib64/python2.7/SocketServer.py", line 419, 
> in __init__
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: self.server_bind()
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: File "/usr/lib64/python2.7/wsgiref/simple_server.py", 
> line 48, in server_bind
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: HTTPServer.server_bind(self)
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, 
> in server_bind
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: SocketServer.TCPServer.server_bind(self)
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: File "/usr/lib64/python2.7/SocketServer.py", line 430, 
> in server_bind
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: self.socket.bind(self.server_address)
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: File "/usr/lib64/python2.7/socket.py", line 224, in meth
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: return getattr(self._sock,name)(*args)
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: socket.error: [Errno 98] Address already in use
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine systemd: 
> ovirt-imageio-proxy.service: main process exited, code=exited, 
> status=1/FAILURE
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine systemd: Failed 
> to start oVirt ImageIO Proxy.
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine systemd: Unit 
> ovirt-imageio-proxy.service entered failed state.
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine systemd: 
> ovirt-imageio-proxy.service failed.
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine systemd: 
> ovirt-imageio-proxy.service holdoff time over, scheduling restart.
> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine systemd: 
> Starting oVirt ImageIO Proxy...
> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
> ovirt-imageio-proxy: Traceback (most recent call last):
> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
> 

Re: [ovirt-devel] ovirt.org presentation template

[Allon Mureinik]

Yup:
https://www.ovirt.org/community/get-involved/resources/slide-decks/



On Thu, Nov 23, 2017 at 4:42 PM, Yaniv Kaul  wrote:

> Hi,
>
> Do we have such a template for presentation?
> TIA,
> Y.
>
> ___
> 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] Jupiter isn't just a planet - it's how we test things in the Engine

[Allon Mureinik]

Hi all,

Over the past couple of days I've merged a series of patches that upgrade the 
Engine's usage of JUnit to JUnit Jupiter 5.2 in order to make it easier to 
write new tests.

Despite the patches being quite straight-forward, since Jupiter is **not** 
backwards compatible to JUnit 4, or even JUnit 5 Vintage, here's the short 
version of what you need to know:

1. You no longer use annotations from the org.junit package, but the 
junit.org.jupiter.api packages. @Before and @After have been replaced with 
@BeforeEach and AfterEach respectively, and @BeforeClass and @AfterClass have 
been replaced with @BeforeAll and @AfterAll.

2. Assertions now live in the org.junit.jupiter.api.Assertions class. Note that 
the optional message parameter is now the **last** parameter in all the 
assertions, not the first. Also worth noting that assertThat has been removed. 
More often than not, assertTrue can be used with a Supplier, but if 
you absolutely need an assertThat method, just use the one that Hamcrest 
provides.

3. Similarly, assumptions live in org.junit.jupiter.api.Assumptions.

4. No more runners - extending tests in JUnit Jupiter is done with Extensions. 
There's no longer a need for the Parameterized and Theories runners, as you can 
just use the built-in @ParameterizedTest annotation. Instead of the 
MockitoJUnitRunner we used to heavily rely on, you should now use 
MockitoExtension.

5. No more Rules - these too were replaced with extensions. Our custom rules 
were replaced with extensions, which are pretty well documented both in their 
javadoc and in wiki under [1]

For additional information, you could take a look at the official documentation 
[2]


Happy testing!
Allon

[1] https://ovirt.org/develop/dev-process/unit-testing-utilities/
[2] https://junit.org/junit5/docs/current/user-guide/
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[ovirt-devel] Jupiter isn't just a planet - it's how we test things in the Engine

[Allon Mureinik]

Hi all,

Over the past couple of days I've merged a series of patches that upgrade the 
Engine's usage of JUnit to JUnit Jupiter 5.2 in order to make it easier to 
write new tests.

Despite the patches being quite straight-forward, since Jupiter is **not** 
backwards compatible to JUnit 4, or even JUnit 5 Vintage, here's the short 
version of what you need to know:

1. You no longer use annotations from the org.junit package, but the 
junit.org.jupiter.api packages. @Before and @After have been replaced with 
@BeforeEach and AfterEach respectively, and @BeforeClass and @AfterClass have 
been replaced with @BeforeAll and @AfterAll.

2. Assertions now live in the org.junit.jupiter.api.Assertions class. Note that 
the optional message parameter is now the **last** parameter in all the 
assertions, not the first. Also worth noting that assertThat has been removed. 
More often than not, assertTrue can be used with a Supplier, but if 
you absolutely need an assertThat method, just use the one that Hamcrest 
provides.

3. Similarly, assumptions live in org.junit.jupiter.api.Assumptions.

4. No more runners - extending tests in JUnit Jupiter is done with Extensions. 
There's no longer a need for the Parameterized and Theories runners, as you can 
just use the built-in @ParameterizedTest annotation. Instead of the 
MockitoJUnitRunner we used to heavily rely on, you should now use 
MockitoExtension.

5. No more Rules - these too were replaced with extensions. Our custom rules 
were replaced with extensions, which are pretty well documented both in their 
javadoc and in wiki under [1]

For additional information, you could take a look at the official documentation 
[2]


Happy testing!
Allon

[1] https://ovirt.org/develop/dev-process/unit-testing-utilities/
[2] https://junit.org/junit5/docs/current/user-guide/
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt Master ] [ bootstrap.verify_add_hosts ] [ 18/10/17 ]

[Allon Mureinik]

Bloody hell. The original was also completely broken, and worked by chance.
Damn it.

This should fix it:
https://gerrit.ovirt.org/#/c/82989/

On Thu, Oct 19, 2017 at 3:49 PM, Martin Perina  wrote:

> So the real issue on adding a host is the same as I've today described in
> [2] and most probably caused by [3] (I reverted engine in my dev env prior
> this patch and host deploy finished successfully).
>
> Allon, do you have time to post a fix? If not I'll try to dig into your
> change and related networking code to post it ...
>
>
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1504005
> [3] https://gerrit.ovirt.org/#/c/82545/
>
> On Thu, Oct 19, 2017 at 11:12 AM, Martin Perina 
> wrote:
>
>>
>>
>> On Thu, Oct 19, 2017 at 11:04 AM, Martin Perina 
>> wrote:
>>
>>>
>>>
>>> On Thu, Oct 19, 2017 at 10:58 AM, Dan Kenigsberg 
>>> wrote:
>>>
 On Thu, Oct 19, 2017 at 10:29 AM, Martin Perina 
 wrote:
 >
 >
 > On Thu, Oct 19, 2017 at 7:35 AM, Dan Kenigsberg 
 wrote:
 >>
 >> On Wed, Oct 18, 2017 at 2:40 PM, Daniel Belenky 
 >> wrote:
 >>>
 >>> Hi all,
 >>>
 >>> The following test is failing: 002_bootstrap.verify_add_hosts
 >>> All logs from failing job
 >>> Only 2 engine patches participated in the test, so the suspected
 patches
 >>> are:
 >>>
 >>> https://gerrit.ovirt.org/#/c/82542/2
 >>> https://gerrit.ovirt.org/#/c/82545/3
 >>>
 >>> Due to the fact that when this error first introduced we had another
 >>> error, the CI can't automatically detect the specific patch.
 >>>
 >>> Error snippet from logs: ovirt-host-deploy-ansible log (Full log)
 >>>
 >>> TASK [ovirt-host-deploy-firewalld : Enable firewalld rules]
 >>> 
 >>> failed: [lago-basic-suite-master-host-0] (item={u'service':
 >>> u'glusterfs'}) => {"changed": false, "failed": true, "item":
 {"service":
 >>> "glusterfs"}, "msg": "ERROR: Exception caught:
 >>> org.fedoraproject.FirewallD1.Exception: INVALID_SERVICE:
 'glusterfs' not
 >>> among existing services Permanent and Non-Permanent(immediate)
 operation,
 >>> Services are defined by port/tcp relationship and named as they are
 in
 >>> /etc/services (on most systems)"}
 >>>
 >>>
 >>> Error from HOST 0 firewalld log:
 >>> lago-basic-suite-master-host-0/_var_log/firewalld/ (Full log)
 >>>
 >>> 2017-10-15 16:51:24 ERROR: INVALID_SERVICE: 'glusterfs' not among
 >>> existing services
 >>
 >>
 >> Ondra, would such an error propagate through the playbook to Engine
 and
 >> fail the add-host flow? (I think it should!)
 >
 >
 > We didn't do that so far, because of EL 7.3
 > . We need firewalld from 7.4 to have all available services in place
 (I
 > don't remember but I think imageio service was the one delivered only
 in
 > firewalld from 7.4). So  up until now we ingore non-existent firewalld
 > service, but if needed we can turn this on and fail host deploy.

 Ok, so for now your "luckily" off the hook and not the reason of
 failure.

 >>
 >>
 >> Do you know which package provide the glusterfs firewalld service,
 and why
 >> it is missing from the host?
 >
 >
 > So we have used 'glusterfs' firewalld service per Sahina
 recommendation,
 > which is included in glusterfs-server package from version 3.7.6 [1].
 But
 > this package is not installed when installing packages for cluster
 with
 > gluster capabilities enabled. So now I'm confused: don't we need
 > glusterfs-server package? If not and we need those ports open because
 they
 > are used by services from different already installed glusterfs
 packages,
 > shouldn't the firewalld configuration be moved from glusterfs-server
 to
 > glusterfs package?

 glusterfs-cli.rpm is required to consume gluster storage (virt use
 case), but I don't recall that it needs open ports.

>>>
>>> ​It was there even for IPTables, if gluster support is enabled on
>>> cluster, then gluster specific ports were enabled even with IPTables.
>>> FirewallD feature continues to use that.
>>> ​
>>>
>>>
 glusterfs-server.rpm is required to provide gluster storage (gluster
 use case).
 If I recall correctly, firewalld feature has differentiated between
 the two; opening needed ports only when relevant.

>>>
>>> ​Right, but if gluster services are configured for firewalld it means
>>> that the host has been added to the cluster with gluster feature enabled
>>> and not only virt
>>> ​
>>>
>>>

 >
 >
 > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1057295
 >
 >

>>>
>>>
>>
>
___
Devel 

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt Master ] [ bootstrap.verify_add_hosts ] [ 18/10/17 ]

[Allon Mureinik]

Fix merged based on Alona and Martin's reviews.
It seems to do the trick with my testing on my local engine, let's hope
that's really it.

On Thu, Oct 19, 2017 at 4:37 PM, Allon Mureinik <amure...@redhat.com> wrote:

> Bloody hell. The original was also completely broken, and worked by
> chance. Damn it.
>
> This should fix it:
> https://gerrit.ovirt.org/#/c/82989/
>
> On Thu, Oct 19, 2017 at 3:49 PM, Martin Perina <mper...@redhat.com> wrote:
>
>> So the real issue on adding a host is the same as I've today described in
>> [2] and most probably caused by [3] (I reverted engine in my dev env prior
>> this patch and host deploy finished successfully).
>>
>> Allon, do you have time to post a fix? If not I'll try to dig into your
>> change and related networking code to post it ...
>>
>>
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1504005
>> [3] https://gerrit.ovirt.org/#/c/82545/
>>
>> On Thu, Oct 19, 2017 at 11:12 AM, Martin Perina <mper...@redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Oct 19, 2017 at 11:04 AM, Martin Perina <mper...@redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Oct 19, 2017 at 10:58 AM, Dan Kenigsberg <dan...@redhat.com>
>>>> wrote:
>>>>
>>>>> On Thu, Oct 19, 2017 at 10:29 AM, Martin Perina <mper...@redhat.com>
>>>>> wrote:
>>>>> >
>>>>> >
>>>>> > On Thu, Oct 19, 2017 at 7:35 AM, Dan Kenigsberg <dan...@redhat.com>
>>>>> wrote:
>>>>> >>
>>>>> >> On Wed, Oct 18, 2017 at 2:40 PM, Daniel Belenky <
>>>>> dbele...@redhat.com>
>>>>> >> wrote:
>>>>> >>>
>>>>> >>> Hi all,
>>>>> >>>
>>>>> >>> The following test is failing: 002_bootstrap.verify_add_hosts
>>>>> >>> All logs from failing job
>>>>> >>> Only 2 engine patches participated in the test, so the suspected
>>>>> patches
>>>>> >>> are:
>>>>> >>>
>>>>> >>> https://gerrit.ovirt.org/#/c/82542/2
>>>>> >>> https://gerrit.ovirt.org/#/c/82545/3
>>>>> >>>
>>>>> >>> Due to the fact that when this error first introduced we had
>>>>> another
>>>>> >>> error, the CI can't automatically detect the specific patch.
>>>>> >>>
>>>>> >>> Error snippet from logs: ovirt-host-deploy-ansible log (Full log)
>>>>> >>>
>>>>> >>> TASK [ovirt-host-deploy-firewalld : Enable firewalld rules]
>>>>> >>> 
>>>>> >>> failed: [lago-basic-suite-master-host-0] (item={u'service':
>>>>> >>> u'glusterfs'}) => {"changed": false, "failed": true, "item":
>>>>> {"service":
>>>>> >>> "glusterfs"}, "msg": "ERROR: Exception caught:
>>>>> >>> org.fedoraproject.FirewallD1.Exception: INVALID_SERVICE:
>>>>> 'glusterfs' not
>>>>> >>> among existing services Permanent and Non-Permanent(immediate)
>>>>> operation,
>>>>> >>> Services are defined by port/tcp relationship and named as they
>>>>> are in
>>>>> >>> /etc/services (on most systems)"}
>>>>> >>>
>>>>> >>>
>>>>> >>> Error from HOST 0 firewalld log:
>>>>> >>> lago-basic-suite-master-host-0/_var_log/firewalld/ (Full log)
>>>>> >>>
>>>>> >>> 2017-10-15 16:51:24 ERROR: INVALID_SERVICE: 'glusterfs' not among
>>>>> >>> existing services
>>>>> >>
>>>>> >>
>>>>> >> Ondra, would such an error propagate through the playbook to Engine
>>>>> and
>>>>> >> fail the add-host flow? (I think it should!)
>>>>> >
>>>>> >
>>>>> > We didn't do that so far, because of EL 7.3
>>>>> > . We need firewalld from 7.4 to have all available services in place
>>>>> (I
>>>>> > don't remember but I think imageio service was the one delivered
>>>>> only in
>>>>> > firew

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt Master ] [ bootstrap.verify_add_hosts ] [ 18/10/17 ]

[Allon Mureinik]

not my finest hour.
thanks, Barak, it's merged now.

On Thu, Oct 19, 2017 at 6:29 PM, Barak Korren <bkor...@redhat.com> wrote:

>
>
> On 19 October 2017 at 17:48, Allon Mureinik <amure...@redhat.com> wrote:
>
>> Fix merged based on Alona and Martin's reviews.
>> It seems to do the trick with my testing on my local engine, let's hope
>> that's really it.
>>
>>
> Umm... It does not seem to be merged yet...
>
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Let's get oVirt in Stack Overflow's Open Source Advertising again

[Allon Mureinik]

Hi all,

With Eldan's help, we have an advert for oVirt [1] suggested on Stack
Overflow's traditional Open Source Advertising campaign [2].

Like always, we need the upvotes to get it up there.

Want to see oVirt on Stack Overflow's sidebar again? Hope over and upvote.


-Allon

[1] https://meta.stackoverflow.com/a/363689/2422776
[2] https://meta.stackoverflow.com/q/362773/2422776
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] qemu-kvm-ev-2.9.0-16.el7_4.14.1 has been released

[Allon Mureinik]

>From oVirt's perspective - this build includes a fix that allows for live
storage migration of a disk that uses iothreads.

I've already posted a vdsm patch to require it, reviews are welcome:
https://gerrit.ovirt.org/#/c/88770/


And thanks for the quick turnaround here, Sandro!

On Fri, Mar 9, 2018 at 11:02 AM, Sandro Bonazzola 
wrote:

> Hi, qemu-kvm-ev-2.9.0-16.el7_4.14.1
>  has been tagged for
> release and should land on mirrors.centos.org on Monday, March 12th 2018.
>
> Here's the ChangeLog:
>
> * Thu Mar 08 2018 Sandro Bonazzola  -
> ev-2.9.0-16.el7_4.14.1 - Removing RH branding from package name * Thu Jan
> 18 2018 Miroslav Rezanina  - rhev-2.9.0-16.el7_4.14
> - kvm-fw_cfg-fix-memory-corruption-when-all-fw_cfg-slots-a.patch
> [bz#1534649] - kvm-mirror-Fix-inconsistent-backing-AioContext-for-after.patch
> [bz#1535125] - Resolves: bz#1534649 (Qemu crashes when all fw_cfg slots are
> used [rhel-7.4.z]) - Resolves: bz#1535125 (Mirror jobs for drives with
> iothreads make QEMU to abort with "block.c:1895: bdrv_attach_child:
> Assertion `bdrv_get_aio_context(parent_bs) ==
> bdrv_get_aio_context(child_bs)' failed." [rhel-7.4.z])
> Regards,
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
>
> Red Hat EMEA 
> 
> TRIED. TESTED. TRUSTED. 
>
>
> ___
> Users mailing list
> us...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] [ENGINE] JUnit version upgrade

[Allon Mureinik]

Hi oVirt Engine developers,

I've just merged a patch to bump oVirt Engine's JUnit requirement to the
latest available 5.1 GA.

As a first step, I've integrated the vintage engine, which is a drop-in
replacement that can run old JUnit 4 (and even JUnit 3!) tests, just with a
newer runtime engine.

This isn't the final goal, but a first step towards moving to the newer
Jupiter engine, which won't be a clean dependency replacement.

Please let me know if you encounter any problem.


Regards,
Allon
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [Engine-devel] revievers needed

[Allon Mureinik]

I'd be happy to review them, but someone else will have to +2 them.

- Original Message -
 From: Laszlo Hornyak lhorn...@redhat.com
 To: engine-devel engine-devel@ovirt.org
 Sent: Thursday, March 15, 2012 12:50:31 PM
 Subject: [Engine-devel] revievers needed
 
 Hi,
 
 I have a big pile of patches waiting for reviewers, some of them are
 very old. If you have some spare-time, please take any:
 http://gerrit.ovirt.org/#dashboard,127
 
 Thank you,
 Laszlo
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] The easy way to mock Config in your unit tests

[Allon Mureinik]

Here's the outcome of the thread below:
http://ovirt.org/wiki/MockConfigRule

Enjoy!

Many thanks to the patches' reviewers.

- Original Message -
 From: Laszlo Hornyak lhorn...@redhat.com
 To: engine-devel engine-devel@ovirt.org
 Sent: Monday, May 7, 2012 2:23:10 PM
 Subject: Re: [Engine-devel] The correct way to create test dependencies   
 between
 
 +1
 I like the idea, I think this would really improve our unit tests.
 
 - Original Message -
  From: Allon Mureinik amure...@redhat.com
  To: engine-devel engine-devel@ovirt.org
  Sent: Sunday, May 6, 2012 2:46:03 PM
  Subject: [Engine-devel] The correct way to create test dependencies
  between
  
  Hi guys,
  
  I've recently come up with (what I believe is) an elegant way to
  mock
  the Config object using JUnit @Rules and Mockito  (The gritty
  details can be found at http://gerrit.ovirt.org/4155).
  
  This presented me with another issue:
  On the one hand, the code depends on junit and mockito jars, which
  are not available in the main scope, only in the test scope.
  On the other hand, in vanilla Maven there is no dependency between
  tests of different projects, so placing this class in util's test
  would make it inaccessible to bll tests.
  
  The solution Maven suggests for these kind of issues is creating a
  test jar
  (http://maven.apache.org/guides/mini/guide-attached-tests.html): In
  addition to the regular jar the module produces, you'll get another
  -test jar, which other modules can depend on using the
  typetest-jar/type, which could of course be put in
  scopetest/scope.
  
  Before pushing forward with this approach, I'd like to know if
  anyone
  has a principle objection to it.
  
  
  Thanks,
  Allon
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
  
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] git-review error.

[Allon Mureinik]

Hi Sharad,

I'm not too big on git-review, but AFAIK -t is used to supply a topic (see 
https://github.com/openstack-ci/git-review#readme).

can you try with an explicit notation refs/for/master/nullpointer ?

-Allon

- Original Message -
 From: snmis...@linux.vnet.ibm.com
 To: engine-devel@ovirt.org
 Sent: Monday, May 14, 2012 9:07:38 PM
 Subject: [Engine-devel] git-review error.
 
 
 Hi,
 
 I am trying to push a patch to gerrit for review.
 
 $ ./git-review -t nullpointer
 remote: Resolving deltas:   0% (0/6)
 To ssh://snmis...@gerrit.ovirt.org:29418/ovirt-engine.git
   ! [remote rejected] HEAD - refs/publish/master/nullpointer
 (prohibited by Gerrit)
 error: failed to push some refs to
 'ssh://snmis...@gerrit.ovirt.org:29418/ovirt-engine.git'
 
 
 I can ssh to gerrit.ovirt.org without password, so that seems to be
 setup correctly. git-review version is 1.17. I am on 'nullpointer'
 branch.
 
Thanks in advance for your help.
 
 Regards
 Sharad Mishra
 
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] Testing queries

[Allon Mureinik]

Hi guys,

following some questions from last week regarding writing unit-tests for query 
objects, I whipped up this quick wiki page:
http://ovirt.org/wiki/Testing_Queries


Enjoy,
Allon
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Forking unit tests

[Allon Mureinik]

- Original Message -
 From: Roy Golan rgo...@redhat.com
 To: engine-devel@ovirt.org
 Sent: Wednesday, June 13, 2012 4:14:06 PM
 Subject: Re: [Engine-devel] Forking unit tests
 
 On 06/13/2012 03:41 PM, Laszlo Hornyak wrote:
  We can just move the surefire config to a higher level in the pom
  hierarchy, but that makes the tests slower globaly.
  It is more work, but we could help Allon to rewrite the Powermock
  tests :-) And then the surefire settings could be removed and the
  tests will run quick again.
 
 great job.
 I think that any further effort we want to put in refactoring the
 tests
 must be in abstracting the code *first* i.e creating facade +
 interfaces
 + getters instead of static calling classes (Backend, Config,
 DbFacade
 ...) . that way we can avoid a lot of mocking code (mkublin we can
 remove a lot of code here!)
+gazilion.
 
  - Original Message -
  From: Yair Zaslavskyyzasl...@redhat.com
  To: Mike Kolesnikmkole...@redhat.com
  Cc: engine-develengine-devel@ovirt.org
  Sent: Wednesday, June 13, 2012 1:44:39 PM
  Subject: Re: [Engine-devel] Forking unit tests
 
  On 06/13/2012 01:28 PM, Mike Kolesnik wrote:
  Hi guys,
 
  If you're using settings.xml as published in Building the oVirt
  Engine page, you'd see we're forking for every test, in every
  subproject.
  This behaviour was introduced to handle memory leaks in
  PowerMock
  we
  use in some subprojects, but is redundant in others.
 
  Over the past month or so I've been working on removing
  PowerMock
  from as many places as possible (many thanks to mkolesni and
  lhornyak!), and we've got to the stage that forking is only
  needed
  in to subprojects - bll and resttypes.
  +1 - great job!
  +1
  Would it be possible to have this as a parameter (defaul true)
  that
  can be overridden, such as -Dengine.forkTests=false ?+
  +1 - good idea.
 
  The forking was defined explicitly in those two projects, so if
  you
  want to speed up your tests, just take the latest version of
  settings.xml from
  http://ovirt.org/wiki/Building_oVirt_engine#Maven_personal_settings.
 
 
  -Allon
 
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
 
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
 
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] oVirt UI: Legacy UserPortal removed

[Allon Mureinik]

awesome!

- Original Message -
 From: Laszlo Hornyak lhorn...@redhat.com
 To: Vojtech Szocs vsz...@redhat.com, engine-devel@ovirt.org
 Sent: Thursday, June 14, 2012 2:29:40 PM
 Subject: Re: [Engine-devel] oVirt UI: Legacy UserPortal removed
 
 Hi,
 
 A visualization of how that counts (from sonar)
 https://twitter.com/kozka/status/213229060103483392/photo/1
 
 Laszlo
 
 - Original Message -
  From: Vojtech Szocs vsz...@redhat.com
  To: engine-devel@ovirt.org
  Sent: Thursday, June 14, 2012 12:55:18 PM
  Subject: [Engine-devel] oVirt UI: Legacy UserPortal removed
  
  Hi everyone,
  
  please note that the original (SmartGWT-based) UserPortal
  application
  has been removed from oVirt repository, as part of patch
  [http://gerrit.ovirt.org/5317].
  
  This has no impact on the current UserPortal application, which is
  part of the standard oVirt Maven build.
  
  Please let me know if you have any questions.
  
  Thanks,
  Vojtech
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
  
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Developer's All In One

[Allon Mureinik]

Cross-posting to engine-devel

 - Forwarded Message -
 From: Yeela Kaplan ykap...@redhat.com
 To: vdsm-de...@lists.fedorahosted.org,
 engine-de...@lists.fedorahosted.org
 Cc: Ayal Baron aba...@redhat.com
 Sent: Monday, June 18, 2012 2:58:55 PM
 Subject: Developer's All In One
 
 Enclosed is the link to a wiki containing a detailed explanation for
 installing a developer's All-In-One environment:
  
 http://www.ovirt.org/wiki/Developers_All_In_One
 
 Regards,
 Yeela
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Forking unit tests

[Allon Mureinik]

- Original Message -
 From: Allon Mureinik amure...@redhat.com
 To: Mike Kolesnik mkole...@redhat.com
 Sent: Thursday, June 14, 2012 12:12:54 PM
 Subject: Re: Forking unit tests
 
 
 
 - Original Message -
  From: Mike Kolesnik mkole...@redhat.com
  To: Allon Mureinik amure...@redhat.com
  Cc: Laszlo Hornyak lhorn...@redhat.com, engine-devel
  engine-devel@ovirt.org
  Sent: Wednesday, June 13, 2012 1:28:36 PM
  Subject: Re: Forking unit tests
  
   Hi guys,
   
   If you're using settings.xml as published in Building the oVirt
   Engine page, you'd see we're forking for every test, in every
   subproject.
   This behaviour was introduced to handle memory leaks in PowerMock
   we
   use in some subprojects, but is redundant in others.
   
   Over the past month or so I've been working on removing PowerMock
   from as many places as possible (many thanks to mkolesni and
   lhornyak!), and we've got to the stage that forking is only
   needed
   in to subprojects - bll and resttypes.
  
  +1 - great job!
 10x!
 
  
  Would it be possible to have this as a parameter (defaul true) that
  can be overridden, such as -Dengine.forkTests=false ?
 couldn't find a good way to do it forkMode doesn't seem to work
 when given a property as a value, sorry.
 :-(
Take a look at http://gerrit.ovirt.org/#/c/5653/1.
Once it is merged, you could user -Dengine.powermock.fork=one to stop forking.

 
  
   The forking was defined explicitly in those two projects, so if
   you
   want to speed up your tests, just take the latest version of
   settings.xml from
   http://ovirt.org/wiki/Building_oVirt_engine#Maven_personal_settings.
   
   
   -Allon
   
  
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] java 1.6 compatibility no more?

[Allon Mureinik]

- Original Message -
 From: Vojtech Szocs vsz...@redhat.com
 To: Juan Hernandez jhern...@redhat.com
 Cc: engine-devel@ovirt.org
 Sent: Thursday, July 19, 2012 2:31:40 PM
 Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
  Don't we need that (the source part) to avoid Java 7 syntax in GWT
  code?
 
 That's a very good point.
 
 In general, GWT compiler supports Java 5 syntax (note that there are
 no language changes between Java 5 and 6). 
This may be nitpicking, but there is a difference:
Java 6 allows the @Override annotation for implementing interfaces, 
while Java 5 restricts it to actual overrides.
This is widely used throughout our code, at least in the backend side.

 For this reason, our
 frontend code should be compliant with Java 5. If someone uses new
 Java 7 language features in frontend code, GWT compiler will throw
 an error and the build will fail.
 
 So the 'Java 5 only' limitation applies to frontend code and any
 other code (e.g. shared modules) that is directly referenced by
 frontend code. This shouldn't affect the backend, however.
 
 We could do something like this:
 
 - let oVirt root POM declare source and target compliance to Java 7
 - let frontend modules POM (frontend/webadmin/modules/pom.xml)
 declare source compliance to Java 5 (or 6)
 
 (note that target compliance can be left to Java 7 since frontend
 compilation results in JavaScript code)
 
 What do you think?
 
 Vojtech
 
 
 - Original Message -
 From: Juan Hernandez jhern...@redhat.com
 To: Vojtech Szocs vsz...@redhat.com
 Cc: Yair Zaslavsky yzasl...@redhat.com, engine-devel@ovirt.org
 Sent: Thursday, July 19, 2012 11:01:00 AM
 Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
 On 07/19/2012 10:09 AM, Vojtech Szocs wrote:
  As I previously emailed - JDK7 already fixed a known issue with
  ldap and
  DNS ,and made one of my patches at gerrit redundant.
  Why not enjoy the bug fixes?
  
  I agree, but in that case, why not switch to '1.7' Java
  source/target compliance for oVirt Maven build as well?
  
  If JDK6 cannot be used for building oVirt (because of missing Java
  7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also
  update our Maven POM files. Currently, when I import oVirt
  projects into Eclipse (using Eclipse Maven plugin), I'm getting
  compile errors on 'bll' project. This is because our Maven POM
  files declare '1.6' Java source/target compliance.
  
  Juan - you are right, but for me, it sounds quite strange to have
  '1.6' Java source/target compliance for Maven build, and use JDK7
  to do the build.
 
 Don't we need that (the source part) to avoid Java 7 syntax in GWT
 code?
 
  - Original Message -
  From: Yair Zaslavsky yzasl...@redhat.com
  To: engine-devel@ovirt.org
  Sent: Thursday, July 19, 2012 7:59:45 AM
  Subject: Re: [Engine-devel] java 1.6 compatibility no more?
  
  On 07/18/2012 08:21 PM, Juan Hernandez wrote:
  On 07/18/2012 06:33 PM, Vojtech Szocs wrote:
  In fact, for both backend and frontend, Maven effective POM
  contains:
 
  artifactIdmaven-compiler-plugin/artifactId
  configuration
source1.6/source
target1.6/target
  /configuration
 
  Therefore, according to Maven POM files, oVirt should be
  build-able using Java 6, but it's not. (?)
 
  These maven settings just tell the java compiler to accept Java 6
  syntax
  only and to generate a Java 6 compatible .class file format, but
  they
  don't restrict the set of APIs that can be used.
 
  The problem is in backend/manager/modules/bll:
  StorageDomainCommandBase class uses new Java 7 Long.compare()
  static method.
 
  I think we should decide if we want to be compliant with Java 7,
  or submit a patch that uses Java 6 API (Long.compareTo instance
  method).
 
  Vojtech
  
  As I previously emailed - JDK7 already fixed a known issue with
  ldap and
  DNS ,and made one of my patches at gerrit redundant.
  Why not enjoy the bug fixes?
  
 
 
  - Original Message -
  From: Laszlo Hornyak lhorn...@redhat.com
  To: engine-devel engine-devel@ovirt.org
  Cc: Vojtech Szocs vsz...@redhat.com
  Sent: Wednesday, July 18, 2012 5:43:34 PM
  Subject: java 1.6 compatibility no more?
 
  Hi,
 
  It may be a historic moment, but for a few hours oVirt engine is
  no longer building on java 1.6.
  Is this intentional?
 
  Laszlo
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
 
 
 
  
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
  
 
 
 --
 Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
 3ºD, 28016 Madrid, Spain
 Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - 

Re: [Engine-devel] java 1.6 compatibility no more?

[Allon Mureinik]

- Original Message -
 From: Laszlo Hornyak lhorn...@redhat.com
 To: Juan Hernandez jhern...@redhat.com
 Cc: engine-devel@ovirt.org
 Sent: Thursday, July 19, 2012 3:04:17 PM
 Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
 Hi,
 
 At the moment if you update the source and target settings of the
 compiler plugin to 1.7 in the root pom, the project will build fine,
 but some of the junit tests will fail. (some strange problem with
 bytecode manipulation see here
 http://code.google.com/p/powermock/issues/detail?id=355)

The real solution for this is to stop using powermock, an effort we've been 
pursuing for the last couple of months.
After merging a couple more patches that were already approved and just waiting 
for merge on the subject 
(http://gerrit.ovirt.org/#/c/6280/  http://gerrit.ovirt.org/#/c/6392/ - if 
one of the maintainers can lend a hand), 
we remain with two failures which both originate from the same place:
org.ovirt.engine.api.restapi.resource.BackendResourceDebugDetailTest
org.ovirt.engine.api.restapi.resource.BackendResourceInfoDetailTest

Both of these failures are due to powermocking in 
AbstractBackendResourceLoggingTest.
Basically, this test is used for testing that the logging in 
BaseBackendResource.detail(Throwable) method is done properly.
Not sure how useful this is (perhaps someone more familiar with REST-API can 
shed some insight?), but if this is the only thing preventing us from moving to 
jdk-7...
well..

 Moving only the source does not work, moving only the target
 leaves the junit tests failing.
 
 So as you see I have rejected my own patch :-)
 http://gerrit.ovirt.org/6447/
 
 Laszlo
 
 - Original Message -
  From: Juan Hernandez jhern...@redhat.com
  To: Vojtech Szocs vsz...@redhat.com
  Cc: engine-devel@ovirt.org
  Sent: Thursday, July 19, 2012 1:41:26 PM
  Subject: Re: [Engine-devel] java 1.6 compatibility no more?
  
  On 07/19/2012 01:39 PM, Yair Zaslavsky wrote:
   On 07/19/2012 02:31 PM, Vojtech Szocs wrote:
   Don't we need that (the source part) to avoid Java 7 syntax in
   GWT code?
  
   That's a very good point.
  
   In general, GWT compiler supports Java 5 syntax (note that there
   are no language changes between Java 5 and 6). For this reason,
   our frontend code should be compliant with Java 5. If someone
   uses new Java 7 language features in frontend code, GWT compiler
   will throw an error and the build will fail.
  
   So the 'Java 5 only' limitation applies to frontend code and any
   other code (e.g. shared modules) that is directly referenced by
   frontend code. This shouldn't affect the backend, however.
  
   We could do something like this:
  
   - let oVirt root POM declare source and target compliance to
   Java
   7
   - let frontend modules POM (frontend/webadmin/modules/pom.xml)
   declare source compliance to Java 5 (or 6)
  
   (note that target compliance can be left to Java 7 since
   frontend
   compilation results in JavaScript code)
  
   What do you think?
  
   Vojtech
   
   +1 - I really like this idea!
  
  +1 from me as well.
  
   - Original Message -
   From: Juan Hernandez jhern...@redhat.com
   To: Vojtech Szocs vsz...@redhat.com
   Cc: Yair Zaslavsky yzasl...@redhat.com,
   engine-devel@ovirt.org
   Sent: Thursday, July 19, 2012 11:01:00 AM
   Subject: Re: [Engine-devel] java 1.6 compatibility no more?
  
   On 07/19/2012 10:09 AM, Vojtech Szocs wrote:
   As I previously emailed - JDK7 already fixed a known issue
   with
   ldap and
   DNS ,and made one of my patches at gerrit redundant.
   Why not enjoy the bug fixes?
  
   I agree, but in that case, why not switch to '1.7' Java
   source/target compliance for oVirt Maven build as well?
  
   If JDK6 cannot be used for building oVirt (because of missing
   Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we
   should also update our Maven POM files. Currently, when I
   import
   oVirt projects into Eclipse (using Eclipse Maven plugin), I'm
   getting compile errors on 'bll' project. This is because our
   Maven POM files declare '1.6' Java source/target compliance.
  
   Juan - you are right, but for me, it sounds quite strange to
   have
   '1.6' Java source/target compliance for Maven build, and use
   JDK7 to do the build.
  
   Don't we need that (the source part) to avoid Java 7 syntax in
   GWT
   code?
  
   - Original Message -
   From: Yair Zaslavsky yzasl...@redhat.com
   To: engine-devel@ovirt.org
   Sent: Thursday, July 19, 2012 7:59:45 AM
   Subject: Re: [Engine-devel] java 1.6 compatibility no more?
  
   On 07/18/2012 08:21 PM, Juan Hernandez wrote:
   On 07/18/2012 06:33 PM, Vojtech Szocs wrote:
   In fact, for both backend and frontend, Maven effective POM
   contains:
  
   artifactIdmaven-compiler-plugin/artifactId
   configuration
 source1.6/source
 target1.6/target
   /configuration
  
   Therefore, according to Maven POM files, oVirt should be
   build-able using Java 6, but it's 

Re: [Engine-devel] java 1.6 compatibility no more?

[Allon Mureinik]

- Original Message -
 From: Ayal Baron aba...@redhat.com
 To: Itamar Heim ih...@redhat.com
 Cc: Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org, Allon 
 Mureinik amure...@redhat.com
 Sent: Sunday, July 22, 2012 8:34:32 PM
 Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
 
 
 - Original Message -
  On 07/22/2012 07:38 PM, Allon Mureinik wrote:
  
  
   - Original Message -
   From: Livnat Peer lp...@redhat.com
   To: Itamar Heim ih...@redhat.com, Michael Kublin
   mkub...@redhat.com
   Cc: Juan Hernandez jhern...@redhat.com,
   engine-devel@ovirt.org
   Sent: Sunday, July 22, 2012 9:50:47 AM
   Subject: Re: [Engine-devel] java 1.6 compatibility no more?
  
   On 21/07/12 15:15, Itamar Heim wrote:
   On 07/19/2012 03:34 PM, Ayal Baron wrote:
  
  
   - Original Message -
  
   On Jul 19, 2012, at 14:14 , Livnat Peer wrote:
  
   On 19/07/12 14:41, Juan Hernandez wrote:
   On 07/19/2012 01:39 PM, Yair Zaslavsky wrote:
   On 07/19/2012 02:31 PM, Vojtech Szocs wrote:
   Don't we need that (the source part) to avoid Java 7
   syntax
   in
   GWT code?
  
   That's a very good point.
  
   In general, GWT compiler supports Java 5 syntax (note
   that
   there
   are no language changes between Java 5 and 6). For this
   reason,
   our frontend code should be compliant with Java 5. If
   someone
   uses new Java 7 language features in frontend code, GWT
   compiler will throw an error and the build will fail.
  
   So the 'Java 5 only' limitation applies to frontend code
   and
   any
   other code (e.g. shared modules) that is directly
   referenced
   by
   frontend code. This shouldn't affect the backend,
   however.
  
   We could do something like this:
  
   - let oVirt root POM declare source and target compliance
   to
   Java 7
   - let frontend modules POM
   (frontend/webadmin/modules/pom.xml)
   declare source compliance to Java 5 (or 6)
  
   (note that target compliance can be left to Java 7 since
   frontend compilation results in JavaScript code)
  
   What do you think?
  
   Vojtech
  
   +1 - I really like this idea!
  
   +1 from me as well.
  
  
   There are two calls to make when it comes to JDK7
   (regardless
   of
   GWT -
   excuse me for taking this discussion some steps backwards)
  
   1. Are we running with JRE 7?
   The answer is yes we agreed on that a few months ago.
  
   2. Are we using code syntax which is incompatible with JDK6?
  
   I think the answer to the above should be no (at least for
   now
   -
   maybe
   until the next ovirt release?).
   +1
   exactly. Why starting with jdk6 incompatible constructs
   unless
   there
   is a good (or at least any) reason for them…
  
   +1
  
   +1 - there is merit keeping backward compatibility to allow
   comparing
   behavior while java 7 is still young.
  
   Since no one objected, we'll go with JDK6 syntax compatibility
   for
   Now.
   I'm a very small fan of enforcing policy by reviewers.
   Not that the community reviews aren't great - but people miss
   things.
  
   Here's my take on Maven's enforcer plugin to actually verify we
   aren't compiling with JDK 7:
   http://gerrit.ovirt.org/#/c/6523
  
  we don't want to enforce compilation or run with JDK 6, only to
  preserve
  backward compatibility.
  I'm for jenkins to have a job to compile and run unitests with
  openjdk 6
  to be on the safe side.
  
 
 Instead of enforcing the compilation to be run with a specific jdk we
 can enforce that the code is java 6 compatible with:
 
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-compiler-plugin/artifactId
 version2.0.2/version
 configuration
 source1.6/source
 target1.6/target
 /configuration
 /plugin

No, this is not the issue we're discussing.
The source and target configurations in the maven-compiler-plugin specify the 
language level compatibility (i.e., syntax) you're using.
This setting only means you won't be able to use Java 7 new syntactic 
constructs like catching multiple exceptions with the pipe operator and 
shorthand generics.
This has nothing to do with the JDK.
The JDK is just a collection of jars, like any other jar, which just happen to 
contain some fundamental classes like Object, String and Long.
Our case here is to force developers not use any methods/classes that aren't 
present in /JDK 6/.

Just to prove the point - if you take a look at lines 367-368 of the master 
pom.xml, 
you'll notice we already have these settings, and have had them since oVirt's 
git repo was created.

 
 
  
   comments welcome.
  
  
   Kublin - can you please send a patch to remove the usage of
   Long.Compare
   in StorageDomainCommandBase
  
   Thanks, Livnat
  
  
   ___
   Engine-devel mailing list
   Engine-devel@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/engine-devel
  
  
   ___
   Engine-devel mailing list

Re: [Engine-devel] java 1.6 compatibility no more?

[Allon Mureinik]

- Original Message -
 From: Itamar Heim ih...@redhat.com
 To: Allon Mureinik amure...@redhat.com
 Cc: Livnat Peer lp...@redhat.com, Juan Hernandez jhern...@redhat.com, 
 engine-devel@ovirt.org, Michael
 Kublin mkub...@redhat.com
 Sent: Sunday, July 22, 2012 7:41:00 PM
 Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
 On 07/22/2012 07:38 PM, Allon Mureinik wrote:
 
 
  - Original Message -
  From: Livnat Peer lp...@redhat.com
  To: Itamar Heim ih...@redhat.com, Michael Kublin
  mkub...@redhat.com
  Cc: Juan Hernandez jhern...@redhat.com, engine-devel@ovirt.org
  Sent: Sunday, July 22, 2012 9:50:47 AM
  Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
  On 21/07/12 15:15, Itamar Heim wrote:
  On 07/19/2012 03:34 PM, Ayal Baron wrote:
 
 
  - Original Message -
 
  On Jul 19, 2012, at 14:14 , Livnat Peer wrote:
 
  On 19/07/12 14:41, Juan Hernandez wrote:
  On 07/19/2012 01:39 PM, Yair Zaslavsky wrote:
  On 07/19/2012 02:31 PM, Vojtech Szocs wrote:
  Don't we need that (the source part) to avoid Java 7
  syntax
  in
  GWT code?
 
  That's a very good point.
 
  In general, GWT compiler supports Java 5 syntax (note that
  there
  are no language changes between Java 5 and 6). For this
  reason,
  our frontend code should be compliant with Java 5. If
  someone
  uses new Java 7 language features in frontend code, GWT
  compiler will throw an error and the build will fail.
 
  So the 'Java 5 only' limitation applies to frontend code
  and
  any
  other code (e.g. shared modules) that is directly
  referenced
  by
  frontend code. This shouldn't affect the backend, however.
 
  We could do something like this:
 
  - let oVirt root POM declare source and target compliance
  to
  Java 7
  - let frontend modules POM
  (frontend/webadmin/modules/pom.xml)
  declare source compliance to Java 5 (or 6)
 
  (note that target compliance can be left to Java 7 since
  frontend compilation results in JavaScript code)
 
  What do you think?
 
  Vojtech
 
  +1 - I really like this idea!
 
  +1 from me as well.
 
 
  There are two calls to make when it comes to JDK7 (regardless
  of
  GWT -
  excuse me for taking this discussion some steps backwards)
 
  1. Are we running with JRE 7?
  The answer is yes we agreed on that a few months ago.
 
  2. Are we using code syntax which is incompatible with JDK6?
 
  I think the answer to the above should be no (at least for now
  -
  maybe
  until the next ovirt release?).
  +1
  exactly. Why starting with jdk6 incompatible constructs unless
  there
  is a good (or at least any) reason for them…
 
  +1
 
  +1 - there is merit keeping backward compatibility to allow
  comparing
  behavior while java 7 is still young.
 
  Since no one objected, we'll go with JDK6 syntax compatibility for
  Now.
  I'm a very small fan of enforcing policy by reviewers.
  Not that the community reviews aren't great - but people miss
  things.
 
  Here's my take on Maven's enforcer plugin to actually verify we
  aren't compiling with JDK 7:
  http://gerrit.ovirt.org/#/c/6523
 
 we don't want to enforce compilation or run with JDK 6, only to
 preserve
 backward compatibility.
 I'm for jenkins to have a job to compile and run unitests with
 openjdk 6
 to be on the safe side.

I don't understand this suggestion.
What you're saying is that you can compile with whatever JDK you want, but:
- it won't compile with JDKs prior to 6, since we're using 6's features.
- you aren't allowed to use JDK 7 features, and if you do, you'll get an email 
from jenkins that you broke something and must fix it.

To me, this sounds a lot like enforcing JDK 6 compatibility.

/today/ if have way too many (i.e., 0) jenkins breaks, a lot of which could be 
avoided by not running with -DskipTetst or making sure to run with 
-Penable-dao-tests.
I fear this suggestion will just add to this noise, and could easily be 
avoided.

 
 
  comments welcome.
 
 
  Kublin - can you please send a patch to remove the usage of
  Long.Compare
  in StorageDomainCommandBase
 
  Thanks, Livnat
 
 
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
 
 
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
 
 
 
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] No more forking in bll tests

[Allon Mureinik]

Hi guys,

This morning a couple of patches were merged to remove Gluster's dependency on 
PowerMock (Shireesh and Selvasundaram - thanks for your commitment and 
involvement!).
Consequentially, there is no more need to fork bll's tests, so that too was 
removed.

Currently, bll's full build runs in just under 3 minutes (on my machine), and 
just under a minute for the test suite alone, without re-compiling the entire 
module.

Let's keep it this way - It is /NOT/ ok to add new usages of PowerMock.
The few leftoveres that are still there are being examined, and the PowerMock 
dependency will be removed once they are also gone.


Here's to speedy builds and agile development,
Allon

P.S.
A mega-huge thanks to everyone that was involved in this effort - Laszlo, Mike, 
Omer, Shireesh, Selvasundaram, and anyone else I may have forgotten by mistake.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] java 1.6 compatibility no more?

[Allon Mureinik]

- Original Message -
 From: Itamar Heim ih...@redhat.com
 To: Allon Mureinik amure...@redhat.com
 Cc: Livnat Peer lp...@redhat.com, Juan Hernandez jhern...@redhat.com, 
 engine-devel@ovirt.org, Michael
 Kublin mkub...@redhat.com
 Sent: Monday, July 23, 2012 8:43:02 AM
 Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
 On 07/23/2012 08:29 AM, Allon Mureinik wrote:
 
 
  - Original Message -
  From: Itamar Heim ih...@redhat.com
  To: Allon Mureinik amure...@redhat.com
  Cc: Livnat Peer lp...@redhat.com, Juan Hernandez
  jhern...@redhat.com, engine-devel@ovirt.org, Michael
  Kublin mkub...@redhat.com
  Sent: Sunday, July 22, 2012 7:41:00 PM
  Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
  On 07/22/2012 07:38 PM, Allon Mureinik wrote:
 
 
  - Original Message -
  From: Livnat Peer lp...@redhat.com
  To: Itamar Heim ih...@redhat.com, Michael Kublin
  mkub...@redhat.com
  Cc: Juan Hernandez jhern...@redhat.com,
  engine-devel@ovirt.org
  Sent: Sunday, July 22, 2012 9:50:47 AM
  Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
  On 21/07/12 15:15, Itamar Heim wrote:
  On 07/19/2012 03:34 PM, Ayal Baron wrote:
 
 
  - Original Message -
 
  On Jul 19, 2012, at 14:14 , Livnat Peer wrote:
 
  On 19/07/12 14:41, Juan Hernandez wrote:
  On 07/19/2012 01:39 PM, Yair Zaslavsky wrote:
  On 07/19/2012 02:31 PM, Vojtech Szocs wrote:
  Don't we need that (the source part) to avoid Java 7
  syntax
  in
  GWT code?
 
  That's a very good point.
 
  In general, GWT compiler supports Java 5 syntax (note
  that
  there
  are no language changes between Java 5 and 6). For this
  reason,
  our frontend code should be compliant with Java 5. If
  someone
  uses new Java 7 language features in frontend code, GWT
  compiler will throw an error and the build will fail.
 
  So the 'Java 5 only' limitation applies to frontend code
  and
  any
  other code (e.g. shared modules) that is directly
  referenced
  by
  frontend code. This shouldn't affect the backend,
  however.
 
  We could do something like this:
 
  - let oVirt root POM declare source and target compliance
  to
  Java 7
  - let frontend modules POM
  (frontend/webadmin/modules/pom.xml)
  declare source compliance to Java 5 (or 6)
 
  (note that target compliance can be left to Java 7 since
  frontend compilation results in JavaScript code)
 
  What do you think?
 
  Vojtech
 
  +1 - I really like this idea!
 
  +1 from me as well.
 
 
  There are two calls to make when it comes to JDK7
  (regardless
  of
  GWT -
  excuse me for taking this discussion some steps backwards)
 
  1. Are we running with JRE 7?
  The answer is yes we agreed on that a few months ago.
 
  2. Are we using code syntax which is incompatible with JDK6?
 
  I think the answer to the above should be no (at least for
  now
  -
  maybe
  until the next ovirt release?).
  +1
  exactly. Why starting with jdk6 incompatible constructs
  unless
  there
  is a good (or at least any) reason for them…
 
  +1
 
  +1 - there is merit keeping backward compatibility to allow
  comparing
  behavior while java 7 is still young.
 
  Since no one objected, we'll go with JDK6 syntax compatibility
  for
  Now.
  I'm a very small fan of enforcing policy by reviewers.
  Not that the community reviews aren't great - but people miss
  things.
 
  Here's my take on Maven's enforcer plugin to actually verify we
  aren't compiling with JDK 7:
  http://gerrit.ovirt.org/#/c/6523
 
  we don't want to enforce compilation or run with JDK 6, only to
  preserve
  backward compatibility.
  I'm for jenkins to have a job to compile and run unitests with
  openjdk 6
  to be on the safe side.
 
  I don't understand this suggestion.
  What you're saying is that you can compile with whatever JDK you
  want, but:
  - it won't compile with JDKs prior to 6, since we're using 6's
  features.
  - you aren't allowed to use JDK 7 features, and if you do, you'll
  get an email from jenkins that you broke something and must fix
  it.
 
  To me, this sounds a lot like enforcing JDK 6 compatibility.
 
 
 its preserving jdk 6 compatibility for a few more months, not
 enforcing
 to use jdk 6 compiler.
Fair enough.

 
  /today/ if have way too many (i.e., 0) jenkins breaks, a lot of
  which could be avoided by not running with -DskipTetst or making
  sure to run with -Penable-dao-tests.
  I fear this suggestion will just add to this noise, and could
  easily be avoided.
 
 jenkins breaks should be visible at patch level prior to commit,
 something we are trying to resolve by adding more hardware to allow
 running the various tests at patch level rather than post commit
 only.
I agree that this is an excellent goal, but I maintain that this is an 
uncomfortable way to work.
I would still like a way to check, on my own machine, as part of my compilation 
process, that I'm not doing anything I shouldn't.
Here's my second take on the issue, using Animal Sniffer 
(http

Re: [Engine-devel] java 1.6 compatibility no more?

[Allon Mureinik]

- Original Message -
 From: Juan Hernandez jhern...@redhat.com
 To: Allon Mureinik amure...@redhat.com
 Cc: Itamar Heim ih...@redhat.com, engine-devel@ovirt.org
 Sent: Monday, July 23, 2012 1:22:37 PM
 Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
 On 07/23/2012 11:46 AM, Allon Mureinik wrote:
  
  
  - Original Message -
  From: Itamar Heim ih...@redhat.com
  To: Allon Mureinik amure...@redhat.com
  Cc: Livnat Peer lp...@redhat.com, Juan Hernandez
  jhern...@redhat.com, engine-devel@ovirt.org, Michael
  Kublin mkub...@redhat.com
  Sent: Monday, July 23, 2012 8:43:02 AM
  Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
  On 07/23/2012 08:29 AM, Allon Mureinik wrote:
 
 
  - Original Message -
  From: Itamar Heim ih...@redhat.com
  To: Allon Mureinik amure...@redhat.com
  Cc: Livnat Peer lp...@redhat.com, Juan Hernandez
  jhern...@redhat.com, engine-devel@ovirt.org, Michael
  Kublin mkub...@redhat.com
  Sent: Sunday, July 22, 2012 7:41:00 PM
  Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
  On 07/22/2012 07:38 PM, Allon Mureinik wrote:
 
 
  - Original Message -
  From: Livnat Peer lp...@redhat.com
  To: Itamar Heim ih...@redhat.com, Michael Kublin
  mkub...@redhat.com
  Cc: Juan Hernandez jhern...@redhat.com,
  engine-devel@ovirt.org
  Sent: Sunday, July 22, 2012 9:50:47 AM
  Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
  On 21/07/12 15:15, Itamar Heim wrote:
  On 07/19/2012 03:34 PM, Ayal Baron wrote:
 
 
  - Original Message -
 
  On Jul 19, 2012, at 14:14 , Livnat Peer wrote:
 
  On 19/07/12 14:41, Juan Hernandez wrote:
  On 07/19/2012 01:39 PM, Yair Zaslavsky wrote:
  On 07/19/2012 02:31 PM, Vojtech Szocs wrote:
  Don't we need that (the source part) to avoid Java 7
  syntax
  in
  GWT code?
 
  That's a very good point.
 
  In general, GWT compiler supports Java 5 syntax (note
  that
  there
  are no language changes between Java 5 and 6). For this
  reason,
  our frontend code should be compliant with Java 5. If
  someone
  uses new Java 7 language features in frontend code, GWT
  compiler will throw an error and the build will fail.
 
  So the 'Java 5 only' limitation applies to frontend
  code
  and
  any
  other code (e.g. shared modules) that is directly
  referenced
  by
  frontend code. This shouldn't affect the backend,
  however.
 
  We could do something like this:
 
  - let oVirt root POM declare source and target
  compliance
  to
  Java 7
  - let frontend modules POM
  (frontend/webadmin/modules/pom.xml)
  declare source compliance to Java 5 (or 6)
 
  (note that target compliance can be left to Java 7
  since
  frontend compilation results in JavaScript code)
 
  What do you think?
 
  Vojtech
 
  +1 - I really like this idea!
 
  +1 from me as well.
 
 
  There are two calls to make when it comes to JDK7
  (regardless
  of
  GWT -
  excuse me for taking this discussion some steps backwards)
 
  1. Are we running with JRE 7?
  The answer is yes we agreed on that a few months ago.
 
  2. Are we using code syntax which is incompatible with
  JDK6?
 
  I think the answer to the above should be no (at least for
  now
  -
  maybe
  until the next ovirt release?).
  +1
  exactly. Why starting with jdk6 incompatible constructs
  unless
  there
  is a good (or at least any) reason for them…
 
  +1
 
  +1 - there is merit keeping backward compatibility to allow
  comparing
  behavior while java 7 is still young.
 
  Since no one objected, we'll go with JDK6 syntax compatibility
  for
  Now.
  I'm a very small fan of enforcing policy by reviewers.
  Not that the community reviews aren't great - but people miss
  things.
 
  Here's my take on Maven's enforcer plugin to actually verify we
  aren't compiling with JDK 7:
  http://gerrit.ovirt.org/#/c/6523
 
  we don't want to enforce compilation or run with JDK 6, only to
  preserve
  backward compatibility.
  I'm for jenkins to have a job to compile and run unitests with
  openjdk 6
  to be on the safe side.
 
  I don't understand this suggestion.
  What you're saying is that you can compile with whatever JDK you
  want, but:
  - it won't compile with JDKs prior to 6, since we're using 6's
  features.
  - you aren't allowed to use JDK 7 features, and if you do, you'll
  get an email from jenkins that you broke something and must fix
  it.
 
  To me, this sounds a lot like enforcing JDK 6 compatibility.
 
 
  its preserving jdk 6 compatibility for a few more months, not
  enforcing
  to use jdk 6 compiler.
  Fair enough.
  
 
  /today/ if have way too many (i.e., 0) jenkins breaks, a lot of
  which could be avoided by not running with -DskipTetst or making
  sure to run with -Penable-dao-tests.
  I fear this suggestion will just add to this noise, and could
  easily be avoided.
 
  jenkins breaks should be visible at patch level prior to commit,
  something we are trying to resolve by adding more hardware to
  allow
  running the various tests

Re: [Engine-devel] java 1.6 compatibility no more?

[Allon Mureinik]

- Original Message -
 From: Juan Hernandez jhern...@redhat.com
 To: Allon Mureinik amure...@redhat.com
 Cc: engine-devel@ovirt.org
 Sent: Monday, July 23, 2012 2:31:24 PM
 Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
 On 07/23/2012 01:02 PM, Allon Mureinik wrote:
  
  
  - Original Message -
  From: Juan Hernandez jhern...@redhat.com
  To: Allon Mureinik amure...@redhat.com
  Cc: Itamar Heim ih...@redhat.com, engine-devel@ovirt.org
  Sent: Monday, July 23, 2012 1:22:37 PM
  Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
  On 07/23/2012 11:46 AM, Allon Mureinik wrote:
 
 
  - Original Message -
  From: Itamar Heim ih...@redhat.com
  To: Allon Mureinik amure...@redhat.com
  Cc: Livnat Peer lp...@redhat.com, Juan Hernandez
  jhern...@redhat.com, engine-devel@ovirt.org, Michael
  Kublin mkub...@redhat.com
  Sent: Monday, July 23, 2012 8:43:02 AM
  Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
  On 07/23/2012 08:29 AM, Allon Mureinik wrote:
 
 
  - Original Message -
  From: Itamar Heim ih...@redhat.com
  To: Allon Mureinik amure...@redhat.com
  Cc: Livnat Peer lp...@redhat.com, Juan Hernandez
  jhern...@redhat.com, engine-devel@ovirt.org, Michael
  Kublin mkub...@redhat.com
  Sent: Sunday, July 22, 2012 7:41:00 PM
  Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
  On 07/22/2012 07:38 PM, Allon Mureinik wrote:
 
 
  - Original Message -
  From: Livnat Peer lp...@redhat.com
  To: Itamar Heim ih...@redhat.com, Michael Kublin
  mkub...@redhat.com
  Cc: Juan Hernandez jhern...@redhat.com,
  engine-devel@ovirt.org
  Sent: Sunday, July 22, 2012 9:50:47 AM
  Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
  On 21/07/12 15:15, Itamar Heim wrote:
  On 07/19/2012 03:34 PM, Ayal Baron wrote:
 
 
  - Original Message -
 
  On Jul 19, 2012, at 14:14 , Livnat Peer wrote:
 
  On 19/07/12 14:41, Juan Hernandez wrote:
  On 07/19/2012 01:39 PM, Yair Zaslavsky wrote:
  On 07/19/2012 02:31 PM, Vojtech Szocs wrote:
  Don't we need that (the source part) to avoid Java 7
  syntax
  in
  GWT code?
 
  That's a very good point.
 
  In general, GWT compiler supports Java 5 syntax (note
  that
  there
  are no language changes between Java 5 and 6). For
  this
  reason,
  our frontend code should be compliant with Java 5. If
  someone
  uses new Java 7 language features in frontend code,
  GWT
  compiler will throw an error and the build will fail.
 
  So the 'Java 5 only' limitation applies to frontend
  code
  and
  any
  other code (e.g. shared modules) that is directly
  referenced
  by
  frontend code. This shouldn't affect the backend,
  however.
 
  We could do something like this:
 
  - let oVirt root POM declare source and target
  compliance
  to
  Java 7
  - let frontend modules POM
  (frontend/webadmin/modules/pom.xml)
  declare source compliance to Java 5 (or 6)
 
  (note that target compliance can be left to Java 7
  since
  frontend compilation results in JavaScript code)
 
  What do you think?
 
  Vojtech
 
  +1 - I really like this idea!
 
  +1 from me as well.
 
 
  There are two calls to make when it comes to JDK7
  (regardless
  of
  GWT -
  excuse me for taking this discussion some steps
  backwards)
 
  1. Are we running with JRE 7?
  The answer is yes we agreed on that a few months ago.
 
  2. Are we using code syntax which is incompatible with
  JDK6?
 
  I think the answer to the above should be no (at least
  for
  now
  -
  maybe
  until the next ovirt release?).
  +1
  exactly. Why starting with jdk6 incompatible constructs
  unless
  there
  is a good (or at least any) reason for them…
 
  +1
 
  +1 - there is merit keeping backward compatibility to allow
  comparing
  behavior while java 7 is still young.
 
  Since no one objected, we'll go with JDK6 syntax
  compatibility
  for
  Now.
  I'm a very small fan of enforcing policy by reviewers.
  Not that the community reviews aren't great - but people miss
  things.
 
  Here's my take on Maven's enforcer plugin to actually verify
  we
  aren't compiling with JDK 7:
  http://gerrit.ovirt.org/#/c/6523
 
  we don't want to enforce compilation or run with JDK 6, only
  to
  preserve
  backward compatibility.
  I'm for jenkins to have a job to compile and run unitests with
  openjdk 6
  to be on the safe side.
 
  I don't understand this suggestion.
  What you're saying is that you can compile with whatever JDK
  you
  want, but:
  - it won't compile with JDKs prior to 6, since we're using 6's
  features.
  - you aren't allowed to use JDK 7 features, and if you do,
  you'll
  get an email from jenkins that you broke something and must fix
  it.
 
  To me, this sounds a lot like enforcing JDK 6 compatibility.
 
 
  its preserving jdk 6 compatibility for a few more months, not
  enforcing
  to use jdk 6 compiler.
  Fair enough.
 
 
  /today/ if have way too many (i.e., 0) jenkins breaks, a lot
  of
  which could be avoided by not running

Re: [Engine-devel] java 1.6 compatibility no more?

[Allon Mureinik]

- Original Message -
 From: Itamar Heim ih...@redhat.com
 To: Juan Hernandez jhern...@redhat.com
 Cc: Allon Mureinik amure...@redhat.com, engine-devel@ovirt.org
 Sent: Monday, July 23, 2012 2:44:02 PM
 Subject: Re: [Engine-devel] java 1.6 compatibility no more?
 
 On 07/23/2012 02:31 PM, Juan Hernandez wrote:
  Well, for me personally the price is actually zero, as I don't use
  the
  Eclipse maven support ;-) . But I know that many people hates when
  they
  try to import the projects and they get errors because of plugins
  that
  Eclipse doesn't understand. Let's see what they think.
 
 ovirt should load in eclipse without any error, and we are working on
 cleaning this up as it currently requires manual work to clean up the
 errors to work in eclipse (which i find less than friendly to new
 community members)
 
Agreed.
I didn't notice any problems in working in Eclipse (I use Juno) + Maven + this 
plugin,
but if anyone did, I'd appreciate the feedback.
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Building ovirt engine instructions

[Allon Mureinik]

Also, if you're using Eclipse Juno, you want to take a look at this gerrit 
topic:
http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:eclipse-juno-support,n,z

I found out the hard way Juno is a tad over-strict when it comes to parsing 
poms, and this may save you some trouble

- Original Message -
 From: Allon Mureinik amure...@redhat.com
 To: George Costea george.cos...@netapp.com
 Cc: engine-devel@ovirt.org
 Sent: Friday, July 27, 2012 9:04:11 PM
 Subject: Re: [Engine-devel] Building ovirt engine instructions
 
 Just had to reinstall and reconfigure Eclipse myself due to a yum
 upgrade misshap (kids, don't try this at home :-)), so here's some
 insight on the process.
 
 - Original Message -
  From: George Costea george.cos...@netapp.com
  To: Yair Zaslavsky yzasl...@redhat.com, engine-devel@ovirt.org
  Sent: Friday, July 27, 2012 2:03:14 PM
  Subject: Re: [Engine-devel] Building ovirt engine instructions
  
  I get to the step that reads, Change project settings to Resolve
  compilation errors.
  
  After completing the first 3 steps below:
  
  restapi-definition -  project -  properties - java build path
  -
   source -  add source folder -  target/generated-sources/xjc
 ack.
 
  webadmin -  project -  properties -  java build path - source
  -
   add source folder-
   target/generated-sources/{annotations,gwt,test-annotations}
 Eclipse Juno did this automatically for me, but yes, if it wasn't
 added automatically, you should add it.
 
  frontend -  project -  properties -  java build path - source
  -
   add source folder-  target/generated-sources/gwt
 Same as above.
 
  
  I am left with 181 Errors.  I then try the 4th step:
  
  frontend - project - properties - Projects - Add - webadmin
  
  This introduces 5 errors stating, A cycle was detected in the
  build
  path of project
  'frontend'/'gwt-common'/'uicommonweb'/'userportal'/'webadmin'.  The
  cycle consists of projects {frontend, webadmin, uicommonweb,
  gwt-common, userportal}
 Indeed - this step seems wrong. I will remove it from the wiki page.
 
  
  I then try the 5th step:
  
  sharedgwt - project - properties - Projects - Add - common
  
 It was indeed removed - skip to the next stage regarding uicompat.
 
 Also, there are steps missing (I'll add them to the wiki):
 gwt-extensios - add anything under target/generated-sources
 gwt-common - add target/generated-sources/annotations; also add
 depdendency on uicommon-web, common and compat
 uicompat - add target/generated-sources/annotations
 generic-api - add dependencies on common, compat and utils
 
  But there is no sharedgwt project.  Does this provide enough
  detail?
  
  -Original Message-
  From: engine-devel-boun...@ovirt.org
  [mailto:engine-devel-boun...@ovirt.org] On Behalf Of Yair Zaslavsky
  Sent: Friday, July 27, 2012 1:13 AM
  To: engine-devel@ovirt.org
  Subject: Re: [Engine-devel] Building ovirt engine instructions
  
  On 07/27/2012 12:58 AM, Costea, George wrote:
   It works fine from the CLI (I was running out of memory).  I'm
   still getting an issue with Eclipse though about a cycle being
   detected from the build path.
  
  Please elaborate on this cyclic dependency (I guess this is the
  issue,
  right?)
  
  What matters the most is that you can build from CLI.
  Some of the oVirt engine mantainers do not build from Eclipse (I
  personally find the maven plugin to be too buggy) , but it's a
  matter of personal preference. We will try to help you regardlessly
  
  Yair
  
  
   -Original Message-
   From: Oved Ourfalli [mailto:ov...@redhat.com]
   Sent: Thursday, July 26, 2012 5:34 PM
   To: Costea, George
   Cc: engine-devel@ovirt.org
   Subject: Re: [Engine-devel] Building ovirt engine instructions
  
  
  
   - Original Message -
   From: George Costeageorge.cos...@netapp.com
   To: engine-devel@ovirt.org
   Sent: Thursday, July 26, 2012 11:33:04 PM
   Subject: [Engine-devel] Building ovirt engine instructions
  
  
  
  
  
   I think the wiki page (
   http://wiki.ovirt.org/wiki/Building_Ovirt_Engine ) to build the
   ovirt
   engine is outdated. When I reach the deploy section, it always
   fails.
   Is there an update to get the ear file deployed?
  
  
   Can you elaborate more on the issue? What's the exact
   failure/error
   you see when deploying?
  
  
   The Eclipse instructions (
   http://wiki.ovirt.org/wiki/Building_Ovirt_Engine/IDE ) also seem
   to
   be out of date. When I follow the steps to change project
   settings, I
   get an error stating that “A cycle was detected in the build
   path
   of
   the project...” Could we get an update on this too?
  
  
  
   Thanks,
  
   George
  
  
   ___
   Engine-devel mailing list
   Engine-devel@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/engine-devel
  
   ___
   Engine-devel

[Engine-devel] Conformining to Java 6 using Animal Sniffer

[Allon Mureinik]

Hi guys,

As you may recall, a couple of weeks ago it was decided (in this mailing list), 
that we want to preserve backwards compatibility to Java 6.
Instead of having to install JDK 6 alongside your Java 7, you can now use 
Animal Sniffer[1] to verify this.

Simply run mvn animal-sniffer:check before you push, and assuming the build 
is successful, you're good to go.

Note: Animal Sniffer takes about a minute to run, so it was NOT added by 
default to the install target.
It is still your responsibility to verify backwards compatibility of you code, 
this is just a convenient way of doing it.

Many thanks to Juan and Doron for their insights and reviews for this patch.

-Allon

[1] http://mojo.codehaus.org/animal-sniffer-maven-plugin/
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Reminder - common

[Allon Mureinik]

Roy is working on a way to prevent this from happening:
http://gerrit.ovirt.org/#/c/6785/

- Original Message -
 From: Yair Zaslavsky yzasl...@redhat.com
 To: engine-devel@ovirt.org
 Sent: Tuesday, July 31, 2012 10:58:37 AM
 Subject: [Engine-devel] Reminder - common
 
 Hi,
 Please do not insert projects to pom.xml which do not compile by both
 engine core and gwt.
 
 Thanks,
 Yair
 
 
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

[Engine-devel] Serial Execution of Async Tasks

[Allon Mureinik]

Hi guys,

As you may know the engine currently has the ability to fire an SPM task, and 
be asynchronously be woken-up when it ends. 
This is great, but we found the for the Live Storage Migration feature we need 
something a bit complex - the ability to have a series of async tasks in a 
single control flow.

Here's my initial design for this, your comments and criticism would be welcome:
http://wiki.ovirt.org/wiki/Features/Serial_Execution_of_Asynchronous_Tasks_Detailed_Design


-Allon
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Unifying (parts of) commit templates.

[Allon Mureinik]

- Original Message -
 From: Livnat Peer lp...@redhat.com
 To: Itamar Heim ih...@redhat.com
 Cc: engine-devel@ovirt.org
 Sent: Thursday, August 9, 2012 11:54:38 AM
 Subject: Re: [Engine-devel] Unifying (parts of) commit templates.
 
 On 09/08/12 11:52, Itamar Heim wrote:
  On 08/09/2012 09:11 AM, Livnat Peer wrote:
  On 09/08/12 00:41, Doron Fediuck wrote:
  Hi All,
  It seems that for commit subjects, vdsm is using a general
  concept of-
 
  BZ#??? some message
 
  I'd like to suggest adopting it to the engine template we use
  today-
 
  BZ#??? core | restapi | tools | history | engine |
  userportal |
  webadmin: short summary under 50 chars
 
  This may help us write some scripts which will work both for vdsm
  and
  engine BZs.
 
 
  +1
  with a small change - adding a \n after the bz number -
  
  wouldn't this kill git shortlog?
  patch short summary must be in first line iirc
  
 
 yes it will.
 +1 for Doron's initial proposal
+1.
Also, while we're at it, a wiki explaining the correct way to use this template 
would be great.
I know, it's pretty straight forward, but new contributed may get confused as 
to the distinction between core and engine, or how to mark a vertical patch 
that fixes a UI dialog and the backend logic behind it (with a coma between 
components? a slash? a pipe?)
 
  BZ#???
  core | restapi | tools | history | engine | userportal |
  webadmin:
  short summary under 50 chars
 
  Long description of what this commit is about
 
  Livnat
 
  Doron.
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
 
 
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
 
  
  
 
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Serial Execution of Async Tasks

[Allon Mureinik]

Hi guys,

Thanks for all your comments!
The correct response for many these points is to update the wiki.
I'm enclosing here the quick-and-dirty replies just to keep this thread alive, 
and will update the wiki shortly.

See inline.

- Original Message -
 From: Livnat Peer lp...@redhat.com
 To: Allon Mureinik amure...@redhat.com
 Cc: Eli Mesika emes...@redhat.com, Liron Aravot lara...@redhat.com, 
 Federico Simoncelli
 fsimo...@redhat.com, engine-devel engine-devel@ovirt.org, Eduardo 
 Warszawski ewars...@redhat.com, Yeela
 Kaplan ykap...@redhat.com
 Sent: Sunday, August 12, 2012 9:39:23 AM
 Subject: Re: [Engine-devel] Serial Execution of Async Tasks
 
 On 10/08/12 03:40, Eli Mesika wrote:
  
  
  - Original Message -
  From: Allon Mureinik amure...@redhat.com
  To: engine-devel engine-devel@ovirt.org
  Cc: Eduardo Warszawski ewars...@redhat.com, Yeela Kaplan
  ykap...@redhat.com, Federico Simoncelli
  fsimo...@redhat.com, Liron Aravot lara...@redhat.com
  Sent: Thursday, August 9, 2012 6:41:09 PM
  Subject: [Engine-devel] Serial Execution of Async Tasks
 
  Hi guys,
 
  As you may know the engine currently has the ability to fire an
  SPM
  task, and be asynchronously be woken-up when it ends.
  This is great, but we found the for the Live Storage Migration
  feature we need something a bit complex - the ability to have a
  series of async tasks in a single control flow.
 
  Here's my initial design for this, your comments and criticism
  would
  be welcome:
  http://wiki.ovirt.org/wiki/Features/Serial_Execution_of_Asynchronous_Tasks_Detailed_Design
  
  Apart from the short explanation  flow , since this is a detailed
  design , I would add
  1) Class diagram
  2) Flow diagram
Good idea, I'll see if I can jimmy something up.

  
 
 +1, it would help understanding the flow.
 
 - It looks like you chose not re-use/extend the ExecutionHandler (the
 entity used for building the tasks view exposed to the users).
 It might be a good idea to keep the separation between the engine
 Jobs
 and the underlying vdsm tasks, but I want to make sure you are
 familiar
 with this mechanism and ruled it out with a reason. If this is the
 case
 please share why you decided not to use it.
As you said Jobs and Steps are pure engine entities - they can contain no VDSM 
tasks, one VDSM task, or plausibly, in the future, several tasks.
Even /today/, AsyncTasks and Jobs/Steps are two different kinds of animals - I 
don't see any added value in mixing them together.

 
 
 - how does this design survives a jboss restart? Can you please a
 section in the wiki to explain that.
Basically, the way as a Command does today - the task is saved with the 
executionIndex, and continues when the command is woken up.
I'll clarify this point in the wiki.

 
 -successful execution -
 * CommandBase iterates over its SPMAsyncTaskHandlers - when?
This is the new suggested format of executeCommand(). I'll clarify this too.

 * If the second task is an HSM command (vs. SPM command), I think you
 should explain in the design how to handle such flows as well.
HSM commands do not create AsyncTasks, as they do today - I will clarify this.

 * Why do we need before task? can you give a concrete example of what
 would you do in such a method.
Basically, /today/, command look like this:
executeCommand() {
  doStuffInTheDB();
  runVdsCommand(someCommand);
}

endSuccessfully() {
  doMoreStuffInTheDB();
}

endWithFailure() {
  doMoreStuffForFailureInTheDB();
}

In the new design, the entire doStuffInTheDB() should be moved to a breforeTask 
of the (only) SPMAsyncTaskHandler.

 
 - I see you added SPMAsyncTaskHandler, any reason not to use
 SPMAsyncTasK to manage it own life-cycle?
Conserving today's design - The SPMAsyncTaskHandler is the place to add 
additional, non-SPM, logic around the SPM task execution, like CommandBase 
allows today.

 
 - In the life-cycle managed by the SPMAsyncTaskHandler there is a
 step
 'createTask - how to create the async task' can you please elaborate
 what are the options.
new [any type of async task]
 
 
 
 
 
 Livnat
 
 
 
  -Allon
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
 
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
  
 
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Any way to break the dao_unit_tests up?

[Allon Mureinik]

- Original Message -
 From: Mike Kolesnik mkole...@redhat.com
 To: Shireesh Anjal san...@redhat.com
 Cc: engine-devel@ovirt.org, infra in...@ovirt.org
 Sent: Tuesday, August 21, 2012 9:43:23 AM
 Subject: Re: [Engine-devel] Any way to break the dao_unit_tests up?
 
 - Original Message -
  On Monday 20 August 2012 11:16 AM, Mike Kolesnik wrote:
   - Original Message -
   The DAO unit tests take twice as long as the rest of the test to
   run
   is
   there any way to break them up into two pieces?
  
   It will not be easy..
  
   The way the tests are built today is with DB-unit.
   DB-unit allows to have an XML file with predefined data (called
   fixtures) which is used to recreate the DB data each time a
   test-class is run.
  
   This is all fine, except that in our tests there are (at least) 2
   issues:
 1. The same fixtures.xml file is used in all DAO tests.
 2. Some DAOs require fixtures for several tables.
  
   Now, we could fix issue #1 by splitting the fixtures file into
   smaller files, each relating to only one table, which would allow
   us to run these tests in parallel on the same DB.
   Issue #2 would require to figure out which tests require several
   fixtures, and have them run isolated from the other tests which
   require only a single table.
  
   A simpler solution could be to have the tests run each on it's
   own
   db schema (or it's own db) which eliminates the dependencies and
   allows to run all in parallel, but is a bit more complicated to
   maintain (we would need some script that generates these
   schemas/dbs for tests automatically) and keeping multiple schemas
   up to date would also require CPU time.
  
   This is speaking in terms of the tests themselves, without
   considering the build process itself.
  
  There are two issues here:
  
  1) DB connection is created during initialization of every test
  case,
  and destroyed at the end of each test case execution
  2) The fixtures data is inserted during initialization of every
  test
  case
  
  I think both of these can be resolved by
- creating the test data only during initialization of the first
test
  case, which will include creating the connection (with auto-commit
  =
  false), inserting fixtures data and committing it
- rolling back any changes done to the database during test case
  execution in the tearDown method
  
  I just tried this in two phases. Using the same connection across
  all
  test cases brought down the dao unit tests run time from 4:42.683s
  to
  1:07.628s, and inserting the fixtures data only once further
  brought
  it
  down to just 22.295s ! (on my local development machine)
  
  I've just sent a patch with these changes:
  http://gerrit.ovirt.org/7336
 
 Patch merged,
 
 Thanks Shireesh for the contribution, now the DAO tests are super
 fast!
20-something seconds to run DAO tests?
awesome!
Kudos, Shireesh!
 
  
  
   --
   Thanks
   Robert Middleswarth
   @rmiddle (twitter/IRC)
  
   ___
   Engine-devel mailing list
   Engine-devel@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/engine-devel
  
   ___
   Engine-devel mailing list
   Engine-devel@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/engine-devel
  
  
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Serial Execution of Async Tasks

[Allon Mureinik]

- Original Message -
 From: Allon Mureinik amure...@redhat.com
 To: Livnat Peer lp...@redhat.com
 Cc: Eli Mesika emes...@redhat.com, Liron Aravot lara...@redhat.com, 
 Federico Simoncelli
 fsimo...@redhat.com, engine-devel engine-devel@ovirt.org, Eduardo 
 Warszawski ewars...@redhat.com, Yeela
 Kaplan ykap...@redhat.com
 Sent: Tuesday, August 14, 2012 2:10:55 PM
 Subject: Re: [Engine-devel] Serial Execution of Async Tasks
 
 Hi guys,
 
 Thanks for all your comments!
 The correct response for many these points is to update the wiki.
 I'm enclosing here the quick-and-dirty replies just to keep this
 thread alive, and will update the wiki shortly.
 
 See inline.
 
 - Original Message -
  From: Livnat Peer lp...@redhat.com
  To: Allon Mureinik amure...@redhat.com
  Cc: Eli Mesika emes...@redhat.com, Liron Aravot
  lara...@redhat.com, Federico Simoncelli
  fsimo...@redhat.com, engine-devel engine-devel@ovirt.org,
  Eduardo Warszawski ewars...@redhat.com, Yeela
  Kaplan ykap...@redhat.com
  Sent: Sunday, August 12, 2012 9:39:23 AM
  Subject: Re: [Engine-devel] Serial Execution of Async Tasks
  
  On 10/08/12 03:40, Eli Mesika wrote:
   
   
   - Original Message -
   From: Allon Mureinik amure...@redhat.com
   To: engine-devel engine-devel@ovirt.org
   Cc: Eduardo Warszawski ewars...@redhat.com, Yeela Kaplan
   ykap...@redhat.com, Federico Simoncelli
   fsimo...@redhat.com, Liron Aravot lara...@redhat.com
   Sent: Thursday, August 9, 2012 6:41:09 PM
   Subject: [Engine-devel] Serial Execution of Async Tasks
  
   Hi guys,
  
   As you may know the engine currently has the ability to fire an
   SPM
   task, and be asynchronously be woken-up when it ends.
   This is great, but we found the for the Live Storage Migration
   feature we need something a bit complex - the ability to have a
   series of async tasks in a single control flow.
  
   Here's my initial design for this, your comments and criticism
   would
   be welcome:
   http://wiki.ovirt.org/wiki/Features/Serial_Execution_of_Asynchronous_Tasks_Detailed_Design
   
   Apart from the short explanation  flow , since this is a
   detailed
   design , I would add
   1) Class diagram
   2) Flow diagram
 Good idea, I'll see if I can jimmy something up.
 
   
  
  +1, it would help understanding the flow.
  
  - It looks like you chose not re-use/extend the ExecutionHandler
  (the
  entity used for building the tasks view exposed to the users).
  It might be a good idea to keep the separation between the engine
  Jobs
  and the underlying vdsm tasks, but I want to make sure you are
  familiar
  with this mechanism and ruled it out with a reason. If this is the
  case
  please share why you decided not to use it.
 As you said Jobs and Steps are pure engine entities - they can
 contain no VDSM tasks, one VDSM task, or plausibly, in the future,
 several tasks.
 Even /today/, AsyncTasks and Jobs/Steps are two different kinds of
 animals - I don't see any added value in mixing them together.
 
  
  
  - how does this design survives a jboss restart? Can you please a
  section in the wiki to explain that.
 Basically, the way as a Command does today - the task is saved with
 the executionIndex, and continues when the command is woken up.
 I'll clarify this point in the wiki.
Added to the wiki.
 
  
  -successful execution -
  * CommandBase iterates over its SPMAsyncTaskHandlers - when?
 This is the new suggested format of executeCommand(). I'll clarify
 this too.
Added to the wiki.

  * If the second task is an HSM command (vs. SPM command), I think
  you
  should explain in the design how to handle such flows as well.
 HSM commands do not create AsyncTasks, as they do today - I will
 clarify this.
Added to the wiki.

 
  * Why do we need before task? can you give a concrete example of
  what
  would you do in such a method.
 Basically, /today/, command look like this:
 executeCommand() {
   doStuffInTheDB();
   runVdsCommand(someCommand);
 }
 
 endSuccessfully() {
   doMoreStuffInTheDB();
 }
 
 endWithFailure() {
   doMoreStuffForFailureInTheDB();
 }
 
 In the new design, the entire doStuffInTheDB() should be moved to a
 breforeTask of the (only) SPMAsyncTaskHandler.
 
  
  - I see you added SPMAsyncTaskHandler, any reason not to use
  SPMAsyncTasK to manage it own life-cycle?
 Conserving today's design - The SPMAsyncTaskHandler is the place to
 add additional, non-SPM, logic around the SPM task execution, like
 CommandBase allows today.
 
  
  - In the life-cycle managed by the SPMAsyncTaskHandler there is a
  step
  'createTask - how to create the async task' can you please
  elaborate
  what are the options.
 new [any type of async task]
  
  
  
  
  
  Livnat
  
  
  
   -Allon
   ___
   Engine-devel mailing list
   Engine-devel@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/engine-devel
  
   ___
   Engine-devel mailing list
   Engine-devel

Re: [Engine-devel] Serial Execution of Async Tasks

[Allon Mureinik]

- Original Message -
 From: Maor Lipchuk mlipc...@redhat.com
 To: Itamar Heim ih...@redhat.com
 Cc: Allon Mureinik amure...@redhat.com, engine-devel 
 engine-devel@ovirt.org, Eduardo Warszawski
 ewars...@redhat.com, Yeela Kaplan ykap...@redhat.com, Federico 
 Simoncelli fsimo...@redhat.com, Liron
 Aravot lara...@redhat.com
 Sent: Thursday, August 16, 2012 8:27:33 PM
 Subject: Re: [Engine-devel] Serial Execution of Async Tasks
 
 On 08/16/2012 06:51 PM, Itamar Heim wrote:
  On 08/16/2012 03:21 PM, Maor Lipchuk wrote:
  On 08/14/2012 05:23 PM, Itamar Heim wrote:
  On 08/14/2012 02:35 PM, Maor Lipchuk wrote:
  How should we handle the auditLogMessages?
  Basically when a command ends it print an audit log.
 
  When we will start to use multiple tasks I assume user might get
  a bulk
  of audit logs which are actually related to the same action
  (when we
  fail for example the process will be create and delete).
  It might be a bit confusing for the user not to know which
  action is
  related to the operation
 
  I thought audit log gets written regardless of the transaction,
  so audit
  log appears as they happen?
  That is correct,
  The issue that I was referring to, is that now, with multiple
  tasks
  execution, we will get many audit logs which related to the same
  transaction but each one will be printed at a different time.
 
  I think that it might be confusing for the user to relate each
  audit log
  to the operation that was started.
 
 
  For example :
  User run an action that executes some tasks of create volumes,
  then the engine encounter a problem, and decide to rollback the
  operation and delete the volumes, in that case the engine will
  execute a
  delete task for the volumes, so user might see that delete of the
  volume
  (for example a snapshot) was initiated.
  Since those are asynchronous tasks, audit log will be printed in a
  different period of time and a user might not be aware what is the
  relation of those specific delete.
  
  async doesn't mean we don't print an audit log when we start it,
  and
  when we end it.
  so user would get the starting audit log when the task failed in
  your
  example. of course this may happen 2 hours after they started the
  task.
  as long as we can correlate the audit log to be part of the same
  job,
  i don't see the issue.
 yes, but if I understood correctly, we don't want to correlate the
 multiple tasks with the execution handler (which AFAIK handle the
 correlation id).
I actually didn't mention this, but I don't see why not.
What's I'd probably like to have is a log with Correlation ID xyzabc, step #3 
starting/executing/ending
Does this make any sense?
 
 I assume this issue can be addressed in a future phase,
 but maybe it is an issue that might worth to think about.
  
 
 
  Maybe we will need to use the correlation id of the Execution
  handler as
  Eli suggested or maybe add new states at CommandActionState?
 
  On 08/14/2012 02:10 PM, Allon Mureinik wrote:
  Hi guys,
 
  Thanks for all your comments!
  The correct response for many these points is to update the
  wiki.
  I'm enclosing here the quick-and-dirty replies just to keep
  this
  thread alive, and will update the wiki shortly.
 
  See inline.
 
  - Original Message -
  From: Livnat Peer lp...@redhat.com
  To: Allon Mureinik amure...@redhat.com
  Cc: Eli Mesika emes...@redhat.com, Liron Aravot
  lara...@redhat.com, Federico Simoncelli
  fsimo...@redhat.com, engine-devel
  engine-devel@ovirt.org,
  Eduardo Warszawski ewars...@redhat.com, Yeela
  Kaplan ykap...@redhat.com
  Sent: Sunday, August 12, 2012 9:39:23 AM
  Subject: Re: [Engine-devel] Serial Execution of Async Tasks
 
  On 10/08/12 03:40, Eli Mesika wrote:
 
 
  - Original Message -
  From: Allon Mureinik amure...@redhat.com
  To: engine-devel engine-devel@ovirt.org
  Cc: Eduardo Warszawski ewars...@redhat.com, Yeela
  Kaplan
  ykap...@redhat.com, Federico Simoncelli
  fsimo...@redhat.com, Liron Aravot lara...@redhat.com
  Sent: Thursday, August 9, 2012 6:41:09 PM
  Subject: [Engine-devel] Serial Execution of Async Tasks
 
  Hi guys,
 
  As you may know the engine currently has the ability to fire
  an
  SPM
  task, and be asynchronously be woken-up when it ends.
  This is great, but we found the for the Live Storage
  Migration
  feature we need something a bit complex - the ability to
  have a
  series of async tasks in a single control flow.
 
  Here's my initial design for this, your comments and
  criticism
  would
  be welcome:
  http://wiki.ovirt.org/wiki/Features/Serial_Execution_of_Asynchronous_Tasks_Detailed_Design
 
 
 
  Apart from the short explanation  flow , since this is a
  detailed
  design , I would add
  1) Class diagram
  2) Flow diagram
  Good idea, I'll see if I can jimmy something up.
 
 
 
  +1, it would help understanding the flow.
 
  - It looks like you chose not re-use/extend the
  ExecutionHandler (the
  entity used for building the tasks view exposed

Re: [Engine-devel] Serial Execution of Async Tasks

[Allon Mureinik]

- Original Message -
 From: Yair Zaslavsky yzasl...@redhat.com
 To: Eli Mesika emes...@redhat.com
 Cc: Liron Aravot lara...@redhat.com, Federico Simoncelli 
 fsimo...@redhat.com, engine-devel
 engine-devel@ovirt.org, Eduardo Warszawski ewars...@redhat.com, Yeela 
 Kaplan ykap...@redhat.com, Allon
 Mureinik amure...@redhat.com
 Sent: Friday, August 10, 2012 10:48:16 PM
 Subject: Re: [Engine-devel] Serial Execution of Async Tasks
 
 
 
 - Original Message -
 From: Eli Mesika emes...@redhat.com
 To: Allon Mureinik amure...@redhat.com
 Cc: Liron Aravot lara...@redhat.com, Federico Simoncelli
 fsimo...@redhat.com, engine-devel engine-devel@ovirt.org,
 Eduardo Warszawski ewars...@redhat.com, Yeela Kaplan
 ykap...@redhat.com
 Sent: Friday, August 10, 2012 3:40:48 AM
 Subject: Re: [Engine-devel] Serial Execution of Async Tasks
 
 
 
 - Original Message -
  From: Allon Mureinik amure...@redhat.com
  To: engine-devel engine-devel@ovirt.org
  Cc: Eduardo Warszawski ewars...@redhat.com, Yeela Kaplan
  ykap...@redhat.com, Federico Simoncelli
  fsimo...@redhat.com, Liron Aravot lara...@redhat.com
  Sent: Thursday, August 9, 2012 6:41:09 PM
  Subject: [Engine-devel] Serial Execution of Async Tasks
  
  Hi guys,
  
  As you may know the engine currently has the ability to fire an SPM
  task, and be asynchronously be woken-up when it ends.
  This is great, but we found the for the Live Storage Migration
  feature we need something a bit complex - the ability to have a
  series of async tasks in a single control flow.
  
  Here's my initial design for this, your comments and criticism
  would
  be welcome:
  http://wiki.ovirt.org/wiki/Features/Serial_Execution_of_Asynchronous_Tasks_Detailed_Design
 
 Apart from the short explanation  flow , since this is a detailed
 design , I would add
 1) Class diagram
 2) Flow diagram
 
 +1
 I am also interested to get a flow how a task is created (i.e -
 replacement of ConcreateCreateTask) - but this will be handled in
 what Eli has asked for.
 
 In addition, you have two titles of  Successful Execution.
Fixed.

 At compensate - see how revertTasks currently behaves.
 Also read -
 http://wiki.ovirt.org/wiki/Main_Page/features/RunningCommandsOnEndActionFailure
 
 This is the work I did for CloneVmFromSnapshot - not saying it's
 perfect - but you should have an infrastructure/pattern to rollback
 not just via spmRevertTask but also using an engine command.
This is what the endWithFailure does - or am I missing your point?
 
 Yair
 
 
 
  
  
  -Allon
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
  
 ___
 Engine-devel mailing list
 Engine-devel@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Serial Execution of Async Tasks

[Allon Mureinik]

- Original Message -
 From: Eli Mesika emes...@redhat.com
 To: Allon Mureinik amure...@redhat.com
 Cc: Eduardo Warszawski ewars...@redhat.com, Yeela Kaplan 
 ykap...@redhat.com, Federico Simoncelli
 fsimo...@redhat.com, Liron Aravot lara...@redhat.com, engine-devel 
 engine-devel@ovirt.org
 Sent: Friday, August 10, 2012 3:40:48 AM
 Subject: Re: [Engine-devel] Serial Execution of Async Tasks
 
 
 
 - Original Message -
  From: Allon Mureinik amure...@redhat.com
  To: engine-devel engine-devel@ovirt.org
  Cc: Eduardo Warszawski ewars...@redhat.com, Yeela Kaplan
  ykap...@redhat.com, Federico Simoncelli
  fsimo...@redhat.com, Liron Aravot lara...@redhat.com
  Sent: Thursday, August 9, 2012 6:41:09 PM
  Subject: [Engine-devel] Serial Execution of Async Tasks
  
  Hi guys,
  
  As you may know the engine currently has the ability to fire an SPM
  task, and be asynchronously be woken-up when it ends.
  This is great, but we found the for the Live Storage Migration
  feature we need something a bit complex - the ability to have a
  series of async tasks in a single control flow.
  
  Here's my initial design for this, your comments and criticism
  would
  be welcome:
  http://wiki.ovirt.org/wiki/Features/Serial_Execution_of_Asynchronous_Tasks_Detailed_Design
 
 Apart from the short explanation  flow , since this is a detailed
 design , I would add
 1) Class diagram
Done
 2) Flow diagram
 
  
  
  -Allon
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
  
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel