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