On Tue, Sep 08, 2015 at 13:43:09 +0300, Nikolay Shirokovskiy wrote:
Current implementation of 'toURI' migration interfaces does not support all combinations of interface versions and protocol versions. For example 'toURI2' with p2p flag will not migrate if driver supports only v3params proto.
In general, this patch is pretty large and hard to review, I suggest splitting it into a series of several shorter patches. They all need to compile and work, but it shouldn't be too hard in this case.
This is not convinient as drivers that starts to support migration have to manually support older versions of protocol. I guess this should be done in one place, namely here.
Well, the thing is all the code you're changing runs on a *client* and then the appropriate API calls are sent as RPC to a daemon. So just checking what APIs are implemented by the *client's* remote driver to choose what API will be called on the daemon is wrong. The client can be new enough to support all migration APIs while the daemon may be pretty old supporting only a few of them. Thus, for backward compatibility, the client has to either check what API is supported by the daemon (via VIR_DRV_SUPPORTS_FEATURE(..., VIR_DRV_FEATURE_MIGRATION_...)) or it has to be conservative and call the oldest API which supports the parameters passed by the application/user. This approach(namely checking driver capabilities beforehand) is already
On 08.09.2015 15:14, Jiri Denemark wrote: present in code and i dont change it.
Overall, if you see a way to refactor and improve the code so that it's more readable and maintainable, just go ahead, but be careful about this kind of changes in behavior.
Ok. I'll split into a more managable patches.
Jirka