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

[Greg Sheremeta]

On Thu, Jan 28, 2016 at 9:57 AM, Michal Skrivanek
<michal.skrivanek at redhat.com> wrote:
>
> 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
> I like vdsm.
> any variant with “agent” brings confusion with guest agent (let alone the
> fact we have three of them)

Oved has a point, but all native English speakers will agree that "vdsm" is
a bad (i.e. almost inappropriate) name.

I think it should be changed for that reason alone.

It's unfortunate that the name "ovirt-agent" is already taken.

Greg


>
> 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



-- 
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme at redhat.com
919-741-4016