11:34 a.m.
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(a)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(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
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel