[ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Oved Ourfali]

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 at 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160126/bf08e03c/attachment.html>