Thanks for posting your idea on the list here. I like the idea of a more
fine-grained version query API. getVdsCapabilities has become too much of a
catch-all and I agree that something lighter is useful. I do think vdsm will
want to add a real capabilities mechanism and it could probably go here as well.
As we work to make the vdsm API evolve in a stable, compatible manner,
capabilities/feature-bits will come into play. Since you're proposing a
structure return value, we can easily add the capabilities field to it in a
future release, but it might make sense to have it there now to reduce
client-side complexity of figuring out if the return value has a capabilities
item.
To avoid the bloat that we have with the current getVdsCapabilities API, I
propose a simple format for the new capabilities:
{'enum': 'Capabilities',
'data': ['StorageDomain_30', 'StorageDomain_22', 'Sanlock', ...]}
and then add the following to the return type for your new API:
'capabilities': ['Capabilities']
This is essentially an expandable bitmask of features where a feature is present
by its presense in the 'capabilities' array. This will be extensible by simply
adding new capabilities to the enum as we find them to be necessary.
Thoughts on this? The reason I am bringing it up now is it would be nice to
restrict the pain of migrating to this new version API to just one time.
On Wed, Oct 17, 2012 at 01:37:08PM +0200, Peter V. Saveliev wrote:
> …
>
> 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
--
Adam Litke <a...@us.ibm.com>
IBM Linux Technology Center
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
