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