6:29 p.m.
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(a)redhat.com
IRC : ydary
6:41 p.m.
+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(a)redhat.com>
To: "devel" <devel(a)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(a)redhat.com IRC : ydary
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
6:47 p.m.
----- Original Message -----
From: "Martin Betak" <mbetak(a)redhat.com>
To: "Yaniv Dary" <ydary(a)redhat.com>
Cc: "devel" <devel(a)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(a)redhat.com>
> To: "devel" <devel(a)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(a)redhat.com IRC : ydary
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
6:55 p.m.
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(a)redhat.com
IRC : ydary
On Tue, Jan 26, 2016 at 5:47 PM, Martin Perina <mperina(a)redhat.com> wrote:
----- Original Message -----
> From: "Martin Betak" <mbetak(a)redhat.com>
> To: "Yaniv Dary" <ydary(a)redhat.com>
> Cc: "devel" <devel(a)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(a)redhat.com>
> > To: "devel" <devel(a)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(a)redhat.com IRC : ydary
> >
> > _______________________________________________
> > Devel mailing list
> > Devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
6:58 p.m.
----- Original Message -----
From: "Yaniv Dary" <ydary(a)redhat.com>
To: "Martin Perina" <mperina(a)redhat.com>
Cc: "Martin Betak" <mbetak(a)redhat.com>, "devel"
<devel(a)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(a)redhat.com
IRC : ydary
On Tue, Jan 26, 2016 at 5:47 PM, Martin Perina <mperina(a)redhat.com> wrote:
>
>
> ----- Original Message -----
> > From: "Martin Betak" <mbetak(a)redhat.com>
> > To: "Yaniv Dary" <ydary(a)redhat.com>
> > Cc: "devel" <devel(a)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(a)redhat.com>
> > > To: "devel" <devel(a)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(a)redhat.com IRC : ydary
> > >
> > > _______________________________________________
> > > Devel mailing list
> > > Devel(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/devel
> > _______________________________________________
> > Devel mailing list
> > Devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> >
>
8 p.m.
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
9:13 p.m.
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(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
5:57 p.m.
--Apple-Mail=_ACF5413A-13CC-4346-8896-6D8417D816A9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
On 26 Jan 2016, at 19:13, Oved Ourfali <oourfali(a)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 =
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
+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)
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(a)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 =
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(a)ovirt.org <mailto:Devel@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/devel =
<http://lists.ovirt.org/mailman/listinfo/devel>
>
>
_______________________________________________
Devel mailing list
Devel(a)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(a)redhat.com</a>&gt;=
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(a)redhat.com</a>&gt; 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.h... =
class=3D"">http://lists.ovirt.org/pipermail/devel/2016-Janua...
</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(a)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<... =
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(a)ovirt.org</a><br =
class=3D"">http://lists.ovirt.org/mailman/listinfo/devel<...
</div><br class=3D""></body></html>=
--Apple-Mail=_ACF5413A-13CC-4346-8896-6D8417D816A9--
5:59 p.m.
----- Original Message -----
From: "Michal Skrivanek"
<michal.skrivanek(a)redhat.com>
To: "Oved Ourfali" <oourfali(a)redhat.com>
Cc: "devel" <devel(a)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(a)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
1:06 p.m.
----- Original Message -----
From: "Michal Skrivanek"
<michal.skrivanek(a)redhat.com>
To: "Oved Ourfali" <oourfali(a)redhat.com>
Cc: "devel" <devel(a)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(a)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(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
1:09 a.m.
On Thu, Jan 28, 2016 at 9:57 AM, Michal Skrivanek
<michal.skrivanek(a)redhat.com> wrote:
On 26 Jan 2016, at 19:13, Oved Ourfali <oourfali(a)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(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme(a)redhat.com
919-741-4016
8 p.m.
On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary(a)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(a)redhat.com
IRC : ydary
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
8:06 p.m.
--Apple-Mail=_CE5A1836-BEF3-4477-A1C8-8A1236EEFA42
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Jan 26, 2016, at 6:00 PM, Nir Soffer <nsoffer(a)redhat.com>
wrote:
=20
On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary(a)redhat.com =
<mailto: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..
=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
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(a)redhat.com
> IRC : ydary
>=20
>=20
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)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(a)redhat.com</a>&gt; =
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(a)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(a)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(a)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(a)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<...
uote></div><br class=3D""></body></html>=
--Apple-Mail=_CE5A1836-BEF3-4477-A1C8-8A1236EEFA42--
8:07 p.m.
--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--
8:26 p.m.
On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary(a)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
9:27 p.m.
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(a)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.
10:29 a.m.
On Tue, Jan 26, 2016 at 7:26 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary(a)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
10:53 a.m.
On Wed, Jan 27, 2016 at 9:29 AM, Yedidyah Bar David <didi(a)redhat.com> wrote:
On Tue, Jan 26, 2016 at 7:26 PM, Nir Soffer
<nsoffer(a)redhat.com> wrote:
> On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary(a)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
6:30 p.m.
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.
12:16 p.m.
On 27/01/16 09:53 +0200, Nir Soffer wrote:
On Wed, Jan 27, 2016 at 9:29 AM, Yedidyah Bar David
<didi(a)redhat.com> wrote:
> On Tue, Jan 26, 2016 at 7:26 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
>> On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
12:30 p.m.
On Thu, Jan 28, 2016 at 10:16 AM, Martin Polednik <mpolednik(a)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(a)redhat.com>
> wrote:
>>
>> On Tue, Jan 26, 2016 at 7:26 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
>>>
>>> On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--
Fabian Deutsch <fdeutsch(a)redhat.com>
RHEV Hypervisor
Red Hat
12:36 p.m.
On Thu, Jan 28, 2016 at 11:16 AM, Martin Polednik <mpolednik(a)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(a)redhat.com>
> wrote:
>
>> On Tue, Jan 26, 2016 at 7:26 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
>>
>>> On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
11:02 a.m.
On 26/01/16 19:26 +0200, Nir Soffer wrote:
On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary(a)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
11:34 a.m.
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(a)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(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
3215
days inactive
3222
days old
24 comments
21 participants
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