On Thu, Jan 28, 2016 at 10:16 AM, Martin Polednik <mpolednik@redhat.com> wrote:
On 27/01/16 09:53 +0200, Nir Soffer wrote:
On Wed, Jan 27, 2016 at 9:29 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Jan 26, 2016 at 7:26 PM, Nir Soffer <nsoffer@redhat.com> 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:
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
This might cause confusion with node.
Alt 2:
Not sure it's that important. Still, how about:
ovirt-host
ovirt-hostd
I like this
ovirt-host-helper
ovirt-priv-hostd
How about ovirt-privd?
I like short names.
ovirt-host-tool
ovirt-hostd-tool
ovirt-host-cli
ovirt-hostd-cli
I think we should use the example of systemd:
systemd systemctl
So ovirt-hostd, ovirt-hostctl ovirt-hostcli
I'd even suggest going simply with ovirtd and ovirtctl (maybe ovirtdctl to differentiate ovirt, ovirtd and ovirt-engine).
I'd definetly not go with plain ovirtd - this is to generic IMHO. ovirthostd might be more suitable …
Names like ovirt-host-agent possibly introduce abbreviation clashes - we would most likely end up abbreviating host-agent to HA and that could be mistaken for high availability in discussions.
… ovirt-host-agent actually sounds pretty good. - fabian
Also we should get rid of '/rhev/' in start of mount points IMO. How about '/var/lib/ovirt-hostd/mounts/' or something like that?
We want to use /run/ovirt-host/storage/ for that, but this is hard change, since it breaks migration to from hosts using different vdsm versions. New vms expect the disks at /rhev/data-center and old vms at /rhev/data-center/
Maybe we can change disks path during migartion on the destination, but migrating vms to older hosts will be impossible, as the vdsm on the older machine does not support such manipulation.
Nir _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Fabian Deutsch <fdeutsch@redhat.com> RHEV Hypervisor Red Hat