| 2016-10-12 13:38:50 |
Yuriy Zveryanskyy |
description |
Currently if automatic cleaning disabled node does quickly transition via CLEANING state. If API "get node" request comes at this moment it shows wrong state. Node provision state notifications should follow FSM logic and to be consistently with DB states. Therefore two messages (start, end) will be issued in this case. If a service collects nodes states history based on notifications, operator always will see transitions related to automatic cleaning in the results, even it disabled on the cluster. This also causes two non needed updates on services like Searchlight. Proposal: add new FSM event "skip" that changes state directly to AVAILABLE, two new FSM transitions related to automatic cleaning with this event. Add logic based on existing config option that enables/disables automatic cleaning and new event to conductor manager. |
Currently if automatic cleaning disabled node does quickly transition via CLEANING state. If API "get node" request comes at this moment it shows wrong state. Node provision state notifications should follow FSM logic and to be consistently with DB states. Therefore two messages (start, end) will be issued in this case. If a service collects nodes states history based on notifications, operator always will see transitions related to automatic cleaning in the results, even it disabled on the cluster. This also causes two non needed updates on services like Searchlight. Proposal: add new FSM event "skip" that changes state directly to AVAILABLE, two new FSM transitions related to automatic cleaning with this event:
add_transition(MANAGEABLE, AVAILABLE, 'skip')
add_transition(DELETING, AVAILABLE, 'skip')
Add logic based on existing config option that enables/disables automatic cleaning and new event to conductor manager. |
|
