.. _UC10:

Use Case 10 - MN Status Reports
-------------------------------

.. index:: Use Case 10, UC10, MN Status, status, health

Revisions
  View document revision history_.

Goal 
  Coordinating Node checks "liveness" of all Member Nodes - checks ping,
  service x, load, space, bandwidth, transaction rate, ...

Summary 
  As part of the infrastructure monitoring process, a CN checks on the
  "liveness" of all Member Nodes. This operation will be performed with moderate
  frequency (perhaps in the order of once every few minutes). The "lite" version
  of this use case, implemented for V0.3, is a simple ping to each Member Node.
  Later, more in-depth status information will be retrieved from Member Nodes
  using the ``MN_health.getStatus()`` method.

  The responses from the MNs should report sufficient metrics to gauge their
  performance in absolute terms and also relative to other MNs. See
  ``MN_health.getStatus()`` for those metrics.


Actors
  CN, MN

Preconditions 
  - CNs are operational

  - MN is registered

Triggers
  - Timed interval

  - Registration change (not for V0.3)

Post Conditions
  - Status metadata is updated at CNs


.. 
   @startuml images/10_seq.png
   actor Admin
   participant "Admin" as app_admin << Application >>
   Admin -> app_admin: login()
   participant "State of Health API" as c_health << Coordinating Node >>
   participant "State of Health API" as m_health << Member Node >>
   app_admin -> c_health: generateReport(token)
   loop for each MN
     alt V0.3
       c_health -> m_health: ping()
       m_health --> c_health: PingResponse
     else after V0.3
       c_health -> m_health: getStatus(token)
       m_health --> c_health: StatusResponse
     end
   end
   note right of c_health
     internal process, 
     not in the CN API
   end note
   c_health -> c_health: processStatusReports() 
   c_health --> app_admin: statusReport
   @enduml

.. image:: images/10_seq.png

*Figure 1.* Interactions for use case 10. These interactions describe a
synchronous process for generating a report. Most likely, a better mechanism
would be for a background process to be accumulating the necessary statistics
from Member Nodes, then the generateReport function would operate on the
accumulated data rather than forcing a fresh copy.


.. _history: https://redmine.dataone.org/projects/d1/repository/changes/documents/Projects/cicore/architecture/api-documentation/source/design/UseCases/10_uc.txt