New verb proposal: getVersionInfo()


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.


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.


It can be used in the future in *any* VDSM communication that can expose version difference.


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

Reply via email to