Monitoring interface

[vinodreddy-g]

No description provided.

[TWilhelmV]

Hi @vinodreddy-g thanks for the draft. I think it illustrates what shall be achieved.

I have some thoughts for your consideration:

• Are there multiple instances of LogicalFlowSupervisors and TimeConstraintMonitors?
• if not: enable() and disable(): Do they enable/disable all monitoring of the application?
• what does a checkpoint_id look like? Where do they come from? How does one identify them when debugging?
• How do reference conditions work? It is implied that inform_linked_conditions does something, but the concept doesn't say what it does (or I am missing this point).
• Can checkpoint_ids be reused? I.e. entry of A = checkpoint 1, exit A = checkpoint 2, entry B = checkpoint 2, exit B = checkpoint 3 to construct longer flows?
• "last_checkpoint" implies some logic based on that. Will you describe that logic? In any case, with the allowed transitions, an oriented graph is being constructed. Is "last_checkpoint" a node in that graph?
• How to go about handling failures ("set status to failure") (note: there also a "state" besides a "status". I'd believe it's the same thing?)?

From the concepts I gather that a heartbeat would only be sent to the Launch Manager, periodically, if the current supervision state/status (see above) is OK.

BR

[vinodreddy-g]

Hi @TWilhelmV thanks for the review. Please check the answers below.

• Are there multiple instances of LogicalFlowSupervisors and TimeConstraintMonitors?
  -- Yes while writing this draft , i assumed it to have multiple instances.

• if not: enable() and disable(): Do they enable/disable all monitoring of the application?
  -- It enables or disables the particular instance.
• what does a checkpoint_id look like? Where do they come from? How does one identify them when debugging?
  -- checkpoint is just a unique identifier, with additonal api's get some info which supervisor instances use it and in which transitions. checkpoint(id) are instantiated by the user or with config.
• How do reference conditions work? It is implied that inform_linked_conditions does something, but the concept doesn't say what it does (or I am missing this point).
  -- I was thinking like condition is a interface(trait in rust) which can be implemented by something like alivesupervision status
  and this is injected into supervisor and linked conditions call them with status as input.
• Can checkpoint_ids be reused? I.e. entry of A = checkpoint 1, exit A = checkpoint 2, entry B = checkpoint 2, exit B = checkpoint 3 to construct longer flows?
  -- Yes checkpoint can be reused
• "last_checkpoint" implies some logic based on that. Will you describe that logic? In any case, with the allowed transitions, an oriented graph is being constructed. Is "last_checkpoint" a node in that graph?
  -- last_checkpoint is last reported checkpoint(node in graph) so see if the next checkpoint when reported is valid transition.
• How to go about handling failures ("set status to failure") (note: there also a "state" besides a "status". I'd believe it's the same thing?)?
  -- status here is if the supervision is ok ,failed , disabled etc is same as state of supervisor instance.We could still have a component state kind of thing to filter like if this transition is allowed in this state.
  From the concepts I gather that a heartbeat would only be sent to the Launch Manager, periodically, if the current supervision state/status (see above) is OK.
  -- when there is failure , it could call inform_linked_conditions (status) and pass status it could update alivesupervision failed to not send heartbeat .

-- Just a draft but this was the thinking when doing it.

[github-actions]

The created documentation from the pull request is available at: docu-html