9:13 p.m.
I must agree with Martin here.
In addition, I think the benefit here is low, and the efforts it will
require and the risks are high. Upgrade issues? Compatibility ones? Effect
on engine features such as host upgrade manager, different provisioning
products that might rely on that such as puppet recipes, ansible modules,
or others...
(can't say all mentioned stuff are relevant, and I guess there might be
more implications than I've described).
IMHO, we should spend our time improving our project rather than spend a
lot of developers, testers and integration people on these kind of tasks.
In addition, bootstrapping of hosts doesn't require manual installation of
VDSM, and as of 3.6 neither does upgrade, so most users shouldn't know and
care what VDSM is.
Regards,
Oved
On Jan 26, 2016 7:00 PM, "Martin Sivak" <msivak(a)redhat.com> wrote:
Hi,
name change might be considered, but I do not think it will make a big
difference. People do not see vdsm too often (installed by host
deploy, managed by engine..).
But trying to make sure that (all?) component versions in a project
are the same is not a good idea if you ask me. You are not going to
rebuild everything when a hot fix is needed, but granted, you might
use minor numbers so the versions will at least start with the same
numbers. Or will we force a version bump and rebuild to unchanged
component, when others were updated for a given release? (we have
components like that - ovirt-scheduler-proxy for example)
Engine does not depend on an exact vdsm version, we have gradual
feature degradation built in in form of capabilities, machine type and
cluster levels so it should be totally up to the user what version of
vdsm is used. The same we do not control libvirt or kernel. Some of
the components (at least on my side) are completely usable without
oVirt and when oVirt is released it just gets the latest stable bits
available.
Why don't we treat oVirt as a package distribution it is? The long
term plan still is to break the monoliths (like vdsm or engine) and
the possibly new teams (or community) might have different needs.. we
might even want to promote reuse of some of the components (like [2])
in oVirt unrelated way and I would really love to see that kind of
adoption. We are trying to keep so much control that we are an open
project, but not a community one (where the community can influence
future plans, release schedules, workflows or processes).
Neither Fedora, nor RHEL (Debian, ..) try to control the version of
components. They depend purely on package dependencies and separate
component development from distribution compose processes (something
we lack..). Even OpenStack abandoned the unified versioning last year
(at least partially) [1]. We decided to use similar age based
versioning like described in [1] when I was still part of the Anaconda
team and it worked perfectly fine.
I really wish we would loosen the project coupling (and processes)
instead of tightening it. Sadly everything we have done lately is
going in the tightening direction...
TL;DR: Please let us use whatever versions of packages we want,
release as often as we want and just take the latest bits to compose
the oVirt distribution. Most of the components we have handle that
just fine.
[1] OpenStack versioning plans: http://ttx.re/new-versioning.html (and
please pay particular attention to the last section and especially the
last two paragraphs in it)
[2] There was a thread about vdsm RPMs being too granular:
http://lists.ovirt.org/pipermail/devel/2016-January/012185.html
--
Martin Sivak
oVirt / SLA
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel