On 26/01/16 19:26 +0200, Nir Soffer wrote:
On Tue, Jan 26, 2016 at 5:29 PM, Yaniv Dary <ydary@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