Changing the name of VDSM in oVirt 4.0.
Hi, I wanted to bring this up to get feedback on this proposed change. VDSM doesn't align to other project under the oVirt umbrella like ovirt-engine, ovirt-node, ovirt-guest-agent etc.. I suggest for ease of use and tracking we change the versioning to align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which version was in which release and also change the package naming to something like ovirt-host-manager\ovirt-host-agent. What do you think on this? What do you think the name should be? Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: ydary@redhat.com IRC : ydary
+1 Honestly I think that any name is better and more descriptive than "VDSM" :) "host-agent" seems appropriate to me. Best regards, Martin B. ----- Original Message -----
From: "Yaniv Dary" <ydary@redhat.com> To: "devel" <devel@ovirt.org> Sent: Tuesday, January 26, 2016 4:29:46 PM Subject: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.
Hi, I wanted to bring this up to get feedback on this proposed change. VDSM doesn't align to other project under the oVirt umbrella like ovirt-engine, ovirt-node, ovirt-guest-agent etc..
I suggest for ease of use and tracking we change the versioning to align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which version was in which release and also change the package naming to something like ovirt-host-manager\ovirt-host-agent.
What do you think on this? What do you think the name should be? Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109
Tel : +972 (9) 7692306 8272306 Email: ydary@redhat.com IRC : ydary
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Martin Betak" <mbetak@redhat.com> To: "Yaniv Dary" <ydary@redhat.com> Cc: "devel" <devel@ovirt.org> Sent: Tuesday, January 26, 2016 4:41:29 PM Subject: Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.
+1
Honestly I think that any name is better and more descriptive than "VDSM" :) "host-agent" seems appropriate to me. +1
But more important is to align engine and VDSM version. Wwe build them together for one release, so they should have the same release version, for example in oVirt 4.0 we should have ovirt-engine 4.0.0 ovirt-host-agent 4.0.0 Martin Perina
Best regards,
Martin B.
----- Original Message -----
From: "Yaniv Dary" <ydary@redhat.com> To: "devel" <devel@ovirt.org> Sent: Tuesday, January 26, 2016 4:29:46 PM Subject: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.
Hi, I wanted to bring this up to get feedback on this proposed change. VDSM doesn't align to other project under the oVirt umbrella like ovirt-engine, ovirt-node, ovirt-guest-agent etc..
I suggest for ease of use and tracking we change the versioning to align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which version was in which release and also change the package naming to something like ovirt-host-manager\ovirt-host-agent.
What do you think on this? What do you think the name should be? Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109
Tel : +972 (9) 7692306 8272306 Email: ydary@redhat.com IRC : ydary
_______________________________________________ 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
Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: ydary@redhat.com IRC : ydary On Tue, Jan 26, 2016 at 5:47 PM, Martin Perina <mperina@redhat.com> wrote:
----- Original Message -----
From: "Martin Betak" <mbetak@redhat.com> To: "Yaniv Dary" <ydary@redhat.com> Cc: "devel" <devel@ovirt.org> Sent: Tuesday, January 26, 2016 4:41:29 PM Subject: Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.
+1
Honestly I think that any name is better and more descriptive than "VDSM" :) "host-agent" seems appropriate to me.
I think the 'ovirt-' initial is needed to mark this is part of the upstream project.
+1
But more important is to align engine and VDSM version. Wwe build them together for one release, so they should have the same release version, for example in oVirt 4.0 we should have
ovirt-engine 4.0.0 ovirt-host-agent 4.0.0
Martin Perina
Best regards,
Martin B.
----- Original Message -----
From: "Yaniv Dary" <ydary@redhat.com> To: "devel" <devel@ovirt.org> Sent: Tuesday, January 26, 2016 4:29:46 PM Subject: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.
Hi, I wanted to bring this up to get feedback on this proposed change. VDSM doesn't align to other project under the oVirt umbrella like
ovirt-engine,
ovirt-node, ovirt-guest-agent etc..
I suggest for ease of use and tracking we change the versioning to align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which version was in which release and also change the package naming to something like ovirt-host-manager\ovirt-host-agent.
What do you think on this? What do you think the name should be? Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109
Tel : +972 (9) 7692306 8272306 Email: ydary@redhat.com IRC : ydary
_______________________________________________ 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
----- Original Message -----
From: "Yaniv Dary" <ydary@redhat.com> To: "Martin Perina" <mperina@redhat.com> Cc: "Martin Betak" <mbetak@redhat.com>, "devel" <devel@ovirt.org> Sent: Tuesday, January 26, 2016 4:55:10 PM Subject: Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.
Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109
Tel : +972 (9) 7692306 8272306 Email: ydary@redhat.com IRC : ydary
On Tue, Jan 26, 2016 at 5:47 PM, Martin Perina <mperina@redhat.com> wrote:
----- Original Message -----
From: "Martin Betak" <mbetak@redhat.com> To: "Yaniv Dary" <ydary@redhat.com> Cc: "devel" <devel@ovirt.org> Sent: Tuesday, January 26, 2016 4:41:29 PM Subject: Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.
+1
Honestly I think that any name is better and more descriptive than "VDSM" :) "host-agent" seems appropriate to me.
I think the 'ovirt-' initial is needed to mark this is part of the upstream project.
Sure, I meant to silently imply the "ovirt-" prefix :)
+1
But more important is to align engine and VDSM version. Wwe build them together for one release, so they should have the same release version, for example in oVirt 4.0 we should have
ovirt-engine 4.0.0 ovirt-host-agent 4.0.0
Martin Perina
Best regards,
Martin B.
----- Original Message -----
From: "Yaniv Dary" <ydary@redhat.com> To: "devel" <devel@ovirt.org> Sent: Tuesday, January 26, 2016 4:29:46 PM Subject: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.
Hi, I wanted to bring this up to get feedback on this proposed change. VDSM doesn't align to other project under the oVirt umbrella like
ovirt-engine,
ovirt-node, ovirt-guest-agent etc..
I suggest for ease of use and tracking we change the versioning to align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which version was in which release and also change the package naming to something like ovirt-host-manager\ovirt-host-agent.
What do you think on this? What do you think the name should be? Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109
Tel : +972 (9) 7692306 8272306 Email: ydary@redhat.com IRC : ydary
_______________________________________________ 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
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
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. 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@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
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--
----- Original Message -----
From: "Michal Skrivanek" <michal.skrivanek@redhat.com> To: "Oved Ourfali" <oourfali@redhat.com> Cc: "devel" <devel@ovirt.org> Sent: Thursday, January 28, 2016 3: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@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)
then maybe ovirt-vdsmd? :) -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani
----- Original Message -----
From: "Michal Skrivanek" <michal.skrivanek@redhat.com> To: "Oved Ourfali" <oourfali@redhat.com> Cc: "devel" <devel@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@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@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
On Thu, Jan 28, 2016 at 9:57 AM, Michal Skrivanek <michal.skrivanek@redhat.com> wrote:
On 26 Jan 2016, at 19:13, Oved Ourfali <oourfali@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@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 gshereme@redhat.com 919-741-4016
On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary@redhat.com> wrote:
Hi, I wanted to bring this up to get feedback on this proposed change. VDSM doesn't align to other project under the oVirt umbrella like ovirt-engine, ovirt-node, ovirt-guest-agent etc..
+1
I suggest for ease of use and tracking we change the versioning to align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which version was in which release and also change the package naming to something like ovirt-host-manager\ovirt-host-agent.
We cannot use the same version number, since we have different components, and we will not rebuild a good an tested component if another component was modified. So we can share the major and probably the minor version, but the rest of the version will be per component.
What do you think on this? What do you think the name should be?
ovirt-agent - symmetric with ovirt-engine - these are the biggest parts of the system. ovirt-host-agent is too long, we don't want to use to word "host" for everything that run on the host. For example, supervdsm - we cannot call it ovirt-host-superagent or ovirt-host-agent-helper or vdsm-tool - we don't want to call it ovirt-host-agent-tool - think about the poor user trying to type these names in the shell. Nir
Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109
Tel : +972 (9) 7692306 8272306 Email: ydary@redhat.com IRC : ydary
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
--Apple-Mail=_CE5A1836-BEF3-4477-A1C8-8A1236EEFA42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii
Hi, I wanted to bring this up to get feedback on this proposed change. = VDSM doesn't align to other project under the oVirt umbrella like = ovirt-engine, ovirt-node, ovirt-guest-agent etc.. =20 +1 =20 =20 I suggest for ease of use and tracking we change the versioning to = align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which = version was in which release and also change the package naming to something like ovirt-host-manager\ovirt-host-agent. =20 We cannot use the same version number, since we have different = components, and we will not rebuild a good an tested component if another = component was modified. =20 So we can share the major and probably the minor version, but the rest = of the version will be per component. =20 =20 What do you think on this? What do you think the name should be? =20 ovirt-agent - symmetric with ovirt-engine - these are the biggest
On Jan 26, 2016, at 6:00 PM, Nir Soffer <nsoffer@redhat.com> wrote: =20 On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary@redhat.com = <mailto:ydary@redhat.com>> wrote: parts of the system.
Might get confused with the ovirt-guest-agent though - I can see already = bugs being filed in the wrong components due to confusion
=20 ovirt-host-agent is too long, we don't want to use to word "host" for = everything that run on the host. =20 For example, supervdsm - we cannot call it ovirt-host-superagent or ovirt-host-agent-helper or vdsm-tool - we don't want to call it ovirt-host-agent-tool - think about the poor user trying to type these names in the shell. =20 Nir =20
=20 Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 =20 Tel : +972 (9) 7692306 8272306 Email: ydary@redhat.com IRC : ydary =20 =20 _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org <mailto:Devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/devel = <http://lists.ovirt.org/mailman/listinfo/devel>
--Apple-Mail=_CE5A1836-BEF3-4477-A1C8-8A1236EEFA42 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></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 Jan 26, 2016, at 6:00 PM, Nir Soffer <<a = href=3D"mailto:nsoffer@redhat.com" class=3D"">nsoffer@redhat.com</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><span = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary = <</span><a href=3D"mailto:ydary@redhat.com" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" = class=3D"">ydary@redhat.com</a><span style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; orphans: auto; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: = auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; = display: inline !important;" class=3D"">> wrote:</span><br = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D""><blockquote type=3D"cite" = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D"">Hi,<br class=3D"">I wanted = to bring this up to get feedback on this proposed change. VDSM<br = class=3D"">doesn't align to other project under the oVirt umbrella like = ovirt-engine,<br class=3D"">ovirt-node, ovirt-guest-agent etc..<br = class=3D""></blockquote><br style=3D"font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">+1</span><br style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; orphans: auto; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: = auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><br = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D""><blockquote type=3D"cite" = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D""><br class=3D"">I suggest for = ease of use and tracking we change the versioning to align to<br = class=3D"">the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know = which version was<br class=3D"">in which release and also change the = package naming to something like<br = class=3D"">ovirt-host-manager\ovirt-host-agent.<br = class=3D""></blockquote><br style=3D"font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">We cannot use the same version number, since we = have different components,</span><br style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; orphans: auto; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: = auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span= style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">and we will not rebuild a good an tested = component if another component was</span><br style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" = class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: = inline !important;" class=3D"">modified.</span><br style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" = class=3D""><br style=3D"font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">So we can share the major and probably the minor = version, but the rest of the</span><br style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; orphans: auto; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: = auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span= style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">version will be per component.</span><br = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D""><br style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" = class=3D""><blockquote type=3D"cite" style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; orphans: auto; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: = auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><br = class=3D"">What do you think on this? What do you think the name should = be?<br class=3D""></blockquote><br style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; orphans: auto; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: = auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span= style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">ovirt-agent - symmetric with ovirt-engine - = these are the biggest</span><br style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; orphans: auto; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: = auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span= style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">parts of the system.</span><br = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D""></div></blockquote><div><br = class=3D""></div><div>Might get confused with the ovirt-guest-agent = though - I can see already bugs being filed in the wrong components due = to confusion</div><br class=3D""><blockquote type=3D"cite" class=3D""><div= class=3D""><br style=3D"font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">ovirt-host-agent is too long, we don't want to = use to word "host" for everything</span><br style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" = class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: = inline !important;" class=3D"">that run on the host.</span><br = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D""><br style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" = class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: = inline !important;" class=3D"">For example, supervdsm - we cannot call = it ovirt-host-superagent or</span><br style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; orphans: auto; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: = auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span= style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px; float: none; display: inline = !important;" class=3D"">ovirt-host-agent-helper</span><br = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: = none; display: inline !important;" class=3D"">or vdsm-tool - we don't = want to call it ovirt-host-agent-tool - think</span><br = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: = none; display: inline !important;" class=3D"">about the poor</span><br = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: = none; display: inline !important;" class=3D"">user trying to type these = names in the shell.</span><br style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; orphans: auto; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: = auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><br = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: = none; display: inline !important;" class=3D"">Nir</span><br = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D""><br style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" = class=3D""><blockquote type=3D"cite" style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; orphans: auto; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: = auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><br = class=3D"">Yaniv Dary<br class=3D"">Technical Product Manager<br = class=3D"">Red Hat Israel Ltd.<br class=3D"">34 Jerusalem Road<br = class=3D"">Building A, 4th floor<br class=3D"">Ra'anana, Israel = 4350109<br class=3D""><br class=3D"">Tel : +972 (9) 7692306<br = class=3D""> 8272306<br = class=3D"">Email: <a href=3D"mailto:ydary@redhat.com" = class=3D"">ydary@redhat.com</a><br class=3D"">IRC : ydary<br = class=3D""><br class=3D""><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"">http://lists.ovirt.org/mailman/listinfo/devel<br = class=3D""></blockquote><span style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; orphans: auto; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: = auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; = display: inline !important;" = class=3D"">_______________________________________________</span><br = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" class=3D""><span style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: = none; display: inline !important;" class=3D"">Devel mailing = list</span><br style=3D"font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><a = href=3D"mailto:Devel@ovirt.org" style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; orphans: auto; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: = auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" = class=3D"">Devel@ovirt.org</a><br style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant: normal; font-weight: = normal; letter-spacing: normal; orphans: auto; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; widows: = auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><a = href=3D"http://lists.ovirt.org/mailman/listinfo/devel" = style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; word-spacing: 0px; = -webkit-text-stroke-width: 0px;" = class=3D"">http://lists.ovirt.org/mailman/listinfo/devel</a></div></blockq= uote></div><br class=3D""></body></html>= --Apple-Mail=_CE5A1836-BEF3-4477-A1C8-8A1236EEFA42--
--7NjowLKd7vnh9EDVURbtwXh70IELAW2gf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 26/01/16 16:29, Yaniv Dary wrote:
Hi, I wanted to bring this up to get feedback on this proposed change. VDSM doesn't align to other project under the oVirt umbrella like ovirt-engine, ovirt-node, ovirt-guest-agent etc.. =20 I suggest for ease of use and tracking we change the versioning to align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which version was in which release and also change the package naming to something like ovirt-host-manager\ovirt-host-agent. =20 What do you think on this? What do you think the name should be?
Hi, just commenting from the end user perspective: version align: +1 ovirt-prefix: +1 new name(suffix): host-agent: don't know, I think it crashes a little with ovirt-guest-agent (already used). This might confuse some users, or what do you thing? maybe ovirt-host-manager suites it more (to differentiate between vdsm and guest-agent)? I personally don't like the work "manager" for a software. in the end it's your decision and I could also get along with ovirt-host-agent. --=20 Mit freundlichen Gr=FC=DFen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG K=F6nigsberger Stra=DFe 6 32339 Espelkamp T: +495772 293100 F: +495772 293333 https://www.mittwald.de Gesch=E4ftsf=FChrer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhause= n Komplement=E4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen --7NjowLKd7vnh9EDVURbtwXh70IELAW2gf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWp6fJAAoJEMby9TMDAbQRQDQP/1bVvzRO4rxFL5hqT1D+aAtg V5HkkcDekf6SEQJBknEiVr2+LafGfqjBynToG2Sf/fXtwJSVBIy9aKBXMlEwT6KC rBOWaWnOlC1F4DnJ+13kChMSGJT1Jq2ecY2Ki9dW040i/WWhe0oturr3NixGGN0v Dut98uxLYUgvek2VOzIFq/PEjGKfH7HUq90jx36nJlwN8vdWUq+ZUkUWinhXI83a uQ+N4m1Ks56sfX/rmidkZlbLYJKZLDE06s3JuLfZahtuazZ3+8dmilOSAm5/hWvX 6GRx+EzkshV5dtvtgJw6pLPTdz/C8ql/v7rCDKRXkgUX9I/vks3JSIDHtMgT06ex 5fhwBA5RxwhiMAfmSXlPNoNstdIMkvxyRKJaIbV3BNI36MFoDAgXGIj++gq/ZdXg hmDHHvvk0E/qsSDVyYNxNGmehjnNAOw3Wlz+441oF4eBx54kfl2p4PlfTDSUOD4x j35jQ8vY3Odf2BFVQAhJhYRAOj3kFplzZ6c2lZXXSzKploE3ruygjM9H+7cwM0b9 nBmcEymasxMDl0t8yPBpS7zJELxIQlWb9YOyTIrXrd/NpVrshro+ZvTzI98I4j7X mqvW65i5ISC/0n+r67WILxM/IM44TLO58Zc6RF5OF2GbPcInNyFcp/tFoC9E+8pO XQM/oXMNdoksk5tANjy/ =3DO2 -----END PGP SIGNATURE----- --7NjowLKd7vnh9EDVURbtwXh70IELAW2gf--
On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary@redhat.com> wrote:
I suggest for ease of use and tracking we change the versioning to align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which version was in which release and also change the package naming to something like ovirt-host-manager\ovirt-host-agent.
When we think about the names, we should consider all the components installed or running on the host. Here is the current names and future options: Current names: vdsmd supervdsmd vdsm-tool vdsClient (we have also two hosted engine daemons, I don't remember the names) Here are some options in no particular order to name these components: Alt 1: ovirt-hypervisor ovirt-hypervisor-helper ovirt-hypervisor-tool ovirt-hyperviosr-cli Alt 2: ovirt-host ovirt-host-helper ovirt-host-tool ovirt-host-cli Alt 3: ovirt-agent ovirt-agent-helper ovirt-agent-tool ovirt-agent-cli Thoughts? Nir
On Tue, Jan 26, 2016 at 07:26:55PM +0200, Nir Soffer wrote:
On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary@redhat.com> wrote:
I suggest for ease of use and tracking we change the versioning to align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which version was in which release and also change the package naming to something like ovirt-host-manager\ovirt-host-agent.
When we think about the names, we should consider all the components installed or running on the host. Here is the current names and future options:
Current names:
vdsmd supervdsmd vdsm-tool vdsClient (we have also two hosted engine daemons, I don't remember the names)
Here are some options in no particular order to name these components:
Alt 1: ovirt-hypervisor ovirt-hypervisor-helper ovirt-hypervisor-tool ovirt-hyperviosr-cli
This (IMHO) limits it to virtualisation. It'd be surprised if a hypervisor was only a storage node. Docker containers would be excluded as well.
Alt 2: ovirt-host ovirt-host-helper ovirt-host-tool ovirt-host-cli
Might make sense
Alt 3: ovirt-agent ovirt-agent-helper ovirt-agent-tool ovirt-agent-cli
Mentioned before by Sven - too similar to ovirt-guest-agent.
On Tue, Jan 26, 2016 at 7:26 PM, Nir Soffer <nsoffer@redhat.com> wrote:
On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary@redhat.com> wrote:
I suggest for ease of use and tracking we change the versioning to align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which version was in which release and also change the package naming to something like ovirt-host-manager\ovirt-host-agent.
When we think about the names, we should consider all the components installed or running on the host. Here is the current names and future options:
Current names:
vdsmd supervdsmd vdsm-tool vdsClient (we have also two hosted engine daemons, I don't remember the names)
Here are some options in no particular order to name these components:
Alt 1: ovirt-hypervisor ovirt-hypervisor-helper ovirt-hypervisor-tool ovirt-hyperviosr-cli
Alt 2:
Not sure it's that important. Still, how about:
ovirt-host
ovirt-hostd
ovirt-host-helper
ovirt-priv-hostd
ovirt-host-tool
ovirt-hostd-tool
ovirt-host-cli
ovirt-hostd-cli Also we should get rid of '/rhev/' in start of mount points IMO. How about '/var/lib/ovirt-hostd/mounts/' or something like that? Re versioning, we have many other tools with their own, including e.g. ovirt-hosted-engine-setup, ovirt-host-deploy, ovirt-guest-agent (unsynced), ovirt-engine-dwh and ovirt-engine-reports (synced major.minor). Reasons already mentioned by others. -- Didi
On Wed, Jan 27, 2016 at 9:29 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jan 26, 2016 at 7:26 PM, Nir Soffer <nsoffer@redhat.com> wrote:
On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary@redhat.com> wrote:
I suggest for ease of use and tracking we change the versioning to align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which version was in which release and also change the package naming to something like ovirt-host-manager\ovirt-host-agent.
When we think about the names, we should consider all the components installed or running on the host. Here is the current names and future options:
Current names:
vdsmd supervdsmd vdsm-tool vdsClient (we have also two hosted engine daemons, I don't remember the names)
Here are some options in no particular order to name these components:
Alt 1: ovirt-hypervisor ovirt-hypervisor-helper ovirt-hypervisor-tool ovirt-hyperviosr-cli
Alt 2:
Not sure it's that important. Still, how about:
ovirt-host
ovirt-hostd
I like this
ovirt-host-helper
ovirt-priv-hostd
How about ovirt-privd? I like short names.
ovirt-host-tool
ovirt-hostd-tool
ovirt-host-cli
ovirt-hostd-cli
I think we should use the example of systemd: systemd systemctl So ovirt-hostd, ovirt-hostctl ovirt-hostcli
Also we should get rid of '/rhev/' in start of mount points IMO. How about '/var/lib/ovirt-hostd/mounts/' or something like that?
We want to use /run/ovirt-host/storage/ for that, but this is hard change, since it breaks migration to from hosts using different vdsm versions. New vms expect the disks at /rhev/data-center and old vms at /rhev/data-center/ Maybe we can change disks path during migartion on the destination, but migrating vms to older hosts will be impossible, as the vdsm on the older machine does not support such manipulation. Nir
On Wed, Jan 27, 2016 at 09:53:52AM +0200, Nir Soffer wrote:
Also we should get rid of '/rhev/' in start of mount points IMO. How about '/var/lib/ovirt-hostd/mounts/' or something like that?
We want to use /run/ovirt-host/storage/ for that, but this is hard change, since it breaks migration to from hosts using different vdsm versions. New vms expect the disks at /rhev/data-center and old vms at /rhev/data-center/
Maybe we can change disks path during migartion on the destination, but migrating vms to older hosts will be impossible, as the vdsm on the older machine does not support such manipulation.
This may be costly, but we can have have a libvirt migration hook run on the source AND the destination hosts. The source hook would convert everything to /rhev/data-center/ to fit old hosts; new hosts would re-convert it to /var/run/ovirt-hostd.
On 27/01/16 09:53 +0200, Nir Soffer wrote:
On Wed, Jan 27, 2016 at 9:29 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jan 26, 2016 at 7:26 PM, Nir Soffer <nsoffer@redhat.com> wrote:
On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary@redhat.com> wrote:
I suggest for ease of use and tracking we change the versioning to align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which version was in which release and also change the package naming to something like ovirt-host-manager\ovirt-host-agent.
When we think about the names, we should consider all the components installed or running on the host. Here is the current names and future options:
Current names:
vdsmd supervdsmd vdsm-tool vdsClient (we have also two hosted engine daemons, I don't remember the names)
Here are some options in no particular order to name these components:
Alt 1: ovirt-hypervisor ovirt-hypervisor-helper ovirt-hypervisor-tool ovirt-hyperviosr-cli
Alt 2:
Not sure it's that important. Still, how about:
ovirt-host
ovirt-hostd
I like this
ovirt-host-helper
ovirt-priv-hostd
How about ovirt-privd?
I like short names.
ovirt-host-tool
ovirt-hostd-tool
ovirt-host-cli
ovirt-hostd-cli
I think we should use the example of systemd:
systemd systemctl
So ovirt-hostd, ovirt-hostctl ovirt-hostcli
I'd even suggest going simply with ovirtd and ovirtctl (maybe ovirtdctl to differentiate ovirt, ovirtd and ovirt-engine). Names like ovirt-host-agent possibly introduce abbreviation clashes - we would most likely end up abbreviating host-agent to HA and that could be mistaken for high availability in discussions.
Also we should get rid of '/rhev/' in start of mount points IMO. How about '/var/lib/ovirt-hostd/mounts/' or something like that?
We want to use /run/ovirt-host/storage/ for that, but this is hard change, since it breaks migration to from hosts using different vdsm versions. New vms expect the disks at /rhev/data-center and old vms at /rhev/data-center/
Maybe we can change disks path during migartion on the destination, but migrating vms to older hosts will be impossible, as the vdsm on the older machine does not support such manipulation.
Nir _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Thu, Jan 28, 2016 at 10:16 AM, Martin Polednik <mpolednik@redhat.com> wrote:
On 27/01/16 09:53 +0200, Nir Soffer wrote:
On Wed, Jan 27, 2016 at 9:29 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jan 26, 2016 at 7:26 PM, Nir Soffer <nsoffer@redhat.com> wrote:
On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary@redhat.com> wrote:
I suggest for ease of use and tracking we change the versioning to align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which version was in which release and also change the package naming to something like ovirt-host-manager\ovirt-host-agent.
When we think about the names, we should consider all the components installed or running on the host. Here is the current names and future options:
Current names:
vdsmd supervdsmd vdsm-tool vdsClient (we have also two hosted engine daemons, I don't remember the names)
Here are some options in no particular order to name these components:
Alt 1: ovirt-hypervisor ovirt-hypervisor-helper ovirt-hypervisor-tool ovirt-hyperviosr-cli
This might cause confusion with node.
Alt 2:
Not sure it's that important. Still, how about:
ovirt-host
ovirt-hostd
I like this
ovirt-host-helper
ovirt-priv-hostd
How about ovirt-privd?
I like short names.
ovirt-host-tool
ovirt-hostd-tool
ovirt-host-cli
ovirt-hostd-cli
I think we should use the example of systemd:
systemd systemctl
So ovirt-hostd, ovirt-hostctl ovirt-hostcli
I'd even suggest going simply with ovirtd and ovirtctl (maybe ovirtdctl to differentiate ovirt, ovirtd and ovirt-engine).
I'd definetly not go with plain ovirtd - this is to generic IMHO. ovirthostd might be more suitable …
Names like ovirt-host-agent possibly introduce abbreviation clashes - we would most likely end up abbreviating host-agent to HA and that could be mistaken for high availability in discussions.
… ovirt-host-agent actually sounds pretty good. - fabian
Also we should get rid of '/rhev/' in start of mount points IMO. How about '/var/lib/ovirt-hostd/mounts/' or something like that?
We want to use /run/ovirt-host/storage/ for that, but this is hard change, since it breaks migration to from hosts using different vdsm versions. New vms expect the disks at /rhev/data-center and old vms at /rhev/data-center/
Maybe we can change disks path during migartion on the destination, but migrating vms to older hosts will be impossible, as the vdsm on the older machine does not support such manipulation.
Nir _______________________________________________ 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
-- Fabian Deutsch <fdeutsch@redhat.com> RHEV Hypervisor Red Hat
On Thu, Jan 28, 2016 at 11:16 AM, Martin Polednik <mpolednik@redhat.com> wrote:
On 27/01/16 09:53 +0200, Nir Soffer wrote:
On Wed, Jan 27, 2016 at 9:29 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jan 26, 2016 at 7:26 PM, Nir Soffer <nsoffer@redhat.com> wrote:
On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary@redhat.com> wrote:
I suggest for ease of use and tracking we change the versioning to align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which version was in which release and also change the package naming to something like ovirt-host-manager\ovirt-host-agent.
When we think about the names, we should consider all the components installed or running on the host. Here is the current names and future options:
Current names:
vdsmd supervdsmd vdsm-tool vdsClient (we have also two hosted engine daemons, I don't remember the names)
Here are some options in no particular order to name these components:
Alt 1: ovirt-hypervisor ovirt-hypervisor-helper ovirt-hypervisor-tool ovirt-hyperviosr-cli
Alt 2:
Not sure it's that important. Still, how about:
ovirt-host
ovirt-hostd
I like this
ovirt-host-helper
ovirt-priv-hostd
How about ovirt-privd?
I like short names.
ovirt-host-tool
ovirt-hostd-tool
ovirt-host-cli
ovirt-hostd-cli
I think we should use the example of systemd:
systemd systemctl
So ovirt-hostd, ovirt-hostctl ovirt-hostcli
I'd even suggest going simply with ovirtd and ovirtctl (maybe ovirtdctl to differentiate ovirt, ovirtd and ovirt-engine).
Names like ovirt-host-agent possibly introduce abbreviation clashes - we would most likely end up abbreviating host-agent to HA and that could be mistaken for high availability in discussions.
ohad (oVirt Host Agent Daemon, and that's also an Israeli name), or just oha (not to be confused with the Office of Hawaiian Affairs) ohanha (oVirt Host Agent Not High Availability , and that's also an Israeli family name, mostly known for some past famous Israeli soccer player) ohd (oVirt Host Daemon), far enough from OCD. I think we are doing a bit of yak shaving here, but it is entertaining ;-) Y.
Also we should get rid of '/rhev/' in start of mount points IMO. How about '/var/lib/ovirt-hostd/mounts/' or something like that?
We want to use /run/ovirt-host/storage/ for that, but this is hard change, since it breaks migration to from hosts using different vdsm versions. New vms expect the disks at /rhev/data-center and old vms at /rhev/data-center/
Maybe we can change disks path during migartion on the destination, but migrating vms to older hosts will be impossible, as the vdsm on the older machine does not support such manipulation.
Nir _______________________________________________ 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
On 26/01/16 19:26 +0200, Nir Soffer wrote:
On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary@redhat.com> wrote:
I suggest for ease of use and tracking we change the versioning to align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which version was in which release and also change the package naming to something like ovirt-host-manager\ovirt-host-agent.
When we think about the names, we should consider all the components installed or running on the host. Here is the current names and future options:
Also consider that we have discussed breaking vdsmd into its sub-components. In that case we'd need names for: vdsm-storage vdsm-virt vdsm-network etc I am thinking of vdsm as a service provider to the engine. Today it provides a virtualization hypervisor, a storage repository, network configuration services, etc. I think using the word 'provider' is too long (and possibly too vague). We could just make up something to represent the concept of an endpoint that ovirt-engine uses to get things done. For example, an engine often connects to gears to get things done (but gear is already taken by OpenShift, sadly). How about ovirt-minion? :) ovirt-target? ovirt-element? ovirt-unit? Also consider that an abbreviation or acronym is still okay. Thanks for reading to the bottom of my pre-coffee stream of consciousness. Of the alternatives listed below, I'd be inclined to support 'ovirt-host*'.
Current names:
vdsmd supervdsmd vdsm-tool vdsClient (we have also two hosted engine daemons, I don't remember the names)
Here are some options in no particular order to name these components:
Alt 1: ovirt-hypervisor ovirt-hypervisor-helper ovirt-hypervisor-tool ovirt-hyperviosr-cli
Alt 2: ovirt-host ovirt-host-helper ovirt-host-tool ovirt-host-cli
Alt 3: ovirt-agent ovirt-agent-helper ovirt-agent-tool ovirt-agent-cli
Thoughts?
Nir
-- Adam Litke
I think that ovirt- prefix is good idea but vdsm is much more than an agent and as Vinzenz pointed it could be confused with guest agent. Nir suggested ovirt-host or ovirt-hostd which seems like good idea. Supervdsm could be ovirt-host-priv or ovirt-host-privd and our replacement for vdsClient could be ovirt-host-ctl or ovirt-host-cli. Different components in a solution should have freedom of using its own versioning approach. Each component would change differently so versions would change at different times. Currently vdsm is using 4.x versioning and next release would be 4.x so I worried about confusion we create for users. I understand that is not a problem from technological point of view. On Wed, Jan 27, 2016 at 9:02 AM, Adam Litke <alitke@redhat.com> wrote:
On 26/01/16 19:26 +0200, Nir Soffer wrote:
On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary@redhat.com> wrote:
I suggest for ease of use and tracking we change the versioning to align to the engine (4.0.0 in oVirt 4.0 GA) to make it easy to know which version was in which release and also change the package naming to something like ovirt-host-manager\ovirt-host-agent.
When we think about the names, we should consider all the components installed or running on the host. Here is the current names and future options:
Also consider that we have discussed breaking vdsmd into its sub-components. In that case we'd need names for:
vdsm-storage vdsm-virt vdsm-network etc
I am thinking of vdsm as a service provider to the engine. Today it provides a virtualization hypervisor, a storage repository, network configuration services, etc. I think using the word 'provider' is too long (and possibly too vague).
We could just make up something to represent the concept of an endpoint that ovirt-engine uses to get things done. For example, an engine often connects to gears to get things done (but gear is already taken by OpenShift, sadly).
How about ovirt-minion? :) ovirt-target? ovirt-element? ovirt-unit?
Also consider that an abbreviation or acronym is still okay.
Thanks for reading to the bottom of my pre-coffee stream of consciousness. Of the alternatives listed below, I'd be inclined to support 'ovirt-host*'.
Current names:
vdsmd supervdsmd vdsm-tool vdsClient (we have also two hosted engine daemons, I don't remember the names)
Here are some options in no particular order to name these components:
Alt 1: ovirt-hypervisor ovirt-hypervisor-helper ovirt-hypervisor-tool ovirt-hyperviosr-cli
Alt 2: ovirt-host ovirt-host-helper ovirt-host-tool ovirt-host-cli
Alt 3: ovirt-agent ovirt-agent-helper ovirt-agent-tool ovirt-agent-cli
Thoughts?
Nir
-- Adam Litke
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
participants (21)
-
Adam Litke -
Dan Kenigsberg -
Eli Mesika -
Ewoud Kohl van Wijngaarden -
Fabian Deutsch -
Francesco Romani -
Greg Sheremeta -
Martin Betak -
Martin Perina -
Martin Polednik -
Martin Sivak -
Michal Skrivanek -
Milan Zamazal -
Nir Soffer -
Oved Ourfali -
Piotr Kliczewski -
Sven Kieske -
Vinzenz Feenstra -
Yaniv Dary -
Yaniv Kaul -
Yedidyah Bar David