I would very much like to see a major overhaul of the deploy pending changes process to be consistent with the published REST API documentation. At the moment it appears that each deploy calls /restarts/commit_and_restart which isn't actually even documented in the REST API doc, and causes the LMI to be restarted (slow) every time.
What is supposed to happen is that you GET /isam/pending_changes to see if anything needs commiting, and if it does then PUT /isam/pending_changes. Then you need to introspect the response, and SELECTIVELY decide what to do next based on the returned result Integer, AND status bitmask.
There may also need to be some state management around remembering the last start time of the LMI and/or runtime to ensure that you wait until restarted services are actually restarted. This is not entirely easy, but when done right things are MUCH faster to configure, and everyone benefits.
I would very much like to see a major overhaul of the deploy pending changes process to be consistent with the published REST API documentation. At the moment it appears that each deploy calls /restarts/commit_and_restart which isn't actually even documented in the REST API doc, and causes the LMI to be restarted (slow) every time.
What is supposed to happen is that you GET /isam/pending_changes to see if anything needs commiting, and if it does then PUT /isam/pending_changes. Then you need to introspect the response, and SELECTIVELY decide what to do next based on the returned result Integer, AND status bitmask.
There may also need to be some state management around remembering the last start time of the LMI and/or runtime to ensure that you wait until restarted services are actually restarted. This is not entirely easy, but when done right things are MUCH faster to configure, and everyone benefits.