On 10/18/2012 08:34 PM, Itamar Heim wrote:
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.
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
- storage core version supported domain formats
- VM core version and supported host capabilites.
- network core and capabilities.
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
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.
I will be sending the proposed solution for it to the list. So we can
discuss it into more details.
Senior Software Engineer
IRC: vfeenstr or evilissimo
vdsm-devel mailing list