On Thu, Mar 2, 2017 at 11:40 AM Yedidyah Bar David <[email protected]> wrote:
> On Thu, Mar 2, 2017 at 11:34 AM, Yaniv Kaul <[email protected]> wrote: > > > > > > On Thu, Mar 2, 2017 at 11:32 AM Yedidyah Bar David <[email protected]> > wrote: > >> > >> On Thu, Mar 2, 2017 at 11:24 AM, Pavel Zhukov <[email protected]> > 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 <[email protected]> > >> >> 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 > >> >>> [email protected] > >> >>> http://lists.ovirt.org/mailman/listinfo/devel > >> >>> > >> > > >> > > >> > -- > >> > Pavel Zhukov > >> > Software Engineer > >> > RHV DevOps > >> > IRC: landgraf > >> > >> > >> > >> -- > >> Didi > >> _______________________________________________ > >> Devel mailing list > >> [email protected] > >> http://lists.ovirt.org/mailman/listinfo/devel > > > > -- > Didi >
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
