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