[ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 02.03.2017 ] [001_upgrade_engine.py]

Thu Mar 2 09:43:59 UTC 2017

On Thu, Mar 2, 2017 at 11:40 AM Yedidyah Bar David <didi at redhat.com> wrote:

> On Thu, Mar 2, 2017 at 11:34 AM, Yaniv Kaul <ykaul at redhat.com> wrote:
> >
> >
> > On Thu, Mar 2, 2017 at 11:32 AM Yedidyah Bar David <didi at redhat.com>
> wrote:
> >>
> >> On Thu, Mar 2, 2017 at 11:24 AM, Pavel Zhukov <pzhukov at 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 at 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 at ovirt.org
> >> >>> http://lists.ovirt.org/mailman/listinfo/devel
> >> >>>
> >> >
> >> >
> >> > --
> >> > Pavel Zhukov
> >> > Software Engineer
> >> > RHV DevOps
> >> > IRC: landgraf
> >>
> >>
> >>
> >> --
> >> Didi
> >> _______________________________________________
> >> Devel mailing list
> >> Devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
> --
> Didi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170302/c9406cbe/attachment.html>