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