On 26 Jan 2016, at 19:13, Oved Ourfali <oourfali@redhat.com> wrote: =20 I must agree with Martin here.=20 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 =
--Apple-Mail=_ACF5413A-13CC-4346-8896-6D8417D816A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 provisioning products that might rely on that such as puppet recipes, = ansible modules, or others..=20
(can't say all mentioned stuff are relevant, and I guess there might = be more implications than I've described). =20 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. =20
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. =20 Regards,=20 Oved=20 =20 On Jan 26, 2016 7:00 PM, "Martin Sivak" <msivak@redhat.com = <mailto:msivak@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 =
+1 I like vdsm.=20 any variant with =E2=80=9Cagent=E2=80=9D brings confusion with guest = agent (let alone the fact we have three of them) 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
--Apple-Mail=_ACF5413A-13CC-4346-8896-6D8417D816A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On 26 Jan 2016, at 19:13, Oved Ourfali <<a = href=3D"mailto:oourfali@redhat.com" class=3D"">oourfali@redhat.com</a>>= wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><p = dir=3D"ltr" class=3D"">I must agree with Martin here. <br class=3D""> 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.. <br class=3D""> (can't say all mentioned stuff are relevant, and I guess there might be = more implications than I've described). </p><p dir=3D"ltr" = class=3D"">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. </p></div></blockquote><div><br = class=3D""></div>+1</div><div>I like vdsm. </div><div>any variant = with =E2=80=9Cagent=E2=80=9D brings confusion with guest agent (let = alone the fact we have three of them)</div><div><br class=3D""><blockquote= type=3D"cite" class=3D""><div class=3D""><p dir=3D"ltr" class=3D"">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.</p><p dir=3D"ltr" class=3D"">Regards, <br = class=3D""> Oved <br class=3D""></p><p dir=3D"ltr" class=3D"">On Jan 26, 2016 7:00 = PM, "Martin Sivak" <<a href=3D"mailto:msivak@redhat.com" = class=3D"">msivak@redhat.com</a>> wrote:<br class=3D""> ><br class=3D""> > Hi,<br class=3D""> ><br class=3D""> > name change might be considered, but I do not think it will make a = big<br class=3D""> > difference. People do not see vdsm too often (installed by host<br = class=3D""> > deploy, managed by engine..).<br class=3D""> ><br class=3D""> ><br class=3D""> > But trying to make sure that (all?) component versions in a = project<br class=3D""> > are the same is not a good idea if you ask me. You are not going = to<br class=3D""> > rebuild everything when a hot fix is needed, but granted, you = might<br class=3D""> > use minor numbers so the versions will at least start with the = same<br class=3D""> > numbers. Or will we force a version bump and rebuild to = unchanged<br class=3D""> > component, when others were updated for a given release? (we = have<br class=3D""> > components like that - ovirt-scheduler-proxy for example)<br = class=3D""> ><br class=3D""> > Engine does not depend on an exact vdsm version, we have gradual<br = class=3D""> > feature degradation built in in form of capabilities, machine type = and<br class=3D""> > cluster levels so it should be totally up to the user what version = of<br class=3D""> > vdsm is used. The same we do not control libvirt or kernel. Some = of<br class=3D""> > the components (at least on my side) are completely usable = without<br class=3D""> > oVirt and when oVirt is released it just gets the latest stable = bits<br class=3D""> > available.<br class=3D""> ><br class=3D""> > Why don't we treat oVirt as a package distribution it is? The = long<br class=3D""> > term plan still is to break the monoliths (like vdsm or engine) = and<br class=3D""> > the possibly new teams (or community) might have different needs.. = we<br class=3D""> > might even want to promote reuse of some of the components (like = [2])<br class=3D""> > in oVirt unrelated way and I would really love to see that kind = of<br class=3D""> > adoption. We are trying to keep so much control that we are an = open<br class=3D""> > project, but not a community one (where the community can = influence<br class=3D""> > future plans, release schedules, workflows or processes).<br = class=3D""> ><br class=3D""> > Neither Fedora, nor RHEL (Debian, ..) try to control the version = of<br class=3D""> > components. They depend purely on package dependencies and = separate<br class=3D""> > component development from distribution compose processes = (something<br class=3D""> > we lack..). Even OpenStack abandoned the unified versioning last = year<br class=3D""> > (at least partially) [1]. We decided to use similar age based<br = class=3D""> > versioning like described in [1] when I was still part of the = Anaconda<br class=3D""> > team and it worked perfectly fine.<br class=3D""> ><br class=3D""> > I really wish we would loosen the project coupling (and = processes)<br class=3D""> > instead of tightening it. Sadly everything we have done lately = is<br class=3D""> > going in the tightening direction...<br class=3D""> ><br class=3D""> ><br class=3D""> ><br class=3D""> > TL;DR: Please let us use whatever versions of packages we want,<br = class=3D""> > release as often as we want and just take the latest bits to = compose<br class=3D""> > the oVirt distribution. Most of the components we have handle = that<br class=3D""> > just fine.<br class=3D""> ><br class=3D""> > [1] OpenStack versioning plans: <a = href=3D"http://ttx.re/new-versioning.html" = class=3D"">http://ttx.re/new-versioning.html</a> (and<br class=3D""> > please pay particular attention to the last section and especially = the<br class=3D""> > last two paragraphs in it)<br class=3D""> > [2] There was a thread about vdsm RPMs being too granular:<br = class=3D""> > <a = href=3D"http://lists.ovirt.org/pipermail/devel/2016-January/012185.html" = class=3D"">http://lists.ovirt.org/pipermail/devel/2016-January/012185.html= </a><br class=3D""> ><br class=3D""> > --<br class=3D""> > Martin Sivak<br class=3D""> > oVirt / SLA<br class=3D""> > _______________________________________________<br class=3D""> > Devel mailing list<br class=3D""> > <a href=3D"mailto:Devel@ovirt.org" class=3D"">Devel@ovirt.org</a><br = class=3D""> > <a href=3D"http://lists.ovirt.org/mailman/listinfo/devel" = class=3D"">http://lists.ovirt.org/mailman/listinfo/devel</a><br = class=3D""> ><br class=3D""> ><br class=3D""> </p> _______________________________________________<br class=3D"">Devel = mailing list<br class=3D""><a href=3D"mailto:Devel@ovirt.org" = class=3D"">Devel@ovirt.org</a><br = class=3D"">http://lists.ovirt.org/mailman/listinfo/devel</div></blockquote=
</div><br class=3D""></body></html>=
--Apple-Mail=_ACF5413A-13CC-4346-8896-6D8417D816A9--