Maintenance Registry starts among first and reads from disk information about MaintenanceRecords registered earlier.
Other components start after Maintenance and check MM if they should function differently in this mode. If node in MM they register special callback within Maintenance Registry that provides Maintenance Actions to the registry.
After all components are started Maintenance Registry prepares maintenance: checks if user has already fixed issues manually during shut down, prints information about this to log and modifies/deletes Maintenance Records if needed.
When Maintenance is prepared and there are still unresolved MaintenanceRecords Maintenance component starts automatic actions like PDS defragmentation or exposes list of user-triggered actions through CLI/JMX APIs and waits for user commands.

Implementation improvements

With fixed structure of workflow (register records → restart → prepare maintenance → execute maintenance) it is not possible to request new actions when node is in maintenance mode. We could improve this by exploiting InternalSubscriptionProcessor and registering components as listeners for events like "Maintenance Record with ID registered..."
Current implementation lacks validation of Maintenance Records except of basic validation of UUID structure. The problem here is that validation is component-specific and should be implemented by components themselves. If we employ InternalSubscriptionProcessor we could potentially implement validation of MaintenanceRecords in an elegant way: when component is notified about new record it knows how to validate, it validates it and sets specific flag to the record. When MaintenanceProcessor sees that no components have validated next record, it skips it as invalid.

Risks and Assumptions

It is assumed that no major changes are needed in CommandHandler to enable connecting to a particular node (the one in MM).

...