We've discussed the current state of ampinstmgr and that it needs work. Rather than backporting the existing GUI functionality, we decided it best to simplify the codebase by converting the tool to use the existing API which would allow controlling multiple AMP installs from a single server. Below are some of the requirements discussed with the other community contributors:
1) Convert ampinstmgr to an API driven tool mostly
2) Keep current functionality to avoid breaking existing scripts, but will be "use at your own risk" until eventually removed completely
3) Parallel coding new flags that mirror the old
4) Make the GUI more reliable than the CLI since it will be the "source of truth" in the code.
Note: Not all commands will be converted. Starting instances or checking the status will likely remain the same. Commands that create/alter instances are the main focus.
We've discussed the current state of ampinstmgr and that it needs work. Rather than backporting the existing GUI functionality, we decided it best to simplify the codebase by converting the tool to use the existing API which would allow controlling multiple AMP installs from a single server. Below are some of the requirements discussed with the other community contributors:
1) Convert ampinstmgr to an API driven tool mostly 2) Keep current functionality to avoid breaking existing scripts, but will be "use at your own risk" until eventually removed completely 3) Parallel coding new flags that mirror the old 4) Make the GUI more reliable than the CLI since it will be the "source of truth" in the code.
Note: Not all commands will be converted. Starting instances or checking the status will likely remain the same. Commands that create/alter instances are the main focus.