> On 26 Jan 2016, at 19:13, Oved Ourfali <oourf...@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) > 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" <msi...@redhat.com > <mailto:msi...@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 > > <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 > > <http://lists.ovirt.org/pipermail/devel/2016-January/012185.html> > > > > -- > > Martin Sivak > > oVirt / SLA > > _______________________________________________ > > Devel mailing list > > Devel@ovirt.org <mailto:Devel@ovirt.org> > > http://lists.ovirt.org/mailman/listinfo/devel > > <http://lists.ovirt.org/mailman/listinfo/devel> > > > > > _______________________________________________ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
