Re: [ovirt-devel] [VDSM] New versioning scheme
by Eyal Edri
adding infra also,
in case we need to do changes in ci/builds.
On Wed, Jun 1, 2016 at 1:58 PM, Francesco Romani <fromani(a)redhat.com> wrote:
> ----- Original Message -----
> > From: "Nir Soffer" <nsoffer(a)redhat.com>
> > To: "devel" <devel(a)ovirt.org>, "Dan Kenigsberg" <danken(a)redhat.com>,
> "Francesco Romani" <fromani(a)redhat.com>, "Piotr
> > Kliczewski" <pkliczew(a)redhat.com>, "Adam Litke" <alitke(a)redhat.com>,
> "Yaniv Bronheim" <ybronhei(a)redhat.com>, "Sandro
> > Bonazzola" <sbonazzo(a)redhat.com>
> > Sent: Wednesday, June 1, 2016 12:51:49 PM
> > Subject: [VDSM] New versioning scheme
> >
> > Hi all,
> >
> > We are going to branch 4.0 today, and it is a good time to update our
> > versioning scheme.
> >
> > I suggest to use the standard ovirt versioning, use by most projects:
> >
> > 1. master
> >
> > vdsm-4.19.0-201606011345.gitxxxyyy
> >
> > 2. 4.0
> >
> > vdsm-4.18.1
> >
> > The important invariant is that any build from master is considered newer
> > compare with the stable builds, since master always contain all stable
> > code, and new code.
> >
> > Second invariant, the most recent build from master is always newer
> compared
> > with any other master build - the timestamp enforces this.
> >
> > Thoughts?
>
> +1
>
> given how Vdsm build system works, it should be a matter of just pushing
> the 4.19.0 tag against master after the branch
>
> Bests,
>
> --
> Francesco Romani
> RedHat Engineering Virtualization R & D
> Phone: 8261328
> IRC: fromani
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
--
Eyal Edri
Associate Manager
RHEV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
8 years, 5 months
Debugging stuck vdsm jobs
by Nir Soffer
Hi all,
We had 2 issues causing vdsm check-patch and check-merge jobs to get stuck.
I fixed the one that caused most trouble:
https://gerrit.ovirt.org/57993
The other issue may be related to ioprocess, I fixed a related issue:
https://gerrit.ovirt.org/57473
But I have seen stuck jobs after this change, so the issue may not
be fixed yet.
If you see a stuck vdsm job - job that run more than 15 minutes, please
get me a backtrace:
1. locate the test_runner process pid:
$ ps aux | grep testrunner.py | grep -v grep
nsoffer 26297 82.6 0.9 389592 111144 pts/3 R+ 22:52 0:02
/usr/bin/python ../tests/testrunner.py ...
2. save a backtrace:
gdb attach 26297 --batch -ex "thread apply all py-bt" > py-bt.out
Thanks,
Nir
8 years, 5 months