Something like Z22( Z1 | Z23, Z22( Z40, Z5 | Z23 ) )?
|Open||None||T299176 Phase Theta – Root task|
|Resolved||DMartin-WMF||T303345 Function, Implementation, and Tester meta-data is emitted and displayed to users|
|Resolved||DMartin-WMF||T282164 Change the orchestrator to return status tuples with non-metric metadata (success, error list, …)|
|Resolved||DMartin-WMF||T295496 Add warnings to the Z22/Function call result type|
|Resolved||DMartin-WMF||T291136 Migrate orchestrator/evaluator responses to reply with result envelopes including meta-data map type|
|Declined||DVrandecic||T289796 Function model: Create a type for a return value/meta-data blob|
|Resolved||Jdforrester-WMF||T307483 Consider providing a PHP implementation of ZMap for ease of manipulation|
I think we're agree it should happen, but haven't progressed anything. I discussed with Cory yesterday this semi-epic as something we might split off from other "back-end" work and make a project for someone.
Here's a suggestion. The idea is to have some well-known metadata already have specific keys for, and to have the map to add more of those as needed. In the future we can slowly evolve well-known metadata from the Z22K2 metadata map to keys on Z22 itself. Proper keys have the advantage that they have i18n and are easier to access.
- Z22K1: resulting value of the function call
- Z22K2: error value; if an error is returned; if this is not Z21/void then the Z22K1 is undefined and may not be correct
- Z22K3: warnings; if there is a warning it means that something's up, but the Z22K1/result value is still correct and good
- Z22K4: notices; if there is a notice it adds some more metadata to the call (this is to provide more information not captured by the keys), but the Z22K1/result value is still correct and good
- Z22K5: call; the original received call (maybe normalized or canonicalized, but not changed)
- Z22K6: evaluator type; whether this is an orchestrator, cache, or executor (and which language)
- Z22K7: evaluator machine ID; some ID of the VM or machine evaluating the call
- Z22K8: evaluator machine version; some way to identify the version of the machine, e.g. the git version or the machine config git version
- Z22K9: trace; see below
- Z22K10: timestamp at call; timestamp when the call was received
- Z22K11: timestamp at answer; timestamp when the answer was assembled; after Z22K1 was evaluated
- Z22K12: processing time; wall time used to evaluate the answer; in the best case this is just K11-K10, but in case there was a queue and processing didn't start right away, this would be shorter
- Z22K13: memory; maximal memory usage on this machine
- Z22K14: accumulated real memory; add up all the K14 from all initiated sub calls plus Z13 of this call
- Z22K15: accumulated nominal memory; add up all the K15 from all initiated sub calls plus Z13 of this call (nominal counts cached cost at full cost instead of just the retrieving the cache cost)
- Z22K16: CPU cost; processing cost on this machine, usually add up time use on each core times the power of the machine
- Z22K17: accumulated real CPU; add up all the K17 from all initiated sub calls plus Z16 of this call
- Z22K18: accumulated nominal CPU; add up all the K17 from all initiated sub calls plus Z16 of this call (nominal counts cached cost at full cost instead of just the retrieving the cache cost)
Trace: the trace is the enriched call. If the machine is a cache, then we get the cached trace.
- If this is a cache, this is the cached trace.
- If this is an executor, this is the actual code that has been run by this executor
- If this is an orchestrator, return the Z7s in the call replaced by their Z22s, if they were replaced