On Thu, Jan 28, 2016 at 9:57 AM, Michal Skrivanek <michal.skriva...@redhat.com> wrote: > > 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)
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" <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 (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@ovirt.org >> 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 -- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gsher...@redhat.com 919-741-4016 _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel