Charmed MongoDB Explanation | Advanced Statuses

charm
,
1

MongoDB Advanced Statuses

MongoDB charms leverages Advanced Statuses to expose complex, per component statuses. This interface allows for more complex statuses, multiple statuses but comes with more complexity.

Advanced Statuses: basics

Advanced Statuses are implemented in the homebrewed Data Platform Helpers library.

Each component of the charm recomputes its statuses on every status-update event, and will sort the statuses by order of importance.

They are first order like ops does: Error > Blocked > Maintenance > Waiting > Active > Unknown and then by component priority for an equal status level.

If multiple important (understand Blocked, Maintenance or Waiting) are reported, a special status is computed. This status has the priority of the most important status, and its message is the following:

"<status message>. Run `status-detail`: X action required; Y additional statuses")

Due to the extended structure of the advanced statuses, their bear more information than regular statuses, meaning that developers can provide hints to the operator: there’s an action to run to solve a status, and also which check lead this status to be computed.

Statuses can be set as critical so that they override the regular flow and are displayed no matter what happens since they require immediate action.

Advanced Statuses: status-detail action

The status-detail action is a helper that provides extended access to the charm statuses. Running it will display all the app statuses and the unit statuses. This action comes with an optional argument recompute that allows for status recomputation: unit statuses on non-leader units and all statuses on leader units.

App:
+------------+----------------+---------+---------+--------+
| Status     | Component Name | Message | Action  | Reason |
+------------+----------------+---------+---------+--------+
| Blocked    | <component 1>  | <...>   | <...>   | <...>  |
| Blocked    | <component 2>  | <...>   | <...>   | <...>  |
| Maintence  | <component 3>  | <...>   | <...>   | <...>  |
| Waiting    | <component 1>  | <...>   | <...>   | <...>  |
+------------+----------------+---------+---------+--------+


Unit:
+------------+----------------+---------+---------+--------+
| Status     | Component Name | Message | Action  | Reason |
+------------+----------------+---------+---------+--------+
| Blocked    | <component 1>  | <...>   | <...>   | <...>  |
| Blocked    | <component 2>  | <...>   | <...>   | <...>  |
| Maintenance| <component 3>  | <...>   | <...>   | <...>  |
| Waiting    | <component 1>  | <...>   | <...>   | <...>  |
| Active     | <component 4>  | <...>   | <...>   | <...>  |
+------------+----------------+---------+---------+--------+

json-output: ...

The json-output is provided to have parseable statuses for automation.

For developers: Developing with advanced statuses

With advanced statuses, the charm never sets statuses directly but goes through the Data Platform Helpers advanced statuses module.

Documentation is available in the library, but remember the following:

  • Add your statuses to the status collection in single_kernel_mongo/config/statuses.py in the mongo single kernel library
  • Your manager should inherit from ManagerStatusProtocol
  • You should implement the get_statuses(scope, recompute) method in your manager.
  • You should add your manager to the list of managers that report statuses in the adequate operator (MongoDBOperator or MongosOperator)