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

[Eli Mesika]

----- Original Message -----
> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> To: "Oved Ourfali" <oourfali at redhat.com>
> Cc: "devel" <devel at ovirt.org>
> Sent: Thursday, January 28, 2016 4:57:33 PM
> Subject: Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.
> 
> 
> 
> 
> 
> On 26 Jan 2016, at 19:13, Oved Ourfali < oourfali at redhat.com > wrote:
> 
> 
> 
> 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.
> 
> +1

+1 as well, don't think it worth the effort 

> I like vdsm.
> any variant with “agent” brings confusion with guest agent (let alone the
> fact we have three of them)
> 
> 
> 
> 
> 
> 
> 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
> > 
> > 
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel