[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 <alitke at 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 at 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel