…
New verb proposal: getVersionInfo()
Background
Right now VDSM has only one possibility to discover the peer VDSM
version — it is to call getVdsCapabilities(). All would be nice, but the
verb does a lot of stuff, including disk I/O (rpm data query). It is a
serious issue for high-loaded hosts, that can even trigger call timeout.
Rationale
Working in an environment with multiple VDSM versions, it is inevitable
to fall in a simple choice:
* always operate with one API, described once and forever
* use different protocol versions.
It is a common practice to reserve something in a protocol, that will
represent the protocol version. Any protocols w/o version info sooner or
later face the need to guess a version, that is much worse.
On the other hand, involving rpm queries and CPU topology calculation
into the protocol version discovery is an overkill. So the simplest way
is to reserve a new verb for it.
Usecases
It can be used in the future in *any* VDSM communication that can expose
version difference.
Implementation
Obviously, the usage of a new verb in the current release, e.g. RHEV-3.1
can be done only in try/catch way, 'cause RHEV-3.0 does not support it.
But to be able to use it in RHEV-3.2, we should already have it in 3.1.
Even if we will not use it yet, the future usecases are pretty
straightforward.
So pls comment it: http://gerrit.ovirt.org/#/c/8431/
--
Peter V. Saveliev
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
