Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Greg Sheremeta]

On Thu, Jan 28, 2016 at 9:57 AM, Michal Skrivanek
 wrote:
>
> On 26 Jan 2016, at 19:13, Oved Ourfali  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"  wrote:
>>
>> Hi,
>>
>> name change might be considered, but I do not think it will make a big
>> difference. People do not see vdsm too often (installed by host
>> deploy, managed by engine..).
>>
>>
>> But trying to make sure that (all?) component versions in a project
>> are the same is not a good idea if you ask me. You are not going to
>> rebuild everything when a hot fix is needed, but granted, you might
>> use minor numbers so the versions will at least start with the same
>> numbers. Or will we force a version bump and rebuild to unchanged
>> component, when others were updated for a given release? (we have
>> components like that - ovirt-scheduler-proxy for example)
>>
>> Engine does not depend on an exact vdsm version, we have gradual
>> feature degradation built in in form of capabilities, machine type and
>> cluster levels so it should be totally up to the user what version of
>> vdsm is used. The same we do not control libvirt or kernel. Some of
>> the components (at least on my side) are completely usable without
>> oVirt and when oVirt is released it just gets the latest stable bits
>> available.
>>
>> Why don't we treat oVirt as a package distribution it is? The long
>> term plan still is to break the monoliths (like vdsm or engine) and
>> the possibly new teams (or community) might have different needs.. we
>> might even want to promote reuse of some of the components (like [2])
>> in oVirt unrelated way and I would really love to see that kind of
>> adoption. We are trying to keep so much control that we are an open
>> project, but not a community one (where the community can influence
>> future plans, release schedules, workflows or processes).
>>
>> Neither Fedora, nor RHEL (Debian, ..) try to control the version of
>> components. They depend purely on package dependencies and separate
>> component development from distribution compose processes (something
>> we lack..). Even OpenStack abandoned the unified versioning last year
>> (at least partially) [1]. We decided to use similar age based
>> versioning like described in [1] when I was still part of the Anaconda
>> team and it worked perfectly fine.
>>
>> I really wish we would loosen the project coupling (and processes)
>> instead of tightening it. Sadly everything we have done lately is
>> going in the tightening direction...
>>
>>
>>
>> TL;DR: Please let us use whatever versions of packages we want,
>> release as often as we want and just take the latest bits to compose
>> the oVirt distribution. Most of the components we have handle that
>> just fine.
>>
>> [1] OpenStack versioning plans: http://ttx.re/new-versioning.html (and
>> please pay particular attention to the last section and especially the
>> last two paragraphs in it)
>> [2] There was a thread about vdsm RPMs being too granular:
>> http://lists.ovirt.org/pipermail/devel/2016-January/012185.html
>>
>> --
>> Martin Sivak
>> oVirt / SLA
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel



-- 
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gsher...@redhat.com
919-741-4016
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Eli Mesika]

- Original Message -
> From: "Michal Skrivanek" 
> To: "Oved Ourfali" 
> Cc: "devel" 
> 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 < oourf...@redhat.com > wrote:
> 
> 
> 
> I must agree with Martin here.
> In addition, I think the benefit here is low, and the efforts it will require
> and the risks are high. Upgrade issues? Compatibility ones? Effect on engine
> features such as host upgrade manager, different provisioning products that
> might rely on that such as puppet recipes, ansible modules, or others..
> (can't say all mentioned stuff are relevant, and I guess there might be more
> implications than I've described).
> 
> IMHO, we should spend our time improving our project rather than spend a lot
> of developers, testers and integration people on these kind of tasks.
> 
> +1

+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" < msi...@redhat.com > wrote:
> > 
> > Hi,
> > 
> > name change might be considered, but I do not think it will make a big
> > difference. People do not see vdsm too often (installed by host
> > deploy, managed by engine..).
> > 
> > 
> > But trying to make sure that (all?) component versions in a project
> > are the same is not a good idea if you ask me. You are not going to
> > rebuild everything when a hot fix is needed, but granted, you might
> > use minor numbers so the versions will at least start with the same
> > numbers. Or will we force a version bump and rebuild to unchanged
> > component, when others were updated for a given release? (we have
> > components like that - ovirt-scheduler-proxy for example)
> > 
> > Engine does not depend on an exact vdsm version, we have gradual
> > feature degradation built in in form of capabilities, machine type and
> > cluster levels so it should be totally up to the user what version of
> > vdsm is used. The same we do not control libvirt or kernel. Some of
> > the components (at least on my side) are completely usable without
> > oVirt and when oVirt is released it just gets the latest stable bits
> > available.
> > 
> > Why don't we treat oVirt as a package distribution it is? The long
> > term plan still is to break the monoliths (like vdsm or engine) and
> > the possibly new teams (or community) might have different needs.. we
> > might even want to promote reuse of some of the components (like [2])
> > in oVirt unrelated way and I would really love to see that kind of
> > adoption. We are trying to keep so much control that we are an open
> > project, but not a community one (where the community can influence
> > future plans, release schedules, workflows or processes).
> > 
> > Neither Fedora, nor RHEL (Debian, ..) try to control the version of
> > components. They depend purely on package dependencies and separate
> > component development from distribution compose processes (something
> > we lack..). Even OpenStack abandoned the unified versioning last year
> > (at least partially) [1]. We decided to use similar age based
> > versioning like described in [1] when I was still part of the Anaconda
> > team and it worked perfectly fine.
> > 
> > I really wish we would loosen the project coupling (and processes)
> > instead of tightening it. Sadly everything we have done lately is
> > going in the tightening direction...
> > 
> > 
> > 
> > TL;DR: Please let us use whatever versions of packages we want,
> > release as often as we want and just take the latest bits to compose
> > the oVirt distribution. Most of the components we have handle that
> > just fine.
> > 
> > [1] OpenStack versioning plans: http://ttx.re/new-versioning.html (and
> > please pay particular attention to the last section and especially the
> > last two paragraphs in it)
> > [2] There was a thread about vdsm RPMs being too granular:
> > http://lists.ovirt.org/pipermail/devel/2016-January/012185.html
> > 
> > --
> > Martin Sivak
> > oVirt / SLA
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> > 
> > 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> 
> 
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Francesco Romani]

- Original Message -
> From: "Michal Skrivanek" 
> To: "Oved Ourfali" 
> Cc: "devel" 
> 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 < oourf...@redhat.com > wrote:
> I must agree with Martin here.
> In addition, I think the benefit here is low, and the efforts it will require
> and the risks are high. Upgrade issues? Compatibility ones? Effect on engine
> features such as host upgrade manager, different provisioning products that
> might rely on that such as puppet recipes, ansible modules, or others..
> (can't say all mentioned stuff are relevant, and I guess there might be more
> implications than I've described).
> 
> IMHO, we should spend our time improving our project rather than spend a lot
> of developers, testers and integration people on these kind of tasks.
> 
> +1
> I like vdsm.
> any variant with “agent” brings confusion with guest agent (let alone the
> fact we have three of them)

then maybe ovirt-vdsmd? :)


-- 
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Michal Skrivanek]

> On 26 Jan 2016, at 19:13, Oved Ourfali  wrote:
> 
> I must agree with Martin here. 
> In addition, I think the benefit here is low, and the efforts it will require 
> and the risks are high. Upgrade issues? Compatibility ones? Effect on engine 
> features such as host upgrade manager, different provisioning products that 
> might rely on that such as puppet recipes, ansible modules, or others.. 
> (can't say all mentioned stuff are relevant, and I guess there might be more 
> implications than I've described).
> 
> IMHO, we should spend our time improving our project rather than spend a lot 
> of developers, testers and integration people on these kind of tasks.
> 

+1
I like vdsm. 
any variant with “agent” brings confusion with guest agent (let alone the fact 
we have three of them)

> In addition, bootstrapping of hosts doesn't require manual installation of 
> VDSM, and as of 3.6 neither does upgrade, so most users shouldn't know and 
> care what VDSM is.
> 
> Regards, 
> Oved 
> 
> On Jan 26, 2016 7:00 PM, "Martin Sivak"  > 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

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Yaniv Kaul]

On Thu, Jan 28, 2016 at 11:16 AM, Martin Polednik 
wrote:

> On 27/01/16 09:53 +0200, Nir Soffer wrote:
>
>> On Wed, Jan 27, 2016 at 9:29 AM, Yedidyah Bar David 
>> wrote:
>>
>>> On Tue, Jan 26, 2016 at 7:26 PM, Nir Soffer  wrote:
>>>
 On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary  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
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Fabian Deutsch]

On Thu, Jan 28, 2016 at 10:16 AM, Martin Polednik  wrote:
> On 27/01/16 09:53 +0200, Nir Soffer wrote:
>>
>> On Wed, Jan 27, 2016 at 9:29 AM, Yedidyah Bar David 
>> wrote:
>>>
>>> On Tue, Jan 26, 2016 at 7:26 PM, Nir Soffer  wrote:

 On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary  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 
RHEV Hypervisor
Red Hat
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Martin Polednik]

On 27/01/16 09:53 +0200, Nir Soffer wrote:

On Wed, Jan 27, 2016 at 9:29 AM, Yedidyah Bar David  wrote:

On Tue, Jan 26, 2016 at 7:26 PM, Nir Soffer  wrote:

On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary  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

___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Dan Kenigsberg]

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.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Piotr Kliczewski]

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  wrote:
> On 26/01/16 19:26 +0200, Nir Soffer wrote:
>>
>> On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary  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
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Adam Litke]

On 26/01/16 19:26 +0200, Nir Soffer wrote:

On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary  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

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Nir Soffer]

On Wed, Jan 27, 2016 at 9:29 AM, Yedidyah Bar David  wrote:
> On Tue, Jan 26, 2016 at 7:26 PM, Nir Soffer  wrote:
>> On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary  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
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Milan Zamazal]

Yedidyah Bar David  writes:

> Also we should get rid of '/rhev/' in start of mount points IMO. How
> about '/var/lib/ovirt-hostd/mounts/' or something like that?

Technical note: It should probably be /var/run/... or /run/...
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Yedidyah Bar David]

On Tue, Jan 26, 2016 at 7:26 PM, Nir Soffer  wrote:
> On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary  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
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Ewoud Kohl van Wijngaarden]

On Tue, Jan 26, 2016 at 07:26:55PM +0200, Nir Soffer wrote:
> On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary  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.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Oved Ourfali]

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"  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

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Nir Soffer]

On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary  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
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Sven Kieske]

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..
> 
> 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?


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.


-- 
Mit freundlichen Grüßen / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +495772 293100
F: +495772 29
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad
Oeynhausen



signature.asc
Description: OpenPGP digital signature
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Vinzenz Feenstra]

> On Jan 26, 2016, at 6:00 PM, Nir Soffer  wrote:
> 
> On Tue, Jan 26, 2016 at 5:29 PM, 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..
> 
> +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.

Might get confused with the ovirt-guest-agent though - I can see already bugs 
being filed in the wrong components due to confusion

> 
> 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: yd...@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 
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Nir Soffer]

On Tue, Jan 26, 2016 at 5:29 PM, 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..

+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: yd...@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

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Martin Sivak]

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

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Martin Betak]

- Original Message -
> From: "Yaniv Dary" 
> To: "Martin Perina" 
> Cc: "Martin Betak" , "devel" 
> 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: yd...@redhat.com
> IRC : ydary
> 
> 
> On Tue, Jan 26, 2016 at 5:47 PM, Martin Perina  wrote:
> 
> >
> >
> > - Original Message -
> > > From: "Martin Betak" 
> > > To: "Yaniv Dary" 
> > > Cc: "devel" 
> > > 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" 
> > > > To: "devel" 
> > > > 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: yd...@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
> > >
> >
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Yaniv Dary]

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: yd...@redhat.com
IRC : ydary


On Tue, Jan 26, 2016 at 5:47 PM, Martin Perina  wrote:

>
>
> - Original Message -
> > From: "Martin Betak" 
> > To: "Yaniv Dary" 
> > Cc: "devel" 
> > 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" 
> > > To: "devel" 
> > > 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: yd...@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
> >
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Martin Betak]

+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" 
> To: "devel" 
> 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: yd...@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

Re: [ovirt-devel] Changing the name of VDSM in oVirt 4.0.

[Martin Perina]

- Original Message -
> From: "Martin Betak" 
> To: "Yaniv Dary" 
> Cc: "devel" 
> 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" 
> > To: "devel" 
> > 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: yd...@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
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel