[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

[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: [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] 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] [ 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 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] 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 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

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] 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] [ 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] [ 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]

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 ] [ 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

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]

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]

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-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 ] [ 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

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

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] [ 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] [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

[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] 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

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] 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

[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

[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] 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] 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] 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] 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

[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

[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] 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

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]

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]

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] 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

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] 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] [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

[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] 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

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: 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

[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] 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

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] 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] 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] [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] [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] [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] [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: [Engine-devel] Proposing Liron Aravot as an engine-core maintainer

[Allon Mureinik]

- Original Message -
 From: Tal Nisan tni...@redhat.com
 To: Itamar Heim ih...@redhat.com, Livnat Peer lp...@redhat.com, Omer 
 Frenkel ofren...@redhat.com, Doron
 Fediuck dfedi...@redhat.com, Yair Zaslavsky yzasl...@redhat.com, Maor 
 Lipchuk mlipc...@redhat.com, Roy
 Golan rgo...@redhat.com, Eli Mesika emes...@redhat.com, Mike 
 Kolesnik mkole...@redhat.com, Moti Asayag
 masa...@redhat.com, Shahar Havivi shav...@redhat.com, ov...@redhat.com, 
 Allon Mureinik amure...@redhat.com
 Cc: engine-devel engine-devel@ovirt.org, in...@ovirt.org
 Sent: Sunday, January 26, 2014 2:47:30 PM
 Subject: Proposing Liron Aravot as an engine-core maintainer
 
 Hi core maintainers,
 
 I would like to propose Liron Aravot as an engine-core maintainer.
 
 Liron joined the oVirt project on June 2012, and has since contributed
 over 170 patches to master (not counting backports to various stable
 branches).
 
 He has been instrumental in implementing oVirt's Backup API for external
 providers, and has a been a driving force in improving flows regarding
 SPM election and master domain reconstruction, handling OVF backups and
 various concurrency issues both as a coder and a reviewer.
 
 Your response would be appreciated.

I've worked with Liron since the very first day he joined oVirt and have been 
impressed by his analytic capabilities and by his keen sense for detail on more 
than one occasion.

+1, full-heartedly. 

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

Re: [Engine-devel] IMPORTANT: FindBugs threshold update

[Allon Mureinik]

- Original Message -
 From: Moti Asayag masa...@redhat.com
 To: Yair Zaslavsky yzasl...@redhat.com
 Cc: Oved Ourfalli ov...@redhat.com, engine-devel 
 engine-devel@ovirt.org
 Sent: Thursday, January 2, 2014 11:46:29 AM
 Subject: Re: [Engine-devel] IMPORTANT: FindBugs threshold update
 
 
 
 - Original Message -
  From: Yair Zaslavsky yzasl...@redhat.com
  To: Moti Asayag masa...@redhat.com
  Cc: Oved Ourfalli ov...@redhat.com, Eyal Edri ee...@redhat.com,
  engine-devel engine-devel@ovirt.org
  Sent: Thursday, January 2, 2014 11:12:17 AM
  Subject: Re: [Engine-devel] IMPORTANT: FindBugs threshold update
  
  
  
  - Original Message -
   From: Moti Asayag masa...@redhat.com
   To: Oved Ourfalli ov...@redhat.com, Eyal Edri ee...@redhat.com
   Cc: engine-devel engine-devel@ovirt.org
   Sent: Thursday, January 2, 2014 12:08:43 AM
   Subject: Re: [Engine-devel] IMPORTANT: FindBugs threshold update
   
   
   
   - Original Message -
From: Oved Ourfalli ov...@redhat.com
To: engine-devel engine-devel@ovirt.org, Allon Mureinik
amure...@redhat.com, Alissa Bonas
abo...@redhat.com
Sent: Wednesday, January 1, 2014 4:25:50 PM
Subject: [Engine-devel] IMPORTANT: FindBugs threshold update

Hi all,

Up until now the jenkins jobs on the gerrit patches included a findbugs
job,
that failed only in case of a warning of level NORMAL or higher.
Now we update this threshold to fail on any findbugs warning, including
LOW
ones.
  
  Moti -
  1. Aren't use running a local jenkins instance on one of your hosts? Maybe
  Eyal can publish the findbugs job?
 
 Well...that server is on maintenance for quite a while...
 
  2. What about running the findbugs UI? I find it kinda handy...
 
 The findbugs UI expects the xml created by findbugs with all of the
 violations.
 The question is how those violation are created ? where are the rules by
 which
 findbugs verifies the code (can be findbugs jar or jenkins findbugs plugin or
 other...).
 
 Currently by running 'mvn findbugs:findbugs' i don't get a a single xml
 aggregating
 all of the violations and the produced ones contain a lot of warnings.
 
 So I'd like to know how can i be able to run this test locally ?
You're missing the profile with the project's exclusions.
What you'd want to do is probably this:
mvn findbugs:check -Pfindbugs-general

This way you won't have to go over any report, you will just fail the build if 
you introduce a regression.

 
  
  

   
   Could you provide instructions of running findbugs locally and how to
   evaluate
   the result the same as done by the jenkins job ?
   
Please make sure to rebase your current patches and check that the
findbugs
job finish successfully.
It will probably fail without a rebase, as the last patches clearing
the
warnings were merged a few hours ago.

Kodus to everyone involved in clearing all the LOW level warnings...
mostly
Allon and Alissa, but others helped as well! :-)

   
   Well done!
  
  Great news - good work guys!
  
   
Cheers,
Oved
___
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 technology stack upgrade complete

[Allon Mureinik]

- Original Message -
 From: Vojtech Szocs vsz...@redhat.com
 To: Allon Mureinik amure...@redhat.com
 Cc: engine-devel engine-devel@ovirt.org
 Sent: Monday, August 19, 2013 3:46:56 PM
 Subject: Re: [Engine-devel] oVirt UI technology stack upgrade complete
 
 
 - Original Message -
  From: Allon Mureinik amure...@redhat.com
  To: Vojtech Szocs vsz...@redhat.com
  Cc: engine-devel engine-devel@ovirt.org
  Sent: Thursday, August 15, 2013 12:52:55 PM
  Subject: Re: [Engine-devel] oVirt UI technology stack upgrade complete
  
  Thanks for the detailed explanation on the field initialization issues,
  Vojtech.
  
  
  Looking at the common and compat packages, there a dozens of such
  initializers. Some are probably redundant anyway and can safely be ignored,
  but some (most?) have a purpose.
  
  My incline is always to prevent such issues from happening, and not rely on
  developers having to remember to move their initializers.
  Here's my take on the issue (patchset available for review at [1]):
  - Move all member initializers to constructors
  - Add a checkstyle check to ensure that new members aren't initialized
  inline
 
 Nice work, Allon. I agree with your point not to rely solely on developers
 (having to remember GWT-specific limitations) but solving this issue
 globally in common  compat modules.
 
 I went over patches at [1] that aren't fully-acked yet, they looked good to
 me.
Patchset was merged.
A bug thank you to all the reviewers!

 
  
  Reviews are welcome, thanks!
  
  -Allon
  
  [1]
  http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:no-member-init,n,z
  
  - Original Message -
   From: Vojtech Szocs vsz...@redhat.com
   To: engine-devel engine-devel@ovirt.org
   Sent: Wednesday, July 31, 2013 4:17:30 PM
   Subject: [Engine-devel] oVirt UI technology stack upgrade complete
   
   Hello everyone,
   
   last week, we merged a patch that upgrades oVirt UI technology stack to
   use
   the latest version of Google Web Toolkit SDK and related modules [1].
   This
   patch includes all essential upgrade changes as described in [2].
   
   After merging the above mentioned patch, we faced some issues related to
   GWT
   RPC serialization, involving classes shared between frontend and backend.
   Please read on to learn more about these issues and ways to fix them.
   
   --
   
   (A) NullPointerException at server-side (GWT RPC servlet) when
   serializing
   backend business entity into RPC response payload
   
   Symptoms
   * exception in server.log - Exception while dispatching incoming RPC
   call:
   java.lang.NullPointerException
   * error dialog in web UI with status code 500 (internal server error)
   
   Root cause
   * fields such as private X field = Y; of the given entity are not
   included
   in GWT RPC serialization policy
   * this happens when entity constructor isn't referenced in UI code - GWT
   compiler marks the constructor and instance initializer as dead code
   * since instance initializer takes care of adding such fields to given
   type
   (entity) in generated JavaScript, such fields won't be added at all
   
   Workaround
   * for each field such as private X field = Y;
 1, change field declaration to private X field;
 2, add field = Y; statement to constructor
   
   Consequence
   * even though constructor and instance initializer are marked as dead
   code,
   fields such as private X field; are still added to given type (entity)
   in
   generated JavaScript
   * this is due to how generated JavaScript works, i.e. fields without
   initialization statement such as private X field; are always added,
   whereas fields with initialization statement such as private X field =
   Y;
   are added via instance initializer (which might be removed if it's marked
   as
   dead code)
   
   References
   * patch [http://gerrit.ovirt.org/#/c/17352/] for RepoImage entity
   
   --
   
   (B) Instance field(s) with null values at server-side after deserializing
   RPC
   request payload
   
   Symptoms
   * object passed from client contains field(s) with null values, despite
   client initializing fields before making RPC call
   
   Root cause
   * client uses RPC method signature that works with type A, i.e.
   VdcActionParametersBase
   * type A meets GWT RPC serialization rules, as defined in [3] section
   Serializable User-defined Classes
   * client uses type B (extends A) when calling given RPC method at
   runtime,
   i.e. MyCustomParameters
   * type B does NOT meet GWT RPC serialization rules, i.e. missing no-arg
   constructor
   * back at server-side, GWT RPC servlet fails to deserialize type B
   properly
   
   Workaround
   * ensure all types participating in GWT RPC communication meet GWT RPC
   serialization rules
 1, assignable to IsSerializable or Serializable interface
 2, all non-final  non-transient instance fields meet GWT RPC
 serialization
 rules
 3, contains

Re: [Engine-devel] oVirt UI technology stack upgrade complete

[Allon Mureinik]

Thanks for the detailed explanation on the field initialization issues, Vojtech.


Looking at the common and compat packages, there a dozens of such initializers. 
Some are probably redundant anyway and can safely be ignored, but some (most?) 
have a purpose.

My incline is always to prevent such issues from happening, and not rely on 
developers having to remember to move their initializers.
Here's my take on the issue (patchset available for review at [1]):
- Move all member initializers to constructors
- Add a checkstyle check to ensure that new members aren't initialized inline

Reviews are welcome, thanks!

-Allon

[1] 
http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:no-member-init,n,z

- Original Message -
 From: Vojtech Szocs vsz...@redhat.com
 To: engine-devel engine-devel@ovirt.org
 Sent: Wednesday, July 31, 2013 4:17:30 PM
 Subject: [Engine-devel] oVirt UI technology stack upgrade complete
 
 Hello everyone,
 
 last week, we merged a patch that upgrades oVirt UI technology stack to use
 the latest version of Google Web Toolkit SDK and related modules [1]. This
 patch includes all essential upgrade changes as described in [2].
 
 After merging the above mentioned patch, we faced some issues related to GWT
 RPC serialization, involving classes shared between frontend and backend.
 Please read on to learn more about these issues and ways to fix them.
 
 --
 
 (A) NullPointerException at server-side (GWT RPC servlet) when serializing
 backend business entity into RPC response payload
 
 Symptoms
 * exception in server.log - Exception while dispatching incoming RPC call:
 java.lang.NullPointerException
 * error dialog in web UI with status code 500 (internal server error)
 
 Root cause
 * fields such as private X field = Y; of the given entity are not included
 in GWT RPC serialization policy
 * this happens when entity constructor isn't referenced in UI code - GWT
 compiler marks the constructor and instance initializer as dead code
 * since instance initializer takes care of adding such fields to given type
 (entity) in generated JavaScript, such fields won't be added at all
 
 Workaround
 * for each field such as private X field = Y;
   1, change field declaration to private X field;
   2, add field = Y; statement to constructor
 
 Consequence
 * even though constructor and instance initializer are marked as dead code,
 fields such as private X field; are still added to given type (entity) in
 generated JavaScript
 * this is due to how generated JavaScript works, i.e. fields without
 initialization statement such as private X field; are always added,
 whereas fields with initialization statement such as private X field = Y;
 are added via instance initializer (which might be removed if it's marked as
 dead code)
 
 References
 * patch [http://gerrit.ovirt.org/#/c/17352/] for RepoImage entity
 
 --
 
 (B) Instance field(s) with null values at server-side after deserializing RPC
 request payload
 
 Symptoms
 * object passed from client contains field(s) with null values, despite
 client initializing fields before making RPC call
 
 Root cause
 * client uses RPC method signature that works with type A, i.e.
 VdcActionParametersBase
 * type A meets GWT RPC serialization rules, as defined in [3] section
 Serializable User-defined Classes
 * client uses type B (extends A) when calling given RPC method at runtime,
 i.e. MyCustomParameters
 * type B does NOT meet GWT RPC serialization rules, i.e. missing no-arg
 constructor
 * back at server-side, GWT RPC servlet fails to deserialize type B properly
 
 Workaround
 * ensure all types participating in GWT RPC communication meet GWT RPC
 serialization rules
   1, assignable to IsSerializable or Serializable interface
   2, all non-final  non-transient instance fields meet GWT RPC serialization
   rules
   3, contains no-arg constructor (in order to create instance during
   deserialization)
 
 References
 * patch [http://gerrit.ovirt.org/#/c/17368/] for Gluster Parameter classes
 
 --
 
 Regards,
 Vojtech
 
 [1] http://gerrit.ovirt.org/#/c/16739/
 [2] http://www.ovirt.org/Features/GWT_Platform_Upgrade
 [3]
 http://www.gwtproject.org/doc/latest/DevGuideServerCommunication.html#DevGuideSerializableTypes
 ___
 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] LockManager maybe not be really taking locks in your flows...

[Allon Mureinik]

- Original Message -
 From: Roy Golan rgo...@redhat.com
 To: Yair Zaslavsky yzasl...@redhat.com
 Cc: engine-devel engine-devel@ovirt.org
 Sent: Sunday, August 11, 2013 5:16:47 PM
 Subject: Re: [Engine-devel] LockManager maybe not be really taking locks in 
 your flows...
 
 On Sun 11 Aug 2013 05:14:04 PM IDT, Roy Golan wrote:
  On Sun 11 Aug 2013 05:03:05 PM IDT, Yair Zaslavsky wrote:
  Hi all,
  Thanks to Alon Bar Lev's efforts for preventing to concurrent host
  installation for the same host entity + Roy Golan's check of the
  code, we saw that for commands that override
 
  getExclusiveLocks() or getSharedLocks() the locking mechanism does
  not work (lock is not being acquired) if there is no annotation of
  @LockIdNameAttribute on the class.
  A bug was filed for removing this annotation (leftover from some
  historical code ) , but until it is fixed - bare in mind you need to
  add this annotation in current commands you are working on
  in order to utilize the mechanism.
  See RemoveVmCommand (has the annotation) vs AddDiskCommand (which
  doesn't have the annotation)
 
 
  Cheers,
  Yair
  ___
  Engine-devel mailing list
  Engine-devel@ovirt.org
  http://lists.ovirt.org/mailman/listinfo/engine-devel
 
  just to make it clear, the storage commands are calling explicitly
  aquireLockInternal in the canDoAction. since there is no contract (no
  interface) we are open to mistakes and misuse. this should be rectified.
 
 more info from the bug:
 see the list of commands that overrrides getExcelusiveLocks but *don't*
 have the @LockIdNameAttribute annotation:
 
 bll/src/main/java/org/ovirt/engine/core/bll/AddDiskCommand.java
Manually calls acquireLockInternal() - disgusting, but works (on my todo list 
for some future version, don't worry).

 bll/src/main/java/org/ovirt/engine/core/bll/MoveOrCopyDiskCommand.java
Same.

 bll/src/main/java/org/ovirt/engine/core/bll/AddVdsCommand.java
 bll/src/main/java/org/ovirt/engine/core/bll/UpdateVmTemplateCommand.java
 bll/src/main/java/org/ovirt/engine/core/bll/ExportRepoImageCommand.java
 
 ___
 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] LockManager maybe not be really taking locks in your flows...

[Allon Mureinik]

- Original Message -
 From: Allon Mureinik amure...@redhat.com
 To: Roy Golan rgo...@redhat.com
 Cc: engine-devel engine-devel@ovirt.org
 Sent: Monday, August 12, 2013 9:59:17 AM
 Subject: Re: [Engine-devel] LockManager maybe not be really taking locks in 
 your flows...
 
 
 
 - Original Message -
  From: Roy Golan rgo...@redhat.com
  To: Yair Zaslavsky yzasl...@redhat.com
  Cc: engine-devel engine-devel@ovirt.org
  Sent: Sunday, August 11, 2013 5:16:47 PM
  Subject: Re: [Engine-devel] LockManager maybe not be really taking locks in
  your flows...
  
  On Sun 11 Aug 2013 05:14:04 PM IDT, Roy Golan wrote:
   On Sun 11 Aug 2013 05:03:05 PM IDT, Yair Zaslavsky wrote:
   Hi all,
   Thanks to Alon Bar Lev's efforts for preventing to concurrent host
   installation for the same host entity + Roy Golan's check of the
   code, we saw that for commands that override
  
   getExclusiveLocks() or getSharedLocks() the locking mechanism does
   not work (lock is not being acquired) if there is no annotation of
   @LockIdNameAttribute on the class.
   A bug was filed for removing this annotation (leftover from some
   historical code ) , but until it is fixed - bare in mind you need to
   add this annotation in current commands you are working on
   in order to utilize the mechanism.
   See RemoveVmCommand (has the annotation) vs AddDiskCommand (which
   doesn't have the annotation)
  
  
   Cheers,
   Yair
   ___
   Engine-devel mailing list
   Engine-devel@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/engine-devel
  
   just to make it clear, the storage commands are calling explicitly
   aquireLockInternal in the canDoAction. since there is no contract (no
   interface) we are open to mistakes and misuse. this should be rectified.
  
  more info from the bug:
  see the list of commands that overrrides getExcelusiveLocks but *don't*
  have the @LockIdNameAttribute annotation:
  
  bll/src/main/java/org/ovirt/engine/core/bll/AddDiskCommand.java
 Manually calls acquireLockInternal() - disgusting, but works (on my todo list
 for some future version, don't worry).
 
  bll/src/main/java/org/ovirt/engine/core/bll/MoveOrCopyDiskCommand.java
 Same.
 
  bll/src/main/java/org/ovirt/engine/core/bll/AddVdsCommand.java
  bll/src/main/java/org/ovirt/engine/core/bll/UpdateVmTemplateCommand.java

  bll/src/main/java/org/ovirt/engine/core/bll/ExportRepoImageCommand.java
Fixed: http://gerrit.ovirt.org/#/c/17946/

  
  ___
  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] Linking to bugs from oVirt wiki

[Allon Mureinik]

Hi guys,

Since a lot of us will be busy opening bugs as part of the oVirt Test Day, I 
cooeked up a quick template to help adding Bugzilla links.

You can just use {BZ|number} in your wiki markup, and you'll get a 
user-friendly link to Bugzilla with the given number (e.g., {BZ|123} will 
create a link to http://bugzilla.redhat.com/123).


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

Re: [Engine-devel] Linking to bugs from oVirt wiki

[Allon Mureinik]

- Original Message -
 From: Allon Mureinik amure...@redhat.com
 To: engine-devel engine-devel@ovirt.org, vdsm-de...@lists.fedorahosted.org
 Sent: Wednesday, July 24, 2013 2:54:44 PM
 Subject: Linking to bugs from oVirt wiki
 
 Hi guys,
 
 Since a lot of us will be busy opening bugs as part of the oVirt Test Day, I
 cooeked up a quick template to help adding Bugzilla links.
 
 You can just use {BZ|number} in your wiki markup, and you'll get a
{{BZ|number}} of course.
Thanks Alissa for pointing this out. ;-)

 user-friendly link to Bugzilla with the given number (e.g., {BZ|123} will
 create a link to http://bugzilla.redhat.com/123).
 
 
 Enjoy,
 Allon
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Kudos to Allon Mureinik for his 1, 000 patch merged

[Allon Mureinik]

Thanks!

Although I would have expected the milestone to be at 1024 :-)

- Original Message -
 From: Itamar Heim ih...@redhat.com
 To: engine-devel engine-devel@ovirt.org
 Sent: Thursday, July 4, 2013 9:59:40 PM
 Subject: [Engine-devel] Kudos to Allon Mureinik for his 1,000 patch merged
 
 While 1,000 is an arbitrary number, kudos to Allon for his 1,000 patch
 to ovirt-engine repo being merged[1]!
 
 (yes, a lot of these are cleanup patches, but these matter too).
 
 Thanks,
 Itamar
 
 [1] you can use 'git shortlog -sn' to get the full list.
 ___
 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] Guid improvements

[Allon Mureinik]

- Original Message - 

 From: Liran Zelkha liran.zel...@gmail.com
 To: Allon Mureinik amure...@redhat.com
 Cc: Yair Zaslavsky yzasl...@redhat.com, engine-devel
 engine-devel@ovirt.org
 Sent: Monday, July 1, 2013 10:36:06 AM
 Subject: Re: [Engine-devel] Guid improvements

 Awesome!!!

 On Mon, Jul 1, 2013 at 10:29 AM, Allon Mureinik  amure...@redhat.com 
 wrote:

  - Original Message -
 
   From: Liran Zelkha  liran.zel...@gmail.com 
 
   To: Yair Zaslavsky  yzasl...@redhat.com 
 
   Cc: Allon Mureinik  amure...@redhat.com , engine-devel 
   engine-devel@ovirt.org 
 
   Sent: Sunday, June 30, 2013 11:37:26 AM
 
   Subject: Re: [Engine-devel] Guid improvements
 
  
 
   Great news.
 
   Allon - please note that GUID is being recreated from String by both DB
   calls
 
   and by data received from VDSM. It is VERY useful to cache Guid
 
   String--Guid, and not just Empty GUID.
 
  I generally agree about the high cost of sting-uuid operations, but I'm
  not
  sure caching is the way to go, at least not everywhere.
 

  At least for the database, there is a much easier solution - stop using
  strings to represent uuids.
 
  Here's an example of how it can be done:
 
  http://gerrit.ovirt.org/#/c/16281/
This patchset was merged [1].
Along with a couple of uber-neat improvements by Juan [2][3], I think we should 
see a real boost in performance.

[1] 
http://gerrit.ovirt.org/#/q/status:merged+project:ovirt-engine+branch:master+topic:guid-database-improvements,n,z
[2] http://gerrit.ovirt.org/#/c/16421/
[3] http://gerrit.ovirt.org/#/c/16467/

 

  
 
   However, as the Guid class runs in GWT as well, you can't use Infinispan
   and
 
   you're limited in the HashMap implementations you can use. Personally, I
 
   don't think it's a memory leak, as GUID number in the system are finite
   and
 
   not too large. What do you think? Want to add it to your patch?
 
  
 
   On Jun 30, 2013, at 11:13 AM, Yair Zaslavsky wrote:
 
  
 
Well done, should have been done ages ago :)
 
Now, for the painful rebase of async_task_mgr changes :)
 
   
 
   
 
- Original Message -
 
From: Allon Mureinik  amure...@redhat.com 
 
To: engine-devel  engine-devel@ovirt.org , Barak Azulay
 
 bazu...@redhat.com 
 
Cc: Yair Zaslavsky  yzasl...@redhat.com , Michael Pasternak
 
 mpast...@redhat.com , Tal Nisan
 
 tni...@redhat.com , Ayal Baron  aba...@redhat.com 
 
Sent: Sunday, June 30, 2013 11:11:30 AM
 
Subject: Guid improvements
 
   
 
Hi all,
 
   
 
I just merged a couple of improvements to the [N]Guid class [1] to
improve
 
it's performance both CPU-wise and memory-wise, based on a set of
 
benchmarks
 
presented by Liran.
 
   
 
What this patchset achieves:
 
1. Clean up the code, so it's easier to understand and use
 
2. Eliminate the inflation in the memory foot print caused by the
 
getValue()
 
method
 
3. Eliminate all the heavy calls to UUID.fromString when creating a
 
new/empty
 
Guid instance as a default value
 
4. Note that the cleanups proposed in (1) will have minor performance
 
benefits (e.g., eliminating useless conditional statements), but I
doubt
 
this would be anything to write home about.
 
   
 
From a developer's perspective, here's what changed:
 
1. No more NGuid, just Guid. Both static methods to create a Guid from
 
String
 
still exist, and are named createGuidFromString and
 
createGuidFromStringDefaultEmpty.
 
2. [N]Guid.getValue() was removed, it's no longer needed after (1) was
 
implemented
 
3. The Guid() constructor was made private, as it forced a redundant
call
 
to
 
UUID.fromString(String). If you need an empty Guid instance, just use
 
Guid.Empty
 
4. The Guid.EMPTY_GUID_VALUE string constant was removed, as it was
used
 
for
 
redundant calls to UUID.fromString. If you really, REALLY, need it,
just
 
call Guid.Empty.getValue() for a UUID or Guid.Empty.toString() for a
 
String.
 
5. All sorts of ways to transform Strings to Guids were removed. If
you
 
have
 
a literal you trust, just use new Guid(String). If you suspect it may
be
 
null, use Guid.createGuidFromString[DefaultEmpty]
 
6. NewGuid is now called newGuid. We're in Java, not C# :-)
 
   
 
   
 
Many thanks to everyone who reviewed this patchset.
 
You guys rock!
 
   
 
   
 
Regards,
 
Allon
 
   
 
   
 
[1]
 
http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:guid-cleanup,n,z
 
   
 
___
 
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] Guid improvements

[Allon Mureinik]

Hi all,

I just merged a couple of improvements to the [N]Guid class [1] to improve it's 
performance both CPU-wise and memory-wise, based on a set of benchmarks 
presented by Liran.

What this patchset achieves:
1. Clean up the code, so it's easier to understand and use
2. Eliminate the inflation in the memory foot print caused by the getValue() 
method
3. Eliminate all the heavy calls to UUID.fromString when creating a new/empty 
Guid instance as a default value
4. Note that the cleanups proposed in (1) will have minor performance benefits 
(e.g., eliminating useless conditional statements), but I doubt this would be 
anything to write home about.

From a developer's perspective, here's what changed:
1. No more NGuid, just Guid. Both static methods to create a Guid from String 
still exist, and are named createGuidFromString and 
createGuidFromStringDefaultEmpty.
2. [N]Guid.getValue() was removed, it's no longer needed after (1) was 
implemented
3. The Guid() constructor was made private, as it forced a redundant call to 
UUID.fromString(String). If you need an empty Guid instance, just use Guid.Empty
4. The Guid.EMPTY_GUID_VALUE string constant was removed, as it was used for 
redundant calls to UUID.fromString. If you really, REALLY, need it, just call 
Guid.Empty.getValue() for a UUID or Guid.Empty.toString() for a String.
5. All sorts of ways to transform Strings to Guids were removed. If you have a 
literal you trust, just use new Guid(String). If you suspect it may be null, 
use Guid.createGuidFromString[DefaultEmpty]
6. NewGuid is now called newGuid. We're in Java, not C# :-)


Many thanks to everyone who reviewed this patchset.
You guys rock!


Regards,
Allon


[1] 
http://gerrit.ovirt.org/#/q/project:ovirt-engine+branch:master+topic:guid-cleanup,n,z
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] checkstyle and tools project

[Allon Mureinik]

checkstyle runs as part of a compile phase in mvn.
as long as you build your code before submitting it to gerrit you should be 
scott-free.

- Original Message -
 From: Eyal Edri ee...@redhat.com
 To: Laszlo Hornyak lhorn...@redhat.com
 Cc: engine-devel engine-devel@ovirt.org, infra in...@ovirt.org
 Sent: Monday, June 24, 2013 5:28:44 PM
 Subject: Re: [Engine-devel] checkstyle and tools project
 
 Can we add a gerrit hook to run checkstyle on the code?
 rather than waiting it to be merged and fail on jenkins?
 
 - Original Message -
  From: Laszlo Hornyak lhorn...@redhat.com
  To: engine-devel engine-devel@ovirt.org
  Sent: Monday, June 24, 2013 11:15:38 AM
  Subject: [Engine-devel] checkstyle and tools project
  
  Hi,
  
  Checkstyle is not executed on tools project. I have sent a patch to gerrit
  to
  fix this, could you guys review?
  
  http://gerrit.ovirt.org/15719
  
  And there are some more cleanup patches for tools:
  http://gerrit.ovirt.org/15720
  http://gerrit.ovirt.org/15721
  http://gerrit.ovirt.org/15722
  
  
  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 mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Disk BE very small refactoring

[Allon Mureinik]

- Original Message -
 From: Vered Volansky ve...@redhat.com
 To: Eli Mesika emes...@redhat.com
 Cc: engine-devel@ovirt.org
 Sent: Sunday, June 2, 2013 12:02:55 PM
 Subject: Re: [Engine-devel] Disk BE very small refactoring
 
 
 
 - Original Message -
  From: Eli Mesika emes...@redhat.com
  To: Vered Volansky ve...@redhat.com
  Cc: engine-devel@ovirt.org
  Sent: Thursday, May 30, 2013 12:57:26 PM
  Subject: Re: [Engine-devel] Disk BE very small refactoring
  
  
  
  - Original Message -
   From: Omer Frenkel ofren...@redhat.com
   To: Vered Volansky ve...@redhat.com
   Cc: engine-devel@ovirt.org
   Sent: Thursday, May 30, 2013 11:29:40 AM
   Subject: Re: [Engine-devel] Disk BE very small refactoring
   
   
   
   - Original Message -
From: Vered Volansky ve...@redhat.com
To: Maor Lipchuk mlipc...@redhat.com, Yair Zaslavsky
yzasl...@redhat.com, Omer Frenkel
ofren...@redhat.com, Mike Kolesnik mkole...@redhat.com, Allon
Mureinik amure...@redhat.com, Daniel Erez
de...@redhat.com
Cc: engine-devel@ovirt.org
Sent: Tuesday, May 28, 2013 8:40:38 PM
Subject: Re: [Engine-devel] Disk BE very small refactoring

I had a problem, didn't see all the replies till now.

I'll add some more info as to why we want to do this like we do.
It all started from adding the readOnly property to disks. It should
have
been handled like plugged is handled, yet plugged is a hack, and if we
don't
change that now, we'll only keep on adding unreasonable hacks.

   
   please explain why you think plugged is a hack? what is wrong with it?
  
  You have is_readonly and is_plugged in the device level , this is far from
  being a hack and managed in the correct place since both may apply to
  multiple device types (disk, nics )
 There's no problem with device level, only I can't use VmDevice (which is
 where this naturally belongs) in UI since it will cause a major change we
 don't want right now.
 Not only that, VmDevice does hold this info, but not other relevant info used
 in UI and available in Disk, so using VmDevice on it's own is not only to
 extensive a change, but also by far will not end there.
 
  
   
So from the start -
Disk currently:
- Sometimes represents a disk in a vm context and sometimes not.
- Holds plugged property, which is only relevant when a disk is in a vm
context, which already suggests this is not the natural place for it.
- Also holds bootable and interface, which cause limitations of use,
but
are
not so obviously related to the relationship between Disk and Vm as
plugged.
- Can be shared between several vm's, to some plugged and to some not
plugged.
- Will soon be optionally RO in one VM and RW in another, which is
exactly
the same as plugged, and therefore plugged issue should be fixed first.

Every column in that shows a disk in the UI receives a Disk entity, and
show
its contents, while plugged/unplugged is ignored when not in a VM
context.
The way things are now, using a VmDevice in the where we need it to
show
plug
status, we'll also have to use it in all other columns, which is
irrelevant
and just totally not related.
So using VmDevice in UI is a no go.

The UI is the main limitation forcing us to use something that extends
Disk,
and what I described below is the easiest thing to implement in the
time
restrictions we have without changing the entire system.

I think this answers all the questions not already answered by others.
Regarding Maor suggestion - might be a good idea, but not in this scope
or
time-frame.

If there is any other/unanswered issue or objection to the design
change
please share.

I appreciate your inputs,
Vered

   
   sorry i didnt understand why the current disk object isnt good enough,
   you get a disk, some of its properties are valid only in some situations.
   i think its easier to use instead of couple of different objects
   representing
   the same entity in different situations.
  
  I totally agree with Omer, please specify what is impossible or hard to
  achieve with the current schema
 No problem with DB schema, please see my answer in engine-devel, I'm not sure
 you're directly cc'ed.
The way I see it, it's a design issue.
A disk is different from other devices as it can be attached to multiple VMs.
I.e., the same Disk record in the database is associated with either 0 device 
records (a floating disk), 1 device record (a normal disk) or multiple device 
records (shared disk).
The java object has a few properties that really belong to the disk (e.g., 
alias, size, wipeAfterDelete), some that belong to the device (plugged, 
readOnly in the near future) and  some the belong to ALL the VMs it's attached 
to (e.g., vmNames).

This way, the object is unusable - depending on which

Re: [Engine-devel] cannot attach ISO with latest master

[Allon Mureinik]

Just pull the latest master - this patch was already merged. 
(Thanks Omer!) 

- Original Message -

 From: Dead Horse deadhorseconsult...@gmail.com
 To: Allon Mureinik amure...@redhat.com
 Cc: engine-devel@ovirt.org
 Sent: Saturday, May 18, 2013 12:30:08 AM
 Subject: Re: [Engine-devel] cannot attach ISO with latest master

 I attempted to test the patch however the result was engine compilation
 failure with the webadmin module.
 - DHC

 On Thu, May 16, 2013 at 11:22 AM, Allon Mureinik  amure...@redhat.com 
 wrote:

  The following patch (still pending review) should do the trick:
 
  http://gerrit.ovirt.org/#/c/14818/
 

   From: Dead Horse  deadhorseconsult...@gmail.com 
  
 
   To: engine-devel@ovirt.org
  
 
   Sent: Thursday, May 16, 2013 5:31:23 PM
  
 
   Subject: Re: [Engine-devel] cannot attach ISO with latest master
  
 

   This occurs only when using Run Once to attach an ISO to a VM.
  
 
   It is still present in master as of this morning.
  
 
   It was reported recently by another user on the user list as well.
  
 
   - DHC
  
 

   On Mon, May 13, 2013 at 4:47 PM, Dead Horse 
   deadhorseconsult...@gmail.com
   
   wrote:
  
 

Cannot attach images from the iso storage domain with latest master.
   
  
 
VDSM version is latest master as well
   
  
 
Host = EL6.4
   
  
 

2013-05-13 16:41:02,184 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
(ajp--127.0.0.1-8702-7) [5d889258] START, IsoPrefixVDSCommand(
storagePoolId
= 0cba78bd-f1b7-438f-afac-acd59fab92ae, ignoreFailoverLimit = false,
compatabilityVersion = null), log id: a85d3c0
   
  
 
2013-05-13 16:41:02,196 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
(ajp--127.0.0.1-8702-7) [5d889258] FINISH, IsoPrefixVDSCommand, return:
/rhev/data-center/mnt/192.168.0.1:_ovirt_dalaran/d6276dc3-1714-4024-9b70-b7971ed5fe35/images/----,
log id: a85d3c0
   
  
 
2013-05-13 16:41:02,328 WARN
[org.ovirt.engine.core.bll.RunVmOnceCommand]
(ajp--127.0.0.1-8702-7) [5d889258] CanDoAction of action RunVmOnce
failed.
Reasons:VAR__ACTION__RUN,VAR__TYPE__VM,ERROR_CANNOT_FIND_ISO_IMAGE_PATH
   
  
 

- DHC
   
  
 

   ___
  
 
   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] cannot attach ISO with latest master

[Allon Mureinik]

The following patch (still pending review) should do the trick: 
http://gerrit.ovirt.org/#/c/14818/ 

- Original Message -

 From: Dead Horse deadhorseconsult...@gmail.com
 To: engine-devel@ovirt.org
 Sent: Thursday, May 16, 2013 5:31:23 PM
 Subject: Re: [Engine-devel] cannot attach ISO with latest master

 This occurs only when using Run Once to attach an ISO to a VM.
 It is still present in master as of this morning.
 It was reported recently by another user on the user list as well.
 - DHC

 On Mon, May 13, 2013 at 4:47 PM, Dead Horse  deadhorseconsult...@gmail.com 
 wrote:

  Cannot attach images from the iso storage domain with latest master.
 
  VDSM version is latest master as well
 
  Host = EL6.4
 

  2013-05-13 16:41:02,184 INFO
  [org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
  (ajp--127.0.0.1-8702-7) [5d889258] START, IsoPrefixVDSCommand(
  storagePoolId
  = 0cba78bd-f1b7-438f-afac-acd59fab92ae, ignoreFailoverLimit = false,
  compatabilityVersion = null), log id: a85d3c0
 
  2013-05-13 16:41:02,196 INFO
  [org.ovirt.engine.core.vdsbroker.irsbroker.IsoPrefixVDSCommand]
  (ajp--127.0.0.1-8702-7) [5d889258] FINISH, IsoPrefixVDSCommand, return:
  /rhev/data-center/mnt/192.168.0.1:_ovirt_dalaran/d6276dc3-1714-4024-9b70-b7971ed5fe35/images/----,
  log id: a85d3c0
 
  2013-05-13 16:41:02,328 WARN [org.ovirt.engine.core.bll.RunVmOnceCommand]
  (ajp--127.0.0.1-8702-7) [5d889258] CanDoAction of action RunVmOnce failed.
  Reasons:VAR__ACTION__RUN,VAR__TYPE__VM,ERROR_CANNOT_FIND_ISO_IMAGE_PATH
 

  - DHC
 

 ___
 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] REST vs. UI validation

[Allon Mureinik]

REST shouldn't have any validations (perhaps maybe only that the passed type is 
correct, etc. - Michael, correct me if I'm wrong).

The real validations are in the backend, which both REST and the GUI invoke. 
Any validation the GUI does in addition to the backend is just a 
user-experience enhancement (e.g., if !@#^!^$) is not a valid DC name, there is 
no reason to send it to the backend).

Vered - I disagree that this is by design.
There is only one definition of what a correct value is, there should be no 
ambiguity about it[1]
If the GUI prohibits you from a legal configuration - it should be fixed.
if the backend allows an illegal configuration - a CDA should be added.
My two cents - this is not OK, please open bugs (or even better - send 
patches!) for the specific issues.

[1] Just to be clear, there is a difference between not being able to do 
something from the UI and having different validations.
For example, there is no GUI for scanning a storage domain 
(http://www.ovirt.org/Features/Domain_Scan). I'd prefer having a GUI for that 
too, but not having it is just a missing capability, not a disambiguity with 
REST.

- Original Message -
 From: Vered Volansky ve...@redhat.com
 To: Kari Whitcomb kari.whitc...@hp.com
 Cc: engine-devel@ovirt.org
 Sent: Tuesday, April 30, 2013 10:15:31 AM
 Subject: Re: [Engine-devel] REST vs. UI validation
 
 
 
 - Original Message -
  From: Kari Whitcomb kari.whitc...@hp.com
  To: engine-devel@ovirt.org
  Sent: Tuesday, April 30, 2013 1:19:00 AM
  Subject: [Engine-devel] REST vs. UI validation
  
  I've been making use of the oVirt REST api, and have noticed that in
  several
  cases the validation done for a REST request is different than what the
  admin UI does.  It seems that the UI is generally more restrictive on the
  data it will accept than the backend.  So you can set things up using the
  REST api that the UI wouldn't let you do.  Two examples I've hit recently,
  both in the cluster policy (load balancing section):
  
  - Cluster load balancing policy duration - the UI requires a value between
  1
  and 100, but the REST api seems to let you set it to any integer.
  
  - Cluster load balancing high and low thresholds / max and min service
  levels
  - The UI restricts the high value to 51-90% and the low value to 10-50%.
  But the backend only requires that the values be 0-100% and that low can't
  be greater than high.
  
  So my question - is this intended behavior, or is it a bug that the
  validation is different?  If similar validation should be done through both
  the UI and REST api, should the UI be less restrictive, or the backend more
  restrictive?
 
 This is the intended behaviour.
 The UI is often more restrictive than the api.
 By definition the api is more lenient that the UI.
 
 Regards,
 Vered
  
  Thanks,
  Kari
  ___
  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] storage overallocation ratio

[Allon Mureinik]

Hi Michal,

apparentsize is the size that you perceive when working with the volume (i.e., 
ignoring sparseness etc.) while trusize is the size taken on the drive (i.e., 
taking sparseness etc. into account).

DiskImage.getActualSize() should report the truesize.
The end result is OK, since truesize overrides apparentsize in that command, 
but it's obviously wrong, and should be fixed [1].

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

- Original Message -
 From: Michal Skrivanek michal.skriva...@redhat.com
 To: engine-devel@ovirt.org
 Sent: Saturday, April 20, 2013 11:13:04 PM
 Subject: [Engine-devel] storage overallocation ratio
 
 Hi,
 I was trying to find out how is this actually calculated. Doesn't look very
 straightforward…:)
 
 I'm curious about the following - vdsm reports something like truesize and
 apparentsize which IIUC should be distinct  but then in engine, in
 backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/irsbroker/GetImageInfoVDSCommand.java
 it's written to the same engine property actual_size.
 That doesn't sound right.
 Can someone enlighten me please?
 
 Thanks,
 michal
 ___
 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] Location of findbugs filter.xml file

[Allon Mureinik]

- Original Message -
 From: Mike Kolesnik mkole...@redhat.com
 To: engine-devel engine-devel@ovirt.org
 Cc: Oved Ourfalli ov...@redhat.com
 Sent: Thursday, April 18, 2013 5:10:39 PM
 Subject: Re: [Engine-devel] Location of findbugs filter.xml file
 
 - Original Message -
  
  
  - Original Message -
   From: Yair Zaslavsky yzasl...@redhat.com
   To: engine-devel engine-devel@ovirt.org
   Sent: Thursday, April 18, 2013 4:55:46 PM
   Subject: [Engine-devel] Location of findbugs filter.xml file
   
   Hi all,
   I sent a patch upstream to add findbugs filter that will filter out bug
   reports that we decided that are not bugs.
   We have a debate on whether to have the findbugs filter definition in the
   root pom.xml or to put it in the jenkins jobs repo and treat it as an
   external tool.
   I would like to hear opinions about what you think should be the proper
   location
   
  Putting it in the root pom.xml file will allow running filtered findbugs
  using maven, without the need to use jenkins, so I'd go with that approach.
 
 +1
Even better than that - each module can override the configuration with its own 
exceptions in its own pom file
 
  
   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 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] build stuck on RunVmCommandTest

[Allon Mureinik]

Real oddness. 
out of interest, can you run 
java -version 

and report the version here? 

- Original Message -

 From: Shireesh Anjal san...@redhat.com
 To: engine-devel@ovirt.org
 Sent: Wednesday, April 10, 2013 9:40:19 AM
 Subject: [Engine-devel] build stuck on RunVmCommandTest

 Hi,

 From last night onwards, my mvn build is getting stuck for a long time (  30
 minutes) on RunVmCommandTest

 Running org.ovirt.engine.core.bll.MoveDisksCommandTest
 Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec
 Running org.ovirt.engine.core.bll.RunVmCommandTest
 Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1,983.033
 sec
 Running org.ovirt.engine.core.bll.lock.InMemoryLockManagerTest
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
 Running org.ovirt.engine.core.bll.RemoveImageCommandTest

 The same issue is happening on one of my colleague's system as well. Any help
 in fixing this will be highly appreciated.

 Regards,
 Shireesh

 ___
 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] build stuck on RunVmCommandTest

[Allon Mureinik]

Einav had a similar issue yesterday with RemoveDiskTest (IIRC), which at first 
pointed me to the direction of Java 7, but this is unrelated. 

The root of all these problems is commit 
fd6835059f110f4e14d67c9d2d31aa786a822f4b (core: Locate data source in a loop) - 
now, whenever we have unmocked DAO calls (like in RunVmCommand), instead of 
failing them fast and silently, we'll get stuck in a loop. 

We need to see if we can offer a quick workaround, or perhaps revert this patch 
until we can offer such a solution. 
Juan, your input would be appreciates here. 

Thanks, 
Allon 

- Original Message -

 From: Shireesh Anjal san...@redhat.com
 To: Allon Mureinik amure...@redhat.com
 Cc: engine-devel@ovirt.org
 Sent: Wednesday, April 10, 2013 11:15:40 AM
 Subject: Re: [Engine-devel] build stuck on RunVmCommandTest

 On 04/10/2013 01:39 PM, Allon Mureinik wrote:

  Real oddness.
 
  out of interest, can you run
 
  java -version
 

  and report the version here?
 

 shireesh@localhost ovirt-engine]$ java -version
 java version 1.7.0_09-icedtea
 OpenJDK Runtime Environment (fedora-2.3.4.fc18-x86_64)
 OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

  - Original Message -
 

   From: Shireesh Anjal san...@redhat.com
  
 
   To: engine-devel@ovirt.org
  
 
   Sent: Wednesday, April 10, 2013 9:40:19 AM
  
 
   Subject: [Engine-devel] build stuck on RunVmCommandTest
  
 

   Hi,
  
 

   From last night onwards, my mvn build is getting stuck for a long time (
   
   30
   minutes) on RunVmCommandTest
  
 

   Running org.ovirt.engine.core.bll.MoveDisksCommandTest
  
 
   Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.04 sec
  
 
   Running org.ovirt.engine.core.bll.RunVmCommandTest
  
 
   Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
   1,983.033
   sec
  
 
   Running org.ovirt.engine.core.bll.lock.InMemoryLockManagerTest
  
 
   Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
  
 
   Running org.ovirt.engine.core.bll.RemoveImageCommandTest
  
 

   The same issue is happening on one of my colleague's system as well. Any
   help
   in fixing this will be highly appreciated.
  
 

   Regards,
  
 
   Shireesh
  
 

   ___
  
 
   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] build stuck on RunVmCommandTest

[Allon Mureinik]

- Original Message -
 From: Juan Hernandez jhern...@redhat.com
 To: Allon Mureinik amure...@redhat.com
 Cc: Shireesh Anjal san...@redhat.com, engine-devel@ovirt.org
 Sent: Wednesday, April 10, 2013 1:58:17 PM
 Subject: Re: [Engine-devel] build stuck on RunVmCommandTest
 
 On 04/10/2013 12:12 PM, Juan Hernandez wrote:
  On 04/10/2013 10:31 AM, Allon Mureinik wrote:
  Einav had a similar issue yesterday with RemoveDiskTest (IIRC), which at
  first pointed me to the direction of Java 7, but this is unrelated.
 
  The root of all these problems is commit
  fd6835059f110f4e14d67c9d2d31aa786a822f4b (core: Locate data source in a
  loop) - now, whenever we have unmocked DAO calls (like in RunVmCommand),
  instead of failing them fast and silently, we'll get stuck in a loop.
 
  We need to see if we can offer a quick workaround, or perhaps revert
  this patch until we can offer such a solution.
  Juan, your input would be appreciates here.
 
 
  As a workaround create /etc/ovirt-engine/engine.conf and add the
  following two lines:
 
  ENGINE_DB_CONNECTION_TIMEOUT=0
  ENGINE_DB_CHECK_INTERVAL=0
 
  Then the tests should run faster.
 
 
 This is a way to solve it:
 
 http://gerrit.ovirt.org/13782
Didn't get a chance to look at it before it was merged, but looks great.
Thanks Juan!

 
 
  Thanks,
  Allon
 
  
 
   *From: *Shireesh Anjal san...@redhat.com
   *To: *Allon Mureinik amure...@redhat.com
   *Cc: *engine-devel@ovirt.org
   *Sent: *Wednesday, April 10, 2013 11:15:40 AM
   *Subject: *Re: [Engine-devel] build stuck on RunVmCommandTest
 
   On 04/10/2013 01:39 PM, Allon Mureinik wrote:
 
   Real oddness.
   out of interest, can you run
   java -version
 
   and report the version here?
 
 
   shireesh@localhost ovirt-engine]$ java -version
   java version 1.7.0_09-icedtea
   OpenJDK Runtime Environment (fedora-2.3.4.fc18-x86_64)
   OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
 
 
 
   
  
 
   *From: *Shireesh Anjal san...@redhat.com
   *To: *engine-devel@ovirt.org
   *Sent: *Wednesday, April 10, 2013 9:40:19 AM
   *Subject: *[Engine-devel] build stuck on RunVmCommandTest
 
   Hi,
 
From last night onwards, my mvn build is getting stuck for
   a long time (  30 minutes) on RunVmCommandTest
 
   Running org.ovirt.engine.core.bll.MoveDisksCommandTest
   Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time
   elapsed: 0.04 sec
   *Running org.ovirt.engine.core.bll.RunVmCommandTest**
   **Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time
   elapsed: 1,983.033 sec**
   *Running
   org.ovirt.engine.core.bll.lock.InMemoryLockManagerTest
   Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time
   elapsed: 0.007 sec
   Running org.ovirt.engine.core.bll.RemoveImageCommandTest
 
   The same issue is happening on one of my colleague's system
   as well. Any help in fixing this will be highly appreciated.
 
   Regards,
   Shireesh
 
   ___
   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 - Red Hat S.L.
 
___
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest?

[Allon Mureinik]

When running [1] on this morning's master (commit hash eca9964, merged April 
8th, 20:15 IST) I didn't notice any issues (built the entire project in ~3 
minutes, backend took 27 seconds), but when running this test alone in eclipse 
it definitely took much longer.

I'm guessing it lacks some mocking, which some earlier test is doing by mistake.
Since JUnit does not enforce any ordering, we may be running our tests in a 
slightly different order (due to different maven/java/os minor versions, etc.), 
which makes the problem visible on your setup but not mine.

I'll do somemore digging and see if I can pinpoint it.

- Original Message -
 From: Einav Cohen eco...@redhat.com
 To: engine-devel engine-devel@ovirt.org
 Sent: Monday, April 8, 2013 6:35:47 PM
 Subject: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest?
 
 Hi,
 
 When trying to compile oVirt (with tests - see [1]), my compilation seems to
 get stuck on
 RemoveSnapshotCommandTest (see [2] for test file full path, [3] for output).
 
 When eliminating this test (e.g. I removed [2] locally from my file-system),
 compilation
 (including tests) is completed successfully.
 
 Anyone else encountered this problem / any idea what the problem might be?
 
 
 Thanks,
 Einav
 
 
 [1] performed the following on the latest upstream:
 mvn clean
 mvn install -Pgwt-user,gwt-admin,all-langs -Dgwt.userAgent=gecko1_8
 
 [2]
 ../backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/RemoveSnapshotCommandTest.java
 
 [3] last lines in compilation output:
 ...
 [INFO]
 
 [INFO] Building Backend Logic @Service bean 3.3.0-SNAPSHOT
 [INFO]
 
 ...
 
 Running org.ovirt.engine.core.bll.network.host.SetupNetworksHelperTest
 Tests run: 56, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.74 sec
 Running
 org.ovirt.engine.core.bll.network.cluster.GetAllNetworksByClusterIdQueryTest
 Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 sec
 Running
 org.ovirt.engine.core.bll.network.cluster.AttachNetworkToVdsGroupCommandTest
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec
 Running org.ovirt.engine.core.bll.network.cluster.NetworkClusterValidatorTest
 Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec
 Running
 org.ovirt.engine.core.bll.network.cluster.GetVdsGroupsAndNetworksByNetworkIdQueryTest
 Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec
 Running org.ovirt.engine.core.bll.network.vm.GetVmInterfacesByVmIdQueryTest
 Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec
 Running
 org.ovirt.engine.core.bll.network.vm.GetVmsAndNetworkInterfacesByNetworkIdQueryTest
 Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec
 Running org.ovirt.engine.core.bll.network.VmInterfaceManagerTest
 Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.321 sec
 Running
 org.ovirt.engine.core.bll.network.template.GetTemplateInterfacesByTemplateIdQueryTest
 Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec
 Running
 org.ovirt.engine.core.bll.network.template.GetVmTemplatesAndNetworkInterfacesByNetworkIdQueryTest
 Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 sec
 Running org.ovirt.engine.core.bll.GetCommandsCompatibilityVersionsQueryTest
 Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec
 Running org.ovirt.engine.core.bll.GetClustersWithPermittedActionQueryTest
 Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec
 Running org.ovirt.engine.core.bll.RemoveSnapshotCommandTest
 [no more output after this point; waited ~20 minutes in this state before
 hitting Ctrl+C]
 ___
 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] compilation stuck on RemoveSnapshotCommandTest?

[Allon Mureinik]

The last message would have been much more useful if I'd actually attached the 
link to my patch:
http://gerrit.ovirt.org/#/c/13733/

Note that it is /not/ merge yet - review would be appreciated.
- Original Message -
 From: Allon Mureinik amure...@redhat.com
 To: Einav Cohen eco...@redhat.com
 Cc: engine-devel engine-devel@ovirt.org
 Sent: Tuesday, April 9, 2013 10:22:38 AM
 Subject: Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest?
 
 OK, my guess is that test uses Mockito Matchers carelessly.
 
 I removed them, and on my setup I reduced the time it takes to run this test
 alone in eclipse from ~70 seconds to ~0.7 seconds (i.e., removed 99% of the
 runtime).
 
 Please check it solves the issue on your setup too.
 
 
 Thanks,
 Allon
 
 - Original Message -
  From: Allon Mureinik amure...@redhat.com
  To: Einav Cohen eco...@redhat.com
  Cc: engine-devel engine-devel@ovirt.org
  Sent: Tuesday, April 9, 2013 9:39:41 AM
  Subject: Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest?
  
  When running [1] on this morning's master (commit hash eca9964, merged
  April
  8th, 20:15 IST) I didn't notice any issues (built the entire project in ~3
  minutes, backend took 27 seconds), but when running this test alone in
  eclipse it definitely took much longer.
  
  I'm guessing it lacks some mocking, which some earlier test is doing by
  mistake.
  Since JUnit does not enforce any ordering, we may be running our tests in a
  slightly different order (due to different maven/java/os minor versions,
  etc.), which makes the problem visible on your setup but not mine.
  
  I'll do somemore digging and see if I can pinpoint it.
  
  - Original Message -
   From: Einav Cohen eco...@redhat.com
   To: engine-devel engine-devel@ovirt.org
   Sent: Monday, April 8, 2013 6:35:47 PM
   Subject: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest?
   
   Hi,
   
   When trying to compile oVirt (with tests - see [1]), my compilation seems
   to
   get stuck on
   RemoveSnapshotCommandTest (see [2] for test file full path, [3] for
   output).
   
   When eliminating this test (e.g. I removed [2] locally from my
   file-system),
   compilation
   (including tests) is completed successfully.
   
   Anyone else encountered this problem / any idea what the problem might
   be?
   
   
   Thanks,
   Einav
   
   
   [1] performed the following on the latest upstream:
   mvn clean
   mvn install -Pgwt-user,gwt-admin,all-langs -Dgwt.userAgent=gecko1_8
   
   [2]
   ../backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/RemoveSnapshotCommandTest.java
   
   [3] last lines in compilation output:
   ...
   [INFO]
   
   [INFO] Building Backend Logic @Service bean 3.3.0-SNAPSHOT
   [INFO]
   
   ...
   
   Running org.ovirt.engine.core.bll.network.host.SetupNetworksHelperTest
   Tests run: 56, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.74 sec
   Running
   org.ovirt.engine.core.bll.network.cluster.GetAllNetworksByClusterIdQueryTest
   Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 sec
   Running
   org.ovirt.engine.core.bll.network.cluster.AttachNetworkToVdsGroupCommandTest
   Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec
   Running
   org.ovirt.engine.core.bll.network.cluster.NetworkClusterValidatorTest
   Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047 sec
   Running
   org.ovirt.engine.core.bll.network.cluster.GetVdsGroupsAndNetworksByNetworkIdQueryTest
   Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec
   Running
   org.ovirt.engine.core.bll.network.vm.GetVmInterfacesByVmIdQueryTest
   Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec
   Running
   org.ovirt.engine.core.bll.network.vm.GetVmsAndNetworkInterfacesByNetworkIdQueryTest
   Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.056 sec
   Running org.ovirt.engine.core.bll.network.VmInterfaceManagerTest
   Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.321
   sec
   Running
   org.ovirt.engine.core.bll.network.template.GetTemplateInterfacesByTemplateIdQueryTest
   Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec
   Running
   org.ovirt.engine.core.bll.network.template.GetVmTemplatesAndNetworkInterfacesByNetworkIdQueryTest
   Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 sec
   Running
   org.ovirt.engine.core.bll.GetCommandsCompatibilityVersionsQueryTest
   Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec
   Running org.ovirt.engine.core.bll.GetClustersWithPermittedActionQueryTest
   Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec
   Running org.ovirt.engine.core.bll.RemoveSnapshotCommandTest

Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest?

[Allon Mureinik]

OK, patch is merged (thanks kind reviewers!)

Einav - please check that this also solves the issue in /your/ setup and let us 
all know.


Thanks,
Allon

- Original Message -
 From: Allon Mureinik amure...@redhat.com
 To: Einav Cohen eco...@redhat.com
 Cc: engine-devel engine-devel@ovirt.org
 Sent: Tuesday, April 9, 2013 10:24:02 AM
 Subject: Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest?
 
 The last message would have been much more useful if I'd actually attached
 the link to my patch:
 http://gerrit.ovirt.org/#/c/13733/
 
 Note that it is /not/ merge yet - review would be appreciated.
 - Original Message -
  From: Allon Mureinik amure...@redhat.com
  To: Einav Cohen eco...@redhat.com
  Cc: engine-devel engine-devel@ovirt.org
  Sent: Tuesday, April 9, 2013 10:22:38 AM
  Subject: Re: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest?
  
  OK, my guess is that test uses Mockito Matchers carelessly.
  
  I removed them, and on my setup I reduced the time it takes to run this
  test
  alone in eclipse from ~70 seconds to ~0.7 seconds (i.e., removed 99% of the
  runtime).
  
  Please check it solves the issue on your setup too.
  
  
  Thanks,
  Allon
  
  - Original Message -
   From: Allon Mureinik amure...@redhat.com
   To: Einav Cohen eco...@redhat.com
   Cc: engine-devel engine-devel@ovirt.org
   Sent: Tuesday, April 9, 2013 9:39:41 AM
   Subject: Re: [Engine-devel] compilation stuck on
   RemoveSnapshotCommandTest?
   
   When running [1] on this morning's master (commit hash eca9964, merged
   April
   8th, 20:15 IST) I didn't notice any issues (built the entire project in
   ~3
   minutes, backend took 27 seconds), but when running this test alone in
   eclipse it definitely took much longer.
   
   I'm guessing it lacks some mocking, which some earlier test is doing by
   mistake.
   Since JUnit does not enforce any ordering, we may be running our tests in
   a
   slightly different order (due to different maven/java/os minor versions,
   etc.), which makes the problem visible on your setup but not mine.
   
   I'll do somemore digging and see if I can pinpoint it.
   
   - Original Message -
From: Einav Cohen eco...@redhat.com
To: engine-devel engine-devel@ovirt.org
Sent: Monday, April 8, 2013 6:35:47 PM
Subject: [Engine-devel] compilation stuck on RemoveSnapshotCommandTest?

Hi,

When trying to compile oVirt (with tests - see [1]), my compilation
seems
to
get stuck on
RemoveSnapshotCommandTest (see [2] for test file full path, [3] for
output).

When eliminating this test (e.g. I removed [2] locally from my
file-system),
compilation
(including tests) is completed successfully.

Anyone else encountered this problem / any idea what the problem might
be?


Thanks,
Einav


[1] performed the following on the latest upstream:
mvn clean
mvn install -Pgwt-user,gwt-admin,all-langs -Dgwt.userAgent=gecko1_8

[2]
../backend/manager/modules/bll/src/test/java/org/ovirt/engine/core/bll/RemoveSnapshotCommandTest.java

[3] last lines in compilation output:
...
[INFO]

[INFO] Building Backend Logic @Service bean 3.3.0-SNAPSHOT
[INFO]

...

Running org.ovirt.engine.core.bll.network.host.SetupNetworksHelperTest
Tests run: 56, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.74
sec
Running
org.ovirt.engine.core.bll.network.cluster.GetAllNetworksByClusterIdQueryTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064
sec
Running
org.ovirt.engine.core.bll.network.cluster.AttachNetworkToVdsGroupCommandTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046
sec
Running
org.ovirt.engine.core.bll.network.cluster.NetworkClusterValidatorTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.047
sec
Running
org.ovirt.engine.core.bll.network.cluster.GetVdsGroupsAndNetworksByNetworkIdQueryTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035
sec
Running
org.ovirt.engine.core.bll.network.vm.GetVmInterfacesByVmIdQueryTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042
sec
Running
org.ovirt.engine.core.bll.network.vm.GetVmsAndNetworkInterfacesByNetworkIdQueryTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.056
sec
Running org.ovirt.engine.core.bll.network.VmInterfaceManagerTest
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.321
sec
Running
org.ovirt.engine.core.bll.network.template.GetTemplateInterfacesByTemplateIdQueryTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed

Re: [Engine-devel] Java 7, revisited again

[Allon Mureinik]

After a week of positive reviews in gerrit, and no objections voiced here, 
patch was merged.

piped catch clauses, here we come.

- Original Message -
 From: Allon Mureinik amure...@redhat.com
 To: Kanagaraj kmayi...@redhat.com
 Cc: engine-devel engine-devel@ovirt.org
 Sent: Wednesday, April 3, 2013 10:06:34 AM
 Subject: Re: [Engine-devel] Java 7, revisited again
 
 Good point, thanks!
 
 Fixed up the patch and uploaded a new version.
 
 - Original Message -
  From: Kanagaraj kmayi...@redhat.com
  To: Allon Mureinik amure...@redhat.com
  Cc: engine-devel engine-devel@ovirt.org
  Sent: Wednesday, April 3, 2013 7:23:16 AM
  Subject: Re: [Engine-devel] Java 7, revisited again
  
  On 04/02/2013 07:03 PM, Allon Mureinik wrote:
   Hola,
  
   A couple of weeks (months?) ago we discussed upgrading to Java 7.[1]
   Generally, there was a positive vibe about moving forward with
   technology,
   although we noted that this should not be done for common, compat and the
   GWT modules,
  
  searchbackend is also used by GWT, this needs to be excluded as well.
  
  Thanks,
  Kanagaraj
  
   under the limitation of the current GWT version we're using.
  
   Here's an initial suggestion for this upgrade:
   http://gerrit.ovirt.org/#/c/13519/
  
   Areas handled and checked:
   1. compilation (including GWT compilation)[2]
   2. animal-sniffer validations for to makes sure that modules that aren't
   supposed to use JDK7 features really don't[2]
   3. Running and making sure the UI still works :-)
   (checkstyle issues which Laslo pointed out in the original discussion
   were
   already solved in a different patch merged long ago)
  
  
   Sincerely,
   Allon and Alissa
  
   [1]
   http://lists.ovirt.org/pipermail/engine-devel/2012-December/003139.html
   [2] This includes, of course, purposely introducing Java 7 syntax and JDK
   7
   features to modules that aren't supposed to have them,
and making sure that the build fails early, as expected, without
having to add the -Pgwt-admin or -Pgwt-user profiles.
   ___
   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] CreateComputerAccount - do we really need it?

[Allon Mureinik]

- Original Message -
 From: Yair Zaslavsky yzasl...@redhat.com
 To: Omer Frenkel ofren...@redhat.com
 Cc: engine-devel@ovirt.org
 Sent: Sunday, March 17, 2013 12:12:21 PM
 Subject: Re: [Engine-devel] CreateComputerAccount - do we really need it?
 
 
 
 - Original Message -
  From: Omer Frenkel ofren...@redhat.com
  To: Yair Zaslavsky yzasl...@redhat.com
  Cc: engine-devel@ovirt.org
  Sent: Sunday, March 17, 2013 12:08:14 PM
  Subject: Re: [Engine-devel] CreateComputerAccount - do we really
  need it?
  
  
  
  - Original Message -
   From: Yair Zaslavsky yzasl...@redhat.com
   To: engine-devel@ovirt.org
   Sent: Sunday, March 17, 2013 12:01:37 PM
   Subject: [Engine-devel] CreateComputerAccount - do we really need
   it?
   
   Hi all,
   Do we need CreateComputerAccountCommand and its correspoding ldap
   broker LdapCreateComputerAccountCommand?
  
  
  is it exposed by any of the front-ends? (rest/user
  portal/webadmin)?
 
 No.
git grep shows no-one uses it.
Yair - are you sending a patch to remove it?

 
   
   
   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 mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel

Re: [Engine-devel] Proposing Kiril nesenko as power user for ovirt engine tools

[Allon Mureinik]

+1

- Original Message -
 From: Eyal Edri ee...@redhat.com
 To: infra in...@ovirt.org
 Cc: knesenko knese...@redhat.com, engine-devel engine-devel@ovirt.org
 Sent: Thursday, February 7, 2013 10:39:47 AM
 Subject: [Engine-devel] Proposing Kiril nesenko as power user for ovirt  
 engine tools
 
 Hi,
 
 I would like to propose kiril nesenko as 'jenkins power user' for
 ovirt engine tools.
 These tools indlude iso uploader, log collector, image uploader and
 others.
 
 Kiril is very involved in building and running Jenkins jobs on the
 rhevm product,
 and maintains  package the ovirt tools currently.
 As part of being power user on jenkins.ovirt.org, he will create new
 jobs to build and release tools for the various OS supported.
 
 I vote +1 as i personally know kiril and he's experience.
 
 Thansk,
 
 Eyal.
 ___
 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 Jenkins] ovirt_engine_unit_tests - Build # 3216 - Still unstable!

[Allon Mureinik]

Fixed in http://gerrit.ovirt.org/#/c/11413/.

- Original Message -
 From: Eyal Edri ee...@redhat.com
 To: Gilad Chaplik gchap...@redhat.com, engine-devel 
 engine-devel@ovirt.org
 Sent: Friday, January 25, 2013 2:32:50 PM
 Subject: Re: [Engine-devel] [oVirt Jenkins] ovirt_engine_unit_tests - Build # 
 3216 - Still unstable!
 
 fyi,
 
 seems like this patch introduced new unit test failure, please check,
 
 http://gerrit.ovirt.org/gitweb?p=ovirt-engine.gita=commith=207cda518399d0474154d5c3a9c363bcc43b6a72
 http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/3212/
 
 
 Eyal.
 Infra team.
 
 - Original Message -
  From: Jenkins oVirt Server jenk...@ovirt.org
  To: ee...@redhat.com, engine-patc...@ovirt.org, ol...@redhat.com,
  yzasl...@redhat.com
  Sent: Friday, January 25, 2013 11:49:10 AM
  Subject: [oVirt Jenkins] ovirt_engine_unit_tests - Build # 3216 -
  Still unstable!
  
  Project: http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/
  Build: http://jenkins.ovirt.org/job/ovirt_engine_unit_tests/3216/
  Build Number: 3216
  Build Status:  Still unstable
  Triggered By: Started by upstream project ovirt_engine build
  number
  4,107, Started by upstream project ovirt_engine build number
  4,109
  
  -
  Changes Since Last Success:
  -
  Changes for Build #3212
  [gerrit2] engine: consolidate VM and Poll queries
  
  
  Changes for Build #3213
  [gerrit2] core:unlock_entity.sh is not finding a locked ...
  
  [gerrit2] core:unlock_entity.sh is not unlocking the vm...
  
  [emesika] core:If no power management configured or fails...
  
  
  Changes for Build #3214
  
  Changes for Build #3215
  [gerrit2] packaging: Starting ssh before adding host in AIO
  
  [gerrit2] packaging: Updated spec to use sdk version that supports
  ssl.
  
  [gerrit2] spelling: s/mster/master/
  
  
  Changes for Build #3216
  
  
  
  -
  Failed Tests:
  -
  1 tests failed.
  FAILED:
   
  org.ovirt.engine.core.bll.GetAllVmPoolsAttachedToUserQueryTest.testQueryIsAUserQuery
  
  Error Message:
  A query tested for filtered access should not be an admin query
  
  Stack Trace:
  java.lang.AssertionError: A query tested for filtered access should
  not be an admin query
  at org.junit.Assert.fail(Assert.java:93)
  at org.junit.Assert.assertTrue(Assert.java:43)
  at org.junit.Assert.assertFalse(Assert.java:68)
  at
  
  org.ovirt.engine.core.bll.AbstractUserQueryTest.testQueryIsAUserQuery(AbstractUserQueryTest.java:58)
  at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
  at
  
  sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:601)
  at
  
  org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
  at
  
  org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
  at
  
  org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
  at
  
  org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
  at
  
  org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
  at
  
  org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
  at
  
  org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
  at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
  at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
  at
  org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
  at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
  at
  org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
  at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
  at
  
  org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
  at
  
  org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
  at
  
  org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at
  
  sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
  at
  
  sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:601)
  at
  
  org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
  at
  
  org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
  at
  
  org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
  at