On 10/18/2012 06:03 PM, Saggi Mizrahi wrote:
currently getVdsCaps() does a lot of unrelated things most of them have no 
relation to capabilites.
This was done because of HTTP overhead. Instead of calling multiple commands we 
will call one that does everything.

I agree with the suggestion that getVdsCaps() will actually return the 
Capabilities being:
- storage core version supported domain formats
- VM core version and supported host capabilites.
- network core and capabilities.
- etc...

These all should be mostly static and set at boot.

As to the query API. I personally dislike the idea of a "bag" API. Now that we 
are moving away from HTTP, call overhead is no longer an issue so we can have multiple 
verbs and call them sequentially. In actuality we already do. Internally getVdsCaps() 
just aggregates other APIs.
This makes return values of the method easier to handle and makes changing the 
results of an API call not affect users that don't care about that change.
This also has better performance as storage APIs tend to slow the response and 
sending multiple commands would mean that you can get the Network stats even 
though the storage server is down.

i thought getVdsCaps return the storage results from cache, which is refreshed by another thread, to make sure getVdsCaps has no latency.
vdsm-devel mailing list

Reply via email to