I don't see how pyinotify is even related to storage stats.
It doesn't work with NFS and is a bit flaky when it comes to VFSs like proc or
Also it doesn't check liveness or latency so the events don't really give us
The data is being taken from cache. I assume there is a prepare call there that
makes everything slower.
This will only be fixed with new style domains that don't have a built in
----- Original Message -----
> From: "Vinzenz Feenstra" <vfeen...@redhat.com>
> To: "Itamar Heim" <ih...@redhat.com>
> Cc: "Saggi Mizrahi" <smizr...@redhat.com>, "Michal Skrivanek"
> Sent: Thursday, October 18, 2012 3:15:47 PM
> Subject: Re: [vdsm] new API verb: getVersionInfo()
> 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
> what I have seen so far.
> I am currently working on a PoC implementation for caching packages
> 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