[ OST Failure Report ] [ oVirt master ] [ 02.03.2017 ] [001_upgrade_engine.py]
Hello, ovirt-engine upgrade is failed on 'rpm -q' command [2] so job [1] was marked as failed. It's reproducible and started from build [1] onward. I don't see any relevant patches in otopi/engine merged recently so no suspected patches sp far. [1] http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_experi... [2] 2017-03-02 02:48:13 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine_common.distro-rpm.packages plugin.execute:926 execute-output: ('/bin/rpm', '-q', 'ovirt-engine-webadmin-portal', 'ovirt-engine-dwh', 'ovirt-engine', 'ovirt-engine-restapi', 'ovirt-engine-dbscripts', 'ovirt-engine-tools-backup', 'ovirt-engine-dashboard', 'ovirt-engine-userportal', 'ovirt-engine-wildfly', 'ovirt-engine-backend', 'ovirt-engine-wildfly-overlay', 'ovirt-engine-hosts-ansible-inventory', 'ovirt-engine-tools', 'ovirt-engine-extension-aaa-jdbc') stderr: 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'Yum Transaction' Loaded plugins: fastestmirror, versionlock 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'DWH Engine database Transaction' 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'Database Transaction' 2017-03-02 02:48:13 DEBUG otopi.context context._executeMethod:142 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in _executeMethod method['method']() File "/usr/share/otopi/plugins/otopi/core/transaction.py", line 93, in _main_end self._mainTransaction.commit() File "/usr/lib/python2.7/site-packages/otopi/transaction.py", line 148, in commit element.commit() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine-common/distro-rpm/packages.py", line 146, in commit osetupcons.RPMDistroEnv.VERSION_LOCK_APPLY File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 931, in execute command=args[0], RuntimeError: Command '/bin/rpm' failed to execute 2017-03-02 02:48:13 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Transaction commit': Command '/bin/rpm' failed to execute -- Pavel
ovirt-engine-hosts-ansible-inventory has been dropped in favor of ovirt-engine-metrics Maybe this is the root cause. On Thu, Mar 2, 2017 at 9:23 AM, Pavel Zhukov <pzhukov@redhat.com> wrote:
Hello,
ovirt-engine upgrade is failed on 'rpm -q' command [2] so job [1] was marked as failed. It's reproducible and started from build [1] onward. I don't see any relevant patches in otopi/engine merged recently so no suspected patches sp far.
[1] http://jenkins.ovirt.org/view/experimental%20jobs/job/test- repo_ovirt_experimental_master/5626/
[2]
2017-03-02 02:48:13 DEBUG otopi.plugins.ovirt_engine_ setup.ovirt_engine_common.distro-rpm.packages plugin.execute:926 execute-output: ('/bin/rpm', '-q', 'ovirt-engine-webadmin-portal', 'ovirt-engine-dwh', 'ovirt-engine', 'ovirt-engine-restapi', 'ovirt-engine-dbscripts', 'ovirt-engine-tools-backup', 'ovirt-engine-dashboard', 'ovirt-engine-userportal', 'ovirt-engine-wildfly', 'ovirt-engine-backend', 'ovirt-engine-wildfly-overlay', 'ovirt-engine-hosts-ansible-inventory', 'ovirt-engine-tools', 'ovirt-engine-extension-aaa-jdbc') stderr:
2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'Yum Transaction' Loaded plugins: fastestmirror, versionlock 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'DWH Engine database Transaction' 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'Database Transaction' 2017-03-02 02:48:13 DEBUG otopi.context context._executeMethod:142 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in _executeMethod method['method']() File "/usr/share/otopi/plugins/otopi/core/transaction.py", line 93, in _main_end self._mainTransaction.commit() File "/usr/lib/python2.7/site-packages/otopi/transaction.py", line 148, in commit element.commit() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt- engine-setup/ovirt-engine-common/distro-rpm/packages.py", line 146, in commit osetupcons.RPMDistroEnv.VERSION_LOCK_APPLY File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 931, in execute command=args[0], RuntimeError: Command '/bin/rpm' failed to execute 2017-03-02 02:48:13 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Transaction commit': Command '/bin/rpm' failed to execute
-- Pavel _______________________________________________ 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
On Thu, Mar 02 2017, Sandro Bonazzola wrote:
ovirt-engine-hosts-ansible-inventory has been dropped in favor of ovirt-engine-metrics Maybe this is the root cause. Right, I see the fix was merged https://gerrit.ovirt.org/73415 and the job is green now. Thank you!
On Thu, Mar 2, 2017 at 9:23 AM, Pavel Zhukov <pzhukov@redhat.com> wrote:
Hello,
ovirt-engine upgrade is failed on 'rpm -q' command [2] so job [1] was marked as failed. It's reproducible and started from build [1] onward. I don't see any relevant patches in otopi/engine merged recently so no suspected patches sp far.
[1] http://jenkins.ovirt.org/view/experimental%20jobs/job/test- repo_ovirt_experimental_master/5626/
[2]
2017-03-02 02:48:13 DEBUG otopi.plugins.ovirt_engine_ setup.ovirt_engine_common.distro-rpm.packages plugin.execute:926 execute-output: ('/bin/rpm', '-q', 'ovirt-engine-webadmin-portal', 'ovirt-engine-dwh', 'ovirt-engine', 'ovirt-engine-restapi', 'ovirt-engine-dbscripts', 'ovirt-engine-tools-backup', 'ovirt-engine-dashboard', 'ovirt-engine-userportal', 'ovirt-engine-wildfly', 'ovirt-engine-backend', 'ovirt-engine-wildfly-overlay', 'ovirt-engine-hosts-ansible-inventory', 'ovirt-engine-tools', 'ovirt-engine-extension-aaa-jdbc') stderr:
2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'Yum Transaction' Loaded plugins: fastestmirror, versionlock 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'DWH Engine database Transaction' 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'Database Transaction' 2017-03-02 02:48:13 DEBUG otopi.context context._executeMethod:142 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in _executeMethod method['method']() File "/usr/share/otopi/plugins/otopi/core/transaction.py", line 93, in _main_end self._mainTransaction.commit() File "/usr/lib/python2.7/site-packages/otopi/transaction.py", line 148, in commit element.commit() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt- engine-setup/ovirt-engine-common/distro-rpm/packages.py", line 146, in commit osetupcons.RPMDistroEnv.VERSION_LOCK_APPLY File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 931, in execute command=args[0], RuntimeError: Command '/bin/rpm' failed to execute 2017-03-02 02:48:13 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Transaction commit': Command '/bin/rpm' failed to execute
-- Pavel _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Pavel Zhukov Software Engineer RHV DevOps IRC: landgraf
On Thu, Mar 2, 2017 at 11:24 AM, Pavel Zhukov <pzhukov@redhat.com> wrote:
On Thu, Mar 02 2017, Sandro Bonazzola wrote:
ovirt-engine-hosts-ansible-inventory has been dropped in favor of ovirt-engine-metrics Maybe this is the root cause. Right, I see the fix was merged https://gerrit.ovirt.org/73415 and the job is green now.
We merged ovirt-engine-metrics-1.0.0 and made sure it was built correctly by build-artifacts, prior to merging the engine patch that needs it. If that's not enough, please explain how should such things - two patches in two different git repos that need to be merged and then tested in a specific order - should be handled in the future. The relevant patches, in current case, are: https://gerrit.ovirt.org/73414 Build ovirt-engine-metrics-1.0.0. build-artifacts finished at 09:36 (IST). https://gerrit.ovirt.org/73363 Remove ovirt-engine-hosts-ansible-inventory, and require ovirt-engine-metrics, which replaces it. Merged at 09:40, build-artifacts finished 10:00. Can we expect ost to run on packages based on the order in which they were merged, or built? If not, is there any other assumption we can make re the order? Also, can we affect this order somehow? Thanks,
Thank you!
On Thu, Mar 2, 2017 at 9:23 AM, Pavel Zhukov <pzhukov@redhat.com> wrote:
Hello,
ovirt-engine upgrade is failed on 'rpm -q' command [2] so job [1] was marked as failed. It's reproducible and started from build [1] onward. I don't see any relevant patches in otopi/engine merged recently so no suspected patches sp far.
[1] http://jenkins.ovirt.org/view/experimental%20jobs/job/test- repo_ovirt_experimental_master/5626/
[2]
2017-03-02 02:48:13 DEBUG otopi.plugins.ovirt_engine_ setup.ovirt_engine_common.distro-rpm.packages plugin.execute:926 execute-output: ('/bin/rpm', '-q', 'ovirt-engine-webadmin-portal', 'ovirt-engine-dwh', 'ovirt-engine', 'ovirt-engine-restapi', 'ovirt-engine-dbscripts', 'ovirt-engine-tools-backup', 'ovirt-engine-dashboard', 'ovirt-engine-userportal', 'ovirt-engine-wildfly', 'ovirt-engine-backend', 'ovirt-engine-wildfly-overlay', 'ovirt-engine-hosts-ansible-inventory', 'ovirt-engine-tools', 'ovirt-engine-extension-aaa-jdbc') stderr:
2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'Yum Transaction' Loaded plugins: fastestmirror, versionlock 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'DWH Engine database Transaction' 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'Database Transaction' 2017-03-02 02:48:13 DEBUG otopi.context context._executeMethod:142 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in _executeMethod method['method']() File "/usr/share/otopi/plugins/otopi/core/transaction.py", line 93, in _main_end self._mainTransaction.commit() File "/usr/lib/python2.7/site-packages/otopi/transaction.py", line 148, in commit element.commit() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt- engine-setup/ovirt-engine-common/distro-rpm/packages.py", line 146, in commit osetupcons.RPMDistroEnv.VERSION_LOCK_APPLY File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 931, in execute command=args[0], RuntimeError: Command '/bin/rpm' failed to execute 2017-03-02 02:48:13 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Transaction commit': Command '/bin/rpm' failed to execute
-- Pavel _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Pavel Zhukov Software Engineer RHV DevOps IRC: landgraf
-- Didi
On Thu, Mar 2, 2017 at 11:32 AM Yedidyah Bar David <didi@redhat.com> wrote:
On Thu, Mar 2, 2017 at 11:24 AM, Pavel Zhukov <pzhukov@redhat.com> wrote:
On Thu, Mar 02 2017, Sandro Bonazzola wrote:
ovirt-engine-hosts-ansible-inventory has been dropped in favor of ovirt-engine-metrics Maybe this is the root cause. Right, I see the fix was merged https://gerrit.ovirt.org/73415 and the
job
is green now.
We merged ovirt-engine-metrics-1.0.0 and made sure it was built correctly by build-artifacts, prior to merging the engine patch that needs it.
If that's not enough, please explain how should such things - two patches in two different git repos that need to be merged and then tested in a specific order - should be handled in the future.
Don't think there's a very good solution to this in our current architecture. I think it's quite alright for the CI to fail on this - and then to succeed when fixed. Y.
The relevant patches, in current case, are:
https://gerrit.ovirt.org/73414
Build ovirt-engine-metrics-1.0.0. build-artifacts finished at 09:36 (IST).
https://gerrit.ovirt.org/73363
Remove ovirt-engine-hosts-ansible-inventory, and require ovirt-engine-metrics, which replaces it. Merged at 09:40, build-artifacts finished 10:00.
Can we expect ost to run on packages based on the order in which they were merged, or built? If not, is there any other assumption we can make re the order? Also, can we affect this order somehow?
Thanks,
Thank you!
On Thu, Mar 2, 2017 at 9:23 AM, Pavel Zhukov <pzhukov@redhat.com>
wrote:
Hello,
ovirt-engine upgrade is failed on 'rpm -q' command [2] so job [1] was marked as failed. It's reproducible and started from build [1] onward. I don't see any relevant patches in otopi/engine merged recently so no suspected patches sp far.
[1] http://jenkins.ovirt.org/view/experimental%20jobs/job/test- repo_ovirt_experimental_master/5626/
[2]
2017-03-02 02:48:13 DEBUG otopi.plugins.ovirt_engine_ setup.ovirt_engine_common.distro-rpm.packages plugin.execute:926 execute-output: ('/bin/rpm', '-q', 'ovirt-engine-webadmin-portal', 'ovirt-engine-dwh', 'ovirt-engine', 'ovirt-engine-restapi', 'ovirt-engine-dbscripts', 'ovirt-engine-tools-backup', 'ovirt-engine-dashboard', 'ovirt-engine-userportal', 'ovirt-engine-wildfly', 'ovirt-engine-backend', 'ovirt-engine-wildfly-overlay', 'ovirt-engine-hosts-ansible-inventory', 'ovirt-engine-tools', 'ovirt-engine-extension-aaa-jdbc') stderr:
2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119
aborting
'Yum Transaction' Loaded plugins: fastestmirror, versionlock 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'DWH Engine database Transaction' 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'Database Transaction' 2017-03-02 02:48:13 DEBUG otopi.context context._executeMethod:142 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in _executeMethod method['method']() File "/usr/share/otopi/plugins/otopi/core/transaction.py", line 93, in _main_end self._mainTransaction.commit() File "/usr/lib/python2.7/site-packages/otopi/transaction.py", line 148, in commit element.commit() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt- engine-setup/ovirt-engine-common/distro-rpm/packages.py", line 146, in commit osetupcons.RPMDistroEnv.VERSION_LOCK_APPLY File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 931, in execute command=args[0], RuntimeError: Command '/bin/rpm' failed to execute 2017-03-02 02:48:13 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Transaction commit': Command '/bin/rpm' failed to execute
-- Pavel _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Pavel Zhukov Software Engineer RHV DevOps IRC: landgraf
-- Didi _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Thu, Mar 2, 2017 at 11:34 AM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Thu, Mar 2, 2017 at 11:32 AM Yedidyah Bar David <didi@redhat.com> wrote:
On Thu, Mar 2, 2017 at 11:24 AM, Pavel Zhukov <pzhukov@redhat.com> wrote:
On Thu, Mar 02 2017, Sandro Bonazzola wrote:
ovirt-engine-hosts-ansible-inventory has been dropped in favor of ovirt-engine-metrics Maybe this is the root cause. Right, I see the fix was merged https://gerrit.ovirt.org/73415 and the job is green now.
We merged ovirt-engine-metrics-1.0.0 and made sure it was built correctly by build-artifacts, prior to merging the engine patch that needs it.
If that's not enough, please explain how should such things - two patches in two different git repos that need to be merged and then tested in a specific order - should be handled in the future.
Don't think there's a very good solution to this in our current architecture.
But for sure there is _something_ we can say, no? If I wait a day, might this not be enough either?
I think it's quite alright for the CI to fail on this - and then to succeed when fixed.
Of course, in general. I just want to understand what's the minimum I need to do (wait some more, something else?) to save some noise...
Y.
The relevant patches, in current case, are:
https://gerrit.ovirt.org/73414
Build ovirt-engine-metrics-1.0.0. build-artifacts finished at 09:36 (IST).
https://gerrit.ovirt.org/73363
Remove ovirt-engine-hosts-ansible-inventory, and require ovirt-engine-metrics, which replaces it. Merged at 09:40, build-artifacts finished 10:00.
Can we expect ost to run on packages based on the order in which they were merged, or built? If not, is there any other assumption we can make re the order? Also, can we affect this order somehow?
Thanks,
Thank you!
On Thu, Mar 2, 2017 at 9:23 AM, Pavel Zhukov <pzhukov@redhat.com> wrote:
Hello,
ovirt-engine upgrade is failed on 'rpm -q' command [2] so job [1] was marked as failed. It's reproducible and started from build [1] onward. I don't see any relevant patches in otopi/engine merged recently so no suspected patches sp far.
[1] http://jenkins.ovirt.org/view/experimental%20jobs/job/test- repo_ovirt_experimental_master/5626/
[2]
2017-03-02 02:48:13 DEBUG otopi.plugins.ovirt_engine_ setup.ovirt_engine_common.distro-rpm.packages plugin.execute:926 execute-output: ('/bin/rpm', '-q', 'ovirt-engine-webadmin-portal', 'ovirt-engine-dwh', 'ovirt-engine', 'ovirt-engine-restapi', 'ovirt-engine-dbscripts', 'ovirt-engine-tools-backup', 'ovirt-engine-dashboard', 'ovirt-engine-userportal', 'ovirt-engine-wildfly', 'ovirt-engine-backend', 'ovirt-engine-wildfly-overlay', 'ovirt-engine-hosts-ansible-inventory', 'ovirt-engine-tools', 'ovirt-engine-extension-aaa-jdbc') stderr:
2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'Yum Transaction' Loaded plugins: fastestmirror, versionlock 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'DWH Engine database Transaction' 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'Database Transaction' 2017-03-02 02:48:13 DEBUG otopi.context context._executeMethod:142 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in _executeMethod method['method']() File "/usr/share/otopi/plugins/otopi/core/transaction.py", line 93, in _main_end self._mainTransaction.commit() File "/usr/lib/python2.7/site-packages/otopi/transaction.py", line 148, in commit element.commit() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt- engine-setup/ovirt-engine-common/distro-rpm/packages.py", line 146, in commit osetupcons.RPMDistroEnv.VERSION_LOCK_APPLY File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 931, in execute command=args[0], RuntimeError: Command '/bin/rpm' failed to execute 2017-03-02 02:48:13 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Transaction commit': Command '/bin/rpm' failed to execute
-- Pavel _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Pavel Zhukov Software Engineer RHV DevOps IRC: landgraf
-- Didi _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Didi
On Thu, Mar 2, 2017 at 11:40 AM Yedidyah Bar David <didi@redhat.com> wrote:
On Thu, Mar 2, 2017 at 11:34 AM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Thu, Mar 2, 2017 at 11:32 AM Yedidyah Bar David <didi@redhat.com>
On Thu, Mar 2, 2017 at 11:24 AM, Pavel Zhukov <pzhukov@redhat.com>
wrote:
On Thu, Mar 02 2017, Sandro Bonazzola wrote:
ovirt-engine-hosts-ansible-inventory has been dropped in favor of ovirt-engine-metrics Maybe this is the root cause. Right, I see the fix was merged https://gerrit.ovirt.org/73415 and
job is green now.
We merged ovirt-engine-metrics-1.0.0 and made sure it was built correctly by build-artifacts, prior to merging the engine patch that needs it.
If that's not enough, please explain how should such things - two
wrote: the patches
in two different git repos that need to be merged and then tested in a specific order - should be handled in the future.
Don't think there's a very good solution to this in our current architecture.
But for sure there is _something_ we can say, no?
If I wait a day, might this not be enough either?
I don't see who's going to wait - especially as we'll be moving to running CI more and more - hopefully per patch at some point.
I think it's quite alright for the CI to fail on this - and then to succeed when fixed.
Of course, in general. I just want to understand what's the minimum I need to do (wait some more, something else?) to save some noise...
Mainly communication - a heads up that you are about to break CI and will fix it right after makes sense to me. There are more sophisticated solutions (Zuul?) out there, but I think straightforward communication is the easiest, at this point - it doesn't happen often. Y.
Y.
The relevant patches, in current case, are:
https://gerrit.ovirt.org/73414
Build ovirt-engine-metrics-1.0.0. build-artifacts finished at 09:36 (IST).
https://gerrit.ovirt.org/73363
Remove ovirt-engine-hosts-ansible-inventory, and require ovirt-engine-metrics, which replaces it. Merged at 09:40, build-artifacts finished 10:00.
Can we expect ost to run on packages based on the order in which they were merged, or built? If not, is there any other assumption we can make re the order? Also, can we affect this order somehow?
Thanks,
Thank you!
On Thu, Mar 2, 2017 at 9:23 AM, Pavel Zhukov <pzhukov@redhat.com> wrote:
Hello,
ovirt-engine upgrade is failed on 'rpm -q' command [2] so job [1]
was
marked as failed. It's reproducible and started from build [1] onward. I don't see any relevant patches in otopi/engine merged recently so no suspected patches sp far.
[1] http://jenkins.ovirt.org/view/experimental%20jobs/job/test- repo_ovirt_experimental_master/5626/
[2]
2017-03-02 02:48:13 DEBUG otopi.plugins.ovirt_engine_ setup.ovirt_engine_common.distro-rpm.packages plugin.execute:926 execute-output: ('/bin/rpm', '-q', 'ovirt-engine-webadmin-portal', 'ovirt-engine-dwh', 'ovirt-engine', 'ovirt-engine-restapi', 'ovirt-engine-dbscripts', 'ovirt-engine-tools-backup', 'ovirt-engine-dashboard', 'ovirt-engine-userportal', 'ovirt-engine-wildfly', 'ovirt-engine-backend', 'ovirt-engine-wildfly-overlay', 'ovirt-engine-hosts-ansible-inventory', 'ovirt-engine-tools', 'ovirt-engine-extension-aaa-jdbc') stderr:
2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'Yum Transaction' Loaded plugins: fastestmirror, versionlock 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'DWH Engine database Transaction' 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'Database Transaction' 2017-03-02 02:48:13 DEBUG otopi.context context._executeMethod:142 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in _executeMethod method['method']() File "/usr/share/otopi/plugins/otopi/core/transaction.py", line 93, in _main_end self._mainTransaction.commit() File "/usr/lib/python2.7/site-packages/otopi/transaction.py", line 148, in commit element.commit() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt- engine-setup/ovirt-engine-common/distro-rpm/packages.py", line 146, in commit osetupcons.RPMDistroEnv.VERSION_LOCK_APPLY File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 931, in execute command=args[0], RuntimeError: Command '/bin/rpm' failed to execute 2017-03-02 02:48:13 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Transaction commit': Command '/bin/rpm' failed to execute
-- Pavel _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Pavel Zhukov Software Engineer RHV DevOps IRC: landgraf
-- Didi _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Didi
On 2 March 2017 at 11:34, Yaniv Kaul <ykaul@redhat.com> wrote:
If that's not enough, please explain how should such things - two patches in two different git repos that need to be merged and then tested in a specific order - should be handled in the future.
Don't think there's a very good solution to this in our current architecture.
Yeah, this is what https://gerrit.ovirt.org/#/c/71353/ is aimed at... -- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
On Thu, Mar 02 2017, Yedidyah Bar David wrote:
On Thu, Mar 2, 2017 at 11:24 AM, Pavel Zhukov <pzhukov@redhat.com> wrote:
On Thu, Mar 02 2017, Sandro Bonazzola wrote:
ovirt-engine-hosts-ansible-inventory has been dropped in favor of ovirt-engine-metrics Maybe this is the root cause. Right, I see the fix was merged https://gerrit.ovirt.org/73415 and the job is green now.
We merged ovirt-engine-metrics-1.0.0 and made sure it was built correctly by build-artifacts, prior to merging the engine patch that needs it. Maybe wait for deploy-to-experimental job which deploys built rpm to the repo...
If that's not enough, please explain how should such things - two patches in two different git repos that need to be merged and then tested in a specific order - should be handled in the future.
The relevant patches, in current case, are:
https://gerrit.ovirt.org/73414
Build ovirt-engine-metrics-1.0.0. build-artifacts finished at 09:36 (IST).
https://gerrit.ovirt.org/73363
Remove ovirt-engine-hosts-ansible-inventory, and require ovirt-engine-metrics, which replaces it. Merged at 09:40, build-artifacts finished 10:00.
Can we expect ost to run on packages based on the order in which they were merged, or built? If not, is there any other assumption we can make re the order? Also, can we affect this order somehow? Sounds like RFE. Different project are independent and can take different ammount of time to be built and tested/verified by CI so I'd not try to make an assumptions here...
Thanks,
Thank you!
On Thu, Mar 2, 2017 at 9:23 AM, Pavel Zhukov <pzhukov@redhat.com> wrote:
Hello,
ovirt-engine upgrade is failed on 'rpm -q' command [2] so job [1] was marked as failed. It's reproducible and started from build [1] onward. I don't see any relevant patches in otopi/engine merged recently so no suspected patches sp far.
[1] http://jenkins.ovirt.org/view/experimental%20jobs/job/test- repo_ovirt_experimental_master/5626/
[2]
2017-03-02 02:48:13 DEBUG otopi.plugins.ovirt_engine_ setup.ovirt_engine_common.distro-rpm.packages plugin.execute:926 execute-output: ('/bin/rpm', '-q', 'ovirt-engine-webadmin-portal', 'ovirt-engine-dwh', 'ovirt-engine', 'ovirt-engine-restapi', 'ovirt-engine-dbscripts', 'ovirt-engine-tools-backup', 'ovirt-engine-dashboard', 'ovirt-engine-userportal', 'ovirt-engine-wildfly', 'ovirt-engine-backend', 'ovirt-engine-wildfly-overlay', 'ovirt-engine-hosts-ansible-inventory', 'ovirt-engine-tools', 'ovirt-engine-extension-aaa-jdbc') stderr:
2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'Yum Transaction' Loaded plugins: fastestmirror, versionlock 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'DWH Engine database Transaction' 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'Database Transaction' 2017-03-02 02:48:13 DEBUG otopi.context context._executeMethod:142 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in _executeMethod method['method']() File "/usr/share/otopi/plugins/otopi/core/transaction.py", line 93, in _main_end self._mainTransaction.commit() File "/usr/lib/python2.7/site-packages/otopi/transaction.py", line 148, in commit element.commit() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt- engine-setup/ovirt-engine-common/distro-rpm/packages.py", line 146, in commit osetupcons.RPMDistroEnv.VERSION_LOCK_APPLY File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 931, in execute command=args[0], RuntimeError: Command '/bin/rpm' failed to execute 2017-03-02 02:48:13 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Transaction commit': Command '/bin/rpm' failed to execute
-- Pavel _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Pavel Zhukov Software Engineer RHV DevOps IRC: landgraf
-- Pavel Zhukov Software Engineer RHV DevOps IRC: landgraf
participants (5)
-
Barak Korren -
Pavel Zhukov -
Sandro Bonazzola -
Yaniv Kaul -
Yedidyah Bar David