8:14 a.m.
All stable branch maintainers,
I just noticed that our oVirt 4.0 nightly repo (
http://resources.ovirt.org/pub/ovirt-4.0-snapshot/ ) still includes a
lot of packages from master branches.
Can you please ensure that our jenkins is building your project
packages in order to compose the 4.0 nightly repo from a stable
branch?
If not, you have to push a patch like https://gerrit.ovirt.org/59150/
to correctly configure the publisher job for 4.0 nightly.
thanks,
Simone
9:24 a.m.
Its relevant for projects who created branch for 4.0.
Do we have a list of those projects? if so we can compare it to the pkg in
the nightly 4.0 repo.
On Tue, Jun 14, 2016 at 4:14 PM, Simone Tiraboschi <stirabos(a)redhat.com>
wrote:
--
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)
9:32 a.m.
example of what should have been done for vdsm:
https://gerrit.ovirt.org/#/c/59168/
any of the project maintainers should check if his project has build for
4.0 in addition to master and update the same file as needed.
On Tue, Jun 14, 2016 at 5:24 PM, Eyal Edri <eedri(a)redhat.com> wrote:
--
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)
9:33 a.m.
----- Original Message -----
I posted this for ovirt-vmconsole:
https://gerrit.ovirt.org/#/c/59158/
--
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani
9:37 a.m.
You don't need to do it francesco if vmconsole doesn't have a 4.0 branch (i
saw you're still using master ?)
In any case, see my previous patch which updates the publisher to publish
the 4.0 rpms that the 4.0 build artifacts for vdsm is creating rather than
master rpms.
On Tue, Jun 14, 2016 at 5:33 PM, Francesco Romani <fromani(a)redhat.com>
wrote:
--
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)
10:34 a.m.
Hi,
ovirt-engine-dashboard is currently built from master as well.
We should probably create a stable branch, e.g. ovirt-engine-dashboard-1.0.
For now, the nightly publisher configs:
jobs/confs/projects/ovirt/publish-rpms-nightly-{master,4.0}.yaml
both use ovirt-engine-dashboard "master" build-artifacts job.
Vojtech
----- Original Message -----
4:06 a.m.
--JHITMubKSiIoiKCLExJ8foN2FBRtH0Q35
Content-Type: multipart/mixed; boundary="qrv430rJEi23QIbTFEhlgaaoflBObNa5w"
From: Sven Kieske <s.kieske(a)mittwald.de>
To: devel(a)ovirt.org
Message-ID: <57626BFE.9040707(a)mittwald.de>
X-Authenticated-mymxserver.com: Yes
Subject: Re: [ovirt-devel] oVirt 4.0 Nightly repo
References: <CAN8-ONooie-Qop2dPfthaatk=Lacqpq1St9Yg_vy0gROipG-XA(a)mail.gmail.com>
<1616714012.70895771.1465918472171.JavaMail.zimbra(a)redhat.com>
In-Reply-To: <1616714012.70895771.1465918472171.JavaMail.zimbra(a)redhat.com>
--qrv430rJEi23QIbTFEhlgaaoflBObNa5w
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 14/06/16 17:34, Vojtech Szocs wrote:
1.0.
Hi,
speaking as an end user (mostly):
please not yet-another-versioning in the great ovirt project.
I'm already having severe issues tracking which engine versions works
with which vdsm version, let alone track which datacenter and cluster
version within each engine version works with which vdsm version and
which features are (un)supported.
Please don't add another different version to the already far to complex
equation.
I'd suggest you take the same version number as the supported
ovirt-engine, you also should adjust release cycles of all the
subprojects where possible (I know that doesn't work always).
this would make every users life make so much less painful.
keep up the great work!
--=20
Mit freundlichen Gr=FC=DFen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
K=F6nigsberger Stra=DFe 6
32339 Espelkamp
T: +495772 293100
F: +495772 293333
https://www.mittwald.de
Gesch=E4ftsf=FChrer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhause=
n
Komplement=E4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynha=
usen
--qrv430rJEi23QIbTFEhlgaaoflBObNa5w--
--JHITMubKSiIoiKCLExJ8foN2FBRtH0Q35
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
--JHITMubKSiIoiKCLExJ8foN2FBRtH0Q35--
8:11 a.m.
I'm not sure what you mean or which versions you're referring to.
Like every project there is the 'master' branch and nightlies which is
latest and greatest (and probably the least stable, but still go over heavy
CI tests).
The oVirt project reached a point when the next stable major version (4.0)
is nearing GA, and part of the process is to branch it to create rpms for
it, in order to continue developing 4.1 (now master) and not to merge new
features that may risk 4.0 stability the new branch has to be created.
You as user/developer has the choice to choose which version to use,
according to you needs:
for e.g, at this time point, you choices are:
1. Use current stable: 3.6 rpms - most stable, only gets specific fixes and
not major features - recommended for a production usage and if you don't
need any of the new features [1]
2. Use current RC candidate for next major 4.0, which should be the next
stable version soon and replace 3.6 as the latest stable version [2]
3. Use nightlies for every version - either 4.0, master, 3.6 - use at your
own risk since these are not official releases and not going via extensive
QA, although the automated tests for each version
are improving over time and make the nightlies more and more stable. [3]
Just to help better undertand, if you'll make the same decision in one more
months for e.g, after 4.0 is GA, you choices will be:
1. use current stable 4.0 (unless you really want to use older 3.6)
2. use nightlies
So the extra versions are temp version that are part of the development
process and actually gives you an oppertunity to check out new features
that are not available yet in a formal stable version.
I hope it gives some info on the diff between all the versions.
[1]. http://resources.ovirt.org/pub/ovirt-3.6/
[2] http://resources.ovirt.org/pub/ovirt-4.0-pre/
[3] http://resources.ovirt.org/pub/ovirt-4.0-snapshot(+-static),
http://resources.ovirt.org/pub/ovirt-master-snapshot(+static)
On Thu, Jun 16, 2016 at 12:16 PM, Vinzenz Feenstra <vfeenstr(a)redhat.com>
wrote:
--
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)
9:11 a.m.
--Tv6CEbvPGCNnldWd1Ql3XW4xoDwjne27R
Content-Type: multipart/mixed; boundary="as3hEfeRcQ0BSoULhKVSDt49nd254xlM6"
From: Sven Kieske <s.kieske(a)mittwald.de>
To: devel(a)ovirt.org
Message-ID: <5762B37F.5070508(a)mittwald.de>
X-Authenticated-mymxserver.com: Yes
Subject: Re: [ovirt-devel] oVirt 4.0 Nightly repo
References: <CAN8-ONooie-Qop2dPfthaatk=Lacqpq1St9Yg_vy0gROipG-XA(a)mail.gmail.com>
<CACuV_HpFHzEhew3=egRjfpC2y+CDGQ+jDX9tWysL=b9+UAhsPw(a)mail.gmail.com>
In-Reply-To: <CACuV_HpFHzEhew3=egRjfpC2y+CDGQ+jDX9tWysL=b9+UAhsPw(a)mail.gmail.com>
--as3hEfeRcQ0BSoULhKVSDt49nd254xlM6
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi,
first thanks for this in depth and long
explanation. I'm actually already aware
of what you just explained.
But I'm a long time user, I guess, so I had
plenty of time to get used to all this.
But you didn't factor in other important things
like: which datacenter or cluster version does include
feature X (e.g. support for el6.6, el6.7 el7.0, etc).
this is further complicated by the fact that someone packages
vdsm for el6epel, but apparently in a backwards incompatible
version for older ovirt releases.
e.g. the current version in epel for el6 is:
vdsm-4.16.20-1.git3a90f62.el6.x86_64.rpm
so you have to blacklist this if you run an older
engine and happen to need some other packages from epel.
I honestly don't know really why vdsm is included in epel
at all. In order to use it, you need an ovirt-engine with
the necessary repository anyway, which contains vdsm in
the correct version, so why would you want to pull vdsm from
epel?
I don't want to complain a lot, but I hope in the future
we'll have fewer backwards incompatible changes, so newer
vdsm can talk to older engines (even if not all features are supported).
My general impression is, that ovirt becomes
more stable, the more releases come out.
So again: keep up the good work! :-)
--=20
Mit freundlichen Gr=C3=BC=C3=9Fen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
K=C3=B6nigsberger Stra=C3=9Fe 6
32339 Espelkamp
T: +495772 293100
F: +495772 293333
https://www.mittwald.de
Gesch=C3=A4ftsf=C3=BChrer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhause=
n
Komplement=C3=A4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oey=
nhausen
--as3hEfeRcQ0BSoULhKVSDt49nd254xlM6--
--Tv6CEbvPGCNnldWd1Ql3XW4xoDwjne27R
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
--Tv6CEbvPGCNnldWd1Ql3XW4xoDwjne27R--
9:18 a.m.
Hi everyone,
I think Sven was referring specifically to oVirt Dashboard component
of oVirt Engine product. Dashboard (UI plugin) has its own repo [1]
[1] https://gerrit.ovirt.org/#/admin/projects/ovirt-engine-dashboard
with dedicated Jenkins job to build its RPM. When Engine is installed,
Dashboard RPM is *automatically* installed & updated as well.
You don't have to worry about tracking Dashboard RPM version installed
on machine running your Engine. Dashboard is technically part of Engine
because it relies on Engine UI plugin infra, it's not "standalone" like
VDSM.
TL;DR the fact that Dashboard has its own RPM shouldn't impact users,
it's a logical part of Engine.
Regards,
Vojtech
----- Original Message -----
9:07 a.m.
On Tue, Jun 14, 2016 at 03:14:03PM +0200, Simone Tiraboschi wrote:
I see that Vdsm
http://resources.ovirt.org/pub/ovirt-4.0-snapshot/rpm/el7Server/x86_64/
has both (correct) 4.18.2 builds and misleading 4.18.9999 ones such as
vdsm-4.18.999-73.gitd35b8e7.el7.centos.x86_64.rpm
Can you manually remove them? they hide the correct builds.
3274
days inactive
3276
days old
13 comments
7 participants
participants (7)
-
Dan Kenigsberg -
Eyal Edri -
Francesco Romani -
Simone Tiraboschi -
Sven Kieske -
Vinzenz Feenstra -
Vojtech Szocs