On 10/18/2012 08:34 PM, Itamar Heim wrote:
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.
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.
Well this is what it should do but it still doesn't do it. At least from what I have seen so far. I am currently working on a PoC implementation for caching packages and having so pyinotify based trigger for refreshing the cache. I plan to really cache everything and we'll have a background thread running for updating the cached data on changes.

I will be sending the proposed solution for it to the list. So we can discuss it into more details.


Vinzenz Feenstra
Senior Software Engineer
IRC: vfeenstr or evilissimo

vdsm-devel mailing list

Reply via email to