On Sun, Mar 17, 2013 at 10:28:15AM -0400, Ayal Baron wrote:
----- Original Message -----
> On 17/03/13 15:13, Ayal Baron wrote:
> >
> > ----- Original Message -----
> >> On 03/13/2013 11:55 PM, Ayal Baron wrote:
> >> ...
> >>>>>> The only reason we have this problem is because there is
this
> >>>>>> thing against making multiple calls.
> >>>>>>
> >>>>>> Just split it up.
> >>>>>> getVmRuntimeStats() - transient things like mem and cpu%
> >>>>>> getVmInformation() - (semi)static things like
disk\networking
> >>>>>> layout
> >>>>>> etc.
> >>>>>> Each updated at different intervals.
> >>>>> +1 on splitting the data up into 2 separate API calls.
> >>>>> You could potentially add a checksum (md5, or any other way)
of
> >>>>> the
> >>>>> "static" data to getVmRuntimeStats and not bother
even with
> >>>>> polling
> >>>>> the VmInformation if this hasn't changed. Then you could
poll
> >>>>> as
> >>>>> often as you'd like the stats and immediately see if you
also
> >>>>> need
> >>>>> to retrieve VmInfo or not (you rarely would).
> >>>> +1 To Ayal's suggestion
> >>>> except that instead of the engine hashing the data VDSM sends
> >>>> the
> >>>> key which is opaque to the engine.
> >>>> This can be a local timestap or a generation number.
> >>> Of course vdsm does the hash, otherwise you'd need to pass all
> >>> the
> >>> data to engine which would beat the purpose.
> >> I thought you meant engine will be sending the hash of previous
> >> requests
> >> per VM to vdsm, then vdsm will reply back with vm's removed, vm's
> >> added,
> >> and the details for vm's that changed (i.e., engine would be doing
> >> something like if-modified-since-checksum per vm).
> >> benefit is reducing a round trip.
> >> but first would need to split to calls of stats (always changing)
> >> and
> >> slowly/never changing data.
> > If vdms accepts the hash then in your method engine would have to
> > periodically call getVmInfo(hash).
> > What I was suggesting is that getVmStats would return vmInfo hash
> > so that we could avoid calling getVmInfo altogether.
> > The stats *always* change so there is no need for checking if that
> > info has changed.
> > What we could do is avoid the split into 2 verbs by calling
> > getVmStats(hash) and then have getVmStats return everything if the
> > hash has changed or only the stats if it hasn't. This would be
> > the least number of roundtrips and avoid the split. If you don't
> > pass a hash it would return everything so this way it's also fully
> > backward compatible.
>
> For the 'static' data, why is there a need for a hash?
> If VDSM sends in each update a timestamp, can't RHEVM just use
> if-modified-since with the last timestamp it got from VDSM?
> Is it cheaper for VDSM to calculate the hash, than update the
> timestamp
> per change in any of the fields? It doesn't really need to update the
> timestamp per change, only for the first change since last update
> sent
> actually (so 'dirty' flag in a way, to signify data that RHEVM hasn't
> seen yet).
> Y.
As Saggi mentioned: "VDSM sends the key which is opaque to the engine. This can be a
local timestap or a generation number."
The content doesn't matter, what matters is that it has changed.
timestamp assumes that vdsm will track changes and send only delta.
Although possible this would be an overkill (for every value in the
dict you'd have to hold a timestamp of last change and send only those
which have changed since the timestamp which was passed by the user).
If we're in the spirit of quoting Saggi, this suggestion is not
compatible with "...mak[ing] the return value differ according to input
... is a big no no when talking about type safe APIs.".
Dan.