On Thu, Sep 13, 2018 at 10:06 AM Etienne Chauchot <[email protected]> wrote:
> Hi, > Ben, thanks for clarifying. It was indeed a terminology misunderstanding > > Le mercredi 12 septembre 2018 à 15:10 -0700, Ben Chambers a écrit : > > I think there is a confusion of terminology here. Let me attempt to > clarify as a (mostly) outsider. > > I think that Etienne is correct, in that the SDK harness only reports the > difference associated with a bundle. So, if we have a metric that measures > execution time, the SDK harness reports the time spent executing *that > bundle*. > > > Exactly ! > I first supposed that the metrics value that Robert mentioned was the > whole value at this point of execution. Thus, to compute it the SDK needed > to receive the metric value for previously committed bundles. But I now > think that Robert was referring to the whole (in the sense of an absolute > value and not -x or +x) metric value * for the current bundle*. That way, > the SDK does not need to receive previously committed value, just to > compute the value for the current bundle and send it. > Yep. Sorry for not being as clear, and thanks Ben for seeing this and clarifying. > > It does not need to report the total execution time which would require > knowing the total execution time without that bundle. This would in fact be > nearly impossible -- since multiple bundles may be executed simultaneously > there is no "total execution time without this bundle" available within the > system.. > > > sure > > > Robert is also correct, in that the SDK harness may send a partial diff > based on the current state, when asked to do so. This is important -- if a > bundle were to take 1 hour to complete, do we want the execution time to be > 5 hours (for the entire hour) and then jump to 6 hours, or do we want it to > be able to increase somewhat smoothly during the hour? Supporting a smooth > increase requires being able to send a partial result back -- "if this > bundle were to complete now, here is the diff that would be commited". > > > it makes sense. I agree, having frequent updates avoids the tunnel effect. > > Of course, if a runner uses these partial updates it may need logic to > deal with the case of a partial update from a bundle that has failed, but > that I think that is outside the scope of the original question. Needless > to say, it requires something like a committed value and "tentative" value > reflecting bundles that are in progress.W > > > Maybe the runner will store such values into attempted counters and not > into committed counters ? > Yes. I don't think we've yet fleshed out the counter-retrieval protocols, or requirements on the runner in that regard, but if a runner wants to be able to report committed (or logical) counters it needs to keep these as-yet uncommitted values separate to do the right think in case of failure, retry, etc.
